不信任的博弈

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

说的是十年前的事情。

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

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

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

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

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

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

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

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

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