说点做FDE的经验。

我现在接一个新项目，前两个星期一行代码都不写。那两周干的也不是需求调研，是给这个项目做一次死亡预演，提前把它会怎么死想清楚。

具体就问五个问题。这五个问题都不聪明，甚至有点冒犯，可它们比任何一份需求文档都更能告诉你后面会发生什么。

第一个，这笔钱是从哪个口子出来的。

这个问题九成的同行不问，我觉得是最该先问的。钱从IT预算出，项目能活，但整个公司会默认这是IT的事，业务部门不会真用，最后变成一个上线了但没人碰的东西。钱从业务部门自己的预算出，这是最好的情况，说明有人真疼，疼到愿意从自己碗里掏。最危险的是那种叫数字化转型专项、创新基金之类的钱，这类预算的考核指标是花出去并且有个像样的汇报，不是有没有人真在用。这种项目在预算年度结束那天，使命就已经完成了，你后面做得再好也没人关心。还有一种是老板临时从哪儿挪的，这种要看老板的任期，他还剩两年，你这项目大概率也只有两年。

第二个，上一个类似的项目是怎么死的。

每家公司都有这么一个，说没有的，要么在瞒你，要么是真没干过。这个问题的关键不在他们说了什么，得听他们怎么说。如果屋子里所有人的版本都是那家供应商不行，你就要小心了，因为你是下一个供应商。如果有人愿意说一句我们自己当时也有问题，比如需求老变、数据没准备好，这家公司还有救，你可以往下谈。我碰到过一次，一个部长在这个问题上说了句我们那时候没人真管这事，我当场就觉得这单能做，后来也确实顺。

第三个，同一个指标，让两个部门各写一遍。

这不是提问，是个动作。你挑一个大家天天挂在嘴上的指标，退货率、库存周转、有效客户数都行，让业务和财务各派一个人，当场在纸上写出算法，不许商量。我做过十几次，从来没有哪一次两边是完全一样的。差异本身不吓人，吓人的是他们大多数时候都不知道有差异，还在一个会上拿着两个数吵了三年。这一步做完，你原来的项目范围基本要重估一遍，很多时候真正的活儿压根就不在系统上，得先把这件事捅破。

第四个，六个月之后谁来更新这套东西。

问这个的时候要个具体的人名，不能接受部门。对方说IT部会负责，你就追一句，IT部里的哪一位。名字说出来之后再追一句，这件事写进他今年的考核了吗。这两句追完，大部分屋子会安静下来。这个安静就是答案。我之前有个项目栽在这儿，交接会上问过一次，对方说到时候再说吧，我就顺水推舟过去了，八个月之后那套系统悄无声息没人用了。

第五个，这套系统跑出来的结果，最不希望看到的人是谁。

这个问题问出来场面通常有点尴尬，对方一般会说没有这种人，我们都是就事论事。你要看的是他们回答之前的那两秒钟，那两秒钟里的表情比答案有用。有这样的人不代表项目不能做，代表你得提前想清楚，那个不好看的数字第一次跑出来的时候，谁来扛，怎么讲，用什么方式让他不至于当场翻脸。这件事想在前面和想在后面，差别很大。

五个问题问完，大部分项目会怎么死其实已经写在墙上了。

可问题是你多半还是得接。真到了要付房租的时候，明知道这单是创新预算出的钱、明知道没人接手维护，你还是会签。所以这套东西真正的用处不是帮你挑项目，是让你在动手之前就知道自己会死在哪儿，然后提前把绳子系上。知道钱是专项预算出的，你就把交付节奏卡在预算年度结束之前，别指望第二期。知道没人接手，你就把系统做得再笨一点，笨到少更新几次也不至于出错。

说句实在的，我自己也不是每次都做得到。有时候客户催得紧，有时候钱给得痛快，两个星期就压成了两天。压缩掉的那部分，后面基本都会以某种形式还回来，一分不少。