聪明人驱动开发

某公司（对，是某公司，这就意味着很多人看到这篇文章可以理直气壮的说，这不是在说我，我们不是某公司，至于到底是谁，可能智者心里最清楚）的几个程序员（记住，这里的程序员是地球上某个地方的人眼中的那些敲代码的）接到了一个项目，要在 3 个月内完成一个一般项目组要半年才能完成的系统。他们除了项目经理口中所描述的客户需求和一份密密麻麻的用户需求规格说明书之外，几乎得不到用户其它的反馈。

项目在一次启动会议上就这样开始了。

接下来就是不计其数（其实再不计其数也超不过 90 次）的加班，他们都很相信自己的实力，也相信时间能够解决一切――因为一天 8 小时工作之余还有其他 16 个小时。临近 3 个月末，程序员们几乎到了崩溃的边缘，但是大家心里都有个信念，那就是坚持过 3 个月就可以解放了，于是肃寂的深夜里他们又精神起来。

3 个月的期限到了，大家终于拿出了一个勉强可以用的系统，虽然仍然漏洞百出， bug 不断，但他们也收获颇丰，无数个临时解决方案、口头协议、与代码脱节的文档、没有注释和缩进的实现、连自己都说不清楚能不能用的代码 … 这一切，他们都有一个共同的理由：时间不多，我们已经顾不得那么多浪费时间的事情了。

但是，正当大家认为可以松一口气并计划周末行程的时候， QA 组却报告了甚至比用户需求还多的问题列表，其中大部分问题都可能会导致系统失败。

而正当大家沮丧且不知所措的时候，项目经理的反应似乎出人意料，在一个漫长的内部评审会上，他平静的做出了项目延期一个月交付的决定。

于是，接下来的一个月大家游走在自己亲手制作的代码迷宫里，过着修改一处 bug 会带来 3 处新问题的日子， 3 个月后可以放松的希望早已消失的无影无踪 … 就这样，大家最终还是用了一个多月的时间把一个补丁摞补丁的系统交付给了客户。

到这里，我们的勇士们似乎虽不完美但也自豪的完成了任务，但事实并不这么让人随心。客户看到系统之后，发现了（这是一定的，系统的问题能欺骗自己但欺骗不了用户）另一批问题，然后是修改、交付、修改交付 … 啊哈，我们的故事又得以重复的继续了 …

这段故事结束已经是将近 7 个月之后的事情了，最终的项目验收会上，程序员们才真正明白客户方其实是计划在 6 个月完成这个项目，而客户为了保证顺利上线，他告诉项目经理需要 4 个半月来完成项目，而项目经理则为自己留出了另 1 个半月的缓冲期，可怜的程序员们只得到了一半的时间来完成这项任务。

到这里，我们好像没看到一个傻子，故事是被一群聪明人驱动着，但事实却似乎并没有偏袒他们，问题出在哪里呢？

怪圈 1 ： 客户认为开发方交付的系统一定是有问题的，所以他必须给自己留出缓冲期来修正这些问题，而缓冲期占用的时间会导致开发方无法交付出高质量的系统。这一怪圈也体现在项目经理身上。

怪圈 2 ： 所有人都是在为了节省时间努力，但最后却比计划用的时间还多――即便是之前已经考虑到了缓冲期。

怪圈 3 ： 贫瘠的沟通和过深的沟通层次导致了双方的不信任，从而使每个人都进入防御状态，而防御状态又进一步阻碍了沟通。

这些大家“耳熟能详”的现象，几乎已经成了业界的杀人灭口必备道具。人们都在很努力寻找各种方法试图摆脱它们，却始终没有走出过这些圈子。

那么针对这几个怪圈我们应该怎么解决呢？

1、    多次交付。  

缓 冲期是降低风险的有效手段，风险又来自于信任度，交付次数太少会使客户无法及时掌握项目情况，影响客户信任度，而信任度不足会导致客户（包括你的上司）为 自己设置缓冲期，从而压缩实际开发时间。因此，用多次交付代替一次交付，可以将风险和误差分摊到每次交付中而不是最终的一次――即便是多次的误差之和要多 于一次交付的，就像人们可以忍受每天班车晚点 2 分钟，也不可忍受它一个月基本不晚点但会有某一天晚点 30 分钟。

2、    有效时间才称为时间。  

怪圈 2 是我们大家常常会走入的误区，认为时间可以以稳定的比率换取价值，但这似乎只是一厢情 愿，不同的任务、不同的开发人员、不同的过程模型，时间与价值的比率是不同的，有的甚至是负值（俗称帮倒忙），再多的时间浪费在比率不高的任务上，只会让 整体速度降低，最终得到时间不够的假象。一般负比率的时间投入有，重复性工作（重复代码、重复过程、翻译代码的文档等等）、误导性工作（错误的注释、脱节 的文档）、资源透支（频繁加班、临时性解决方案、不切实际的进度安排）、过度工作（过度设计、超出需求前提的实现、完美主义） …

3、    现场客户。  

现场客户可以增大客户对项目的了解程度，及时的对需求做出变动，保持项目相关者最及时和畅通的沟通，这样不但可以降低“开发方交付的系统一定有问题”这一想法的出现几率，开发人员也可以得到最直接的反馈和最合适的工期约定。

或许这个故事所暴露的问题不仅仅是这些，但再多的问题也需要正确的方法和大家共同的努力去逐个击破，所以在此抛砖引玉，希望自己的点点想法能为大家带来一些帮助――哪怕是反面教材，也希望给各位看客带来写什么。

哦，对了，故事的结尾应该交待一下最终 BOSS 的情况，虽然不像童话故事那样浪漫，但客户方领导的办公桌上确实放着一份写有“ … 本项目计划在 8 个月的时间内上线运行 … ”的文件。