如何写一份「不坏」的需求文档？

需求文档是产品经理最重要的产出物，它的撰写占据了许多产品经理50%以上的工作精力。然而在实际工作中，依然会存在着诸多问题，这是什么原因呢？应该如何解决？本文作者对此进行了分析，一起来看一下吧。

需求文档是产品经理最重要的产出物，没有之一。许多产品经理在实际工作中，需求文档的撰写占据了 50% 以上的工作精力，即使投入很多精力，需求文档依旧存在诸多问题。如：

1. 需求理解不清晰，挣扎在开发人员提出各种问题和重新沟通确认。
2. 解决方案没有形成闭环，缺少异常流程，重复返工需求文档；
3. 追求高保真原型，大量时间和精力花费在原型设计和交互，后期修改原型的成本高。
4. ……

出现这些问题的核心原因，是产品经理把需求文档当成一份开发交付文档，而不是当成「信息传递工具」，重点不在交付，而在于信息传递。

01 烦人的信息差

产品研发的信息传递，指需求方，实施方为了解决需求，进行需求和解决方案的信息传递过程。

需求文档，是承接产品信息的工具，最核心作用，是实现需求方，实施方的信息统一，减少因为信息传递问题，带来的「产品无法解决需求」 的情况。

信息传递面临核心问题的是：「信息差」。

信息传递本质是信息编码再解码的过程，需求方将想要传递的信息通过媒介进行编码输出，传递给接受者，接受者再解析理解信息的过程。

原始信息在传递环节会存在不同程度的损耗，导致需求方和接受方在信息上存在的理解差距的情况，我们称之为「信息差」。

导致出现信息差的原因很多，例如：

1. 需求方没有清晰表达能力（编码问题）；
2. 文本沟通，没有选择沟通效率更好面对面沟通（通道/媒介问题）；
3. 接受者对接受的信息理解出错（解码问题）；
4. ……

信息传递必定存在信息差，产品研发又存在「多人沟通」的常态化现象：

1. 需求方，人数不定，通常为老板，用户，产品经理等；
2. 产品经理，一般情况 1 人；
3. 技术方，人数不定，通常为前端，后端，测试等。

「信息差」+「多人沟通」形成双喇叭型结构的信息传递模式，在横向传输上，拉长信息传递链。

即需求方编码 → 通道传递 → 产品经理解码 → 产品经理再编码 → 通道传递 → 技术方解码。

传递每个环节按 20% 的信息损失，至少有 70% 的信息在传递过程中被损失。

类似综艺节目的传话游戏，几个人站成一排，每个人都听不到前一个人说的话，只能通过前一个人的口型和肢体语言，猜测对方说的是什么，然后再传话给下个人。

一般到第三个人时，传递的信息和原来要传的信息是天差地别的。

纵向传输上，产品经理即接收多个需求方的信息，也向多个技术方传递信息。

一方面，多个需求方存在着多个需求，需求方往往传递自己认为可行的解决方案，不擅于阐述自己遇到的问题或真实需求。

产品经理需要花费大量精力辨别每个信息传递背后的真实需求，一旦有所疏忽，容易误解用户真实需求，掉入「用户说啥，实现啥」的陷阱，投入开发成本，但没有解决用户实际需求。

另一方面，产品经理要向多名开发人员传递思考后需求和解决方案，开发人员侧重于解决方案的实现可行性和成本，很少主动理解需求方的真实需求，主动与产品经理，需求方同步信息，减少信息差。

每个开发人员对信息的理解程度不同，理解需求和方案容易出现误差，开发过程中，容易出现以下问题：

1. 开发环节，开发人员之间理解差异导致方案差异，例如：前后端人员理解不一致，导致接口缺失，无法联调；
2. 测试环节，开发人员完成功能与测试人员测试用例不相符；
3. 验收环节，开发功能与产品经理预期不一致，产品功能无法满足需求。

出现上述问题，产品经理不得不重复沟通需求，花费大量时间促使所有开发人员达成信息统一。

02 标准化需求文档

需求文档是对产品开发的信息传递问题的解决方案，好的需求文档是能让所有人统一认知，从而提高开发效率的利器。

需求文档的好坏受限于产品经理能力和经验，高水平的产品经理属于小比例人群，所以我们不要求每个产品经理输出高质量的需求文档。

但，随着岗位和行业深入发展，产品经理的工作出现标准化趋势，意味着我们可以输出「标准化需求文档」，保证需求文档的下限，统一上下游对需求认知，减少信息传递过程的损耗。

