产品经理这岗位都多少年了，我还以为早就体系成熟、流程闭环了，所以这个系列我也安心停更了。

结果最近被研发同事轮番吐槽：需求文档东漏一句西漏一段，“这也叫专业？”

虽然不是在点名骂我，但谁让是我带的队呢，脸还是要我来红……

于是我，一个曾立志不再写基础规范的人，现在又默默打开了“手把手教你系列”的草稿页。~~

老规矩，事先声明：本文是写给产品新人的一个指导方向，别指望面面俱到，主要是帮你少挨点骂、少被群嘲。如果你是产品大牛，那我更希望你能站出来写一篇“不被研发吐槽的终极需求文档指南”，拜托了，真心在线等

一、产品需求文档的意义

不讲假大空，就讲人话。

对于产品新人来说，产品需求文档的核心意义只有两个词：“明确” 和 “可做”。

1. 什么叫“明确”？

就是别写那些虚头巴脑的虚词、副词，需求文档里应该尽量只出现三种词：名词、动词、量词。1）先说“虚词”

虚词就是介词、连词、助词、叹词这些——这些词基本是语文老师教你写作文用的，但在需求文档里，谁用谁挨打。

比如错误的写法：

点击“登录”按钮，需要进行用户名和密码校验吧。

请注意那个“吧”。它是个助词，但在研发眼里，它是个雷区，说出来就是自找“被怼”。你在写需求时用“吧”来表达不确定性，那研发就会用“呵呵”来反馈你的不专业。

再说“副词”

副词看着高级，实则没用。它是修饰动词、形容词等的，比如：

错误示范：

校验成功后，要迅速地进入工作台页面。

请问“迅速地”是多快？光靠感情无法落地。正确写法是：

校验成功后，500ms内进入工作台页面。

给出量化标准，才叫明确。不然你以为你是写诗的？

2. 什么叫“可做”？

就是这玩意真的能做出来。

别写那些感天动地但做不到的需求。比如早些年讨论的很激烈的一个需求：

手机壳颜色要能根据用户心情变化。

听起来是不是很酷？是。但你们公司八成没这个技术。

甚至你们连怎么判断“用户今天心情好不好”都不知道——那你让研发怎么做？

再比如下面这个需求，看似合理，实则扯淡：

密码校验成功后，需要1ms内进入工作台页面。

拜托，1ms？你以为你写的是芯片设计规范吗？这违背客观规律，纯属“想当然”。

二、需求文档有没有固定格式？

答案是：没有。

不同公司、不同团队、不同Leader的口味都不一样。你可能在A公司画个5页原型图就叫文档，去了B公司没画10张流程图都不敢说写完了。

但常见的结构大致是这些：

• 版本记录
• 需求背景
• 产品架构图 / 功能信息图 / 流程图
• 功能清单
• 功能性需求详细说明
• 数据埋点
• 非功能性需求，如比如性能、安全性、兼容性等等
• 等到其他内容，如上线准备清单、测试数据等到

是不是听着有点多？别慌。

对于产品新人，我的建议是：别想着全写全会，一开始只抓关键的三块就够了：

1. 版本记录

这玩意不是装样子，是为了防止后面撕逼。写清楚哪个版本改了什么，谁提的需求，什么时候调整了内容——未来回头看时能对上口径。偶尔有时候研发为了证明自己动了脑子，说了很多高要求的话，然后要他敲代码实现的时候，就会舔着你的脸让你重新改下~~

2. 需求背景

说清楚“为什么要做这个需求”，不要“因为老板说要做”就直接写功能了。产品是为了解决问题，不是为了解决老板。也为了让研发能更好的思考代码怎么敲的更顺畅~~

3. 功能性需求详细说明

这是文档的灵魂部分，研发90%的关注点都在这。

要清晰、要量化、要能落地——怎么触发、触发后发生什么、边界条件是啥、有无异常流程……

把这三块写清楚了，你就已经比一半新人强了。

后面那些流程图、埋点、性能要求等等，等你入门之后再慢慢加，没人一口气写出《PRD完全体》。但写不清背景、逻辑混乱、没有版本记录——这些坑，新人最容易踩。

这

三、产品文档的撰写逻辑

其实写法也没固定套路，可以按功能流程来写，比如“用户从A操作走到B”，也可以按页面逻辑来写，一个页面一个模块往下拆。

