作者简介：小6，世界五百强产品出身，电商、零售行业多年，从0到1搭建公司IT团队和10个内部系统，现任深圳某互联网公司IT负责人。
愿景：希望可以让你在这里从对产品经理的一无所知到至少能找份相关工作!
【tips】：小6的本篇内容全文较长，但看完真的会对你的需求文章产出能力有所提升。
深圳这几天下大雨，早上看朋友圈有几个人发的“今天深圳的雨比依萍去见她爸要钱那天的雨还大”，也是有趣，大家出门还是要注意下。
周末跟之前的开发同事聚了一下，他跳槽了几家公司，在吐槽他们的产品经理，写的需求文档，真是一言难尽，记得之前他评价过我们公司的产品经理，是真的“把肉喂到开发嘴边去”，需求文档特别细，写代码看着就很舒服，省事太多。
是啊，这也是我一直要求的，不单单是产品经理，任何岗位都是，都要对自己的下游同事负责，这样整个团队的运转效率才是高效的。
当开发和测试不再吐槽你的需求文档了，你的产品专业就更上了一个台阶，你们的团队也会更和谐了。
因为我是做电商系统的，中后台，我就聊聊这方面的需求文档，应该怎么写，延伸下其实整个B端的产品经理，都可以参考下的。
产品需求怎么写
首先要明确几个问题
首先，我们明确两个问题：
1) 需求文档的目的
需求和功能实现的中间环节，需要一个媒介，可以将产品经理的功能设计描述清楚，这是最主要的目的。其次对于一个项目，所有的材料也需要沉淀。
2) 需求文档的面向对象
面向对象有两部分，一是现有项目成员，设计、研发和测试，需要按需求文档进行功能开发测试工作;二是后续新人，需要按需求文档熟悉现有功能。
综上，需求文档应该具有简单、明确、通俗几个特点，也就是说用最简单的设计、最明确的流程、最通俗的文字来实现用户最复杂的需求。
需求文档的前言部分
1) 文档状态
也就是我们整篇文档的前奏，用来描述文档的一些基本信息。比如文档状态(初稿、副稿、终稿等)、文档名称(WMS系统二期文档)、版本号(V2.3.6)、作者、部门、完成时间、基本概况、保密级别等，对这篇文档给出一个最基本的说明。
2) 方案概述
我们对于这个需求的整体方案描述是怎样的，这里面会牵扯到哪些点，同时也需要将这个方案同步给需求方，以确保两边信息一致。
在方案阶段也需要说明需求的背景和目的，是因为什么原因我们要开发这个功能，它的价值是什么，它上线后会给公司或者整体系统带来什么样的改变等。
3) 要素定义
要素定义指的是一些专业词汇的解释。这个描述清楚，将有利于研发和测试的理解，更好地开发需求。道理很简单，产品经理作为技术团队对外人员和产品的设计者，他会对很多专业词汇有一定了解，但是其他技术人员不会。
比如开发Amazon损益表，里面有个字段叫“计提货损”，这个如果不解释下，估计很多人都不明白。感兴趣的小伙伴可以查下这个词。
4) 权限说明
有些习惯放前面说清楚，有些习惯放后面，都可以。权限说明指的是你要做的这些菜单，哪些按钮要做角色权限，哪些字段要做数据权限等，尤其是数据权限，不建议大家固定几个字段，可以单独做一个数据权限控制的菜单，管控所有字段，这样会灵活很多。
5) 测试要求
需求文档除了研发用来开发需求外，测试也会，这里为什么会强调写测试要求，是因为有些功能对于测试而言，是可以不测的，或者说应该有一定的特殊要求。比如我们的python，爬去amazon的一些review，如果涉及到竞品，数据体量超级大，这就需要说明一些测试要求。
如何撰写优质的产品需求文档
需求文档的表单字段部分
表单就是我们说的菜单的界面，要展示什么内容。
1) 整体描述
对于这个菜单的取值逻辑整体方案描述，说明这个菜单的数据是如何产生的，比如是按xx时间从xx菜单根据xx脚本产生的等，提供大家一个基本的认知。
2) 菜单路径
要写明这个菜单在哪，尤其是新菜单需求，因为后续要配置菜单路径、按钮等，也方便你查看。
3) 字段名称
这个菜单要展示的所有字段，在需求文档里一定要和原型图的顺序保持一致，一定!而且这个顺序也是有学问的，哪些字段比较重要，关注较多，哪些字段存在关联关系，都需要你考虑到位。
后续针对菜单的优化，如果有增加的字段，也要写清楚这些字段的位置，比如新增“总金额”字段，位于“总数量”字段右侧。
4) 取值来源
这个是讲如何取值的，从哪些菜单根据什么规则取来，是否是计算的，还是根据某些字段关联，又或是自己添加，或者系统的自动生成的时间等，是需要保存下来还是动态查询即可。
比如“一级站点”字段，取值来源为根据“二级站点”关联【站点管理】对应的“一级站点”，保存。
再比如我们一个菜单统计实时的“销售数量”，取值来源为统计时间为当天的【销售订单列表】状态为“shipped”的数量合计，动态不保存，这种每次点开需要查询一次，所以不应该保存。
5) 取值表名
如果是从另外的平台获取而来，比如api拉的京东的报表，或者Amazon的报表，需要将报表的字段来匹配我们自己系统的字段，这就需要说明你要拉的这张报表的名字，并且需要把表的路径描述清楚。
6) 取值表字段名称
同第5点，这个就是描述两张表一一对应的字段，这里要说明下，如果拉下来的是中文报表，除非与系统相冲突，否则是建议保留原始表字段名称的，业务方更容易理解。如果是对接Amazon的数据，可以找一个业务方来翻译下，谷歌直译的内容很多还是“挺惨”的。
7) 字段举例
顾名思义，举例让大家看下，也是为了更好的理解。
需求文档的查询条件部分
方便大家筛选想要的内容而增加的一些条件，顺序一样需要与原型图保持一致，后续优化新增的查询条件也是要写清楚位置。查询条件的格式有很多种，大致分以下几点：
1)文本格式
需要写明能支持什么类型的内容输入，比如文字，比如数字;是否支持多个内容查询，多个内容查询中间需要用什么符号隔开;只支持精准查询还是可以支持模糊查询，模糊查询是单边模糊查询还是两边模糊查询，针对模糊查询这里有个技巧，就是数据量，数据量大的表单尽量减少模糊查询，很影响用户体验。
2)下拉框格式
可以是某些控件，比如日期;是固定的内容还是从别的地方动态取出，要不要去重;默认是为空还是某个值，支持单选还是多选;是否支持模糊查询(下拉框本身的模糊查询)。
3)复选(单选)格式
这算是另类下拉框格式吧，只是把内容全部放在外面了，可以同时选中多个或一个条件进行查询。
4)开关格式
类似第3点，也是一种选择格式，不过这个基本上是只能单选。
5)时间格式
这里单独讲一个时间格式，年份啊月份啊，或者到天到秒，很多封装好的控件都可以，到秒，需要注意下，如果是个范围的查询，那么前区间的需要到00:00:00，而后区间的需要到23:59:59，要不然查不出来，这是很多人会犯的一个错误。
6)最后注意一点
要说下样式，尤其是比较特别的，比如你的查询条件是收缩的，默认展示多少行等，要跟原型图保持一致。
需求文档的功能按钮部分
这算是最重要的部分了，也是真正体现一个产品经理水平的部分。
1)查询/搜索
查询算是最简单的按钮了，点击一下根据查询条件查出结果就好，有一个点需要注意下，默认加载页，对于字段很多或者数据量很大的，可以不显示，或者按固定一些条件，否则响应速度很慢会影响用户体验。
2)重置
重置查询条件和查询结果的，一般都会选择重置两者，会更方便，如果有特殊情况，只重置查询条件，保持查询结果不变，也可以，不过不太建议。
3)添加/新增
用于菜单新产生数据，可以按以下几个步骤：
①正常完成情况：
即需要描述清楚在什么条件下，选择哪些内容，可以正常添加成功;
②添加里面的字段：
必填项、非必填项;
字段格式，文本、下拉框、日期、单复选等;
文本格式要说明可以填写哪些内容，比如数字，字段长度要说明;
下拉框格式要说明取值来源，固定哪些字段，还是动态取值哪个菜单，单选还是多选，默认有值还是为空;
日期格式具体是到年、月还是到天、秒。
③校验：
唯一性校验，按xx+xx属于菜单的数据唯一性校验，若有相同的是报错还是覆盖;
匹配性校验，按xx+xx校验是否在哪个菜单存在，或者是否审核通过，如果不满足条件的报错;
校验报错提示需要精确定位，让用户一眼就知道，要不然，就忙坏IT的同学了!
4)编辑/修改
编辑的界面展示基本上同添加，会多几个说明：
①可勾选数量：
是否可以勾选多行编辑，一般只允许一行，这里就需要添加校验，当然没勾选数据的更不可以编辑了。如果是每行数据本身存在编辑按钮，那这个忽略。
②可编辑条件：
很多条件下是不可以再编辑了，比如一个付款申请单，付款状态为已付款，那这个就要禁止编辑，这就是需要写清楚的。
③编辑后的状态：
编辑完成后，这条数据的状态是否要还原最初，尤其是审核状态，因为编辑后很多内容改变了，就需要重新审核。
④其他校验：
同添加一样了，应有的那些校验。
5)删除
删除就是要把数据删掉，有三点需要注意下：
①可勾选数量：
是否可以勾选多行删除，基本上是可以的，如果是每行数据本身存在删除按钮，那这个忽略。
②可删除条件：
很多条件下是不可以再删除了，比如一个付款申请单，付款状态为已付款，那这个就要禁止删除，这就是需要写清楚的。
③删除后的上游数据还原
删除完成后，数据对应的上游数据是否需要还原，还是将付款申请单，从上游传来的，如果删除了，上游的已申请付款金额就要还原，这样才可以继续申请付款。
6)导入(上传)
可以算是批量添加，跟添加类似，但是校验逻辑要比添加多很多。
①支持的文件
一般来说支持Excel，看看哪种格式的，.xlsx/.xls/.csv等，又或者其他格式，如果不属于这种的，导入需要报错提示，同时因为导入模板是固定的，这个每行的字段表头也要校验。
②必填项/非必填项
同添加，哪些字段需要必填项，哪些非必填项，报错后需要提示到第几行，要不然体验太差。
③逻辑性校验
同添加，这里校验的要更多，添加的很多内容界面可以显示出来，导入不可以，所以这里更要考虑全面，报错后一样要提示到第几行。
④重复性校验
若系统中已存在重复性数据，是报错还是可以覆盖。
⑤新增导入
有一种导入就是用于新增数据，系统没有的可以导进去，尤其是涉及到脚本跑出来的，很多是不可以增加数据的，这种新增导入要写清楚。
7)导出(下载)
导出无非三种，勾选的数据、当前页、所有数据，当你的数据量足够大的时候，可以采取异步任务执行，去一个专门的导出菜单慢慢跑数据，跑完了下载即可。这种适合于导出表单，也就是Excel。
如果是表单本身中文内容需要导出英文的，可以加一个语言转化控件，或者简单粗暴一点，固定语言匹配也可以。
导出其他格式就要提前把模板搞好，或者是下载原文件等。
8)审核通过
审核通过这里是统称，可能是初审、复审，可能是运营审核、财务审核，可能是一级也可能是多级，都需要写清楚。
①审核数据量：
审核一定需要勾选数据，但是否支持批量审核，需要注意，大部分支持体验会好一些，如果数据很重要，可以加只支持一条审核的校验。
②审核流：
建议不要固定死，最好是灵活性多级设置，并且是有设置按钮的，不是代码写死，比如按金额设置，多少钱以内一级，超过多少钱需要二级审核。
③下一级审核/数据流向：
审核通过后，下一级审核是到哪里，或者下一步的数据流向哪里，会匹配出哪些字段，哪些内容又会变化。
9)审核驳回
审核驳回也是统称，可能是初审、复审，可能是运营审核、财务审核，可能是一级也可能是多级，都需要写清楚，跟审核通过很多共性，也有一些区分。
①审核数据量：
审核一定需要勾选数据，但是否支持批量审核，需要注意，大部分支持体验会好一些，如果数据很重要，可以加只支持一条审核的校验。
②驳回原因：
这个一定要的，必填项，需要让申请人明确原因。
③数据还原：
审核通过是数据往下走，那审核驳回就是还原数据，比如一个采购合同的付款申请被驳回了，这个合同的申请付款金额就要还原，不能影响后续的付款申请。
④是否可编辑：
如果本菜单的数据审核驳回，这条数据应该可以被编辑的，要不然体验不好，如果是上游流转下来的，就要看情况，是否允许编辑。
10)撤回
撤回也算是自主审核的一个，为了用户发现问题后自主处理。
①撤回数量：
同样需要勾选数据，但是否支持批量撤回，需要注意，大部分支持体验会好一些，如果数据很重要，可以加只支持一条的校验。
②撤回条件：
允许撤回的条件怎样，比如一个付款申请单，当付款状态为已完成，肯定是不允许撤回的。
③数据还原：
当撤回成功，撤回数据本身的字段变化，尤其是审核状态，需要变成最初始的，撤回后下游数据是否要删除，都是需要考虑的。
11)作废/取消
作废有点类似删除，是对不方便删除数据的弃用。
①作废数量：
同样需要勾选数据，但是否支持批量作废，这个基本上都可以支持。
②作废条件：
允许撤回的条件怎样，同样拿付款申请单举例，当付款状态为已完成，肯定是不允许作废的。
③数据还原：
当作废成功，作废数据的上游数据哪些字段需要还原，因为需要让上游数据继续往下走。
12)打印
比如合同，比如付款的单据，很多需要打印功能。
①打印条件：
除了勾选数据外，打印的条件需要考虑，哪些条件下是可以打印的，尤其是设计审核流的，当审核不通过时，是没必要打印出来的。
②打印模板：
这个就是打印出来是什么样，需要提前固定好模板，哪个字段怎么取值，长度、宽度、颜色等，电子签名如何显示，电子签名简单一点，放个图片就好。
13)设置
需要根据某些动态取值确定审核流的，可以用到设置，一般会按审核流+金额(数字)等区分，下一级数值需区别于上一级等。
14)确认/提交
同审核通过，区别这个按钮使用对象一般是自己或者其他部门同级别人员，比较少自己的上级使用，注意的点参考审核通过。
15)复制
对于经常使用且添加相同数据的菜单需要个复制按钮，会方便很多，这个比较简单，一个需要勾选，另一个复制出来的内容，大部分肯定是一样的，需要描述下哪些字段复制出来是空的或者其他取值就好。
16)日志
一般会有这么几项内容。
①操作人：
记录这项操作的姓名，或者用户名。
②操作记录：
操作的按钮，比如添加、编辑、初审通过。
③操作时间：
操作的具体时间，需要精确到秒。
④备注：
记录一些操作内容，比如操作前后的数据变化，或者操作时填写的内容等。
⑤下一级审核流：
涉及到审核的菜单，加一个下一级操作会很方便，当然审核流也可以单独做。
⑥下一级审核流权限：
同5)，让大家可以知道是谁该去处理。
17)入库/出库/调拨
库存功能会有这3个按钮，入库/出库/调拨会涉及这么几点：
①本身字段：
需要填写的数量、入库/出库/调拨地点、涉及到的单号(订单号/需求单号)，有些详细的需要填写仓租量等。
②数据流向：
尤其是出库/调拨，点击出库/调拨后这条数据会流向哪里，这两个按钮还有重要一点，库存数量的变化，入库会导致在途库存减少、在库库存增加、总库存不变，出库会导致在库库存减少、总库存减少，调拨会导致调出方库存减少、调入方库存增加，一般是在途库存增加。
③校验：
入库的比如入库数量不能大于在途数量，或者发货数量，出库数量不能大于在库数量等，有些预出库的在途数量也算，那也可以。库存数量为0的，禁止出库，等等。
④调拨特殊校验：
调拨不同于出库，出库一般是有订单号，不会仓库间出，调拨属于，这里注意每个仓库会有对应的法人公司，不同的法人公司间货物往来需要结算，不仅仅是数量变化了，金额也会涉及，如果财务不允许，也可以禁止。
18)申请付款
跟钱有关的都是大事。
①正常字段：
一般需要填写金额、付款原因，金额如果是很多数据的合计，或者本身就有的，那直接取值就好。
②特殊字段：
比如有些可以使用抵扣，那这里就可以填写抵扣的单据，抵扣的金额，实际申请付款金额就会对应减少。
③校验/流向：
未申请付款金额为0不可以再次申请，审核状态未通过不可以申请，这些都是，申请完后的下游流向也要写清楚。
19)数量拆分
一行数据拆分成多行，这里的校验就是允许拆分的条件，这个还好，重点是拆分后的每行数据每个字段的取值，这个需要写清楚。
20)说明
这个说明是对菜单功能的解释，或者是简单的操作说明，类似于一个文本框，填写保存后可以放在菜单比较显眼的位置，让用户查阅。
21)其他
除了以上的，其他按钮比如付款、退货、兑换、任务分配等，都可以从上面找到共性，重点写清楚按钮的正向条件、逆向条件(报错)、数据流向、数据还原就够了。
需求文档的收尾部分
前面算是完成了90%，还有最后一些说明，也要注意下。
1)默认加载页
也就是进入菜单第一个显示的页面，默认显示每页多少行。对于字段很多或者数据量很大的，一定要考虑清楚，是否可以固定一些查询条件，比如一个几千万行数据的订单菜单，默认加载页的查询条件就可以固定一些日期，只显示当天的，或者只显示10行数据，甚至于可以不显示，这样响应速度就不会很慢影响用户体验。
2)数据初始化处理
尤其是上线新菜单，一定要考虑数据初始化处理，比如需要拉取一些数据的，或者需要跑几个脚本的，要写清楚。
3)历史数据处理
类似于第2点，这里一般是菜单的优化功能，是否会涉及到历史数据处理。
①本菜单
上线后，如果本菜单的字段优化涉及历史数据，比如一个Amazon的库存菜单，新增加了库存金额字段，保存下来的，上线后就需要将历史数据的库存金额刷上。
②关联菜单
功能关联到其他菜单的，还是拿库存举例，比如新增加一个菜单，【京东库存列表】，在【库存汇总列表】就需要加上京东库存，在途、在库，这里面的总库存字段计算逻辑也要更改，加上京东的库存，【京东库存列表】刷完数据后，【库存汇总列表】也需要处理。
4)定时任务
按字面意思拆分注意就好。
①时间
定时任务需要的时间点、频次，比如需要每天早上8:00:00开始执行脚本。
②任务
也就是脚本执行的规则，需要以哪些数据作为数据源，按怎样的逻辑执行，执行完成后数据如何存储，是否有按规则覆盖历史数据等。
5)数据对接形式
菜单是否需要对接别的系统，甚至于别的平台。
①同平台
对接同平台其他系统的，这个比较好处理些，大致有以下几种方式：
接口，使用接口调用的方式，可以是我们主动拿一些字段通过接口去获取，也可以是对方通过接口主动推过来，都可以。这里需要注意，是每次查询时动态获取，还是获取到的数据保存下来，需要写清楚，前者开发简单，后者会更方便。
同步数据库表，也是分为主动和被动，这个占用资源会多一些，适合同步数据字段较多的功能，相当于把菜单的数据库表单复制两份，获取的是整张表。一边产生数据，另一张表就会有，可以是即时，也可以固定个脚本隔几分钟推一下数据。
共享数据库表，也就是几个菜单都用这一张表，对比第2种，会更灵活些，也不会占用资源，如果需求一样，我会推荐这种形式。
②其他平台
也是两种形式，有接口的调用人家的开放接口，没有的想要获取数据，就需要Python了。
接口，拿平台对外公开的接口，我们去主动拉数据，一定要先查询接口文档，最好自己调用接口测试下能否获取到你需要的数据，这样开发会更明确。如果这方面处理起来比较困难，交给开发也好。
爬虫，没有接口说明平台不想给你那么多数据，你就得用爬虫，目前国家禁止，一些平台也要设定很多反爬机制，需要多注意些，违规的自然不推荐。
好啦，需求文档介绍完了，有没有一些收获呢?欢迎大家留评讨论。希望简单的文字对大家的产品学习有些帮助!跟多产品需求怎么写、优质的产品需求文档案例请持续关注墨思产品经理网。
