需求文档是产品经理在日常工作中输出的最重要的文档。需求文档是怎么写的？应该包括什么？
要明确这个问题，首先要明确需求文档的读者是谁，读者需要从需求文档中获取哪些内容。读者的差异影响需求文档的组织形式，组织形式取决于产品经理自己的习惯。笼统。
以下是我理解的需求文档应该是什么样子，供大家讨论。
需求文档最重要的读者是产品经理自己。无论是在需求实现之前用需求文档来描述需求的实现思路，还是根据需求文档来设计、开发、测试需求，还是在需求完成之后对需求文档进行评审和总结推出。它基于产品经理编写的需求文档。接下来的读者是负责实现需求的设计人员、开发人员、测试人员和其他产品经理。
按照我的习惯，需求文档会包含以下五个部分。
一、需求变更日志和版本迭代记录
第一部分是需求变更日志和版本迭代记录。从提出需求到最终推出需求，中间必须经历一些需求变更或者方案调整，所以需要一个变更日志来记录这些变更。
需求变更日志不只是写下从需求中添加或删除了哪些特性，而且更仔细。
比如需求中的功能点A本来打算用方案一来实现，但是考虑到资源和实际场景的限制，改成了方案二。这个也应该写，虽然结果还是在要求。一个功能点，但从流程上看，从计划一到计划二的转变，是产品经理思维的升级，也是对资源约束的更深层次的考虑。
此外，还应该清楚地记录需求为什么会改变，改变前后的样子，以及它可能产生的影响，以便以后可以找到细节。
版本迭代记录，除了需求中功能的版本迭代外，还应包括产品经理对该需求的思维路径的迭代。
需求中功能的版本迭代大家都比较熟悉，就不赘述了。我主要是想解释一下产品经理对于需求的思维路径的迭代是什么？你为什么要这样做？
前面说过，产品经理的工作就是做决策，所以决策的质量非常重要，需要通过不断优化决策思维路径来提高决策质量。总结和优化。
此外，通过展示这些思维过程并与其他同事讨论，可以跳出自己固有的思维模式，具有包容性。
所以我一直认为，一个产品经理在处理一个需求时，他的思维路径和决策依据应该是公开透明的，让所有涉及到需求的人都可以查看和讨论（来自Ray Dalio读者写者问题流程图，感兴趣的朋友可以去见他的原则）。
那么我输出需求变更日志和版本迭代记录的流程是什么？
按照我的习惯，在输出需求文档的时候，我会先根据自己现在能考虑的情况写一个beta版。这个时候，我将它命名为V0.7版本，然后我会每隔一天重写一次。想一想，看你昨天写的需求文档，这时候可以发现很多不足，然后从头改，并注明需求做了哪些改动。此时的版本是V0.8版本。
下一步就是找其他产品经理把需求文档告诉他，或者在群里组织一次需求评审，综合意见，再修改一遍，说明需求做了哪些改动。此时版本为V0.9版本，最后再找开发测试设计的同学进行需求评审，从开发测试的角度对需求的实现进行修改设计，并指出为形成最终版本 V1.0 所做的更改。
这样，一份需求文档就可以包含一个产品经理对于一个需求实现计划的完整思考过程，不仅包括自身思维的升级读者写者问题流程图，还包括从研发等各个角度对实现计划的调整和补充。 、测试和设计。需求，以及当前资源约束和背景约束下的最佳实施方案。
有了需求变更日志和需求版本迭代记录，不仅可以追溯需求的实现逻辑到源头，还可以完整记录整个需求从提案到多版本上线，产品的变更期间的思路和实现逻辑，产品经理可以不定期回顾，以供参考。产品团队可以针对主要需求进行针对性的评审，也可以让后期接手工作的产品经理了解需求的完整迭代过程。
二、背景&方案&价值
背景、计划和价值是需求文档的核心，是任何需求在进入实施阶段之前必须思考清楚、反复讨论的部分。
需要是上下文中的需要。这里的背景，需要写清楚的内容可能包括但不限于产品所在行业的现状，产品/功能模块的现状和目标，开发团队的资源约束，以及技术限制。
刚开始做产品经理的时候，体验了其他产品的一些功能，忍不住吐槽。我怎么能在这里做到这一点？应该这样做，我本可以比他做得更好，等等。
做产品的经历之后，我才意识到，任何需求都是受限于当时的背景条件和资源限制的。抛开这些背景谈实施是无稽之谈。产品经理要做的就是在当前的环境中找到最好的解决方案。实施计划。因此，梳理需求背景是产品经理对当前资源状况的考虑，是实现需求的第一步。
场景是在上下文中实现需求。由于需求会受到资源现状的限制，因此计划必然不同，甚至可能会出现妥协和不完整的计划。有时需求本身是实验性质的，为了快速测试效果，所以选择一些实现简单、开发难度较低的解决方案也就不足为奇了。
在写计划的时候，可以按照“用户-场景-问题-解决”的框架简单描述一下实施计划，即什么样的用户在什么样的场景下遇到什么样的问题，解决方案是什么提供 - 这里 要求计划要细化，可以一句话说清楚。
价值是指实现这个需求可以带来什么样的价值，包括用户价值和商业价值。用户价值是指这个需求的实现能给用户带来什么样的价值，比如提升用户体验；商业价值是指这种需求的实现可以给产品的商业带来什么样的价值，比如增加用户留存或者增加商业收入等。
需求不一定要同时提供用户价值和商业价值，也不一定要两个价值都为正（比如可以在牺牲小用户价值的同时带来大的商业价值），具体需要取决于产品的当前状态。可以考虑，但是不带来价值的需求肯定是有问题的。
另外，在思考一个需求能产生什么价值的时候，还要思考用什么数据指标来评价这个价值，也就是需求上线后的好坏要有量化的指标。 . 并不是所有的需求都能找到量化的绩效指标，但是我们必须努力去寻找这个指标。只有能够衡量需求的效果，才能让产品朝着更好的方向迭代。
三、业务逻辑&流程描述&详细功能需求
第三部分主要是需求实现部分，分为业务逻辑、流程描述和功能需求详述。
业务逻辑部分描述了需求所涉及的数据流和用户流，尤其是当需求涉及多个系统时，数据和用户如何在系统之间进行交互（这部分内容比较复杂，后面会单独写我的理解）。
目前，对于业务逻辑部分，我的主要输出是多通道泳道图来描述系统之间的交互。在解释数据流向时要特别注意正常流程和异常流程的考虑，在解释用户流向时要明确考虑需求边界。
此外，根据需求的复杂程度，还可能包括页面流程图、页面结构图等。
功能需求规范通常被称为原型。
我现在的习惯是，在需求文档的早期版本中，我不喜欢输出高保真原型，而是倾向于使用低保真原型和文字描述来说明需求中的功能实现。
详细的功能需求分为原型图、需求描述和交互描述三个部分。
原型图注释了需求中涉及的每个元素；需求描述为原型图中的注解提供文字描述，包括字段逻辑、按钮逻辑、页面逻辑等；交互描述描述了一些不合逻辑的交互，比如某个需要高亮的字段，页面变化时需要什么特殊效果等。
四、相关文档集合
在我的日常工作中，当我想找到一个需求的相关文档时，我经常四处寻找，浪费了很多时间。为此，我养成了将需求文档作为所有相关文档的集合的习惯。比如埋点文档、设计稿、接口文档、测试用例文档、开发相关的链接、上线后的数据等等，都以链接的形式组织在需求文档中，让每次需要的时候都能找到需求的相关文档，可以从需求文档的快速查找中获取。
五、需求上线后的数据
所有需求都必须有数据来验证效果，从每一个失败和成功的需求中不断总结和反思，是产品经理成长的重要途径。如上所述，产品经理要保持公开透明，这意味着产品经理要公开需求输出的实施计划的实际结果，无论最终结果是好是坏，这不仅鼓励产品经理不断改进产品理念也可以让参与需求的相关同事了解自己的工作成果，增加参与感和成就感。
以上是我理解的需求文档应该包含的一些内容。可能太复杂了。具体选择要根据每个人自己的工作习惯而定。仅供参考。
希望这可以帮助。
本文由@Isaac原创发表于人人都是产品经理，未经允许禁止转载
题图来自Unsplash，基于CC0协议
