产品经理需求文档包括哪些内容(最重要的8大内容)
需求文档每家公司的要求和格式都不尽相同,每个产品经理也都有自己的习惯和方法,一味想归纳出一种适合各种公司环境和不同开发节奏的“普世模板”,未必能达到预期的价值;需求文档中的大部分内容可能是相对同质的,把大量篇幅放在重复性的地方不如抓重点,多总结点心得和遇过的坑;直接给出一个模板讲不太清楚(且能搜到的模板有很多),具体举例说明在书写范围上又不可控,所以想找到一个“取巧”的表达方式。
需求文档结构图
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一定是懂运营和市场,并会利用相关资源的。产品出生后怎么养、怎么包装推广很重要,所以一定要在方案计划时就有所考虑。
最后,是要多沟通。再好的文档也只是一个工具,不能只有售前没有售后”服务”。充分的沟通不仅可以确保协作方理解的一致,也能够增加团队的凝聚力和积极性,最终获得事半功倍的效果。
原创文章,作者:admin,如若转载,请注明出处:https://www.qq65hfghe5.com/tg/106579.html