大家好，我是Z哥。

 

在互联网行业，产品经理和程序员之间的关系很微妙。表面看上去水火不容，在一方的眼里看另外一方总是有这样那样的问题，也总是相互吐槽。

 

但现实是，大家都知道和对方在同一条船上。

 

产品没做好的话，除了公司利益受损，产品经理和程序员也会各回各家各找各妈，重新找新工作去。

 

产品做得好的话，双方和睦相处、其乐融融？那是不可能的，这个辈子都不可能和睦相处。矛盾会更加严重……（都觉得自己功不可没）

 

所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员，都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的，而不是一个零和博弈。

 

这个主题会分别从不同的两个视角展开，我们先聊程序员视角。

 

懂程序员的产品经理是什么样子

 

如果你是程序员可以看看以下这些描述是你眼中的产品经理么？如果你是产品经理也可以看看从程序员起家的Z哥给出的一些建议。

 

程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）：

 

• 开发过程中频繁修改需求；

• 验收过程中要求做比较大的修改；

• 说不清楚需求的价值；

• 替程序员评估工作量；

• 需求整理的不够细。

 

其中，频繁修改需求是程序员们最反感的，这是毋庸置疑的。

 

从产品经理的角度来说，虽然无法100%在开发过程中不修改需求，但是如果前期的工作做得足够充分，与业务方的沟通足够到位，至少去掉“频繁”两个字还是很有可能的。

 

我甚至遇到过一些产品经理，在自己对业务都是一知半解的时候就开始整需求了，这必然会导致后续频繁的需求变更。

 

而到了第二点，验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候，脑子里是一万头草泥马奔过……

 

产生这个情况的原因有很多，可能是程序员理解偏差，也有可能是产品觉得功能效果不佳。但是大多数时候，产生这个情况的根本原因还是在需求评审阶段的沟通不够充分，双方之间并没有达成真正的共识。

 

但是如果要说什么时候双方的矛盾最激烈，那还不是修改需求的时候，而是需求评审的时候。

 

此时，很容易看到的一个景象是“讨价还价”。产品经理站在“价值”一方，程序员站在“成本”一方。

 

当程序员们追问某个他们不认同的功能时，如果产品经理无法阐述出该功能令人信服的价值，那么必然受到吐槽。这是原因三。

 

原因四，有些产品经理是从程序员转过去的，之前做过一两年的开发工作。这个时长的经验其实是很危险的，很容易陷入到“达克效应”的第一阶段：高估自己的技术能力，低估他人的技术能力和工作难度。

 

这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理，甚至会在需求评审的时候替程序员预估时间，如果高于自己的预估，便会认为他们偷懒。

 

最后一点。相信每个人程序员都提出过这样的问题“这里如果……，那么要怎么处理？”，这种就是需求考虑不够细致的体现。不过，要做好这点的确挺难的，这也是产品经理需要花费时间最多的地方。

 

聊了这么多场景，作为产品经理应该如何应对呢？

 

从思路上分为以下几步。

 

1、先明确大方向，并与程序员达成一致

 

 

正如前面所提到的，产品经理站在“价值”方，程序员站在“成本”方，这注定了他们是对立的。最坏的结果就是双方互掐，就算相对好的结果也只是相互妥协做一个半吊子的功能（但是用系统的人不太舒服）。

 

但如果你的视野更大，格局更高，就会发现，如果以“投入产出比”角度来切入，双方不但都能理解，而且很容达成共识，毕竟花最小的成本干价值最大的活，是个正常人都能理解和认可不是么。

 

所以，可以在日常工作中不断的强化这个共识。一旦出现争执，就从这个角度来做最终决定，甚至基于这慢慢地还能建立起相互的信任，程序员真正拥有了产品思维，产品经理真正懂了程序员的难处。

 

2、将产品经理范畴内的事情做到极致

 

 

 

所谓术业有专攻，与其相互吐槽，不如多花点时间把对方吐槽的地方做到极致。

 

3、运用一些沟通技巧解决“确认偏误”现象

 

 

 

有时候你虽然做的很好，想的也很仔细，但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在“确认偏误”现象。

 

确认偏误是指搜寻，解释，偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信，并且在面对相反的证据时可以保持或加强信念。

——维基百科

 

所以，运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成，你就得考虑如何提高协作效率。而产品经理和程序员的协作中，沟通又是最重要的。

 

下面展开说说具体可以做的一些事。主要是思路中的2和3。

 

1）提高专业性

 

 

我观察过一个现象，需求变更比较多的产品经理，他们的工作习惯往往是直接抄起原型工具就画原型，或者有很多工作时间花在原型工具里。

 

这样非常容易陷入到一个思维惯性里面去，就是过于关注交互层面的事情，而轻视了背后业务流程的设计，甚至是业务的合理性。

 

我认为产品经理做事的时候一定要以User Story为核心来展开，先构思好一个User Story，然后再把它真实发生的各种细节阐述清楚。

 

做这件事的过程先后分为以下四步：

 

• 定义User Story；

• 定义交付标准；

• 提供低保真原型；

• 编写Use Case。

 

