前两天网上有个程序员吐槽大会我看挺多人在转的，这么公开黑产品经理，除了娱乐效果之外，确实也反映了很多问题。作为一个前程序员，现产品经理，我觉得还是得说几句。首先以产品经理的角度自省，然后我再吐槽一下程序员。礼尚往来嘛！

01 吐槽产品经理

做产品之前我是做技术的，主要是做前端开发，Android 和 iOS 通吃，之前也做过一段时间的后端开发。

到现在转产品 5 年多了，以一个产品经理的身份也越发能理解为什么程序员对产品经理的意见那么大。

其实最关键的一点就是“不确定性”。

举几个例子你就明白了。

第一个例子是需求评审，在评审会上如果遇到一些没有定义清楚的问题，通常有两种处理方法，一种是当场聊清楚，一种是事后再讨论。

如果是第一种，可能当时是聊明白了，但是产品经理事后去完善文档时有可能和会上的结论有出入，或者干脆忘记完善文档这回事了。

程序员拿到文档去开发时，很可能对这个问题的理解产生偏差，导致开发出来的产品有问题，最后这个锅谁来背？

因为都参会了，也有共识，但文档没体现。毫无疑问，这个锅该产品经理来背。

产品经理是决策者，需要保证方案以确定性的状态进入开发环节，不管是沟通还是文档。所以这种“不确定性”往往会令程序员比较反感。

如果是第二种，对于评审会上不确定的点进行会后讨论，很可能出现因为别的优先级插入或者其他事情而忽略了这个问题。

以至于当再次回来进入开发时，之前的问题就是不确定的，程序员如果根据自己的理解做了，最后的结果肯定和预期是不符的。

如果不做，就会卡在那，然后再找产品经理沟通。

这中间一来一回，效率其实挺低的。一旦不能进入写代码的环节，程序员都觉得是在浪费时间。

真的，以前我就会这么觉得。聊了半天确定不了，又有很多变数，这种不确定性让我不敢轻易写代码。

为什么，一怕返工，二怕背锅。

所以啊，产品经理如果想把自己的工作做好，就需要提升自己对需求对方案的确定性，提前功课做足一点。

不仅是需求背景、意义目标、方案细节、可能的冲突、数据埋点这些，还有就是对过程中的不确定性管理，比如需求变更、优先级调整等，都需要给到程序员非常明确的结论。

一是一，二是二，别弄怎么都行的中间状态。那样真的很烦人。

02 再次吐槽产品经理

第二个例子，是提需求。

程序员吐槽大会中提到，产品经理和程序员就像唐僧和孙悟空，唐僧说“我就要取经”，孙悟空说“那得杀了白骨精变成的妖怪”，唐僧觉得不能滥杀无辜，孙悟空又说“那怎么办”，唐僧说“我不管，我就要取经”。

说实话，我挺认同这段的。做技术时也确实见过这样的产品经理，做产品后，也见过这样的业务方。

这个需求很简单，怎么实现我不管，明天上线。就是这么直白(沙雕)。

作为程序员，面对这样的产品经理，和作为产品经理，面对这样的业务方，内心一万头草泥马奔腾而过。

他们听不进也无法理解你的表达，死死抓住自己的需求并强烈的 push 给你。这种情况通常是两个原因，第一种是真的不懂，第二种是传话筒。

先说第一种情况，真的不懂。

不得不说，大部分的产品经理是不懂技术的，这是行业现状。

但也有越来越多的产品经理开始学习和了解技术，我一直说产品经理不需要具备技术能力，但需要掌握技术思维。

简单说，技术能力就是能上手写代码、能改bug。技术思维就是能听懂程序员的表达、能理解功能背后的技术原理。

有些产品经理带着需求过来找程序员，准确说是带着原型过来找程序员沟通，也不说为什么要做，也不说做了能带来什么好处，开篇就描述功能该怎么实现。

要么功能对现有的技术实现方案改动很大，要么就是技术成本很高。

程序员用技术语言告诉产品经理为什么做不了，产品经理反正也听不懂，然后继续死拽着这个需求向程序员 push，矛盾就这样产生了。

再说第二种情况，传话筒。

领导或者业务方来了个需求，产品经理本身也没很好的理解，也没有对需求做转化，直接就落到程序员这里。拿着尚方宝剑说这是上面来的需求，只能做。

