需求文档是产品经理日常工作输出的最重要的文档。什么是需求文档编写？应该包括哪些内容？

要找出这个问题，首先要搞清楚需求文档的读者是谁，读者想从需求文档中得到什么，不同的读者影响需求文档的组织形式，这取决于产品经理的习惯，不能一概而论。

下面是我理解的需求文档应该是什么样子，可以用来讨论。

需求文档最重要的读者首先是产品经理本人。无论是在需求实现之前用需求文档描述需求的实现思想，在需求实现时根据需求文档进行设计、研发和测试，还是需求上线后对需求文档进行评审和总结，都是基于产品经理编写的需求文档。其次，读者是设计师、研发人员；负责需求实现的人员、测试人员和其他产品经理。

根据我的习惯，需求文档将包含以下五个部分。

一、需求变更日志和版本迭代记录

的第一部分是需求变更日志和版本迭代记录。从需求提出到最终上线，不可避免的会有一些需求变更或者方案调整，所以需要一个变更日志来记录这些变更。

更改日志不仅仅是关于增加或减少了什么功能，而是更加仔细。

比如需求中的A功能点原本打算用方案1来实现，但考虑到资源的限制和现实场景，改为用方案2来实现，也是需要写的。虽然结果显示需求中的A功能点还是实现了，但从流程上来说，方案1到方案2的转变是产品经理思维的升级，是对资源约束的更深层次考虑。

另外，需求变更的原因，变更前后的样子，可能会有什么影响，都要记录清楚，以便以后搞清楚细节。

版本迭代记录不仅包括需求中功能的版本迭代，还包括产品经理对这个需求的思考路径的迭代。

需求中函数版本的迭代大家都很熟悉，就不赘述了。我主要想说明什么是产品经理需求的思维路径的迭代？你为什么要这么做？

如前所述，产品经理的伟大工作就是做决策，所以决策的质量非常重要，决策的质量需要通过不断优化决策的思维路径来提高。产品经理应记录自己对需求的思考过程，并不断总结和优化该过程。

另外，通过展示这些思维过程，与其他同事讨论，可以跳出自己固有的思维模式，做到包容。

所以我一直认为，一个产品经理处理一个需求的时候，他的思维路径和决策依据应该是公开透明的，让所有参与需求的人都可以查看和讨论(从hsdgb，感兴趣的朋友可以去看看他的《原则》)。

那么，我输出需求变更日志和版本迭代记录的过程是怎样的呢？

按照我的习惯，在输出需求文档的时候，我会先根据目前可以考虑的情况写一个Beta版本。这个时候我就命名为V0.7版本，然后隔天再思考一下，看看昨天写的需求文档。这时，我可以发现许多不足之处。然后我会从头开始更改，并指出需求有哪些变化。此时的版本是V0.8版本。

接下来，请其他产品经理告诉他这个需求文档，或者在小组内组织一次需求评审，做出全面的评论，再次修改，并指出需求有哪些变化。此时版本为V0.9版本最后，请开发测试设计的同学对需求进行审核，从开发测试设计的角度再次修改需求，并注明做了哪些修改，形成最终的V1.0版本

这样，需求文档可以包含产品经理对需求实现方案的完整思考过程，不仅包括自己思维的升级，还包括实现方案的调整和补充

有了需求变更日志和需求版本迭代记录，不仅可以追溯需求的实现逻辑，还可以完整记录整个需求从提出到上线多个版本。在此期间，产品经理可以经常进行评审和参考，产品团队可以针对大的需求进行有针对性的复检，也可以为后来接手工作的产品经理提供完整的需求迭代过程。

二、背景方案价值

背景、方案、价值是需求文档的核心，是任何需求在进入实施阶段之前都必须考虑清楚并反复讨论的部分。

是需求背景下的需求。这里需要写清楚的背景，可以包括但不限于产品所在行业的现状、产品/功能模块的地位和目标、开发团队的资源限制、技术限制等。

刚开始做产品经理的时候，体验过其他产品的一些功能，忍不住吐槽。我在这里怎么做？我应该这么做。如果我是你，我会比他做得更好，以此类推。

