prd|5000字教你写ToB产品需求文档( 二 )

3）变更记录
用于记录迭代正式开始后的需求变更，便于追溯和复盘。其中，变更类型包含但不限于产品遗漏、逻辑设计缺陷、研发评估遗漏、老逻辑影响、新增业务、临时方案赶工、版本拆分等等。
2. 需求&调研利用金字塔原理，我们先和大家同步了项目的大致规划，让大家心里有了一个底。这一部分，我们就来和团队同步我们是「在解决谁在什么场景下的哪些问题」？
不同于模棱两可、千人千面的C端产品，B端产品往往有较为明确的需求方和用户。那么，我们还有必要向团队再阐述一遍需求到底是什么吗？
当然有必要。
一是因为实现方（研发、测试等）对需求不了解，我们有必要向他们传递需求场景，帮助他们更好设计和架构业务。
二是因为需求方口述出来的并不一定是客户真正的需求。客户往往会提出一个在他们认知范围内较好的解决方案，告诉需求方“我们缺这个功能、我们想要这个功能、没有这个功能不行”。但在真正了解之后，我们往往会发现客户真正的需求不在于此，可能通过别的功能还能更好地解决问题。
这就说明我们需要对需求方收集来的客户反馈进行二次甄别和挖掘，最终再到PRD中把问题背后的本质阐述出来，而仅仅照搬用户反馈则是一种极不负责任的行为。
如下图所示：在需求&调研部分，我们将整体的内容划分为调研信息和需求场景2大模块。

文章插图
一次迭代的调研信息可以分为用户调研和竞品调研，如果还包含其他类型的调研（例如行业调研），可自行加入其中）。
1）用户调研
需求来源于客户。因此，我们要先通过调研客户来初步了解需求。调研报告的内容包括但不限于时间、调研对象、调研数量、客户类型、调研结论、调研人员等，具体视实情而定。
2）竞品调研
知己知彼，百战不殆。在着手实现之前，我们更需要对竞争对手的情况进行调研。竞品调研内容包括但不限于调研时间、调研数量、竞品名称、调研结论等。
这里插一句，常常有人会问竞品调研有没有什么模版，需要做哪些事情？答案其实就一句话：调研只是手段，只要明确了调研目标，从而也就确立了粒度和内容。
3）需求场景
在通过问卷、访谈、观察等调研手段之后，我们便能够初步归纳出用户的需求场景。当然，只有产品经理知道是远远不够的，我们还需要将这些成果同步给团队，保证让大家就需求场景的理解达成一致，即告诉大家我们在解决xx用户在xx场景下的xx问题。
这里，笔者推荐用户故事和用例图2种工具。
故事往往充满感情，更立体也更容易打动人。因此，用户故事User story是从感性的角度出发，让我们向大家讲述一个典型用户的故事：他们是一群怎样的用户、他们在什么场景下遇到了什么问题、他们的情绪怎样、现在他们是怎么处理这些问题的。
而源自于UML的用例图则更为理性。它能清楚地告诉研发本次迭代中涉及到哪些角色、每类角色的需求及边界、不同需求之间的关系是什么等等。
通过第二部分的需求&调研模块，能够帮助团队成员在脑海里树立一个亟待解决问题的用户形象出来，我们能够知道他有哪些问题、也能尝试感知他的情绪。
3. 方案信息方案指我们需要做哪些功能来帮助用户解决问题。从篇幅上来讲，方案信息是整个PRD的大头部分，也是新人最为关注的内容；但随着经验的增长，处于实现层的方案文档撰写能力将逐渐转化为一种基础能力，而不是竞争性能力。
可能有些人会对文档撰写不屑一顾，但笔者认为这是产品经理对外的第一张名片。产品经理本身是一种无授权的团队leader，我们需要通过递出一张张合格甚至优秀的名片来建立团队影响力和信任感。因此，一个好的文档撰写能力至关重要。
我们将方案信息划分为3大版块：方案规划、方案内容、埋点信息。

文章插图
1）方案规划
在着手开工之前，我们先需要向团队讲清楚这一次我们大致准备怎么做。方案规划的内容包含但不限于分期规划、满足场景、需求清单（粗略版）、目标价值、衡量指标、风险评估等。

分期规划：B端客户的需求往往庞乱而复杂，当我们面对的客户群体标准化程度较低、个性化需求较多时，可能会选择分期解决、小步快跑，先满足核心主流场景，再逐次完善分支异常场景。所以，当我们决定分期解决问题时，就需要提前向大家告知清楚。
- 上一页
- 1
- 2
- 3
- 4
- 下一页