P R D！-技术圈

点击上方“数据管道”，选择“置顶星标”公众号

干货福利，第一时间送达

前几日，一位高校任教的朋友咨询渔歌，一份完整的PRD应该包含哪些内容？因为他刚被指派负责一个学校的系统建设。

渔歌总结了下，PRD的八要素，分别是：

敲黑板，重点来了……

估计有人不爽了，PRD要包含这么多内容，还怎么干活？

哈哈，不爽和挑战之前，请先了解八大要素分别是什么，再根据自己所在公司、团队、产品的情况，针对性的选择哪些需要，哪些不需要，哪些简写，哪些花大力气写。

下面分别介绍八大要素，为什么需要这八要素，每个要素的具体内容是什么。

做产品经理的的人，永远都要知道，为什么比是什么重要。

1.项目背景

1）为什么要有项目背景？

项目背景是为了让大家知道要干件什么事，为什么要干。如果不说背景，直奔项目内容，参与评审的各方会懵逼，反复问为什么这么干、为什么那么干，甚至问为什么要干。所以在PRD最前面就讲清楚项目背景，一方面能够让众多项目参与方和产品经理能到一个频道，方便沟通，减少后续对各问题的重复解释，毕竟我们的时间、精力、耐心都有限。同时，能让各方加深项目参与度，让大家觉得不是在完成产品经理交代的任务，而是干一件自己认可的事。项目背景很重要，也很容易被忽视。

2）项目背景需要包含哪些内容？

A．市场环境变化，包括但不限于国内外环境，政策变化、竞对变化，比如新冠疫情对很多产品形态产生变化，或者市场竞争白热化，各家使出杀手锏，又或者监管发布新的政策。

B．公司战略或业务形态的变化，比如公司业务战略发生调整，或者当前产品完成0-1的使命，需要向1-10迈进，进而产品架构需要升级调整。

C．客户需求，需要有明确的客户需求场景。

a.谁，在什么场景下，有什么问题？

b.解决这个问题的客户价值是什么？业务价值是什么？

C.有多少这样的客户？

项目背景在PRD中的篇幅不重要，关键是质量。有的项目背景仅是个人观点，容易被挑战。项目背景中最好有足够落地的用户研究和数据分析、市场分析，或专家输入。

项目背景项目的起点，也能帮产品经理提高与业务、技术、交互、数据、财法等各方的沟通效率，却有往往最容易被产品经理忽视。很多产品经理喜欢直接奔到产品方案，而忽略项目背景。

2.项目目标

项目目标需要量化数据，可以是日或周的调用量、UV、PV、订购量、订购金额等。

不管定什么目标，目标需要明确、无争议。这能让各方快速对齐，形成合力，也能减少产品经理写周报、月报或者向老板们汇报时，忽然间发现不知道该写啥的痛苦。

项目目标需要根据项目背景中解决谁的问题来定。

确定项目目标是对产品经理的考验（目标很难定），也是对产品经理的保护（减少扯皮）。

目标很重要，同样也容易被忽视，而且最难的部分。

3.项目方案概述

项目方案概述的目标是说清楚整体产品结构，分成1、2、3、4等几个部分，每部分的关系是什么，每部分的重要性怎么样，或者整体&关键业务流程是什么？

项目方案概述是为了便于各方对产品方案有结构性的全局认知，避免各方掉到某一个分支细节中去。越复杂的项目，越需要项目概述。

渔歌自己也遇到过很多次，和程序员GG们一起评审需求的时候，他们由于对业务全貌缺少了解，但又希望更好的理解业务，开发们铆足了劲纠不重要的细节，虽然很多次强调了这是不重要的局部问题，就是要以最小的成本解决问题，重点是另一部分，但程序员GG们依然会铆足了劲来掰扯。

项目概述虽然不能解决所有类似问题，但可以解决很多类似问题。

4.项目详细描述

项目详细描述是PRD中篇幅最多的部分，也是产品经理们往往花时间最多的，甚至很多产品经理的PRD只有详细描述。

不得不说，项目详细描述很重要，也是考验产品经理功底的重要内容，产品详细概述需要把根据业务、市场、客户的综合确定的方案，转化为各方都看得懂，并且理解一致，彼此认可的需求，便于程序员GG们搬砖。

详细描述跟着每个产品方案走，渔歌无法给出标准模板。渔歌可以给2点容易被忽视的建议：

1）不忘分支流程。很多PRD只有主流程，没有分支流程，这对产品来说是不完整的，对于开发来说是bug；

2）不忘逆向流程。同样，逆向也是容易被忽视的部分，但在真实的用户场景，不容忽视，没有逆向流程，对用户和开发来说也是bug。

5.项目运营方案

之所以需要运营方案，是因为产品不但要生，还要养。只管生不管养的产品经理不是好产品经理。

不管谁负责运营，在产品上线之前，都需要有清晰、达成一致的运营计划，包括上线前的预热、上线的推广，上线后的用户反馈。产品需要形成自成波浪的一波波运营迭代（不止产品迭代），并同步完成产品迭代。

从来没有一个产品是之前没有任何酝酿，突然就来到这世界上的，除非运营策略上选择这种方式。

对大部分产品而言，产品上线前、中、后都需要明确运营时间、运营渠道、运营人、及效果监控的整体运营方案。

运营计划示例如下：

6.项目风险及解决方案

对风险的考虑，考验的是产品经理的风险和兜底意识。

每个项目都有项目风险，只是风险的影响大小有差异，解决方案有差异。比如数据质量不符合要求，考虑灰度开放，先邀请少数种子用户进来，和一起查数、验数，确保数据质量后再逐步开放；也比如性能压力大，需要申请服务器，或者用切流的方式逐步开放；比如外部风险大，甚至可能需要采用临时备用方案，随时再切回原方案。

所以产品经理需要尽可能评估风险，并给出解决方案。

产品绝不是上线就万事大吉了噢。

7.项目时间计划

项目时间计划一方面是为了让大家有共同的项目上线目标，另一方面为了圈开发、测试、运营、财务、法务各方面的资源。

在明确到开发、联调、上线的时间计划中，各资源方如果有问题，也可以提前暴露问题，再推进解决，避免把项目时间一再往后压，也避免各方甩锅。

8.项目组人员

项目参与人员一方面也是为了让大家有项目参与感，同时也为了让大家感受到项目责任，所以需要明确到各个角色的人员。

如果人员待定，在需求评审中，需要提出来，并协商解决。

示例：

小结：

PRD的价值，除了要和各方沟通清楚需求外，PRD也承载了项目管理的职责。

讲需求之前，价值先行。讲价值前，背景先行。讲完背景和价值，要有目标。

而后，需要有可实现的方案，风险预警、时间安排、人员安排。