不信任的博弈

很多人在怀念那过去的年代，那个软件英雄的年代：一两个人废寝忘食通宵达旦搞定某一两个关键问题，甚至对交付产生关键作用。最后交付成功了，这些人成为了英雄，在一年一年的口口相传中，成为英雄般的记忆。

说的是十年前的事情。

然而现在英雄越见少了——英雄们逐渐淡出一线开发视野。现在动辄几十人上百人的团队下，英雄的候选们发现他们处于一个相当悲凉的境地：即便有心救国，看着若干年积累出来的代码；或者正在积累中的代码，充满着无力的挫败感。我依然记得在某个项目中，只有20人左右的团队，当发现架构存在问题的时候，却也无法做什么：交付的压力持续不断的增加着，新的方式需要进行花时间验证才能得到证明，于是一方面团队按照旧的方式将代码往上堆，另一方面对此感到痛苦的不断地修改着——这个循环直到项目结束才算真正意义上的结束。

业务团队与开发团队之间的不信任感从此而产生——

为什么这么简单的一个功能要这么久？ 不行，这个功能一定要在某月某日之前出来！ 做不出来，丢了这个客户/市场，你负责吗？！

于是，迫于这种压力，开发团队只好采用更加临时的解决方案来快速解决问题——寄希望于某一天能够有时间把这些问题神奇般的解决——可是这一天从来都没有到来过。一个交付周期过去了，下一个接踵而至，带来更大的挑战——“什么？需要时间重构？没时间啦！这个客户比上一个更重要，一定要做出来啊！”

听到一个很形象的例子。一只蚂蚁只能拉100斤的东西。由于要交付更多的东西，蚂蚁工头对小蚂蚁说，120斤，挑战一下吧。小蚂蚁咬咬牙，挑战了一下。这一下真挑战成功了——120斤成功的拉过去了！然而它自己觉得隐隐作痛——受内伤了，它想歇息一段时间，可是工头说：不错，120斤挑战成功了，这一次我们有更大的挑战，150斤，努力吧！

临时的方案往往带来更多的缺陷。我听说过一些团队为了快速解决某一个问题写了100行的SQL代码——这些SQL代码成为后续维护的噩梦。业务团队发现了这些：虽然这些版本通过加班、通宵能够某种程度上如期交付，但是交付出来质量问题太多——不可接受。但同时要求质量和进度看起来是那么的不可行，于是，为了控制风险，好吧，以后做计划的时候给自己留下余量——不信任的博弈由此开始：

用户说，这个功能我要在2010年10月1日完成。 市场/用户服务部门想了想，说，对开发部门的领导说，这个版本必须在2010年9月10日完成。 开发部门领导想了想，对开发团队说，这个需求非常紧急，这样吧，8月15必须如期交付，否则我们就丢掉了这个客户！

一来二往，双方都清楚了这个游戏规则。然而作为生态链的最底端，开发团队做不了什么——既然整个博弈决定了进度第一，那么质量只好放在那些余量里面了。“先污染，再治理”，所有的临时解决方案被使用——配置文件满天飞，SQL随便写，各式的hack写法，等等等等。到了后期交付的时候，测试问题多多，改吧，加班、通宵改吧。

如果质量不是贯穿在开发过程中，那么通过最终的质检环节来提升质量无疑是低效的。Deming说，”Build Quality in”. 质量是隐含的。形成这个博弈的最大的原因是，从前到后对交付的轻视，对质量的轻视，对于软件演进必要的理解。进度必然是符合质量的功能点的交付，而不是狭隘的代码完成。