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