5000字教你写ToB产品需求文档( 三 )

当然有必要。
一是因为实现方（研发、测试等）对需求不了解，我们有必要向他们传递需求场景，帮助他们更好设计和架构业务。
二是因为需求方口述出来的并不一定是客户真正的需求。客户往往会提出一个在他们认知范围内较好的解决方案，告诉需求方“我们缺这个功能、我们想要这个功能、没有这个功能不行” 。但在真正了解之后，我们往往会发现客户真正的需求不在于此，可能通过别的功能还能更好地解决问题。
这就说明我们需要对需求方收集来的客户反馈进行二次甄别和挖掘，最终再到PRD中把问题背后的本质阐述出来，而仅仅照搬用户反馈则是一种极不负责任的行为。
如下图所示：在需求&调研部分，我们将整体的内容划分为调研信息和需求场景2大模块。

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