七月的最后一天，中国平安一产品经理和APP研发人员办公室直接打起来了，起因则是因为产品经理向开发提了一个需求：让app主题颜色能根据用户手机壳自行调整。
嗯，这是一个非常有想法的产品经理和非常有态度的程序猿之间的较量。
下面是视频：
作为程序员，碰到这种一点开发知识都不懂，还能把要改再改还要改的需求说得如此理直气壮的产品经理其实是非常崩溃的。
100次对话中，起码有99次想要轮棍子直接上的，还有一次，是直接上。
之前在知乎上看到一个经典的比喻：
你去饭店，坐下来。
“服务员，给我来份宫保鸡丁!”
“好嘞!”
——————这叫原始需求
大厨做到一半。
“服务员，菜里不要放肉。”
“不放肉怎么做啊?”
“不放肉就行了，其它按正常程序做，不就行了，难吗?”
“好的您稍等”
——————中途需求变更
厨房：
大厨：“你大爷，我肉都回锅了”
服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗”
大厨：“行你大爷”
然而还是一点点挑出来了
——————改动太大，部分重构
餐厅：
“服务员，菜里能给我加点腐竹吗?”
“行，这个应该简单。”
——————低估改动成本
厨房：
大厨：“你TMD，不知道腐竹得提前泡水?炒到一半才说?跟他说，想吃腐竹就多等半天”
服务员：“啊你怎么不早说?”
大厨：“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
——————新需求引入了新研发成本
餐厅：
“服务员，还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“...好的您稍等”
——————某一功能点摇摆不定
厨房：
大厨：“日你啊，菜都炒过火了你让我放肉?还好肉我没扔”
服务员：“客户提的要求你日我干嘛?”
大厨：“你就不能拒绝他啊?啊?”
服务员：“人家是客户嘛。”
——————甲方是大爷
餐厅：
“服务员!服务员!”
“来了来了，你好?”
“怎么这么半天啊?”
“稍等我给您催催啊”
——————改动开始导致工期延误
厨房：
大厨：“催你M催，腐竹没泡好，我还得重新放油，他要想吃老的也行，没法保质保量”
——————开发者请求重新排期
餐厅：
服务员：“抱歉，加腐竹的话得多等半天，您别着急哈”
“我靠要等那么久?我现在就要吃，你们能快点吗?”
“行...您稍等”
——————甲方催活
厨房：
大厨：“我日他仙人板板，中途改需求又想按期交付，逗我玩呢?”
服务员：“那我问问，要不让他们换个菜?”
大厨：“再换我就死了”
——————开发者开始和中间人pk
餐厅：
“服务员，这样吧，腐竹不要了，换成蒜毫能快点吗?对了，顺便加点番茄酱”
——————因工期过长再次改动需求
厨房：
大厨：“我日了狗啊，你TM不知道蒜毫也得焯水啊?还有你让我怎么往热菜里放番茄酱啊??”
服务员：“焯水也比等腐竹强吧，番茄酱往里一倒不就行了吗?很难吗?”
大厨：“草。腐竹我还得接着泡，万一这孙子一会又想要了呢。”
——————频繁改动开始导致大量冗余
餐厅：
“服务员，菜里加茄丁了没有?我去其它饭店吃可都是有茄丁的”
“好好好您稍等您稍等”
——————奇葩需求
厨房：
大厨：“我去他二大爷他吃的是斯里兰卡三流技校炒的宫保鸡丁吗?宫保鸡丁里放茄丁??”
服务员：“茄丁抄好了扔里边不就行了吗?”
大厨：“那TM还能叫菜吗?哪个系的?”
服务员：“客户要，你就给炒了吧。”
大厨：“MB你顺道问问他腐竹还要不要，我这盆腐竹还占着地方呢不要我就扔了”
——————奇葩你也得做
餐厅：
“服务员，还要多久能好啊”
“很快，很快...”
“再给我来杯西瓜汁。”
“...好”
“我再等10分钟，还不好我就走了，反正还没给钱。”
“很快，很快...”
——————黑暗前的最后黎明
10分钟后
“咦，我上次吃的不是这个味啊?”
从厨房杀出来的大厨：“我TM就日了你的狗...”
——————最终决战
你=客户
服务员=客户经理+产品经理
大厨=码农
请自行转换...
程序员的工作模式是根据产品经理提出的需求来整体构思，构思好了再开始写代码。
对程序员来说，每个项目、每一个功能点都是相互关联的，都不相互独立。
几十万甚至几百万行的代码，无论改还是删都不是一件容易的事，有时候改代码可能比重新写都更加困难。一点点的改动可能会牵一发而动全身导致所有代码都要重写。
而对于产品经理来说，客户的需求和来自用户的实时反馈可能更有价值，他考虑的是如何更好的满足用户的需求，如果不能满足用户的真实需求，多少代码堆出来的功能价值都为零。在极致的追求客户/用户需求的情况下，可能就比较容易忽略程序员的工作量的问题。
程序员和产品经理的关注侧重点不一样，工作模式和思维方式都有不同。产品经理负责需求和文档，程序员开发代码。产品经理不可能和程序员比技术，程序员也做不到从全局角度把握产品。
产品经理可以在项目规划中，尽量做到完整的长期和短期的规划，在一个短期规划周期中不做过大的调整，给予程序员足够的尊重；而对于程序员来说，敲代码不能只敲代码，而要多考虑代码的可拓展性，给予产品经理足够的理解。
嗯，天下产品开发是一家。
另外，作为一名产品经理，真的真的要维护好和开发的关系，买可乐，偶尔一起搓顿冰淇淋，扫码改需求啥的小技巧都多学习下。正式提需求前，可以先咨询下开发这个功能是否可以实现，也不至于被打得很惨。
当然了，就算做到以上几点...也不能保证不被程序员打...
希望大家分享出去，让更多想学习python的朋友看到~
裸睡的猪（ID：IT--Pig）
作者：猪哥-Pythoner，禁止未授权转载，授权请私聊
随时随地看视频