后来我从自己做产品的经验中了解到，任何需求都受到当时的背景和资源限制。没有这些背景谈实现是无稽之谈。产品经理要做的就是在当前的背景下找到最佳的实现方案。因此，梳理需求背景是产品经理对当前资源状况的考量，是实现需求的第一步。

它是方案背景下需求的实现方案。由于需求会受到目前资源情况的限制，方案必然会有所不同，甚至可能出现妥协和不完整的方案。有时候需求本身就是实验性质的，为了快速测试效果，所以选择一些容易实现、开发难度较小的方案也就不足为奇了。

在编写方案时，可以按照“用户-场景-问题-方案”的框架，简单指定实现方案，即用户在什么场景遇到什么样的问题，提供什么解决方案。——这里要求方案细化，一句话就能说清楚。

价值是指实现这种需求可以带来什么样的价值，包括用户价值和商业价值。用户价值是指实现这一需求能够给用户带来的价值。

来什么样的价值，例如提升用户的使用体验等；业务价值是指实现这个需求能给产品的业务带来什么样的价值，例如提升用户留存或者提升业务收入等。

需求不一定要同时提供用户价值和业务价值，也不一定两个价值都需要为正（例如带来很大的业务价值而牺牲很小的用户价值也是可以的），具体需要依据产品当前的状态来考虑，但不能带来价值的需求一定是有问题的。

此外，在思考需求能够产生什么价值时，同时要思考的是以什么数据指标来评估这个价值，也就是需求上线后效果的好与坏要有量化的指标。不一定所有的需求都能够找到量化的效果指标，但一定要尽量找到这个指标。只有需求的效果能够被衡量，产品才能够往更优的方向迭代。

三、业务逻辑&流程说明&功能需求详述

第三部分主要是需求实现的部分，我把它划分为业务逻辑、流程说明和功能需求详述。

业务逻辑部分描述的是需求中涉及到的数据流向和用户流向，特别是需求涉及到多个系统时，数据和用户在系统之间如何交互的（这部分的内容偏复杂，后面再单独写下我的理解）。

目前针对业务逻辑部分，我主要的输出是多通道的泳道图来描述系统间的交互。这里应该特别注意的是在说明数据流向时要兼顾考虑正常流程和异常流程，以及在说明用户流向时要考虑清楚需求边界。

此外，需求的复杂程度不同，可能还会包含页面流程图、页面结构图等。

功能需求详述就是常说的原型。

我目前的习惯，在需求文档的早期版本不喜欢输出高保真的原型，而是倾向于用低保真原型加文字描述的方式来说明需求中的功能实现。

功能需求详述以需求中的页面为单位，分为原型图、需求说明和交互说明三个部分。

原型图对需求涉及的每个元素进行标注；需求说明针对原型图中的标注进行文字说明，包括字段逻辑、按钮逻辑、页面逻辑等；交互说明则是针对一些非逻辑的交互进行说明，例如某些字段、需要突出显示，页面变化时需要怎样的特殊效果等等。

四、相关文档的集合

日常工作中，时常出现想要找需求的某个相关文档时，四处搜索，浪费很多时间的情况，为此我形成了一个习惯，就是把需求文档作为一个所有相关文档的集合。如埋点文档、设计稿、接口文档、测试用例文档、开发相关的链接、上线后的数据等，都以链接的形式整理在需求文档中，这样每次需要找需求的相关文档，都可以从需求文档中快速找到。

五、需求上线后的数据

凡是需求，必然要有验证效果的数据，而从每一个失败与成功的需求中不断总结和反思，是产品经理成长的重要途径。如上文所说，产品经理应该保持开放透明，那么就意味着产品经理对于需求输出的实现方案，最终结果无论是好是坏，都应该将效果数据按实际公开，这既能够促使产品经理自己不断改进产品思路，也能够让参与需求的相关同事了解自己的工作成果，增加他们的参与感与成就感。

以上便是我理解的需求文档应该包含的一些内容，可能过于繁杂，具体还是要根据每个人自己的工作习惯做取舍，仅供参考。

希望能帮到你。

本文由 @Isaac 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议