来自阿里的一份需求文档（PRD）

一篇好的需求文档，能提高研发效率，减少沟通成本，自己也是踩了不少坑，和做产品的朋友也交流了很多，现在总结出了一份相对比较完善的需求文档，希望能帮助到有需要的小伙伴。

01

为什么需要需求文档？

对于产品经理而言，就是一份约束手册，所有的需求都是经过再三推导和验证得出的，不是拍脑袋决定的。

对于研发而言，就是开发范畴的范围手册，避免后续产品变卦，之前我出的需求，一旦涉及变更，研发要求一定要更新在文档上，他们只认文档，不认产品。

对于测试人员而言，作为后续验收测试的标准。

当然一份好的需求文档，也是为了方便后续查阅。人的记忆总是会随着时间的推移而逐渐消退。对于后续新接手这个项目的相关人员也是大大有益的。

02

需求文档有哪些结构？

1.文件名：项目名称+版本号

关于版本号的定义，这里我说明一下。

通常情况下，版本号采用X.Y.Z格式，X、Y和Z为非负整数。X是主要版本号，Y是次要版本号，Z是修订版本号，每个版本号按数字增加，如：v1.8.0 –> v1.9.0 –> v1.10.0

X代表的是：主版本号

如产品的主要功能有较大变动、产品的整体结构改变等重大的改动情况，则在X的数字基础上+1。

Y代表的是：次要版本号

当在产品原有的基础上增加部分功能，且并不影响产品的整体流程或业务，则更新后会在B的数字基础上+1。

Z代表的是：修订版本号

在解决缺陷或者细微功能的扩充时，则在Z的数字基础上+1。

2.文档要素

1）需要变更记录

需求虽然评审确认了，以为不会再有什么差错了，但是会发现研发过程中，还是会遇到各种各样的问题，可能导致需求的变更，这时，需要变更的需求要被一一记录，并再次评审确认，如果影响上线时间，也需要跟相关业务或者业主同步上线时间。

2）研发时间及人员

需要罗列出产品、UI/UE、前端、后端、测试、部署（预发、生产）对应的人员名称和所需要的时间，如开始时间、结束时间，如果时间有延迟，需要添加实际开始时间、实际结束时间。

3）工时评估

将需求功能清单罗列，将功能点尽量罗列清楚，罗列的越清楚，研发评估工时越准确，后面分为UI、前端、后端、测试，等需求评审通过后，让相关负责人填写相应工时，产品经理再根据工时，就可以确认提测和上线时间了。

4）需求背景和列表

每个版本里面的需求，有些需求满足项目交付，有些需求提升用户体验，有些需求丰富产品功能，提高产品竞争力，将版本需求描述清楚，方便研发人员对需求的理解。

需求列表，内容有一级模块和二级模块名称和描述，方便研发人员对这个版本有个大致的了解。

5）名词解释

如果此版本需求里面有些比较晦涩的名词，可将这些名词加以介绍，方便研发对业务和需求的理解。

6）产品总逻辑图、细分业务的时序图

如果设计的软件或平台，里面的功能和流程相对比较复杂，需求涉及的人员角色和流程比较多，最好用流程图梳理一下，有利于产品经理对业务的梳理，防止某些流程和场景的遗漏，也方便业务对产品需求的理解。

除了产品总的逻辑图，遇到一些状态变化较多的需求可以用时序图，比如登录流程、用户交易流程等等。

电商网站用户购买业务流程

话费充值app时序图

7）页面原型及说明

分不同模块，将原型页面贴到需求文档上，可以分为需求说明和功能说明，需求说明就是总体介绍一下这个需求，有哪些模块，用户能用来做什么，解决了用户什么痛点；

功能说明大致有以下内容：

• 前端展示元素：用户登录进到页面会看到什么内容?

• 用户操作反馈：可点、不可点，点了之后页面的反馈是什么？Toast、弹窗、按钮变化等等。

• 异常极值考虑：网络异常、用户状态异常、数据反馈异常，遇到极值场景如何处理等等。

03

注意事项

1.需求场景遗漏

关于这一点，我的看法是再牛叉的产品也做不到能考虑到全部的用户使用场景，做到滴水不漏。

我们能做到的就是尽可能的模拟用户的使用场景，将可能的场景全部罗列出来，按照不同的场景去梳理流程和需求，尽量做到整个业务逻辑完整能闭环、需求表达清晰无误解。

文档前后逻辑能形成闭环，不自相矛盾，覆盖的场景要尽可能的全，不存在较大逻辑缺陷。多问几个为什么，考虑问题更深层点。

整个需求文档表达中，无论是文字标注还是图形呈现，需要做到让研发和测试不会产生歧义和误解。

需求文档撰写完成，会进行需求评审，但不要想着等着需求评审，研发测试会帮你找到一些逻辑漏洞或需求没有考虑清楚的地方，会议上研发不会听的那么详细，评审只会暴露出一些大的流程问题，很多小问题只有在真正研发过程中才能被发现。

但在研发过程中如果暴露出很多问题，会让研发觉得产品经理没有想清楚，这样的事情发生多次，会影响产品经理的公信度，让研发觉得这个产品不靠谱。

所以产品经理思考需求和流程时，尽量考虑全面，撰写完成后，自己模拟用户走一遍流程，不然会因为需求文档描述的不清晰，会极大的增加沟通成本，严重的会使得研发返工，影响版本上线时间。

2.写需求过早陷入交互细节

产品拿到需求，很多刚入行的产品经理，有想法之后会直接开始绘制原型，绘制页面跳转和交互，页面色彩使用丰富，交互设计的很炫酷。

但最后发现原型绘制完了，因为对需求的业务场景、用户群体没有详细深入的了解，发现原型并不能解决用户的需求，导致之前的工作要整改甚至推到全来，之前的努力全部白费。

我发现，确实很多转行或者刚入行的产品经理都把重心放在原型和交互上，其实是本末倒置了，原型这种基础的能力小白也可以做，但产品经理最核心的工作是什么呢？是需求的收集和调研，加强对业务和用户的理解才是最重要的。

3.写需求的视角从阅读者出发

要知道需求文档是给谁写的，主要服务于谁，不要产品经理自己写嗨了，看的人一脸懵逼。

产品经理写需求的过程中，大多数都是从自己的视角出发，其实一个好的需求描述，需要从阅读者的视角出发，需要有同理心。

有时候一句需求描述，用自己的视角看，觉得没什么问题，因为自己是功能的设计者，会自然而然的代入一部分自己的想法，但是从用户、研发、测试视角看，就觉得会有歧义，会导致最终开发的功能与产品设计会有出入。

04

最后

其实以上所说的，说起来容易做起来还是非常难得，说实话，我也没有做的非常好，因为业务场景和需求描述的问题，也经常会被研发怼。

但是我相信，只要不断的写，不断的总结，那些错误和遗漏的场景就会越来越少。