昨天在某社区看到产品同行的吐槽：
程序员写个bug，大家都觉得理所当然；但产品经理的方案出一个漏洞，哪怕这个漏洞无足轻重，都会被怒怼，恨不得ma没了那种…
乍一看貌似没毛病，哪个程序员能保证不出bug？改好就行，类比一下，产品方案出点小问题，是不是也可以理解呢？
站在产品经理的立场，我真的很想说是！但理性分析一下，其实这两者是有本质区别的，关键词就是：最终产出。
首先我们回顾一**边程序员的工作流（这段过于露骨，务必遮住不要让程序员看到）：
从上游产品经理或者运营处接需求，竭力推脱“做不了”之后，硬着头皮接下“老板要做”的需求；
稍加分析需求内容，人工提取关键词之后，登录github，施展秘术ctrl c + ctrl v。
遇到特别定制化的需求，就面向微信群编程，绝活儿现学现写；
每次编译都要默默祈祷上苍，每次调试都愿意拿1个error兑换10个warning；
最后顶着100个warning终于跑通了程序，提交给测试；
然后是喜闻乐见的测bug——打回改——测bug——打回改的无限循环。
（有同款开发同事的，记得点赞）
在开发测试过程中，程序员无论出什么bug都无所谓，因为这期间的代码并不是最终产出。
准备打版上线的代码才是最终产出，这里面是不允许出现问题的。
君不见，一旦线上出bug，测试和开发会率先面如死灰，扣不扣绩点先不说，通宵加班肯定是免不了了。
说完程序员，再回到产品经理，其实方案有漏洞并不一定被喷，也分场景。
如果是每天的划水时间，你在楼下给开发递根烟，一边点评远处妹子的大长腿，一边起手式：小弟有个不成熟的想法…
这个场景下，即使你提出手机壳变颜色的需求，我也能100%保证你的ma还在！
但如果场景切换到需求评审会上，遇到情商不高脾气不好的程序员，你的方案但凡有点瑕疵都可能被喷的妈都不认识。
产品经理在评审会上展示的东西，就是最终产出物，与会者，无论是开发测试还是设计，都是这产出物的用户。
这就是程序员写bug和产品方案有问题的本质区别。
程序员的最终输出物是经过团队多次审核的，很少出错；产品经理的最终输出物往往是自己一个人工作的结果，容易忽视一些东西，这大概是产品经理总被喷的原因。
所以，想要在产品经理的不归路上走的更远，除了具备强大的心理素质之外，还要学会总结每次被喷的教训。
开始，因为只做了功能正向流程忽视逆向流程而被喷，下次注意；
后来，因为提出远超现代技术发展水平的需求而被喷，下次注意；
最后，因为重视用户体验设计出比较复杂的交互而被喷，下次…没下次了，这种情况当场就要怼回去，谁怂谁失先人。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。