关于互联网研发管理的追忆
无意之中，突然发现了早些年间一个培训课程后的一篇作业，但貌似没有完结，不知道还能找到最终版否。现在对互联网软件研发管理的认知和之前肯定有了不一样的体会，看看之前写的东西也很有意思的，贴出来缅怀一下，那个年代很流行 “救火英雄” 啊！呵呵～
听完上周末的研发管理讲座后，引发了我对互联网研发管理的一些思考，互联网的研发管理与传统的软件行业研发似乎有许多相似的地方，但也有许多不同的地方。比较明显的一点就是：互联网行业产品研发周期相对比较短，版本迭代发布速度较快，往往几周就会发布一个“新“的产品。
关于迭代速度快的问题，在本次的培训讲座中，老师对该问题有不同的看法：认为我们所说的版本迭代发布速度快，是由于该产品初期设计就存在先天不足的因素，而造成后期维护成本高，也就是传说中的先纵火，再救火，然后再纵火，再救火的恶性循环。造成这种局面的根源主要在于产品初期的需求分析以及概要设计没有预留充分的时间，如果在需求分析以及概要设计阶段上花费更多的时间(占整个项目10%以上)，将会大大缩短编码以及测试/上线的时间，用样也会减轻后期维护的成本。
我认为，互联网行业这种快速迭代的开发方式，也有他存在的道理以及必然性，但确实我们所做的快速迭代发布，有很大一部分是为了“救火“，我们必须要改进，以下是我对互联网产品需要快速迭代发布的理解：
1， 从互联网产品的特性上来说，当前互联网产品主要存在以下几个基本特性：媒体性、 互动性、 应用性。媒体性，互联网就是媒体，这不需要太多的解释，既然具有媒体的特征，那更新的频率必然不可少。互动性，一款产品如果被设计成一个孤岛，那就失去了互联网产品的先天势，互联网产品的设计理念应该是人与人的交流，而非人与机器的交流。互联网可以说已经逐步成为了人类生存的第二世界，而我们就像在这世界里的市政工人一样，需要为用户建造公路、桥梁、房屋。罗马即非一日所成，那我们的产品又怎能一劳永逸呢？！应用性，当前互联网产品正逐步吞噬着桌面应用，以google和微软的市场争夺为例，如果我们不能提前抢占市场的话，必然会丧失许多机会。
2，从产品的发布来说，产品的发布可以由一个或多个迭代组成，如果我们能把优先级别高的，或者从功能上进行拆分，并有计划的进行迭代发布。在产品后续的迭代开发过程中，可以吸收到大量有价值的回馈。这样会有助于一个产品的完善与稳定。也符合现在流行的敏捷式开发过程。
3，从成本上来说，互联网较传统软件行业来说，具有产品发布成本低的特点，互联网产品的发布成本几乎为零，尤其是产品更新升级的成本，我们的用户不需要做任何事情，也不需要为我们软件的升级付出额外的代价(购买介质或者参与升级过程)。我们软件的发布简单到只需系统工程师在服务器上执行一条命令即可以完成。所以快速
4，从技术上来说，互联网产品存活在一个较为复杂的环境中。从网络环境上来说，我们存在着南北分布的问题，再具体到用户的个人网络环境，以及浏览器的配置。任何一个想不到的地方均可能造成用户不能正常使用我们的产品。即使我们在测试阶段尽可能的模拟用户的使用环境，但最终还是会有一些问题不能完全暴露。在这种情况下，快速的迭代发布有助于我们产品的健壮性。
快速的迭代发布，是互联网产品的一项优势，快速迭代发布的根源在于市场对需求的不断变化造成的，这是不可避免的。快速的迭代发布最终是为市场需求服务的。但在我们的开发中，快速的迭代发布有很大一部分是因“救火”而产生的，从表面上看确实起到了不小的作用，但也像本次培训老师所说的一样，这种“救火”英雄还是少一些的为好。产品版本发布的速度很快，但市场的实际需求我们却没能实际解决多少。
我们在开发的过程中，我们经常称自己是快速迭代发布，但最终看起来并没有快多少。大部分时间还是用到“救火”的过程中去了。我认为当前造成这种状况的原因在于，该快的没有快起来，而该慢的没有慢下来。快，是指对市场需求的快速响应，而慢，我指的是对基础应用的研发。
首先从“快”字来分析一下，互联网市场的竞争是与日俱增，如果一款产品不能争得业界头筹，几乎就等于白干了。如果想拿第一，就必须赢得更多的用户，获取更多的PV，产品如果能在一个合适的时间进入市场，我们就有了更多的获胜筹码。一款产品或者说一个项目什么时候上线，取决于众多因素，但最终需要快速响应市场的变化。在这里面，并非所有项目都是研发新的产品，有一部分项目是对现有产品进行整合，实现产品间的互通，或者是对原有功能的升级。然而我们的技术开发团队在响应产品提出的一些看似简单的需求时，往往不能尽如人意。通常不是因为技术上不能实现，而是工期遥遥无期，产品提出一个看似很小的改动，技术团队可能需要花费很长时间去做后台的调整，重构。这反映了我们的一些基础技术还不是很完善，不能提供有效、快速的接口。以至于每次业务上一个微小的变更，都会牵扯到新的一轮技术上的疯狂改造。
什么需要“慢”下来呢，我认为有以下几点非常重要：
1，产品在需求分析、概要设计阶段需要慢下来，要在产品初期的定位与设计上投入更多的时间，这样的好处正如老师所说的，可以降低整体产品研发的时间与成本。避免人力成本的浪费。前期思考多一些，在后期的开发上，往往会少走很多弯路。而我们现在有些情况，像是摸着石头过河，走一步算一步。同时也表现为一个产品没有一个长期的市场规划，对一些项目计划，往往会被市场上其他对手牵着鼻子走，失去了主动出击性。
2, 从技术角度上来说，我们当前所谓的研发，大部分都是建立在一些基础组件基础上的，互联网上的技术创新往往是一些概念的组合。从宏观上来看，以WEB2.0为例，WEB2.0强调的就是用户间的互动，但技术上对WEB2.0的一些支持，早在2000年的时就有人实现了，直道2005年google的gmail产品才让更多的人知道了ajax这种新瓶装旧酒的技术实现方案。从微观上来看，我们现在所做的一些产品，例如邮箱产品、博客、相册，从产品定位上，可以说是完全独立的产品，我们看不到任何相似的地方，但从技术的角度上来看，这些产品某些基础组件、基础的业务逻辑是可以共享的。但现在我想，除了一些开源的软件以外，我们可以共享的组件则是少之又少。每个产品线在紧锣密鼓的开发自己产品的同时，是否想到我们所开发的一些代码，可以被其他产品共享、复用呢？但有时我们的代码开发甚至连自己产品的复用都很难实现。往往因为项目时间紧、任务急，我们无暇考虑这种问题。但如果我们花些时间想想，我们的产品研发，能像汽车装配的流水线一样，按照一定的业务逻辑去组装各种“基础”部件，最后出场一款新汽车。曾经有人说过，如果技术研发能做到，让一个产品人员拖动几下鼠标，做几个页面就能“傻瓜”式的独立完成一款产品的开发，那将是一个何其壮观的场面啊。呵呵，我想我们的技术研发要做到这种地步，现在可能还是痴人说梦。但即使技术研发现在还不能做到这种地步，但我们是否可以先贡献一些“轮子”呢？基础研发就像我们社会的底层建筑，如果底层建筑不完善，动荡不安，那上层的经济体，必然也不能长久。花些时间完善一下我们的基础研发，不仅可以贡献更多的“零件”，同时也可以节约一定的人力开发成本，避免了重复劳动。
总之，互联网产品的快速迭代发布，是一个产品生存，占有市场的需要，但绝不能为了“救火”而迭代，那将会失去快速迭代发布的意义，最终而引火烧身。我们需要静下心来，看看我们需要什么样的基础技术支持，把他做好，做强，这样才能以小步快跑的形式占有更多的市场。以上是我对本次讲座中所提到的快速迭代发布的一些想法，并不成熟，还需日后继续努力思考。