这里面最费时费力的就是第四环节，而且你想把User Story阐述清楚离不开一个专业的 Use Case编写。我之前收藏了一个非常专业的Use Case模版，是从知乎上的张恂老师那看到的，你感受一下。

 

用例名称：提问 

层次：!（用户目标层） 

范围：问答网站（以下简称系统） 

主用角：注册用户（以下简称用户） 

其他干系者：...

后态： 

前态：用户已登录。 

触发事件：用户选择提问。 

 

基本流：1. 系统显示新建问题框。 

输入问题 { 

2. 用户输入问题陈述（字数限制？）；系统即时验证输入的有效性，并提示已有答案的类似问题（数量？）以免重复提问。 

3. 用户设定该问题的相关话题。 

4. 可选项 

用户可补充输入问题说明（背景、条件等详细信息）。 

5. 可选项 

…… 

6. 用户提交问题。 

} 

7. 系统验证该问题的有效性。 

8. 系统发布该问题，并显示该问题页面。 

 

 扩展流：用户放弃提问：...

 

https://www.zhihu.com/question/48899115/answer/113274323 张恂老师的回答

 

作为产品经理的你，如果想要减少被程序员吐槽需求不够细，或者降低开发过程中变更需求的频次，把Use Case用心做好是必不可少的。

 

2）沟通方面

 

 

与程序员的沟通方面，我总结了五动作，分别是“齐、拉、捧、说、谦”，可以根据情况组合出击。

 

 ① “齐”就是视角对齐的意思

 

在聊需求之前，先交代需求的背景、意义。特别在中途需求变更的时候，这点非常重要。

 

继续搬出之前用过好几次的图。

 

 

如果视角不同，你说接下去还怎么聊？

 

 ② “拉”是拉拢的意思

 

亚里士多德说过：“我们无法通过智力去影响别人，而情感却能做到这一点。”

 

所以，在沟通的时候要把程序员当作自己人看待，而不是敌对。比如，可以多用“我们”，“一起”等词语，进入一个协商的氛围。

 

举个例子：“我们一起来看下这个问题”，少用”我觉得“、”我认为“。

 

 ③ “捧”是吹捧的意思，但并不是简单的拍马屁

 

人都是有多面性的，针对不同的情况和场景，可能会表现出不同的特质，这会影响到双方的沟通。比如有的人在生活中很温和，但在工作时非常严苛，要求很高，这就是激发了不同的特质。

 

类似的，为了激活程序员的积极性，你可以在当下需要他发挥的地方吹捧一下。比如，你觉得某个程序员做的东西质量一般，小问题比较多。那么你在和他聊的时候特地捧一句，“我知道做程序员的都或多或少有完美主义倾向，对细节很关注。我这个功能设计的细节可是想了好久呢，不过对你来说应该很容易搞定吧。”

 

 ④ “说”是说服的意思

 

想要让对方从心底里的认同你，单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。

 

重视数据的产品经理有可能是优秀的产品经理，但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务，并且还不能仅仅懂个皮毛。

 

比如，

 

• 你得知道哪些环节产生的数据是关键；

• 多个数据之间的间接关系和影响是什么；

• 你设计的每一个功能会如何影响这些数据；

• ……

 

如果你心里一直有着这些概念，程序员还会吐槽你提的需求价值低？

 

⑤ “让”是谦让的意思

 

俗话说，“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。

 

原因有两点：

 

• 大多数的产品设计背后有很多的知识是通用知识，每个人的生活经历都能成为经验，而每个人的生活经历又是不同的；

• 专业不同，哪怕站的视角相同，看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发，提出的观点可能会让你眼前一亮。

 

以上就是“齐、拉、捧、说、谦”五点。

 

最后再送给你一句话：非必要情况，一定不要用“这是老板的要求”！重复，重复。重要的事情说三遍。

 

还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如，在领域驱动设计范畴中Event Storming，它就非常适合在前期的需求评审环节去使用，感兴趣的可以自行了解。

 

好了，总结一下。

 

上面Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。

 

思路上分为三步：

 

• 先明确大方向，并与程序员达成一致；

• 将产品经理范畴内的事情做到极致：具体措施是以User Story为核心，做好Use Case的编写工作，而不是花很多时间在原型上；

• 运用一些沟通技巧解决“确认偏误”现象：“齐、拉、捧、说、谦”五个动作，可以根据情况组合出击。

 

如何做一个懂产品的程序员

 

下面我们来说说程序员视角。

 

两个相爱相杀的岗位，想要更好的达成共识、更好的合作，自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子，然后给出一些我的建议。

 

从产品视角是怎么看程序员的呢？我根据我自己的经历以及与其他产品经理的交流下来看，吐槽的主要是以下几点：

 

• 这个功能实现不了；

• 希望所有产品都不要改版，一次性把现在或未来要做的开发完；

• 只关心要写多少代码，不在乎产品体验；

• 写完程序从不自测，直接丢给别人测试；

• 过分追寻新技术潮流，完全不考虑对产品带来什么价值。

 

第一点，的确存在一些由于技术限制导致实现成本无限大的需求，比如手机屏幕背景色根据手机壳颜色切换……

 

