产品新人进阶之路（1）：功能需求文档

撕裂时间的少年 2023-07-22 21:22:15

本文乃作者应一位朋友要求，将项目分析的经验总结并撰写成文。

我所在的公司将产品文档区分为FRD (Functional Requirement Docs, 即功能需求文档) 和PRD (Product Requirement Docs, 即产品需求文档)。二者各司其职缺一不可，甚至在项目推动进程中，功能需求文档的重要性要高过于PRD。同事经常说，当你输出了一份好的功能需求文档，PRD就只是简单的体力活而已。

一、为什么要做功能需求文档

功能需求文档是人写的，给人看的。在我的认知里，功能需求文档有如下两点价值：

对写的人：通透认知
对看的人：统一认知

产品经理在撰写一份合格的功能需求文档时，需充分调研场景、挖掘需求、分析利弊，梳理逻辑以达到逻辑自洽，一步步推演得出最终的设计方案结论。在这个过程中，产品经理能够以书面的形式整理并反复推演自己的逻辑，帮助自身深入理解需求，理解“为什么要做、为什么这么做”。

而项目组里的同事，原先对产品需求、方案解决的问题是几乎一无所知的。产品经理要在一个短短的评审中将“为什么要做、为什么这么做”说透，则需要功能需求文档的支持。一份功能需求文档就像一份项目Kick Off的ppt，帮助视觉、开发等同学快速把对方案的认知拉到与产品接近的水平。

因此功能需求文档是一面镜子，帮产品经理自清；也是一剂催化剂，帮项目成员迅速catch up。

二、写功能需求文档前的思路准备

1. 需求场景分析

开门见山的，往往是最重要的，也是最考验的。

我惯用的分析流程是需求来源、场景还原、痛点追溯。

（1）需求来源是对于需求的数据具象

如今产品经理收到需求的途径有很多，业务同学的反馈、用户的满意度调研、用户的使用数据、竞品的调研报告、产品对于世界动向的感知等等。每个声音途径的权重是不同的，各家产品经理需要表述清楚本期项目的需求具体来自哪个途径，并将需求声音的强度进行数据化表达。

比如我们公司用jira管理业务同学的反馈，则在明确需求来源时，就可以搜集提过该需求的jira数量，以此初步定量需求声音的强度。

（2）场景还原是对于需求的背景故事补全

需求表达的是“用户想要的方案”，而且用户往往会在其中掺杂某些“自以为是”的产品方案设计。因此产品需要做的是抓着用户需求的藤蔓一路向上，到达的第一级便是场景还原。

还原出明确的场景，有助于产品对需求跃然出生动的体感，而非停留在干涩的文字转述。

场景包含三要素：谁、什么条件下、做什么。

其中的核心是「什么条件下」，吃透条件有助于判断该需求的频次。

（3）痛点追溯是对于场景的刨根问底

还原场景后一定要记得多做一步——再多问2个问题：用户为什么要做这件事？在做这件事时遇到了什么问题？如果不刨根问底，就容易掉进“场景陷阱”，以为已抽象到最底层了。

比如我们本月遇到用户提出打卡作业需要一次性布置多份内容不同的主题，经分析后我们发现用户的场景是“在未复学前安排老师做线上的打卡集训营”。有的产品经理此时已觉得分析到位，需求了然于胸，于是找了几个做打卡集训营的竞品研究研究，就准备输出产品方案了。这样就容易沦落到无脑的抄袭照搬中。

正确的方式是深入到用户中，挖掘场景背后的目的。用户要做打卡集训营是想通过内容进行引流获客，因为疫情期间无法线下引流，线上投放又对转化率和现金流要求较高。因此我们除了满足打卡的基础工具支持外，还需要搭配营销解决方案，甚至与平台内的其他投放渠道进行联动，帮助用户获取更多曝光。甚至如果能找到一种更好的线上获客方式，我们完全可以不提供打卡工具，也能够满足用户。

需求场景分析就是抽丝剥茧、寻根溯源的过程，把需求还原成场景、把场景还原成痛点。在这个过程中，对要解决的问题、要达到的目标会愈加清晰。

2. 竞品方案分析

明确需要解决的问题后，建议找几款已然能够较好解决该问题的产品，深入分析后作为参照。新手产品在接触一款新的产品时往往会束手无策，尤其遇到复杂的产品时，容易迷失在眼花缭乱的页面中。此时要注意竞品的分析方法，并且找到能与我们问题对标的具体功能，只取一瓢饮即可。

（1）竞品功能定位

明确竞品的功能定位：给谁用的？做什么用的？做成什么样？

比如在研究竞品的打卡功能时，发现竞品将打卡类型区分为“打卡课程”、“作业课程”、“解锁课程”、“专栏课程”4种，此时则应该通过区分竞品提供的功能差异，明确这4种类型分别对标什么使用场景，不同的场景中用户关注的信息分别是什么、管理动作是什么。

举个“打卡课程”和“作业课程”的例子。

竞品提供的功能中，打卡课程和作业课程的核心区别有3：

