产品经理和程序员的对话

‘壹’ 产品经理如何找到妥协与坚持需求的平衡点

首先，这个平衡点肯定是模糊的，定性而非定量的。而且偏主观，所以大家一般都会说 “拿捏一下” 平衡。在对方提出与自己不同的意见时，妥协之前我们需要尽可能地进行一番就事论事、有理或有据的辩论。然而，并不是每个决策点都能看出不同方案的明显差距的。所以会出现双方都有一定的道理，但谁也说服不了谁的情况。说白了，就是大家的侧重点不一样，导致最终的选择也不一样。面对无法通过辩论而达成一致的情况，有以下几种解决方案：1. 双方做进一步的理论或资料调研，再次 PK2. 通过纸上原型、展示页面效果图或可交互 Demo 进行用户测试（User Testing）3. 两套方案都开发，投放至线上进行 A/B Testing4. 一方主动/被迫妥协然而，采取第 1 个方法很可能还是无法达成一致，因为双方的侧重点依然不同；第 2 个方法成本较高，适用范围也较为狭窄；第 3 个方法显性成本最高，在A/B 测试有什么局限性？ - 郑坚义的回答中有讨论；第 4 个方法，即一方主动/被动妥协，是最常见的做法。但妥协也是有技巧的，最重要的一点是抓大放小。也就是说，在关键的决策点上不能够轻易地妥协，因为它决定了方案质量的 level。而对于一些不影响大局或方案效果差异不大的决策点，则允许在一定条件下进行妥协（相关回答：高级产品经理和普通产品经理有哪些区别？ - 郑坚义的回答）。允许妥协决策点不意味着就要主动妥协，可以观察和猜测对方的坚持程度。如果十分坚持，则妥协，这样可以让自己在下个决策点上掌握更多的话语权，就像谈判一样。如果察觉对方态度其实也并不坚定，则可以强硬一些，尽量把方案拿下。但一定要避免大比例地进行妥协，否则将丧失产品经理基本的影响力。其实，倘若在平常的工作中已经建立了良好的影响力，遭遇到的不同意见会少很多，因为大家都选择信任你。

‘贰’ 产品经理和程序员,如何避免矛盾

产品实现是你的目的，为了这个目的不必太讲究。

做了一阵子之后我有了自己对于与程序员相处的方法论，对这句话并不苟同，我还是倾向于把事做好的同时也能把话说好，虽然我现在也能深刻的领会到当时leader的核心意思是产品本身是第一位的。

接下来我就阐述下自己的一些心得：

• 产品经理与程序员最大的矛盾在于——改需求。这牵涉两个问题，一个是如何尽量地做足前期工作，尽量把需求细化，需求做的足够扎实就会大大减少改需求的次数，这是产品本职工作，不属于沟通问题；另一个问题就涉及如何沟通了，就是需求无论如何确实要改。这个时候有一点很重要就是努力与程序员（或者开发经理）达成共识，比如“我们的目的是要做最好的xxAPP”、“这个功能对于我们的目的来说是必不可少的”等，然后再来谈详细的需求点，程序员也就会逐步认可改需求这件事情。（还有一点很重要的就是，如果无论如何也达不成一致，也有必要反思这个需求是否真的有改的必要？）

• 用数据和客户来帮你增加底气。在谈论某项功能实现的时候，产品经理经常会碰见程序员消极被动不愿意做，或者质疑这么做有没有道理的时候，采取需求依据的数据和真实的客户需求是能有效推进的好办法。比如“80%的同类产品都有这个功能”、“每周都能收到几个客户对某某问题的反馈”，一般来说程序员是能够接受这种说服的。

• 试着多用询问的语气。让程序员感到他是专业的，他是能够解决这个问题的，要依仗他才能做的更好。这会无形中赋予他一种责任感（因为你把问题抛给了他，他就隐形中负有解决这个问题的责任），在传达出意愿的同时也避免了话语的生硬，让程序员感受到对其职业技能的尊重。

• 注重日常交往。日常生活中交个朋友，比如一起打球、打游戏，聊聊电影和漫画，实在是没有共同语言就经常冲他卖个萌、搅个基、撒个娇、讲个笑话。这样，大家都是朋友了，不看工作职责的那一半看交情的那一半，沟通起来也会顺畅很多。

