为了避免开发、测试过程中的扯皮，减少功能上线之后各个部门之间的甩锅，也是为了产品经理的自保，强烈建议产品经理在写的时候要把其它文档使用者当做小白来看待。

比如，这个页面上的每个字段/元素和按钮，写的时候都要想想看开发测试人员，以及功能交付后的运营人员能不能理解，会不会埋雷。

我之所以这么说就是因为踩过坑，比如上图满折优惠券的配置，如果产品经理不添加个字段折扣上限XX元且该字段必填，那么开发人员必定不会做这个功能，运营人员配置优惠券的时候就有可能出问题。

比如运营配置9折优惠券的时候心想客户最多买5000元的商品优惠500元，但如果客户购买了10万的商品就会优惠10000元，这么高的优惠力度可能是运营和财务人员不愿意看到的，可能会给公司造成损失，你觉得这个损失会由谁来担责？

所以页面上的每个元素都要尽可能的做好定义，规避来自方方面面的危险，防止被用户薅羊毛。我之前有家公司就因为优惠券的配置被用户薅了200多万元的羊毛，当时的运营和产品经理都是被追责了的。

每个字段/元素/按钮在开发时都有相应的业务规则，PRD需要将这些规则清晰完整的描述出来，让开发、测试人员能够看的清楚读的明白，且没有产生歧义。

表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等，还有对应的错误提示。

• 文本要考虑最大显示长度，超过怎么处理。
• 链接一定要指定点击后跳转到哪个页面。
• 图片要考虑显示的比例，如果未加载出来该显示什么。
• 还要考虑界面的内容是写死还是通过后台配置。

异常情况：之前听过一个观点觉得很有道理。PRD把正常业务规则写完整不难，但把所有异常情况考虑全却不简单。

比如说用户在前端电商平台领券的时候，在2台设备上登录同个账号同时点击领券操作，系统是发放双倍的优惠券还是怎么处理？

不管是C端页面还是管理后台的需求描述里面，都要尽可能的想清楚客户和公司内部员工都会有哪些*操作，然后梳理出对应的解决方案。

4.6 交互接口

《西游记》里唐僧每次介绍自己都会说：“贫僧唐三藏,从东土大唐而来,去往西天拜佛取经”。这几句话包涵了每人都要问自己的三个问题：我是谁？我从哪里来？我要到哪里去？

这句话用在产品（开发人员）身上也同样适用：我是谁（在哪个页面）、我从哪里来、我要到哪里去。

换做开发人员的视角，他们比较关注的是：

• 我是谁：用户需要输入什么，在哪里输入，输入方式是什么？输入的内容是否有限？应当被如何检查？页面显示什么？数据怎么加载、怎么缓存、怎么刷新？
• 我从哪里来：用户从哪里进入到这个页面？怎么来的？是否可以相互转移（单向还是双向）来的时候有哪些数据一起跟着来的？数据从哪儿传送的？
• 我要到哪去：用户从这个页面会去向何处，哪些数据会跟着一起去？数据怎么传送（提交/上传）？相应操作之后会有什么交互事件？页面会发生什么样的变化？会影响到哪些页面或功能？

当然大部分产品大部分情况无需过多的关注交互接口相关的东西，但如果是程序猿转产品经理的，可能会关注数据交互相关的内容。

4.7 迭代记录

PRD从第一版诞生以后，经过多次需求评审、内部评审、设计评审、用例评审、开发（接口）评审等环节，对于页面布局、功能点多多少少都会有修改或变化。

当时可能通过邮件、会议纪要、微信群聊天等来说明，但如果不整理到需求文档中，时间长了，或者是项目人员变动，可能就没有人知道这部分需求最终的实现方案了。

因此，PRD迭代记录也是非常重要的一部分，记录下每一次讨论后需求的变化点，帮助各方使用者及时了解需求变化，以及对最终的实现方案做记录，方便阅读人员及时找到修改后的内容，直观的了解修改原因。

