互联网研发模式考虑（感觉不错，mark一下）

如果要用一种行为来比喻软件的研发过程，那么哪种模式是更现实的模式呢?

　　第一种模式类似于后羿射日，首先他需要瞄准，然后估算提前量，风速，然后凝神发射，一枪致命。这种模式最大的一个问题就是：你不能要求太快，因为你要一枪命中，就必须考虑到全过程中的所有要素;不然这一点是很难达到的。但是他的确很具有观赏性，这种一枪致命，是我们所追求的;他非常类似于在一个良好环境的竞技场上的行为;

　　另外一种模式是类似于坦克遭遇战，如果两个敌对集团的坦克突然发生遭遇战，那么事实上，由于战场上充满着混乱以及各种背景噪声，于是操作人员事实上不会瞄准那么长时间，而是利用坦克的自动校正系统，快速定位目标，先不管如何打一炮出去再说，然后根据弹着点，去调整方向，再快速开炮;一般来说，用3-4炮就可以真正解决调敌人了。因为他是这样一种认同，当敌人发现炮弹落在他身边的时候，他会变得惊恐，而且，虽然有各种自动化瞄准手段的辅助，你还是很难估算所有的要素，去追求一炮命中，而如果打出一炮以后，你实际上是把所有要素合并起来做为一个要素，根据弹着点进行调整就可以了。这将更容易操作。

　　很有趣的两个比喻吧。但是的确很值得我们讨论。

　　在很长的一段时间中，我一直在考虑一种互联网的研发的模式，这是我们经常说的“互联网速度”。在这种研发模式中，开发人员将在整体人员中占有非常高的比重，他们的测试人员甚至只有开发人员1/4，软件的整个研发过程中充满着传统软件过程所认为的愚蠢和混乱的行为，他们总是在软件完成80%的时候，就用Beta或者Demo的形式推向用户(当然，有2个模块是精益求精的，那就是自动升级机制和自我保护机制，但是这两个模块，只要找到2个经验老到的开发人员，他们就能搞定);然后根据用户的反馈和行为，来快速演变成为下一个版本;但是这种战术在互联网应用中很成功。

　　这是为什么呢?

　　我的理解是因为如下的原因：

　　1、互联网的应用是一种直接面向大量最终消费者的应用，事实上，你是无法确切保证自己的研发就是能够让他们满意的;所以，与其在家里不断去猜测他们的喜好，不如快速推出这个平台，通过他们实际的使用去较准方向;想想短信平台吧，当时我们的设想都是错误的，短信平台几乎在一夜间火起来了，虽然短信业务平台事实上在此以前，已经运行了很长时间了。

　　2、在产品的设计理念中，有一个观点认为：你与其不断改变自己的软件，还不如控制用户的行为更为有效。这一点事实上是一个至理名言;至少我这样认为。比如，一个缺乏进度栏显示的系统，将使得用户变得不能容忍略微长一些的时间，他就会认为操作已经彻底失败了;而一个良好地显示了进度条的系统，用户将能够呆更长的时间;我们有过一个案例，一个在线的直播系统，由于事先需要将近20秒的缓冲时间，从而使得用户耐性明显不足――这很容易理解，因为用户傻傻地盯着一个黑屏去看，事实上不知道发生了什么，那么随便哪个用户，实际上都无法忍受――，某一天，那个公司仅仅把下面缓冲的进度用图形化的方式显示给用户看，当天的并发在线用户量提高了3倍。在这种设计理念中，存在一个巨大的问题就是：你如何知道用户的真正的行为?举例来说，一个长达5个步骤的注册过程，做为产品经理，你有没有考虑过，在每个过程中，放弃注册过程的用户量是多少?如果你发现，每多一个页面，将丢失20%左右的用户，你还会采用如此复杂的注册过程，需要用户填写那么多内容吗?如果对这一点没有感触的，我建议你去申请一下Sina的通行证，1年前我为了下载一个软件，不得不注册一个，但是那个注册过程，对于我这样的上网老鸟，都用了20分种的时间(当然，可能我比较笨)，其中充满着种种不理解…… 比如他告诉我：我填写密码问题是错误的，我感觉很困惑，我写的是“what is your name”，请注意，我都不敢用what’s这种带单引号的东西来考察他的系统;结果他告诉我，这还是不行，我极端困惑;最后我把所有的空格全部删除，就通过了。我都快崩溃了，这是什么破烂系统啊……不知道现在有没有改进，反正我是再也没有信心去用了。但是，这种事情有一部分在内部能够解决，一部分我们还是要正视自己的能力，我们不可能考虑到全部的要素，因为事实上你无法分辨，哪些仅仅是你的需求，而哪些是真正用户需要的东西。于是，与其在家里面不断地去考虑什么是好的，不如尽快放出去，同时分析大量的日志，来知道用户是如何使用系统的。日志就是大量用户行为纪录，你通过这些无声的描述，会更好地了解你的系统在如何被客户适用着;

　　3、互联网是一个快速变化的环境，而且事实上，很少有人能够真正看清楚，将来一年将会是什么样子的(如果你有把握自己的每个判断有51%的正确率，你可以每天从华尔街赚取几百万美元)，所以，尽快推出一些想法，让市场去验证这个想法是否成熟，是一个更现实的做法。企图一个人在深山中，苦练10余载，突然憋出一个天下惊讶的东西，然后发生了颠覆性的事情，这是不现实的。更为常见的一个模型是：一个简陋的系统被推出了，虽然他有这个或者那个不足，但是其中的某些点让用户非常欣赏;于是这个简陋的软件快速经过了0.46, 0.47版本的推出，越来越多的从尝试者手中，转移到跟进者，以及保守者手中，这个软件成功了!这是现实，前一个是更多的是武侠小说中的事情;软件行业本身不是一个基础研究类的行业，他依靠就是了解客户的需求，用成熟以及低成本方式，满足客户的要求，帮助客户减轻他的工作量。

　　4、由于以上的一些原因，不要去做庞大的一个软件架构去适应一切东西，因为你根本不知道一切的边界在哪里。能够适应就好了，也许你需要多考虑2步，但是考虑到20步以后，就实在没有太多价值了。围棋高手会考虑10步，是因为和他下棋的人只有一个人，如果他和全世界的人下棋，恐怕他会觉得考虑10步是件不现实的事情吧。

　　这种研发模式还有一些非常有意思的地方：比如这种研发模式一般都是小团队的研发模式，他的核心开发组不会超过10个人，这个核心开发组手中应该有一个随时可以进行试用的一批网络用户，他们将是新的算法或者新的功能的尝试者。他们往往在开发过程中，试用WIKI或者其他方式方便地来更新文档，他们的很多想法是突然冒出来的，然后就是快速的尝试，反馈，通过日志分析，去知道是否这个改动是值得做出的，或者是不值得做出的;如果你一定要他们先写下来这样的设计，或者那样的设计，通盘考虑好了以后，再进行研发，这是他们比较难以接受的，因为他们会告诉你，如果我能够想全这些东西，我早就写完了……其他更多的团队，会汇聚在这个团队边上，做一些研发的外围的工作。

　　我曾经记得有一个产品经理，带了一支10人的团队进行研发;突然有人告诉他，他的竞争对手也开始了这项业务，而且决心很大。这个产品经理有点紧张，问：“他们的核心有多少人?” ，“200人”;于是项目经理放心了，说：“走吧，我们没有任何风险，那200人的核心团队会被陷入在官僚，扯皮和一个复杂庞大的结构中的”。在2-3年以前，我对这句话多少有点不理解，因为我只是模糊地感觉，他也许感受到了另外一些东西，但是他感受的这些东西，对我来说只是似是而非的一种感觉。今天，我能够理解这句话了，他说得是对的。

　　我们面对的是一个快速变化的，而且是越来越快速变化的世界中，小的团队将更容易做出决定;而且在这种变化中，犯错不是一个最大的问题，而企图排斥一切犯错的可能，才是最大的犯错。

　　也许有人会告诉我，这种模式不是普遍适用的。我的结论是：当然是那样的，如果我企图说明这种模式是全行业通用的模式，那么我自己都不能原谅自己这种胡扯的行为。

　　比如很明显的，这不适合做软件外包的公司，因为他们面临的需求是非常明确的;而且设计已经基本上出来了，他们要做的是用最小的风险，最低的成本替用户开发完毕。因为变化的风险已经被限制在合同中了，为什么外包行业中，绝大多数的利润被上层公司垄断了?理由很简单，因为他们承担了风险，而Code风险几乎是所有软件过程风险中最低的风险，于是获得最小的利润也是必然的。

　　比如，这个模式也不完全适用于给指定用户的信息系统的研发(虽然在很大层面上，你还是可以参考这种模式，比如快速的反馈，比如贴近用户的研发模式等等均是这种行为);

　　但是，我认为这种模式会越来越多地适用于我们所作的软件过程中。

