两年前我参与过一个项目，做了七个月，最后停掉了。没有事故，没有追责，就是有一天开会宣布不做了，代码留在仓库里，现在应该没人再打开过。
停掉之后我们没做过正式的复盘，大家心照不宣地跳过了。我自己私下写了一些，今天整理出来。
先把时间线摆出来，不加评价：
- 第一个月：需求的源头是一位业务负责人在一次会上说的一句话——我们应该有个东西能把这些数据看明白。会后一周，立项。
- 第二到第三个月：做出可演示的原型。中期汇报很顺利，有人当场说这个做出来能省一半人力。
- 第四个月：开始接真实数据，发现三个部门对同一个指标的口径不一样，而且没有人愿意改。
- 第五个月：项目被认为进度落后，加了两个人。加人之后那个月，交付的东西反而更少。
- 第六个月：我第一次真正坐到一线使用者旁边看他们干活，发现他们已经有一套用了三年的表格，每天早上花二十分钟维护，非常顺手。
- 第七个月：宣布停止。
下面是我自己的几条结论。有些是当时就该知道的，有些是过了一年才想清楚的。
第一，需求的源头是一个人的一句话，这件事本身就是红灯。
我不是说领导的判断不值钱。问题在于，那句话是一个愿望，不是一个需求。愿望和需求的区别是：需求有人正在为它痛苦，而且痛苦到愿意改变自己的工作方式。我们整整六个月都没有验证过这件事。第六个月我坐在使用者旁边的那两个小时，价值超过前面五个月。
第二，原型演示得越顺，越危险。
原型是我们自己造的世界，数据是我挑的，路径是我设计的，异常情况一个都没有。演示会上的掌声，验证的是我们讲故事的能力，不是产品的能力。后来我给自己定了个规矩：任何演示，必须至少有一段是用真实的、脏的数据跑的，哪怕它当场出错。出错比掌声有价值。
第三，口径对不上不是技术问题，我却当技术问题处理了。
发现三个部门口径不一致的时候，我的第一反应是做一个映射层，把三套口径都兼容进来。这是我最擅长的解法，所以我下意识就选了它。结果是我花了一个多月做出一个谁也不信的东西——因为每个部门看到的数字，都不是他们自己那套算法出来的。
正确的做法是把这件事捅上去，让有权力的人拍一个口径。这需要我去做一件我不喜欢做的事：反复跟三个部门的人开会、扯皮、得罪人。我逃避了，用技术方案把它包起来了。
这一条是我到现在还会脸红的。
第四，加人不是加速，是加沟通成本。
这条道理谁都听过，但你亲身经历一次才知道具体是怎么发生的。新来的两个人很不错，问题是他们需要有人讲清楚背景，而唯一能讲清楚的是我。那个月我大概有三分之一的时间在解释，剩下的时间被切成碎片。更麻烦的是，为了让他们有活干，我把任务拆得比该有的更细，结果整体设计被拆散了。
第五，最该学的一条：早点承认不行，比坚持七个月更需要勇气。
其实在第四个月，我心里已经有个声音说这事儿不对。我没说。原因很俗气——已经投了四个月，我怕被认为是我能力不行；也怕那两个刚加进来的同事白忙。于是我用更努力来回避那个判断。
后面三个月的所有加班，本质上是在为一个我已经不信的方向买单。
项目停掉那天，我在楼下坐了一会儿，情绪上是松了一口气的。这个反应说明了一切。
最后说个我至今没想明白的：如果第四个月我说了，会怎么样？有可能项目提前收摊，大家各自去做别的；也有可能我被认为悲观、不担事，然后项目照做，只是换个人扛。我倾向于第二种。所以那句我为什么不说，也许并不完全是我的怯懦，还有一部分是环境教会我的沉默。
但这不构成免责。下一次我还是得说。