聪明人驱动开发

某公司（对，是某公司，这就意味着很多人看到这篇文章可以理直气壮的说，这不是在说我，我们不是某公司，至于到底是谁，可能智者心里最清楚）的几个程序员（记住，这里的程序员是地球上某个地方的人眼中的那些敲代码的）接到了一个项目，要在 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 个月的时间内上线运行 … ”的文件。

评论

9 楼 东吴周郎 2009-12-28  

时间管理很难啊，我们项目延期一天按项目资金的百分比算罚款。时间一紧张，代码就乱了，根本没闲心来雕刻的

8 楼 linpyi 2009-12-28  

这是必须管控的风险.你可以站在客户和项目经理的角度考虑,你也会这么做的.

7 楼 realdah 2009-12-28  

项目时间是最好列清楚的。

各位注意一下，整个项目开发过程当中，coding毕竟只是其中小部分而已。
大部分计划都必须有2到3轮的测试，同时还包括UAT（用户测试）。


如果说时间被每个“聪明”的上司压缩，那出现lz所说的现象是不可避免的。

时间，质量，内容这三者必然要有妥协。 也就是说，如果项目经理无法在协调好这3个方面，那他也是失职的。

在本文当中，因为时间和内容没法妥协，所以代码质量和产品质量就成了牺牲品。 当然，团队士气和名声也被重创。  我想，这是所有所谓“聪明”的上司应该反省的地方。

6 楼 hatedance 2009-12-27  

反过来说，如果真的给你8个月去开发，结果到了那天客户领导发现系统还是有一堆bug，不得不延迟2个月做修补。人是最难管理的。

5 楼 stevezheng 2009-12-27  

我们一直就是这么玩儿的。

提前交付？谁都知道这这事儿扯淡，该什么时候完就什么时候完。

找一个专人配合客户扯好这个蛋就解决了，有必要当真吗？

这不是一个怪圈，只能说项目经理努力的方向错了。

4 楼 shatuo 2009-12-27  

敏捷就是做这些事的，快速交付，持续集成，用户参与（产品经理），把风险分散在各个很短的迭代中。

3 楼 liuming 2009-12-27  

这是从客户那边把进度压过来的情况。要是反过来从开发这边把进度压回过去的话，也是一个逆运算而已。三个月的项目层层上报就变八个月了。

2 楼 presses 2009-12-26  

如果项目一开始定为半年，那可能要在一年后能能交付。
任何人都会为自已留后路和余地，这也是可以理解的。

1 楼 Jonney 2009-12-26  

狗屎啊，这种现象太普遍了。