先问个问题，你有没有主动为自己的工作失误承担过责任？
对于责任，不一定是接受惩罚，而是主动担当并勇于直面自己的过错。
线上产品出问题，到底是产品经理背锅还是程序员背锅？
有人说是产品经理，有人说是程序员。
在我看来，这个问题很难有正解。
产品经理和程序员之间存在天然的张力，二者的思维方式和视角不同，对于同一件事的理解和认知存在一些差异化。
这也就是为什么大部分产品经理都觉得自己说得那么清楚了，可程序员还是不明白的原因。
这也就是为什么大部分程序员觉得产品经理啥也没说清楚，可产品经理依然自我感觉良好的原因。
昨天我跟一个做技术的朋友聊天，他跟我说了件事，是关于他们公司新来的产品总监如何花式甩锅的。
为此，他们技术团队的同事给这位新任产品总监起了个外号叫「不粘锅」。
这位「不粘锅」从来不会让任何不利于自己的事与自己沾边，一定是把自己摘得干干净净的。
对于他们团队的人来说，都直呼怕了这路神仙。
说实话，我觉得这个案例在很多公司应该都存在，所以分享出来，希望能对你有些启发。
防甩锅能力要有，主动担当的意识同样要有。
他们这位新任产品总监有多神？
说个例子。
他们产品发版后，在 iOS 客户端发现一句文案里有错别字，而且这个问题还是老板发现的。
问题被反馈到产品部以后，这位产品总监首先是积极响应，把领导的工作做足了，然后再把问题反馈给开发团队进行排查，看能否在线修改。
开发团队看了后发现，文案是「写死」在客户端代码里的，无法通过云配置的方式进行修改。
也就是说，必须等下次发布新版本客户端后才能顺便更新文案。
而且，因为这个版本已经发布到市场上了，就算发布了新版本，用户也不一定会全部更新。
这就意味着这个有错别字的版本会一直分散存在于整个市场上。
而产生错别字的原因，是因为产品经理在 PRD 文档里写了错别字，而程序员没有仔细核查，直接复制文档里的文案就写到程序里去了。
问题定义清楚后，好戏开始了。
产品总监为了甩锅程序员，说这个文案应该做成可配置的，这在系统架构时就应该考虑好，也不至于现在这么被动。
技术团队不干了，说这是你们产品经理写的文案，我们只是原封不动复制过去了，而且需求里也没提要做成可配置式的。
就这样，问题陷入了僵局。
可产品总监机灵啊，直接把问题怼到了老板那，说技术团队考虑不周到，所以导致了这个问题的发生。
老板后来直接找我这个朋友问话，弄得他气不打一处来。虽然百般解释，但老板始终认为这个问题应该在技术层面提前考虑好。
如果换做你是技术团队的成员，你会怎么想？
对于这个例子，我是站程序员的，问题的根源在于产品经理，如果不是写了错别字，就不至于出这个问题。
如果把问题往大了说，还有设计、测试、以及上线前的内部验收，既然大家都没发现问题，那就是个集体责任。
既然是集体责任，那相当于没人负责。
所以，直接责任人是产品经理。并且，关键是下次如何避免，如何才能防止此类问题的二次出现。
听完这个例子，我算是理解了他们为啥要给这位产品总监起个「不粘锅」的外号了。
而且，这只是其中一个小例子。工作中还有很多的场景以及事情，这位产品总监甩锅能力一流。
说实话，我也是做技术出身的，从程序员的角度看，还是希望把产品做好的，也并不会刻意为难产品经理。大部分时候，是希望产品经理把完整的逻辑梳理清楚，并给出明确的定义。
我做技术时，最怕的需求就是「大概」、「差不多」、「应该」这类的描述，因为你不知道到底什么才是准确的。
按自己的理解做，做错了怕背锅。
等一个明确的定义，时间又耽误了，所以对产品经理的要求比较高。
当然，我也听一些产品经理反馈过，确实存在一些刻意刁难的程序员，这跟人品有关系，这种人其实在任何职业都有，不能以偏概全。
对于一个没有担当的产品经理，程序员是敬而远之的，也不会产生信任感和信服度。
敢于承担责任、敢于站在团队前面、敢于真正为产品代言的产品经理，才是程序员们所佩服的。
不要求你能力多强，只要站在兄弟们一边共进退、能抗事儿，就能够赢得尊重。
对于产品经理和程序员的相处，我认为不管哪一方，首先是做到专业，然后做到职业。
专业不用多说，基本的知识和专业能力要靠谱，能够对问题给出专业的建议和行动方案。
而职业，却是很多人需要加强的。
保持职业性，要去掉情绪和个人利益的牵引，做到这一点不容易、但能做到的，通常都非常了不起。
希望你别成为一个「不粘锅」的产品经理，争取成为一位有担当、有责任、有知识、有能力的产品人。
共勉！
··
···············END···············
··
写过代码、做过产品、出过一本书，在创业公司厮杀过，也在大厂服役过，如今是一个
自由职业者。
用产品视角观察世界，用产品思维解决难题，在这里记录自己想表达的一切！
