需求文档结构图
1. 用户是谁。写需求文档其实跟做产品有些相似，要了解你的阅读用户是谁。上图中分成了两个颜色，其中红色部分的目标用户是PM，可以是你的产品总监也可以是其他领导，目的是输出产品调研、分析、推演的过程和结论。当然部分内容不是必须出现在需求文档中的，因为它们可能在产品方向讨论、用户分析调研和需求分析等环节就已经确定了。所以具体怎么书写还是要看自己公司的情况。而紫色部分是给主要使用者：研发、UI、测试、项目或者运营同学看的，这部分作为说明、实施部分一般都需要包含，且要达到完整、清晰、易懂。
2. 项目背景。笔者刚从业时项目背景总是一笔带过，觉得这是很虚的东西没人看。作为执行层面，这部分确实没有什么价值。可如果PM真的想要进阶商业能力，从整个产品甚至生态的维度去考虑方案和机会的话，项目背景就一定要认真写，起码要认真思考、认真总结。这部分需要解释的有两个地方：
行业：行业是一个组织化的概念，像出行、健康、零售等这些都属是行业，一般情况下的产品业务分析，最高维度的抽象差不多就到这了。要了解或思考的关键问题是：行业中有哪些角色？它们之间的关系是什么样的？市场政治经济环境如何？行业的变化规律是什么（可以对比国外，也可以参照相似的行业）？以及有哪些可能的机会？ 市场：市场是相对行业低纬度的横向概念，需要考虑的是规模，上下游关系，平台和应用分别是什么，是否有同质和差异化等问题。3. 目标与预期。设立目标和预期是为了保证方向明确，并在产品上线后根据预期可以比对、验证效果。
目标：需要找到可以反映目标的可量化关键指标，如果目标不止一个，目标和指标的设定就要有优先级的意识。且一定要明确最关键的一个指标。 预期：若是完全新的产品和功能，要根据调研结果进行量化估算；若是已有产品的优化改进，则要列出当前的数值和推演后预期的数值。4. 业务架构和产品架构。这不是需求文档中必须包含的部分，但是能够让PM从更高的角度去思考业务和产品，同时可以锻炼抽象和理解本质的的能力。
5. 方案概述。这算是一个提升阅读体验的部分。如果需求文档太长，直接描述具体细节会让阅读者理解成本提高。在文章具体展开前，整体的讲述方案并列出涉及的职能范围，可以让阅读者有整体概念的同时有方向性的分配注意力。
6. UI元素+功能交互。这里是笔者积累的一个写作经验，即将需求的结构按照类似“MVC框架”来实现。好处一是修改方便：若修改了UI只需要改UI部分，修改了交互也不用去改关联的UI；二是这种书写方式跟研发的实现方法较吻合，经验上看研发一般也都比较喜欢。拿“外卖成单后的履约进度tips”举例：
1、 UI元素： 1）icon：… 2）文案：… 2、 功能交互： 1）出现时机： 2）消失时机： 3）过渡动画： 4）状态切换逻辑： 5）点击交互逻辑：7. 接口人说明。跟方案概述中的”涉及范围“相呼应的部分，可以在每个模块/页面前加一个接口人表格，这样的好处时可以减少组织间的沟通成本，同时也会给你自己省出很多协调的时间。
8. 市场运营计划。这是一个非必现的部分。但是好的PM一定是懂运营和市场，并会利用相关资源的。产品出生后怎么养、怎么包装推广很重要，所以一定要在方案计划时就有所考虑。
最后，是要多沟通。再好的文档也只是一个工具，不能只有售前没有售后”服务”。充分的沟通不仅可以确保协作方理解的一致，也能够增加团队的凝聚力和积极性，最终获得事半功倍的效果。
