如果能修炼到高级后台产品经理，是可以根据业务发展提出一些预见性的需求。

初做产品经理时，发现产品后台的经验分享总是不如前端产品来的多，想找一些经验帖却不知道该去哪儿。现在我做产品后台已经比较长的时间了，希望能把一些常见的坑拿出来跟大家分享，给产品小白们做个参考。

坑1：需求目的不明确，做出需求有偏差

在做需求之前，各位产品经理会进行充分的需求分析。这其中包括与需求部门、需求的上下游部门、老板以及相关部门进行需求调研，做充分的沟通以后产出PRD文档。

产出PRD文档时，最容易忽略的一环就是需求的目的。后台产品的需求大多是一个新功能的实现，或是一个老功能的优化。在做一些小版本迭代的需求时，产品经理往往会忽略将需求的目的以文字的形式输入在产品原型中，或者用一两句话敷衍了事。事实上，做这些需求的目的虽然产品经理能够做到心里有数，但是并不能良好的将此信息传达到开发方、测试方的每一个人，会导致整体需求理解的偏差，那对于细节需求，有偏差的可能性就会更大。将需求目的详实的落实在需求文档中还有一个好处，可以帮助产品经理整理需求的思路，自我检查需求的合理性。当然也不用细化到每一个细小功能设计的目的，把整体目的清晰完整的表达清楚就好。

坑2：逻辑说明太散碎，无法串成主线

在PRD文档内对于功能的设计需包含逻辑说明，通俗意义上说就是功能描述。包括输入什么，如何做逻辑判断，输出什么。可以用的方法有文字描述、表格法、流程图法等。后台产品经理，尤其是需要画后台页面的产品经理可能会在每个功能模块中进行逻辑说明。但是每个功能模块的逻辑说明相对独立，在写PRD的时候没有清晰的写出逻辑主线，不利于其他的产品经理理解PRD中的隐含逻辑，最终交付的产品也会让人大跌眼镜。

坑3：系统交互不了解，上线强行背锅

作为一个后台产品经理，要了解自己做负责的系统中的交互。数据来源是其他系统的信息是需要尤其注意的，这些数据是通过接口推的还是查的，在哪些节点会产生哪些数据。如果这些不够清楚，建议各位去问问开发，或者看接口文档。因为在做版本迭代的时候，是很难全面的预估会不会对其他系统产生其他影响的；在其他系统做版本迭代的时候，也要评估会不会影响你负责系统的现有逻辑和数据。当然这些问题可能会被测试童鞋cover掉的，但是从源头上预防背锅的情况不是更好吗？

坑4：历史数据没处理，在途数据未考虑

在每一次做版本迭代的时候，希望可以有个声音问问自己，历史数据如何处理？会对在途数据产生怎样的影响？产品、开发和测试人员可以针对这两个问题共同讨论出最合理的处理方案。考虑不周上线的话，就有可能造成为了保证业务线上改数据的情况，这大概是所有人都不想看到的结果哦。

坑5：盲目接业务需求，埋个坑再挖个坑

最后一个也是最重要的一个：

• 不要接业务部门的所有需求
• 不要接业务部门的所有需求
• 不要接业务部门的所有需求

重要的事情说三遍！业务部门的需求有可能会变化很快，而且最常见的需求就是：系统的设计最好是能包含住所有特殊情况的处理。但是越全面的事务越是容易暴露出缺陷，很有可能你很得意的功能设计就是一个未来的大坑在等着你。

所以在业务部门提出需求的时候，一定要多问为什么，深挖出最深层次的需求，对于一些不合理的需求及时指正。

如果能修炼到高级后台产品经理，是可以根据业务发展有一些预见性的需求提出的。

作者：芝士肉松包

本文由 @芝士肉松包 原创发布于人人都是产品经理。未经许可，禁止转载。