如何写好产品需求文档？

0.写文当前

0.1端正心态

很多初级产品经理会陷入一个攀比陷阱，看谁文档的“格式好”，内容“丰富”，到处找高大上的模板。这是常有的错误心态，正确的心态，尤其对于小团队，应该是如何让设计师、前后端开发工程师能快速理解业务并能了解接下来各自要做什么。

0.2一半的精力放到业务流程

产品经理要明确业务相关方的实际流程，围绕核心需求，梳理清楚关键的业务流程。

一般会用到泳道图，每个实际的角色是一列，每个业务从始至终在每个角色下要完成那些关键事件，然后按照时间线连接起来。

产出一个泳道图其实是不够的，有条件的话，尽量能知道每个角色在业务环节中的痛点，这就是梳理需求的过程，这些细节也许不会再需求文档中体现，但是需求评审时，可以和设计师、工程师传达。大厂“正规”一些的产品流程里，会用用户画像、用户故事地图、用户体验地图来做更细致的描述。

需求评审时，讲述业务流程或者是重点功能时，可以多讲一些实际的场景，这样设计师、工程师都能发挥更多的效用，对提高整体效率和产品质量都有帮助。

0.3团队磨合

不同的工程师、设计师，可能对文档的预期要求也不一样，对原型的标注方式都有自己的偏好，初加入一个团队，尽量多了解现有团队文档输出的方式，以及团队成员合作的方式，文档最后还是为他人服务的，太繁琐可能会影响可读性。

因此文档的格式，还要照顾到团队具体的情况，不一定“大而全”的文档就是最合适的文档。

接下来详细说下常见需求文档结构，以及每个模块的意义。

1.项目概要

简要说明写项目背景，项目要解决的核心问题，达到的预期效果；利息关联方，大致的排期规划、特殊的要求。

目的是让所有成员明确项目的整体情况，多项目协调中明确资源倾斜程度。该部分简洁有力即可，千万不要为了高大上，写得又臭又长。

2.版本记录。

每个版本、排期开发的内容，好追溯，前后端测试一般错开一个小版本的，前后端工作看的版本可能不一样。

3.流程逻辑

3.1业务流程、角色用例。

项目实际业务涉及的全部业务流程，哪些流程在本次项目体现，哪些是重点流程。

外贸ERP代理流程.png

目的是让项目组了解项目业务的整体概要，后续做具体功能实现，焦点能不偏离核心。

3.2功能流程、状态转移图

某些复杂的功能，需要再额外画一下功能流程、状态转移图。

功能流程，特别实在条件判断多的业务逻辑经常用到，产品经理因梳理好。比如注册登录、下订单，后台需要很多逻辑校验，

状态转移图，一些单据会有很多状态，产品经理需要描述清楚，状态之间的转移关系，以及对应具体的功能。比如订单状态：草稿、待支付、已支付、发货、收货、退款、删除，那些操作会让状态发生变化。有时候，可能同一种状态在不同页面、用户展示的描述也不同，都需描述清楚，以免误会。

4.术语、规范解释

文档可以约定一部分术语，目的在于统一团队认知，减少误会。

术语包括项目本身涉及的专业词汇、文档描述的约定（比如[模块]、【单据】可能在文档中会用不同的括号标注，方便大家快速理解）。

5.功能模块详细需求

描述每个功能的详细内容，三大类，列表页、编辑页、公共组件

5.1每个模块的列表页，描述：

列表展示的字段含义：展示哪些字段

列表数据范围：展示哪些数据，可能和用户、角色、状态都有关系

行操作：删除、编辑等
批量操作：

列表默认排序规则

列表筛选的需求

核心的业务逻辑说明：比如涉及权限等关键逻辑

交互要求

5.2.每个编辑页：

每个字段的含义
字段的类型、长度要求
字段是否必填

页面操作：保存、提交、返回等。

交互要求：包括跳转逻辑，操作后返回到哪里！

有必要时，可以关联具体的功能流程。

5.3.公共组件

如果有不常见的组件，特殊的树装菜单、选择控件，可以单独整理，方便交互、开发统一设计。