第一章 需求黑洞：为什么你的项目总在返工？

说实话，我做了十几年项目，最怕的不是技术难题，而是需求。

技术难题再难，总有解法。但需求这东西，就像个无底洞。你永远不知道下一秒会冒出什么新要求。我见过太多团队，代码写了一半，产品经理跑过来说：「客户觉得这个功能不够好，我们改一下吧。」

这一改，就是三天。改完第三天，客户又说：「嗯，还是原来的好。」

你想想看，这种场景是不是很熟悉？

1.1 需求黑洞的三种典型症状

需求黑洞不是一天形成的。它通常有三个阶段，我管它叫「三不」：

• 需求不明确——客户说「我要一个智能系统」，但什么是「智能」？没人说得清。
• 需求频繁变更——今天说要A，明天说要B，后天说A+B。
• 需求文档缺失——全靠口头沟通，出了问题谁也说不清楚。

我在一个电商项目中遇到过这种情况。客户说「我要一个推荐系统」，我们团队花了两个月做了一套基于协同过滤的算法。结果上线前一天，客户说：「不对，我要的是基于内容的推荐。」

两个月白干了。

为什么会这样？因为一开始的需求描述，只有一句话。没有文档，没有原型，没有确认流程。

1.2 需求黑洞的根源分析

说白了，需求黑洞的本质是信息不对称。客户以为自己说清楚了，你以为自己听懂了。但中间隔着一层「我以为」。我画了一张图，你看看就明白了：

你看，从客户想法到开发理解，中间至少衰减了30%的信息。再加上没有文档记录，口头沟通又衰减30%。最后落到代码里的，可能只有客户原始想法的40%。

这就是返工的根源。

1.3 我的实战解法：需求冻结三板斧

我这些年总结了一套方法，叫「需求冻结三板斧」。说白了就是三个步骤：

1. 写下来——所有需求必须形成文档，哪怕是一页纸。
2. 画出来——用原型图、流程图把需求可视化。
3. 签下来——关键节点必须客户签字确认。

我习惯在每个项目启动时，先做一次「需求澄清会」。会上我会问三个问题：

• 这个功能解决什么问题？
• 用户是谁？他们怎么用？
• 不做这个功能会怎样？

你别说，第三个问题特别管用。很多需求一问这个，客户自己就放弃了。

1.4 需求变更管理流程

需求变更是躲不掉的。但我们可以管理它。我设计了一个简单的变更流程：

步骤	动作	产出物	责任人
1	提出变更请求	变更申请单	需求方
2	评估影响范围	影响分析报告	技术负责人
3	评估工作量	工时估算表	项目经理
4	变更评审会	评审纪要	变更控制委员会
5	确认实施	变更确认书	双方签字

我曾经在一个项目中严格执行这个流程。客户一开始很不习惯，觉得太麻烦。但三个月后，客户主动跟我说：「你们这个流程好，至少我们知道每次变更要花多少钱了。」

1.5 需求文档的「三页纸」原则

很多人觉得写需求文档很痛苦。我理解。所以我提倡「三页纸」原则：

• 第一页：一句话说清楚项目目标
• 第二页：核心功能列表（不超过10条）
• 第三页：关键用户场景（3-5个）

别小看这三页纸。我见过太多项目，连第一页都写不出来。你想想看，连项目目标都说不清楚，后面怎么可能不返工？

1.6 避坑指南

最后，分享几个我踩过的坑：

• 不要相信「先做出来看看」——这句话背后意味着「我也不知道要什么」。
• 不要用口头确认替代书面确认——人的记忆是会骗人的。
• 不要跳过原型验证——一个可点击的原型，胜过十页需求文档。

我曾经因为一个口头确认，多花了三周时间。客户说「这个功能先这样吧」，我以为他满意了。结果验收的时候他说：「我当时说先这样，意思是先放着，后面再改。」

嗯，从那以后，所有确认必须邮件回复。没有邮件，就当没说过。

好了，这一章就到这里。下一章我们聊聊「技术债务」——那个你欠下的，迟早要还的东西。