这对产品经理也能起到自保作用，比如某个功能出了线上事故，这个功能是前任产品经理做的还是你做的，都可以通过PRD文档里面的迭代记录来佐证。

4.8 其它部分

以上只是PRD比较核心或主要的部分，其实PRD还有一些其它内容，例如：

1)相关影响点

2)非功能性需求

3)角色权限需求

相关影响点：没有任何功能是独立存在的，其或多或少都会与其它系统发生关联。这就要求PRD文档在撰写的时候需要指出这些影响点，并给予解决方案。

比如优惠券配置页面增加了1个字段优惠券类别(内部优惠券，外部优惠券)，那么就要考虑到历史的优惠券要不要刷上这个字段，用户已领取但尚未使用的券要不要刷上，以及怎么去刷。

非功能性需求：最常见的包括页面性能、页面监控和兼容性3方面。比如业务部门希望订单结算页面能够自动帮用户勾选出优惠力度最高的促销活动和优惠券，这就要求程序要把用户可用的促销和优惠券遍历一遍然后取出最优值。

假定促销活动可以叠加，优惠券可以叠加，当用户有10个促销活动和10张券的时候，这个计算量还是很大的，如果活动采用的是递进式计算而不是平行式计算，那么先满减再满折和先满折再满减的计算结果可能是不一样的。

这个计算的过程会比较耗时，从购物车点击去结算后订单确认页面，在3秒查询并计算出最优结果再显示出应付金额是符合用户预期的，如果这个过程需要5秒甚至10秒以上，那用户体验就会大打折扣。这个性能要求产品经理也需要在PRD中予以说明。

做过促销或者订单结算某款的产品经理，应该都清楚上述计算的工作量，如果产品经理在PRD没有写清楚这个性能要求，又遇到了外包性质的项目，那这个点就可能出现扯皮的情况。

我之前公司有个项目就出现了这种情况，开发提供的版本最快都得6秒 ，但产品经理在PRD里面没有说明要求，最后开发团队要求加钱才能做到3秒左右。经过长时间的扯皮后问题上报到了高层，最后没办法还是加了钱。

角色权限需求：部分产品或者功能点可能会涉及到角色权限部分，比如哪些人可以使用这些功能，有什么条件限制等等。

比如订单列表页面上的导出按钮，用户审批页面的批量操作等等。这个也需要产品经理在PRD中予以说明，否则就需要在以后的迭代中增补进来。如果是自研的产品还好，如果是外包性质的，可能就需要走需求变更增加工作量增加预算，这是项目经理最不愿意看到的。

如果产品经理的PRD写的不够好或者不够用心，则会有很大的项目风险，同时也会影响到产品经理本人的职业发展。

项目延期：如果PRD里面的关键需求或者主要流程描述不准确不严谨，则研发或测试过程中需要反复修改，进而导致成本增加项目延期。

这种问题我在以往的工作和项目经历中见得太多太多了，为了尽可能的避免这种情况的出现，我们一般会采用交叉审核 产品组内部评审的方式。

前者是让其他产品同事帮忙找茬找需求中的不足，后者是产品小组一起来找茬找不足。事实证明通过这两种方式内部自查后，产品经理再去做需求澄清时基本就没有大的问题了。

打击自信：如果PRD写的不够尽善尽美，则可能会出现需求评审或需求澄清的时候，项目经理 研发人员 测试人员不断挑刺甚至开怼，进而大家集体怀疑产品经理的能力和专业性，进而导致产品经理信誉度降低，自信心受打击。

这种情况发生的多了，项目经理或者部门主管在评定绩效的时候必定没法给产品经理打高分，项目组的开发测试同学也就不太愿意和这位产品经理共事来做新的项目了，然后这位产品经理在公司也就没有太大的成长和上升空间了。

所以，我建议产品经理把PRD需求文档当成一个产品去设计，要尽最大的能力用心做到尽善尽美，这样在需求澄清的时候才不会被开发和测试集体开怼，才不会在开发和测试的过程中不断亡羊补牢。

作者：詹老师，公众号：詹老师

本文由 @詹老师 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。