0.写文当前
0.1端正心态
很多初级产品经理会陷入一个攀比陷阱，看谁文档的“格式好”，内容“丰富”，到处找高大上的模板。这是常有的错误心态，正确的心态，尤其对于小团队，应该是如何让设计师、前后端开发工程师能快速理解业务并能了解接下来各自要做什么。
0.2一半的精力放到业务流程
产品经理要明确业务相关方的实际流程，围绕核心需求，梳理清楚关键的业务流程。
一般会用到泳道图，每个实际的角色是一列，每个业务从始至终在每个角色下要完成那些关键事件，然后按照时间线连接起来。
产出一个泳道图其实是不够的，有条件的话，尽量能知道每个角色在业务环节中的痛点，这就是梳理需求的过程，这些细节也许不会再需求文档中体现，但是需求评审时，可以和设计师、工程师传达。大厂“正规”一些的产品流程里，会用用户画像、用户故事地图、用户体验地图来做更细致的描述。
需求评审时，讲述业务流程或者是重点功能时，可以多讲一些实际的场景，这样设计师、工程师都能发挥更多的效用，对提高整体效率和产品质量都有帮助。
0.3团队磨合
不同的工程师、设计师，可能对文档的预期要求也不一样，对原型的标注方式都有自己的偏好，初加入一个团队，尽量多了解现有团队文档输出的方式，以及团队成员合作的方式，文档最后还是为他人服务的，太繁琐可能会影响可读性。
因此文档的格式，还要照顾到团队具体的情况，不一定“大而全”的文档就是最合适的文档。
接下来详细说下常见需求文档结构，以及每个模块的意义。
1.项目概要
简要说明写项目背景，项目要解决的核心问题，达到的预期效果；利息关联方，大致的排期规划、特殊的要求。
目的是让所有成员明确项目的整体情况，多项目协调中明确资源倾斜程度。该部分简洁有力即可，千万不要为了高大上，写得又臭又长。
2.版本记录。
每个版本、排期开发的内容，好追溯，前后端测试一般错开一个小版本的，前后端工作看的版本可能不一样。
3.流程逻辑
3.1业务流程、角色用例。
项目实际业务涉及的全部业务流程，哪些流程在本次项目体现，哪些是重点流程。
目的是让项目组了解项目业务的整体概要，后续做具体功能实现，焦点能不偏离核心。
3.2功能流程、状态转移图
某些复杂的功能，需要再额外画一下功能流程、状态转移图。
功能流程，特别实在条件判断多的业务逻辑经常用到，产品经理因梳理好。比如注册登录、下订单，后台需要很多逻辑校验，
状态转移图，一些单据会有很多状态，产品经理需要描述清楚，状态之间的转移关系，以及对应具体的功能。比如订单状态：草稿、待支付、已支付、发货、收货、退款、删除，那些操作会让状态发生变化。有时候，可能同一种状态在不同页面、用户展示的描述也不同，都需描述清楚，以免误会。
4.术语、规范解释
文档可以约定一部分术语，目的在于统一团队认知，减少误会。
术语包括项目本身涉及的专业词汇、文档描述的约定（比如[模块]、【单据】可能在文档中会用不同的括号标注，方便大家快速理解）。
5.功能模块详细需求
描述每个功能的详细内容，三大类，列表页、编辑页、公共组件
5.1每个模块的列表页，描述：
列表展示的字段含义：展示哪些字段
列表数据范围：展示哪些数据，可能和用户、角色、状态都有关系
行操作：删除、编辑等
批量操作：
列表默认排序规则
列表筛选的需求
核心的业务逻辑说明：比如涉及权限等关键逻辑
交互要求
5.2.每个编辑页：
每个字段的含义
字段的类型、长度要求
字段是否必填
页面操作：保存、提交、返回等。
交互要求：包括跳转逻辑，操作后返回到哪里！
有必要时，可以关联具体的功能流程。
5.3.公共组件
如果有不常见的组件，特殊的树装菜单、选择控件，可以单独整理，方便交互、开发统一设计。