　　当然，在以上的描述中，我无意说明，在这样的过程研发中，就不需要进行常规的软件管理。很多人认为这种形态就是无管理;但是我要说的是：他是一种更高形态的管理;举例来说，这种团队一般都具有非常良好的快速集成能力，因为他们很可能要几天就放出一个版本，要他们每次用一周时间来进行集成和发布，不太适合;这种团队一般都具有良好的自动化测试方式，因为快速的集成需要尽量降低软件周期性测试的压力，事无巨细，没有风险评估的全程走Full testing是不适合这样的研发模式的;因为这将导致测试边际成本飞快提升上去(顺便说一句;最差的测试是什么样子的?他们都在想到哪里，测到哪里，最后没有任何报告，没有任何评估，这种测试人员我在国内随便抓就是一大把;比较差的是什么样子的呢?他已经学会了测试管理和规划，但是他不会平衡风险，把他想像的每一个点都进行测试：比如用ADSL接入和美国的宽带接入都进行全部的Full testing，这实际上是一个错误的做法，你需要评估风险和测试成本，测试这种东西，只要你愿意去想，你永远不会结束，你要学会把有限时间投入到最有价值的东西上);他们不见得是一个文档追求者，比如他们从来不会为什么文档模板去买单;A模板和B模板，他们很少会关注，他们只是把困惑自己最长时间的东西拿出来，而那些东西往往是后来者也会最为困惑的东西;他们的文档虽然看起来不专业，但是实际上比较管用，而且是符合现状的;比起那些又臭又长，一个项目上百兆的文档来说，更有价值一些;类似点点滴滴的东西很多很多;

　　用一种更快速，更容易应变的心态和团队去迎接挑战。我们需要克服三点：第一点是所有职业经理人的风险避免的天性;我理解这是一个职业经理人下意识的行为，但是你要知道，如果你不愿意看见任何一点风险，实际上也许你就在风险的中心(因为一个没有风险的领域往往意味着最低收益的领域);第二是要更谦卑一些，承认某些东西是我们不了解的，大量的客户才是我们的老师;第三，在维持良好的客户满意度的基础上，认可一些失误;事实上，某些失误并不可怕，可怕的是大家都害怕失误……

　　可能有可能有人问：

　　如果我把一个不是最完善的系统放出去，那么将引起大量的用户方面发现错误，这不是更高的成本吗?的确是，但是即使你延长再多的内部测试，也无法避免这个问题(甚至也不会有太大层面的改善，因为用户那里总是会出现各种你想像不到的问题);而且，事实上，你需要在处理错误方面掌握一些技巧，比如每周解决最前面的一些问题，但是在解决这个客户的时候，不要考虑单一用户成本;该买花买花，该上门上门，该道歉道歉，因为你解决的是一类问题，赢得了一批用户，而不是一个用户。当你是一个用户，你会更加信赖这个公司，从而更信赖这个软件。

　　最后说一下，这种系统所必须做好的几个点：

　　1. 良好的自我升级机制，这是保证你的客户得到更新的软件和排错的方法;

　　2. 自我的保护机制：总是有一些烂公司或者烂人，会在软件中做一些针对你的软件的事情，所以你需要好好保护一下自己的软件的生存权;

　　3. 良好的用户行为搜集机制：你不可能去看着每一个使用你软件的人，即使是少量用户群的信息系统也不可能，所以，你要纪录用户的行为来分析用户使用习惯;并且根据这些来控制一些用户行为，来提高你的软件的适用性;

　　4. 记住，你不仅仅是在做软件，当你面对的用户量越大，你越是要考虑一些心理学，甚至是经济学的东西。举一个最简单的例子，红绿灯是一个固化的规则，这种规则是有效的;但是在某些时候，这种固化的规则会引起一些不利因素，因为每一个司机都会替自己考虑，所以看见黄灯的时候，即使前面的车已经堵得很利害了，他也会冲过停车线，这样将使得他可能更快一些过这个路口，但是事实上，他将阻碍另外一条车道车辆的行驶，于是两条车道的车就纠缠在一起(结果就是，从全局来看，每个人都那样做，实际上使得每个人通过路口的时间都变长了);这时候更好的做法是，先清理干净这个路口的车辆，然后短期内订下更严厉的规则，派警察疏导就是起到这个作用的。同样，你的软件也需要有一定这样的机制;这一点对于P2P软件来说是关键，但是对于其他软件应该也有部分借鉴作用。这玩意有点深奥，我也不是想得特别明白，也许再过一段时间，我会更清楚一些。现在就这样吧……

　　以上表述的是互联网的一种开发模式，快鱼吃慢鱼，是一个趋势;虽然不能说是一个绝对的模式，但是他的适用面将越来越大。让自己更灵活一些总不是坏事!