近期落地某个项目正式进入上线流程了。但上线后出现的部分问题发现是技术方案选择的问题导致而无法访问。
在项目上线后，产品出现的问题就需要对应的团队解决与发现问题的原因。但在这沟通过程中，很多产品经理莫名其妙成了“背锅侠”
到底是什么问题导致呢？
这里我总结有3点原因
产品经理无法判断技术方案
这个原因很多人说是因为产品经理不懂技术导致的。但其实就算你是从技术转型的产品经理，也很难判断技术方案的合理性。毕竟写代码的不是你本人，感觉这样做是没错的，但是实际上上线后 可能因为鉴权、系统访问接口等问题导致某些问题只有上线或测试环境才能发现。
技术方案可能会影响产品的使用流程。使用流程导致用户的野页面路径发送错乱，可能最终都没有办法解决问题
类似之前我也原创过几个case是很难仅仅靠产品经理来决定怎么落地的。以曾经负责的账户体系来表现
尤其是涉及到后台管理系统但需要实现用户端操作的，产品经理很多情况下会说：“这个需求我认为很简单，为什么不可以？”
开发：“.......“
增加沟通与评审的严谨性
上面说产品经理是背锅侠是出现在产品上线或进入到测试环节后才发现的大问题。
因此增加有效的沟通与评审严谨性就成为背锅与否的决定因素。
项目组成员参加
业务人员、开发评估是否关联人员
反复重复
会议记录
我发现，部分公司在评审后很少有会议记录。比如需求变更、需求待定点都需要通过会议记录来展现。关于需求评审如何落地，我之前原创的可以阅读
产品经理的话语权
这个可能不适合每个团队，但产品经理也是人。工作其实也是人与人之间的相处。解决问题的时候，除了冷静的分析问题原因和可以解决的方案外，尽可能的强势一些。
人本来就是哺乳类动物，动物的天性是伴随着的。若上线后的问题，发现是技术方案需要重新调整，基本宣布本次上线的问题无法解决。
产品经理的内心和开发人员一样，鬼火冒。辛辛苦苦努力那么久，到头来可能因为技术方案的实现问题，导致某些小问题或BUG无法解决在当前要上线的版本。我之前原创的这篇内容就非常符合这份定义
总之，产品工作中是不能避免上线不出问题的。就算测试再仔细，每个产品都需要经过上线后的不稳定期。因此合理的与团队沟通解决方案，确定是当前解决还是在下一个版本需求解决，才是背锅侠背后的意义。
推荐阅读：
网友评论