夜雨聆风
这个判断听起来不对。
需求文档不详细，项目不是更容易跑偏吗？
问题出在"详细"的定义上。
01
大多数需求文档的"详细"，指的是页数多、描述细、规则覆盖全。每一个交互状态都写了，每一个异常流程都列了，每一个权限节点的判断条件都画了。
写完的那一刻，项目经理觉得稳了。产品觉得稳了。所有人签字。研发开始做。
三个月后，联调炸了。炸的点永远不在文档里。
不是一个规则忘写了。不是某个流程漏了。是文档没有描述到的那个东西：上下文。
02
文档可以描述"用户点击按钮之后跳转到A页面"。但它描述不出"用户是在什么心态下点了这个按钮"。
文档可以列出"当a条件成立、b条件为真、c触发缺省值，系统返回d"。但它列不出"实际业务里，abc很少同时出现，但一旦同时出现，d这个值在业务逻辑上有没有意义"。
上下文这种东西，只有实际干过这件事的人脑子里有。文档写不出来。
需求文档越详细，给人的错觉就越强：既然都写了，那就不用跟需求方反复确认了，按文档做就行。文档成了研发和业务之间的一道墙。业务觉得"我都写清楚了"，研发觉得"我就按这个做"。两边都觉得不需要再沟通。
三个月后联调，发现做的东西和业务要的东西在上下文意义上完全不同。这时候谁也怪不了谁，因为文档上确实都写了。但文档上写的和实际上下文中需要的，是两套东西。
03
好的需求管理不是把文档写到没有人可以质疑的程度。是保留足够的模糊空间，然后强迫各方在模糊空间里不断对话，直到上下文被对齐。
文档再详细，也替代不了对话。因为对话暴露的不是规则，是假设。而项目的风险，全部藏在假设里。
写在最后
文档的"详细"常常是安全感的幻觉。真正保护项目的不是写进去的字数，是没写进去的那部分东西，有没有在人与人之间被聊清楚。
