这六个问题答不上来，需求文档写得再厚也会在第一次评审时崩掉。
需求文档的作用是把已经想清楚的事写下来，它没法替你想清楚。项目启动前真正需要的是六个答案，而不是一份 80 页的文档。
文档越厚，往往说明共识越少——不同部门把各自想要的东西都写了进去，却没有人对优先级负责。
评审时真正被挑战的也不是功能是否齐全，而是「为什么要做这个、做完怎么判断有用」。这两个问题文档通常答不上来。
说不出具体的人和场景，需求就是想象出来的。
现状流程是基线，没有基线就无法衡量改善。
指标要在开发前定，而不是上线后找。
没有责任人，项目就会变成所有人都同意、没人推动。
能在一个月内验证的那部分，先做它。
提前约定止损条件，比事后争论是否继续有效得多。
现在所有项目的一号里程碑都是「六个问题有答案」，而不是「原型评审通过」。这个调整让项目的第一次返工平均推迟了两个月——通常是彻底消失了。
启动会的目标不是确认功能清单，而是确认我们是否真的知道要做成什么。答不上来就换个时间再开，这比硬着头皮开工便宜得多。
这六个问题没有任何技术含量，难的是诚实回答。它们最大的作用，是在项目最便宜的时候暴露最大的不确定性。
告诉我们所在行业与业务阶段，我们提供对应的交付路径与周期参考。
