产品经理要发现需求，而不是复制已有的需求。功能需求文档能够帮助产品经理深入理解需求，理解“为什么要做、为什么这么做”。

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

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

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

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

对写的人：通透认知

对看的人：统一认知

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

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

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

二、写功能需求文档前的思路准备 1. 需求场景分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 竞品方案分析

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

（1）竞品功能定位

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