标准化需求文档包含 3 个部分：文档结构化，绘制标准化，功能描述标准化。

1. 文档结构化

按照产品经理的工作流程，我们将需求文档的作业流程分为 4 项内容：「需求介绍」，「解决方案」，「修订记录」，「其他事项」。

各项内容都有各个细项，会在后续章节进行讲解，不再赘述。

2. 绘制标准化

绘制标准化，核心掌握是流程图的绘制标准化和低保真原型快速输出。

产品经理在流程图上经常犯 2 个问题：

一是多数产品经理为非科班入行，很少掌握流程图的规范，容易绘制错误规范的流程图，被开发人员按正确规范误解。

产品经理不需要掌握流程图所有绘制规范，只需要掌握 10 个常用简单绘制规范即可。

二是不考虑异常流程，异常流程分为 3 大类：

1. 全局型异常流程，指在系统全局都会出现的异常流程；
2. 功能型异常流程，指在功能操作和规则上出现的异常流程；
3. 业务型异常流程，指正常业务过程中，发生不符合预期的业务流程。

不同类型异常流程应用，我们会在后续「流程图篇」进行讲解。

产品经理在原型绘制上避免追求高保真原型和原型交互设计，需求文档的核心是传递需求信息，只要能达到目的，低保真原型和无交互设计都可以。

相仿原型和交互设计精细度越高，意味着我们投入原型设计的时间越多，理解和传递需求时间越少，本末倒置。

如何在极短的时间内输出一份低保真原型，我们会在后续「原型篇」进行讲解。

3. 功能描述标准化

功能描述是产品经理码字最多的地方，也是开发人员理解和落地功能点开发的根据。

开发人员在功能点出现理解误差的主要原因，是功能描述不标准，即遗漏功能点。

我们以信息流「下滑加载」为例，用户通过「下滑加载」功能获取信息，我们怎么写这个功能点？

A. 用户可以在页面顶部向下滑动触发加载功能，每次加载获取下一页的内容，加载失败时，toast 文字提示：「加载失败~」。

作为对比，我们看另一份功能描述 B：

1. 触发方式：在内容列表顶部，用户通过从上向下手势触发滑动触发，滑动区域超过 1/6 屏幕生效，滑动过程显示滑动进度 icon，具体样式和动效以 UI 为主。
2. 加载内容数量：每次加载，均可获取 50 条内容。
3. 加载内容规则：将下一页未加载的内容，按照内容的与用户算法匹配值排序，展示匹配值最大发布的内容。
4. 网络异常处理：网络异常状况下，执行加载功能后，Toast 提示「网络异常，请更换网络后再试」，并显示加载前的内容。
5. 网络异常：无网络，弱网络，均视为网络异常。
6. 请求超时：若服务器5秒内未返回数据，Toast 提示用户「服务器忙，请稍后再试」，并显示加载前的内容。
7. 内容数量不足：加载时，若下一页内容超过 0 条，但小于 50 条，则返回所有的内容。
8. 下一页无内容：加载时，若下一页内容数量为0，则Toast 提示「无最新内容，我们再加急生产中……」。
9. 非正常加载：若是非正常加载，仅视为一次加载，加载过程中，Toast 提示用户「马上出现你想要的内容」。
10. 非正常加载定义：监控用户加载频率，两次加载的间隔时间低于1秒，即视为非正常加载。

通过 A 与 B 两段功能描述，我们清楚看到 A 遗漏 8 点功能点，还有 1 点功能描述不清晰，这意味着开发和测试人员就一个功能，得和产品经理沟通 9 次以上。

功能描述标准化的最大好处，是减少产品经理和开发人员的信息差，减少反复沟通确认，让开发人员更多时间专注在功能落地。

功能描述如何标准化，在后续「功能描述篇」进行详细阐述。

03 最后的话

在文章最后，我们总结全篇核心内容：

1. 需求文档的本质是：需求方，产品经理，开发人员之间需求和解决方案的「信息传递工具」。
2. 产品开发主要沟通问题，是「信息差」+「多人沟通」导致信息不同步，容易做出无用产品。
3. 高需求文档水平的方式是标准化，指「文档结构化」，「绘制标准化」，「功能描述标准化」。

后续的想法，希望通过 5-6 篇阐述需求文档的文章，帮助大家减少一点时间在需求文档和沟通上，

然后，2023 年多一点时间让自我成长。