“终于知道产品经理为啥总被程序员嫌弃了，看完下面生活中的一个常见场景，你会对产品经理这个高危行业有更加深入的了解...当然，如果你想打死产品经理，请算我一个
你去饭店，坐下来。
“服务员，给我来份宫保鸡丁！”
“好嘞！”
这叫原始需求
大厨做到一半。
“服务员，菜里不要放肉。”
“不放肉怎么做啊？”
“不放肉就行了，其它按正常程序做，不就行了，难吗？”
“好的您稍等”
这叫中途需求变更
厨房：
大厨：“你大爷，我肉都回锅了”
服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗”
大厨：“行你大爷”
然而还是一点点挑出来了
改动太大，部分重构
餐厅：
“服务员，菜里能给我加点腐竹吗？”
“行，这个应该简单。”
低估改动成本
厨房：
大厨：“你TMD，不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就多等半天”
服务员：“啊你怎么不早说？”
大厨：“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
新需求引入了新研发成本
餐厅：
“服务员，还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“...好的您稍等”
某一功能点摇摆不定
厨房：
大厨：“日你啊，菜都炒过火了你让我放肉？还好肉我没扔”
服务员：“客户提的要求你日我干嘛？”大厨：“你就不能拒绝他啊？啊？”
服务员：“人家是客户嘛。”
甲方是大爷
餐厅：
“服务员！服务员！”
“来了来了，你好？”
“怎么这么半天啊？”
“稍等我给您催催啊”
改动开始导致工期延误
厨房：
大厨：“催你M催，腐竹没泡好，我还得重新放油，他要想吃老的也行，没法保质保量”
开发者请求重新排期
餐厅：
服务员：“抱歉，加腐竹的话得多等半天，您别着急哈”
“我靠要等那么久？我现在就要吃，你们能快点吗？”
“行...您稍等”
甲方催活
厨房：
大厨：“我日他仙人板板，中途改需求又想按期交付，逗我玩呢？”
服务员：“那我问问，要不让他们换个菜？”
大厨：“再换我就死了”
开发者开始和中间人pk
餐厅：
“服务员，这样吧，腐竹不要了，换成蒜毫能快点吗？对了，顺便加点番茄酱”
因工期过长再次改动需求
厨房：
大厨：“我日了狗啊，你TM不知道蒜毫也得焯水啊？还有你让我怎么往热菜里放番茄酱啊？？”
服务员：“焯水也比等腐竹强吧，番茄酱往里一倒不就行了吗？很难吗？”
大厨：“草。腐竹我还得接着泡，万一这孙子一会又想要了呢。”
频繁改动开始导致大量冗余
餐厅：
“服务员，菜里加茄丁了没有？我去其它饭店吃可都是有茄丁的”
“好好好您稍等您稍等”
奇葩需求
厨房：
大厨：“我去他二大爷他吃的是斯里兰卡三流技校炒的宫保鸡丁吗？宫保鸡丁里放茄丁？？”
服务员：“茄丁抄好了扔里边不就行了吗？”
大厨：“那TM还能叫菜吗？哪个系的？”
服务员：“客户要，你就给炒了吧。”
大厨：“MB你顺道问问他腐竹还要不要，我这盆腐竹还占着地方呢不要我就扔了”
奇葩你也得做
餐厅：
“服务员，还要多久能好啊”
“很快，很快...”
“再给我来杯西瓜汁。”
“...好”
“我再等10分钟，还不好我就走了，反正还没给钱。”
“很快，很快...”
黑暗前的最后黎明
10分钟后
“咦，我上次吃的不是这个味啊？”
从厨房杀出来的大厨：“我TM就日了你的狗...”
最终决战
——————
你=客户
服务员=客户经理+产品经理
大厨=码农
请自行转换...
——————
注：
1)以上场景已极度夸张，实际生产生活中码农和PM是和睦友好的相亲相爱的一家人
2)对于做2C产品的公司，你=公司大boss
-END-
互联网行业中，众人热衷于讨论「程序员砍产品经理」。虽然，「砍」更多是调侃的意思，一种消遣工作的方式；但是，这不是一个饭后笑话，侧面反应了产品经理和程序员间的对立关系。很多时候，产品经理和程序员间就像对手，产品研发过程就像打仗，总要争个你死我亡。「砍」的本质，是程序员表达对产品经理的不满，也是一种情绪的宣泄。
在产品研发的过程中，产品经理与程序员对立关系，会严重影响项目的推进。一旦产品经理和程序员对立关系公开化，很容易导致团队人心涣散。这种对立关系，经常滋生出一些极端的事情，骂娘、打架已屡见不鲜。
下文就列举一些程序员想砍产品经理的场景。这些场景都是我过去和很多程序员朋友交流时，他们遇到的对产品不满的场景。这些场景，都会以产品经理的沟通话语表现出来。通过这些场景，去解析这种对立关系产生的原因。以及，作为对照，产品经理应该如何规避和处理这种对立关系。
这样说法是程序员们最不喜欢的，最容易惹毛程序员的。这句话，在程序员们看来就是削减工时、加班的代名词，他们当然不喜欢。而且他们也非常讨厌，一个非技术人员为技术人员做技术难度的定论。简不简单，都需要技术人员做了技术评估，才能下结论。
这种言语，会让程序员们觉得产品经理不靠谱。大家通常都是比较排斥借鉴。借鉴你也得有合理明确的理由。以我某程序员朋友的话来说：微信怎么做的，你就怎么做，那你不如去微信做产品算了。
每个产品，在表面的UI下，都有其背后的复杂的业务逻辑。如果产品经理只是叫程序员照着某个产品做，很多时候技术们是很难实现的，因为他们也需要弄懂背后的逻辑和流程。当然，这应该是产品经理的工作。
这就是抬杠。产品经理虽然名字里面有「经理」二字，但并没有经理的权利，当然不能命令合作的技术们。这句话，言下之意也是拒绝了商量和讨论。而程序员也需要参与感和团队感。
这就是质疑他人能力，是人都不会喜欢。如果产品经理提出的方案，程序员们没有理解。那就说明产品经理的解释说明和文档，做的不够优秀，不够简洁易懂。让程序员们理解需求，是产品经理的基本工作内容。
在互联网产品开发中，修改需求和插入新需求都是挺常见的。对于程序员们来说，这是非常不爽的事情。这种 *** 作通常会打断程序员的思路，思路被打断是非常痛苦的。当然，这样也会影响他们的开发效率。更可怕的是，反复的修改需求，会使他们有种劳动成果不被尊重的感受，同时也会对项目的未来抱有怀疑的态度。反复的更改方案，也说明产品经理设计是未经过严密的论证，或对细节的把控是不够。
程序员都比较讨厌反复的催促。当项目的节点确定后，技术们会严格遵守节点，产品应该信任他们。当然，时间比较紧凑时，反复催促也会加大程序员们的压力，使他们变得非常烦躁。在这种时候，催促就是添麻烦。
甩锅会导致团队分崩离析，人心不齐。不管任何问题，都是团队的责任，不要将责任指定给某人。特别是在项目复盘时，如果心态不好同事，这是非常难堪的。所以，我们要尽量以原因和结果为导向，而不是责任为导向。
程序员也是也是团队的一份子，有权利知道知道需求的背景。同时，了解需求背景也利于程序员们更好的开发程序。
产品经理给程序员们画饼是最不切实际的，只会引起大家的反感。程序员都是喜欢偏实际的东西，虚的东西只会招致白眼。
任何传递给程序员的需求，都是需要有计划和规范的。如果口头传达一个需求，很容易导致开发出的功能与需求不匹配。同时，因为缺乏相关的记录和文档，可能会造成需求流失。这对于程序员们来说，可能就是延迟、加班、返工、担责等等风险。这是团队合作的大忌，也是项目管理不专业的体现。
以上的这些场景，可能出现一次，程序员们都会顺着我们的想法做。但是，这会渐渐改变程序员们的心态，最终会使产品经理与程序员间产生隔阂和矛盾。如果出现这些场景，作为产品经理都需要小心的处理好，以免影响项目的正常推进。当然，最好是不要出现这些场景。作为产品经理，我们的最终目标，都是要保证我们的产品，准时、保质、保量的落地。
产品经理在与程序员们合作时，产品经理需要讲究合作共赢、互相体谅。在产品经理的相关工作中，最要避免的就是抬杠。抬杠是一切矛盾的根源。很多时候，产品经理要站在程序员的角度考虑问题。比如，对于产品来说可能就是改改需求，但对于程序员，他们更在意的可能是因为改需求而导致的加班。
产品经理在工作中，经常会追求产品上的极致。追求极致本身是好事，但是切忌过分偏执。我们也需要考虑团队的现状和资源，在极致和现实间寻找均衡。毕竟，如果没有乔布斯的团队，要像乔布斯一样做产品，只会拖垮团队。
在产品开发的过程，改需求、改方案等项目异常，都是不可避免的。这是项目管理的第一部分。如何进行项目异常的处理，考验的是产品经理的沟通能力和项目管理能力。产品经理需要在保持技术们高效工作的情况下，完成项目异常的处理。
当然，在产品经理工作中，矛盾的根源也并不总是产品经理。有时候，也可能是某些程序员的性格或者对该工作的态度导致的。这时候，产品经理要明确，作为团队的润滑剂，有责任推动和协调大家的工作。如果，矛盾不可调和，我们需要尽早提出问题、控制风险，避免「勉强」行事。
有时候，程序员在私下评价一起工作的产品经理时，总是会补加一句「我感觉我也能做产品经理」。这句话的背后，是产品经理没有让程序员们感受到产品工作的价值。在这种背景下，产品经理是很难获取程序员们的注重，也会为很多争论埋下诱因。那如何感受到我们工作的价值那？其实很简单，就是保持工作信息的透明。将我们针对需求和产品做的相关工作，体现在我们的沟通或者文档中。
导致程序员想「砍」产品经理，本质是产品经理工作方式的问题，也有情商的问题。在我的产品经理工作经验中，我总结下了以下四点，我们需要注意和避免的。这四点，都可以和上文的场景相对应，是最容易慢慢改变程序员的心态的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）