程序员此时是无语的，一个奇葩需求还非得让我写代码实现，沙雕得不行。

让你产品经理吸气的同时呼气，你做一个试试！

我做技术时遇到类似需求就是这样的感觉，非常不爽。然后觉得产品经理整天都在干啥呢！

这种情况就是典型的没有对需求做转化，有的甚至是直接把业务方案落地成技术需求，没有经过中间的产品方案。

这就是产品经理工作的不到位了。世界上这么多软件、这么多需求，如果是一个逻辑合理场景成立的需求，在技术层面实现是没问题的。

此外，产品方案也不是唯一的，先入为主的拿着老板或者业务方的方案就觉得是唯一解，那只能说动脑还不够，没有发挥自己的专业性在业务和技术间寻找好平衡。

回忆一下，是不是一些沙雕需求其实都有 plan B 的做法。

03 产品经理吐槽

说完了产品经理，下面就该吐槽一下程序员了。

“这个页面对应的是一个 Activity，如果要加个按钮新开一个页面，我需要改一下 Layout 然后在代码里新写一个 Intent”。

说实话，有哪个产品经理看懂了上面这句纯技术语言？很少是吧，这是 Android 开发用语。

简单说，就是一个页面对应一个布局文件(Layout)，按钮摆在哪长什么样都在这个文件里登记记录了。每个页面的操作都由配套对应的中央处理器(Activity)来控制，页面的跳转和更新逻辑都登记在里面。而 Intent 就是一个消息，将一个事件通过消息传递出去。

我当过程序员，我也跟程序员合作过。用技术术语跟外行对话的毛病真的得改，不是所有人都懂这些天书，说人话很重要。

业务用一堆营销和行业术语跟你说话，你也懵逼是一样的。

再说一个。

“你找下后端把这个字段定义清楚吧，我不知道具体的数据类型是什么”，产品经理肯定遇到过这样的前端。

而实际上，后端程序员就坐在他的前面，非得找产品经理转一下。拜托，技术问题你们不能直接面聊么，没必要这么含蓄。

还有。

别总觉得产品经理安排活儿，如果没人安排活儿，天天在那写 bug 么！市场是变化的，需求也是变化的，互联网变化这么快，我们也没法一招鲜吃遍天。

04 产品经理再次吐槽

被堵住是什么感觉？

就是程序员说“这个需求做不了”的时候。真的，在你说了一堆后，最后这么来一句，也不告诉你为什么做不了。

大家都是专业人士，专业人士都讲科学依据、有理有据，为啥做不了说出来，结论容易下，过程难推导。

如果做不了，是否有其他可行的方案？别用一句话把大家的路都堵死，堵路不要紧，关键是心堵。

咱们都是合作方，相互扶持才是正事嘛！

可能有程序员觉得产品经理水平不行，同样，程序员怎么证明自己的水平真的行呢，每个人的认知边界都是有限的。

早上跟老板聊、上午跟业务撕、中午写方案、下午开评审会、晚上还要把评审会要修改的东西拿回来返工。

可能程序员只看到了自己和产品经理的这一环，其实还有很多糟心事他们没感受到。

说产品经理没事干的，工作不饱和的，过来轮岗两天试试就明白了。

程序员觉得跟产品经理说不通，那一定是没试过跟业务沟通需求有多费劲，产品经理是挡了多少刀才把需求筛选到技术那。

大家都不容易，互利共生才是正事呀。

写在最后

以上，当然不是针对程序员或者产品经理，有的也只是玩笑。

程序员和产品经理同在一家公司，公司好大家好，出来做事的嘛，最重要的就是开心咯！

少一些怀疑和抨击，多一些耐心和理解，狗和猿还是可以和谐相处的。

当产品上线被用户被市场认可的那一刻，相信所有的吐槽都会烟消云散，一起享受成功带来的快感。

祝程序员和产品经理们工作快乐！

#专栏作家#

唐韧(Ryan)，微信公众号：唐韧，人人都是产品经理专栏作家。前Juliye Care产品总监，《产品经理必懂的技术那点事儿》作者，在创业公司负责过多款从0到1产品，目前在某电商巨头负责产品工作 。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！赞赏