但是，国内的技术环境不像老美那的技术味道重，大多还是商业导向的，很少企业里需要用到高精尖的技术，所以，真正实现不了的功能微乎其微。

 

对于大多数的功能需求来说，无非是一个成本大小、价值高低的问题。从立场上看，程序员自然是站在“成本”一方的，但对大多数人来说，决定这个成本的主要因素往往是自己工作的难度和耗时，费时费力的功能就容易得到“实现不了”的结果。

 

第二点对大多数产品经理来说是他们的对立面，因为大多数产品经理最喜欢“走一步算一步”地高频迭代，甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的，并且内容要非常详细的，心里的想法是，这样的话我一开始就可以设计一个完美架构来支撑它。

 

而且，内容越详细，产品经理就越不敢乱调整需求，毕竟“证据在手”嘛：D。

 

第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多，对需要有同理心、需要靠感受的事情的确弱了一些。

 

第四点的原因主要有两个，

 

• 一个是对自己的代码过度自信导致，我自己深有体会。我还记得有一次我交付一个功能，那个功能我单元测试都写了不少，对质量很有信心，觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug；

• 另一个原因是反正有测试人员在，等他们测出问题我再改不是更轻松。惰性使然，从个人角度的确如此。但是从团队角度来看，徒增了不少的沟通成本。

 

第五点的原因也有两个，

 

• 一个是行业里的新技术迭代的确太快，怕不学新技术被淘汰；

• 另一个原因是，只有用上新技术才能有谈资，显得自己与众不同、有成就感。

 

以上就是对这五点的简单分析，那么如何改善呢？继续往下看。

 

下面这些方法都是我亲测有效的，强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。

 

1、说实现不了之前，先三思

 

 

根据先后可以做以下3个思考：

 

• 是觉得这个功能没有价值不想做吗？

• 真的实现不了？我想全了吗？

• 这些方案里，有成本比价值低的吗？

 

第一个问题先确定必要性。我们不是说不能推需求，而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算，但至少这才能算是拒绝的理由；

 

第二个问题，努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案，那么将会永远在舒适区止步不前；

 

第三个问题，拒绝需求虽然不用动之以情，但一定需要晓之以理。当你能清楚的阐述利弊、收益比，拒绝需求自然不是一件需要相互扯皮的事情。

 

经过了这三个问题的思考，不管最终能不能实现，相信可以很好的与产品经理达成共识。

 

2、明白需求本身也是成本

 

 

过度地苛求需求要细、要完整、要全面，这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本，产品经理的也是。

 

与其等一个“XXXX最终绝对不改版”，不如从已经达成共识的部分开工，在这个过程中再与产品经理“共创”，多一起沟通打磨，此时再让产品完善PRD等文档，形成最终版。

 

3、刻意练习，多换位到用户视角

 

 

平时多去体验一下自家的产品以及竞品，把整个过程中的感受记录下来。比如，哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。

 

结果不重要，重要的是这个过程，慢慢锻炼自己作为用户的感知力。

 

有些程序员看起来经常把用户体验挂在嘴上，其实提出来的很多反而是脱离大众习惯的“个性化”需求，就是因为平时缺少对同行、外界的关注。

 

4、交付的东西是自己的“招牌”

 

 

“有人的地方就有江湖，有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态，你在别人心中的称号就是负面的。

 

轻则影响自己的口碑，影响与他人之间的协作关系；重则失去未来的晋升机会。

 

一个对自己的东西都不负责的人，如何负责更多的人、更大的事情呢？

 

在这件事上，除了多自测外，作为过来人，我建议每一个程序员认真对待单元测试。特别是把核心、复杂的方法单元测试给做上，这对交付功能的质量的提升非常明显。

 

5、不产生价值的新技术是“垃圾”

 

 

拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它，这不但给团队在挖坑，也在给自己挖坑。

 

比如你花了不少的时间在项目里用了某个新技术，但是对团队没有带来什么价值，你说后续公司还会继续投入资源加大新技术的使用吗？大概率并不会。那么之前了解到的一些知识，就会随着时间的推移而淡忘，投入的时间大多数浪费掉了。

 

所以，对待新技术Z哥的观点是：对于无法在工作中找到价值点的新技术浅尝辄止即可。相反，遇到可以产生价值的新技术，请全身心投入进去，而不是仅仅在应用层面捣腾，不去深入细节。

 

很多程序员对待新技术的习惯是，打一枪换一个地方，经过了几年，发现技术实力还在原地打转，不免有些可惜。

 

另外，推荐大家可以阅读一两本心理学、行为学相关的书，特别是我们做程序员的。不但可以提高自己对用户体验的感觉，还能提高对人性的洞察力和对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。

 

好了，总结一下。

 

刚才Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议：

 

• 说实现不了之前，先三思；

• 明白需求本身也是成本；

• 刻意练习，多换位到用户视角；

• 交付的东西是自己的“招牌”；

• 不产生价值的新技术是“垃圾”。

 

希望对你有所帮助。

 

作者丨Zachary

来源丨跨界架构师（ID：Zachary_ZF）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn