产品经理这岗位都多少年了，我还以为早就体系成熟、流程闭环了，所以这个系列我也安心停更了。
结果最近被研发同事轮番吐槽：需求文档东漏一句西漏一段，“这也叫专业？”
虽然不是在点名骂我，但谁让是我带的队呢，脸还是要我来红……
于是我，一个曾立志不再写基础规范的人，现在又默默打开了“手把手教你系列”的草稿页。~~
老规矩，事先声明：本文是写给产品新人的一个指导方向，别指望面面俱到，主要是帮你少挨点骂、少被群嘲。如果你是产品大牛，那我更希望你能站出来写一篇“不被研发吐槽的终极需求文档指南”，拜托了，真心在线等
不讲假大空，就讲人话。
对于产品新人来说，产品需求文档的核心意义只有两个词：“明确” 和 “可做”。
就是别写那些虚头巴脑的虚词、副词，需求文档里应该尽量只出现三种词：名词、动词、量词。1）先说“虚词”
虚词就是介词、连词、助词、叹词这些——这些词基本是语文老师教你写作文用的，但在需求文档里，谁用谁挨打。
比如错误的写法：
点击“登录”按钮，需要进行用户名和密码校验吧。
请注意那个“吧”。它是个助词，但在研发眼里，它是个雷区，说出来就是自找“被怼”。你在写需求时用“吧”来表达不确定性，那研发就会用“呵呵”来反馈你的不专业。
再说“副词”
副词看着高级，实则没用。它是修饰动词、形容词等的，比如：
错误示范：
校验成功后，要迅速地进入工作台页面。
请问“迅速地”是多快？光靠感情无法落地。正确写法是：
校验成功后，500ms内进入工作台页面。
给出量化标准，才叫明确。不然你以为你是写诗的？
就是这玩意真的能做出来。
别写那些感天动地但做不到的需求。比如早些年讨论的很激烈的一个需求：
手机壳颜色要能根据用户心情变化。
听起来是不是很酷？是。但你们公司八成没这个技术。
甚至你们连怎么判断“用户今天心情好不好”都不知道——那你让研发怎么做？
再比如下面这个需求，看似合理，实则扯淡：
密码校验成功后，需要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天前的口述群聊记录，只有文档说了算。
作者：光点神奇，微信公众号：产品研究所
本文由 @光点神奇 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图由作者提供
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。