在创建方式上，打卡课程创建时有开始与结束时间；而作业课程没有；
在子任务生成方式上，打卡课程在创建完毕后，系统会根据设置的时间范围创建出对应的子任务列表；而作业课程创建后无子任务列表，仍需用户自行在课程内创建；
在数据统计上，打卡课程侧重打卡完成进度和时间进度的比较；作业课程侧重子任务数以及作业提交的份数。

从这些功能差异点上，还原出各自对标的场景：

打卡课程满足的场景，是用户需要布置一个有始有终的打卡任务。如英语教育机构内常见的每日打卡活动，从固定日期开始，到固定日期结束，每日打卡学习的内容均不相同。机构管理者关注的重点，是学员是否每日按要求完成打卡任务。

作业课程满足的场景，是用户以一个课程或一个班级为单位去统一管理作业。如培优辅导机构内老师经常会在课后给学员们布置提高题，机构就可以在建班时为这个班级创建一个作业课程，这个作业课程自身无必要设置开始与结束时间，因为班级的周期可以非常长也可以很灵活。老师需要布置作业时，在课程内添加作业子任务即可。机构管理者关注的重点，是总共布置了多少次作业，学员又提交了多少。

（2）竞品概念模型

经验丰富的产品可以通过测试，反推出竞品的概念模型：有几个实体？实体和实体间的关系是什么？

同样以上文中的竞品举例，分析后不难发现，竞品存在“课程”和“子任务”两个系统。子任务是依据课程的规则生成的。老师创建课程后，系统依据规则生成对应的子任务，将课程分发给学员后才可生成学员的课程。学生提交作业的过程，就是提交与子任务关联的答案。

产品经理，产品经理网站

由于概念模型不是本文重点，图中仅绘制了流程中涉及的核心实体，实体的具体属性及其他关联实体，这里不作展开。

（3）竞品功能使用流程

测试竞品的功能主流程、异常流程，有助于我们在异常流程的设计中做参照。

3. 核心方案抽象

心中有了远方 (需求场景分析) ，手里也有了地图 (竞品方案分析) ，剩下的就是设计路线了 (核心方案) 。许多产品经理在设计核心方案时容易照搬竞品的方案，这里建议采用“否定分析法”，确保功能是充分且必要的。

比如竞品设计了打卡具备独立的打卡介绍页，支持富文本编辑。新手产品也许会想：“嗯这个功能不错，我要抄过来”，但却忘了多思考一步——打卡子任务也有内容，打卡介绍页也有内容，为什么两边内容要分开做？不给用户提供打卡介绍行不行？

要回答这个问题，则需要思考清楚打卡介绍和打卡子任务的不同定位——打卡介绍，正常的用法是用于介绍一份打卡作业，相当于书的封面，吸引别人把读；而打卡子任务则相当于书的内页，是正文内容。

因此需要打卡介绍的场景，更多是要用图文介绍的方式吸引潜在客户参与，对于现有客户的客情维护则不需要打卡介绍。而我们的客户由于行业及规模属性，几乎没有面向潜在客户打卡的场景。

这样分析下来，就能得出与深入思考前相反的结论：打卡介绍对我们而言是一个不必要的功能，不做。

三、功能需求文档的表达方式

即便思路清晰万事俱备，语言表达也是文档中不容小觑的重要一环。好的表达方式能够给FRD加分，差的表达则容易蒙蔽FRD中思维的闪光。每个人有自己惯用的语言组织方式，这里仅列举几个能给文档加分的表达小技巧。

1. 举例代替描述

需要注意在描述场景时，尽量讲具体、完整的用户故事，新手产品要避免抽象模糊的需求描述。用户故事最好有实例支撑，如用户调研时获得的某个经典素材，甚至是与用户沟通时的聊天截图。

比如“调研发现A机构在疫情期间无法线下开课的情况下，选择采用微信群内打卡接龙的方式，与学员保持高频沟通，圈住学员。A机构采用的打卡频次为每日一练，每日内容为机构老师精心选择（配上内容案例），会在当晚12点前准备好第二天学员打卡的内容”，这样的表述，就会好过“调研发现，机构有每日打卡的需求”。

2. 图表代替描述

尽可能避免大段文字，长文对于开发同学来说看着会较为费劲。撰写文档时可以考虑用ppt绘制结构性的内容；用表格表达多维对比；用processon绘制用户使用流程。

3. 一次说清一件事

请记住：不同流程不要混在一个流程图里，不同系统不要混在一个概念模型package里。

新手产品往往容易犯把所有信息塞在同一张图里的错误。比如流程图时把多角色多流程放一起，不仅绘制流程图时指向线很多，难以表述，而且读者的理解成本也很高。建议如遇这种情况，分开绘制，一个流程画一张图，一次说清一件事。

4. 阶段性结论

较大项目在功能需求分析时抽丝剥茧层层深入，篇幅较长，建议阶段性给一个结论，且实际的可往下执行的结论。如场景分析part，结论是“哪些场景已覆盖、哪些未覆盖，本期重点覆盖哪些”；竞品分析part，结论是“竞品哪些点值得学习，哪些虽然涉及精巧但不符合我们受众人群，哪些不值得借鉴”；项目方案part，结论是“本期有哪些重点方案要做，为什么做，解决什么问题”。

像这样的阶段性总结，可以帮助你把思路一个个串起来，也能让听的人顺着你的思路走，不走神不跑偏。