需求文档每家公司的要求和格式都不尽相同，每个产品经理也都有自己的习惯和方法，一味想归纳出一种适合各种公司环境和不同开发节奏的“普世模板”，未必能达到预期的价值；需求文档中的大部分内容可能是相对同质的，把大量篇幅放在重复性的地方不如抓重点，多总结点心得和遇过的坑；直接给出一个模板讲不太清楚（且能搜到的模板有很多），具体举例说明在书写范围上又不可控，所以想找到一个“取巧”的表达方式。
文件结构图
1。用户是谁。写需求文档其实有点类似于做产品。知道你的阅读用户是谁。上图分为两种颜色，其中红色部分的目标用户是PM，可以是你的产品总监，也可以是其他领导。目的是输出产品研究、分析、推演的过程和结论。当然，有些内容不一定要出现在需求文档中，因为可能在产品方向讨论、用户分析研究、需求分析等环节就已经确定了。所以怎么写要看你自己公司的情况。紫色部分是给主要用户的:R&D，UI，测试，项目或者运营的学生。作为解释和实现部分，这部分一般需要包含，并且要完整、清晰、易懂。
2。项目背景。刚开始工作的时候，项目的背景总是被刷到一边，我觉得那是一个没人看的虚拟的东西。作为高管级别，这部分真的不值钱。但如果PM真的想要高级的商业能力，从整个产品甚至生态维度考虑方案和机会，项目背景一定要认真写，至少要认真思考和总结。这部分需要在两个地方说明:
行业：行业是一个组织化的概念，像出行、健康、零售等这些都属是行业，一般情况下的产品业务分析，最高维度的抽象差不多就到这了。要了解或思考的关键问题是：行业中有哪些角色？它们之间的关系是什么样的？市场政治经济环境如何？行业的变化规律是什么（可以对比国外，也可以参照相似的行业）？以及有哪些可能的机会？市场：市场是相对行业低纬度的横向概念，需要考虑的是规模，上下游关系，平台和应用分别是什么，是否有同质和差异化等问题。
3。目标和期望。【/s2/】设定目标和期望是为了保证明确的方向，产品上线后可以根据期望对比验证结果。目标：需要找到可以反映目标的可量化关键指标，如果目标不止一个，目标和指标的设定就要有优先级的意识。且一定要明确最关键的一个指标。预期：若是完全新的产品和功能，要根据调研结果进行量化估算；若是已有产品的优化改进，则要列出当前的数值和推演后预期的数值。
4。业务架构和产品架构。
这不是需求文档中必须包含的部分，但是可以让PM从更高的角度思考业务和产品，同时可以锻炼抽象和理解本质的能力。
5。程序概述。
这是提高阅读体验的部分。如果需求文档太长，直接描述具体细节会让读者理解成本增加。在文章具体展开之前，整体的叙事方案和涉及的功能范围，可以让读者有一个整体的概念和方向性的注意力分配。
6。UI元素+功能交互。
这里是作者积累的一个写作经验，就是按照类似“MVC框架”来实现需求的结构。一是修改方便:修改UI只需要修改UI部分，修改交互不需要修改关联的UI；第二，这种写法与R&D的实现方法是一致的，一般凭经验更倾向于R&D。以“外卖订单后的履约进度提示”为例:
1、 UI元素： 1）icon：… 2）文案：… 2、 功能交互： 1）出现时机： 2）消失时机： 3）过渡动画： 4）状态切换逻辑： 5）点击交互逻辑：
7。接口人员的描述。
对于与方案概述中的“覆盖范围”相呼应的部分，可以在每个模块/页面前添加一个界面表单。这样做的好处是减少组织之间的沟通成本，为自己节省大量的协调时间。
8。市场运营计划。这是不必要的部分。但是一个好的项目经理必须了解运营和市场，并且会利用相关资源。产品出生后如何饲养、包装、推广是非常重要的，所以必须在计划中考虑。
最后，要多沟通。文档再好，也只是工具而已。不能只有售前没有售后”服务”。充分的沟通既能保证合作方的理解，又能增加团队的凝聚力和积极性，最终事半功倍。
本文来自年轻人玩的就是心跳投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/632410.html
微信扫一扫 
