需求文档写完开发还是看不懂,问题出在这几点

      为什么需求文档写完开发还是说“都写了一些什么东西”。

      前四篇我们一路说到：项目失败很多时候根子在需求；糟糕文档会带来返工、沟通、质量与士气的代价；创业公司尤其容易忽略需求阶段；而文档本身必须站在读者角度来写。即便如此，现实中最常见的情况依然是——文档写完了，开发看完还是一脸懵。

      这并不是开发“不愿意看”，也不是开发爱抱怨，需求文档可能真没有写清楚。

      第一，描述停留在"需求要实现什么"，却缺少“为什么要做，怎么判断做对了”，代码写起来不连续。

      很多文档会写“支持用户管理客户信息”、“增加订单导出功能”，不说清楚：哪些字段是必填、什么情况下允许操作、异常怎么处理、怎样算完成。开发只能按自己的经验设计数据库表，猜错了就返工。这正是前面提到的“验收标准缺失”和“沟通成本上升”的直接来源。

      第二，业务规则和边界条件写得模糊或遗漏。

      “根据权限显示不同内容”、“金额超过一定数值需要审批”——这类看起来正确的规则，实际上充满缺口。权限具体怎么划分？“一定数值”是多少？审批人和流程是什么，不同的审批人数值是否一样？开发遇到这些模糊点，要么反复来问，要么先按自己理解做，结果后期大改。

      第三，缺少真实使用场景，只剩功能罗列。

      文档堆了功能点，却很少说明“谁在什么情况下、为了达到什么目的来用、使用的实际业务流程”。没有场景，开发很难判断优先级和交互细节，也容易把次要功能做成重点，或把关键路径做简。最终做出来的东西，业务一看就说“不是这个意思”。

      第四，结构和表达只方便自己写，不方便别人读。

      大段文字没有分层、标题不清晰、相同概念前后用词不一致、关键信息埋在段落中间……这些都会让开发把时间花在“找信息”而不是“理解需求”上。文档还长，读起来费劲，实际使用效率低。

      这些问题叠在一起，就会出现我们前面反复强调的连锁反应：开发反复确认和返工，测试标准不清，业务验收时再提新要求，项目节奏被拖乱，团队逐渐疲惫。

      写需求分析时，不妨时刻记住一句话：开发读完后，能否相对独立地开始设计和编码，能否正确的写出自动化测试用例，能够写出异常边界的代码，如果自己做详细设计，细节是否足够？ 如果答案是否定的，那就重点检查上面这几点。

      把“让对方看懂”作为标准，比把“自己写完整”作为标准，更能减少后续的代价。一个好的产品经理，如果没有做过分析设计和代码开发，就需要加强了解开发写代码想的是什么。

      下一篇，我会继续往下说：当需求已经乱成一锅粥时，项目通常会怎样一步步走向失控。理解这个过程，有助于我们更早地踩刹车。