我个人更推荐按页面逻辑写。为什么？因为这种方式更“防漏”。你每打开一个页面，就能顺着页面里有哪些按钮、入口、弹窗去列功能，漏点的概率比按流程走低很多。不过你的流程图之类的得说清楚，不然研发可能看的有点头疼。

举个栗子：登录页面

一、版本记录

略
二、需求背景

略
三、功能流程图

略
四、功能需求描述

1、登录页

1.1 显示系统名称及说明：XXX管理系统，东半球最具影响力的系统

1.2 登录方式选择

1.2.1 账号密码登录

略

1.2.2 手机号登录（默认选中）

1.2.2.1 手机号-文本输入框

a. 弱提示：手机号

b. 输入规则：必填，必须输入11位数字，超出后不支持输入。

c. 校验规则：首位只能为1且为11位数字。

d. 报错提示：

1)为空时提醒：请输入手机号

2)手机号不符合校验规则提示：请输入正确的11位手机号

1.2.2.2 验证码-文本输入框

a. 弱提示：验证码

b. 输入规则：必填，最初支持输入6位数字，超出后不支持输入。

c. 校验规则：6位数字。

d. 报错提示：

1）为空时提醒：请输入验证码

2）验证码不符合校验规则提醒：请输入正确的6位数验证码

1.2.2.3 获取验证码-按钮

a. 状态1：未点击状态，默认状态

1）显示文字：获取验证码

2）操作：支持点击之后校验手机号是否为注册用户,不支持连续点击：

2.1）不是则提示“账号不存在，请注册后再尝试”。

2.2）是注册用户，则切换【状态2：60秒倒计时】状态

2.2.1）发送验证码短信。短信内容为：您的验证码为：XXXXXX，验证码有效期为5分钟

2.2.2）如果短信发送成功，则弹出气泡提示：验证码发送成功

2.2.3）如果短信发送识别，则弹出气泡提示：验证码发送失败，请稍后再试。 状态切换为【状态1：未点击状态】

b. 状态2：60秒倒计时

1）显示文字：XX秒，60秒倒计时

2）操作：不可点击

3) 倒计时结束后，切换为【状态3：重新获取验证码】

c. 状态3：重新获取验证码

1）显示文字：重新获取验证码

2）操作：支持点击，不支持连续点击，点击之后效果与【1.2.2.3 获取验证码-按钮】一致。可参考该部分内容。

1.2.3 自动登录-单选框

1.2.3.1 状态1：未选中状态（默认状态）

操作：支持点击，点击切换状态

1.2.3.2）状态2：已选中状态

操作：支持点击，点击切换状态

1.2.4 忘记密码-按钮

操作：点击进入找回密码页面。

1.2.5 登录-按钮

1.2.5.1 点击，校验以下内容：

a 手机号是否为空、是否符合校验规则，不符合则提示：请输入正确的11位手机号

b 验证码是否为空、是否符合校验规则，不符合则提示：请输入正确的6位数验证码

c 校验手机号与验证码是否匹配、验证码是否过期，不符合则提示：验证码错误，请重新输入

d 以上校验全部通过，则弹出气泡提示”登录成功”，并进入工作台页面。

e 异常报错提示：

1）如果无法正常通信，则提示”网络错误,请检查网络后重新尝试”。

2）其他错误，则提示”登录失败，请联系管理员，错误代码1001″

1.2.6 注册账号-按钮，点击，进入注册页面。

1.2.7 帮助-按钮，点击进入帮助页面。

1.2.8 隐私-按钮，点击进入隐私页面。

1.2.9 条款-按钮，点击进入条款页面。

以上这些，就是一份需求文档在具体填写时的基本要求。如果你认真按这个思路写，研发大概能知道该做什么，测试也能明确哪些地方该测、哪些边界要重点关注。

但别太乐观地以为写完就一劳永逸了。

现实是这样的：

你写完后觉得很清楚

• 研发一看：“这个跳转在哪实现？”
• 测试一看：“这个异常状态没写啊？”

所以记住一句话：需求文档是“动态更新”的，不是写完就丢进知识库的PPT。

在开发过程中，有遗漏很正常，但不能“遗漏了就不补”。谁补？当然是你补。

及时修订文档，更新版本记录，标注修改时间和内容 —— 这才是一个专业产品的基本功。

因为到了测试阶段，没人有空翻你10天前的口述群聊记录，只有文档说了算。

相关阅读

思路｜产品新人应如何进行数据分析

思路｜产品新人应如何撰写测试用例（功能性测试）