总结：有很多时候产品的产生不完全是靠严格的流程和规章制度诞生的，也需要很多沟通的润滑。能够开开心心地把产品做出来最好，但是最终我们还是不能离开产品实现这个 标的物。

‘叁’ 项目负责人如何和程序员沟通

做一名程序员，虽然好的口才不是必要条件， 但不善于表达自己想法以及与上司同事沟通，吃亏的是自己；

最近做一个项目，与项目的负责人出现一些不愉快的事情,出现这种情况虽然与其它杂七杂八的事情有点关联， 但最重要的原因还是在工作上缺乏沟通； 例如， 上周他给我们C#组的人员分配工作， 每人负责一个小模块， 数据库和需求文档已经提供有，但数据库的表字段有可能根据实现开发情况做少许改动，而且也给我们一个例子看， 可能参考该例子来做； 在统一讲需求时虽然听起来明白了，但做起来会发现很多关节的细节没考虑进去，而这些细节往往会影响到开发的速度， 甚至看骈符合了文档的需求，但却不符合负责人或者说是客户的实际需求;因为文字类型的需求是比较抽象，特别是要做用户界面， 虽然有例子，但也只能参考，不能照搬也做，这样做出来的程序很多情况下只符合程序员自己的需求； 已经花了很多时间去做一个可能不需要的功能，如我当时做一个日历控件来显示排班信息，且也接近交货日期了，到时交到负责人手里时才发现，这个日历控件不是必要的，选择的时间范围是在弹出窗口里，且不保存到数据...， 这时发现做了很多无用功，又要加班加点去赶进度了。虽然这只是一个小例子，但相似的例子在前几个月里已经发生过几次，为什么呢，因为表达能力差，也不善于与人沟通。可以利用日事清管理工具来沟通，把想法写出来。然后@给项目负责人。不用直接面对，效果不错。

‘肆’ 暴风影音程序更新称杀程序员祭天是什么小幽默

暴风影音软件新版本描述中，出现“杀了一个程序员祭天”这一表述，属于“产品经理和程序员的一个小幽默”。

今日下午开始，一张截图在网络刷屏。截图系暴风影音软件在苹果商店的下载页面，其最新版本更新于8月25日，最新动态一栏中，描述为“修复了闪退的bug，还杀了一个程序员祭天”。

引发关注的产品描述，是“产品经理和程序员的一个小幽默”。一名公关人员称，暴风影音本次更新，涉及的工作量较大，程序员及产品经理工作要求都比较高。其表示，软件的更新描述，是“产品经理和用户沟通的一个窗口，很多APP的说明都很生动有趣”。

估计那程序员已经是前同事了。

‘伍’ 如何向外行解释产品经理频繁更改需求为什么令程序员烦恼

某产品经理经过多年努力，终于研制出可定制多层冰淇淋，可以根据顾客的需要现场定制。开张第一个顾客是聪明可爱的小汤姆，指着摊位的冰淇淋机问：我可以要多个自己喜欢的口味吗？产品经理：当然了，你可以自由选择4种口味来叠加哦。汤姆：那太好了！那我第一层要巧克力味的。产品经理：好嘞，巧克力味的。第二层呢？汤姆：我还喜欢吃奶油，那就要奶油的吧。产品经理：奶油，OK了。汤姆：第三层要花生酱吧。产品经理：搞定，花生酱。汤姆：嗯...叔叔，我能不能把花生酱的换成草莓味的呢？我刚想起来，隔壁小妹妹花生过敏。产品经理：啊，这样啊，那我帮你换掉。汤姆：谢谢！那我还要原味的...产品经理：好，原味的...汤姆：等，等下，我觉得还是橙子的吧产品经理：怪我手快...橙子的汤姆：嗯...好像我妈妈不让我吃奶油，能不能帮我把第二层换成梅子的呢？好不好~产品经理：...好吧，看在你是我第一位顾客的份上，帮你换。汤姆：太感谢了！...哎呀！狗狗不能吃巧克力对吧？！产品经理：狗狗确实不能吃巧克力。汤姆：我怎么忘了呢，要是我家布丁吃了巧克力死掉怎么办呢？产品经理：那就不要给狗狗吃呀。汤姆：那怎么行，这么好吃的冰淇淋怎么能让它就这样看着呢？帮我把巧克力换成抹茶的吧~叔叔~产品经理：...小兔崽子，怎么学成这样了，你爸也是个产品经理吗？！汤姆：不，我爸是程序员。