这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「155」篇原创敬上
在互联网行业，产品经理和程序员之间的关系很微妙。表面看上去水火不容，在一方的眼里看另外一方总是有这样那样的问题，相互吐槽。但现实是，大家都知道和对方在同一条船上。产品没做好的话，除了公司利益受损，产品经理和程序员也会各回各家各找各妈，重新找新工作去。产品做得好的话，双方和睦相处、其乐融融？那是不可能的，这个辈子都不可能和睦相处。矛盾会更加严重……（都觉得自己功不可没）所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员，都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的，而不是一个零和博弈。这个主题会分别从不同的两个视角展开，今天我们先聊程序员视角，本来想两个视角一起聊，发现内容太多，写到一半还是拆了，先把一个视角写了。如果你是程序员可以看看以下这些描述是你眼中的产品经理么？
如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）：开发过程中频繁修改需求。
验收过程中要求做比较大的修改。
说不清楚需求的价值
替程序员评估工作量
需求整理的不够细。
其中，频繁修改需求是程序员们最反感的，这是毋庸置疑的。从产品经理的角度来说，虽然无法100%在开发过程中不修改需求，但是如果前期的工作做得足够充分，与业务方的沟通足够到位，至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理，在自己对业务都是一知半解的时候就开始整需求了，这必然会导致后续频繁的需求变更。第二，验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候，脑子里是一万头草泥马奔过……产生这个情况的原因有很多。可能是程序员理解偏差，也有可能是产品觉得功能效果不佳。但是大多数时候，产生这个情况的根本原因还是在需求评审阶段的沟通不够充分，双方之间并没有达成真正的共识。但是如果要说什么时候双方的矛盾最激烈，那还不是修改需求的时候，而是需求评审的时候。此时，很容易看到的一个景象是“讨价还价”。产品经理站在「价值」一方，程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时，如果产品经理无法阐述出该功能令人信服的价值，那么必然受到吐槽。这是原因三。原因四，有些产品经理是从程序员转过去的，之前做过一两年的开发工作。这个时长的经验其实是很危险的，很容易陷入到「达克效应」的第一阶段：高估自己的技术能力，低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理，甚至会在需求评审的时候替程序员预估时间，如果高于自己的预估，便会认为他们偷懒。最后一点。相信每个人程序员都提出过这样的问题“这里如果……，那么要怎么处理？”。这种就是需求考虑不够细致的体现。不过，要做好这点的确挺难的，这也是产品经理花费时间最多的地方。正如前面所提到的，产品经理站在「价值」方，程序员站在「成本」方，这注定了他们是对立的。最坏的结果就是双方互掐，就算相对好的结果也只是相互妥协做一个半吊子的功能（用系统的人不太舒服）。但如果你的视野更大，格局更高，就会发现，如果以「投入产出比」角度来切入，双方不但都能理解，而且很容达成共识，毕竟花最小的成本干价值最大的活，是个正常人都能理解和认可不是么。所以，可以在日常工作中不断的强化这个共识。一旦出现争执，就从这个角度来做最终决定，甚至基于这慢慢地还能建立起相互的信任，程序员真正拥有了产品思维，产品经理真正懂了程序员的难处。所谓术业有专攻，与其相互吐槽，不如多花点时间把对方吐槽的地方做到极致。有时候你虽然做的很好，想的也很仔细，但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在「确认偏误」现象。确认偏误是指搜寻，解释，偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信，并且在面对相反的证据时可以保持或加强信念。
所以，运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成，你就得考虑如何提高协作效率。而产品经理和程序员的协作中，沟通又是最重要的。下面展开说说具体可以做的一些事。主要是思路中的2和3。我观察过一个现象，需求变更比较多的产品经理，他们的工作习惯往往是直接抄起原型工具就画原型，或者有很多工作时间在原型工具里。这样非常容易陷入到一个思维惯性里面去，就是过于关注交互层面的事情，而轻视了背后业务流程的设计，甚至是业务的合理性。我认为产品经理做事的时候一定要以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用心做好是必不可少的。与程序员的沟通方面，我总结了五动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。「齐」就是视角对齐的意思。在聊需求之前，先交代需求的背景、意义。特别在中途需求变更的时候，这点非常重要。
我们无法通过智力去影响别人，而情感却能做到这一点。
所以，在沟通的时候要把程序员当作自己人看待，而不是敌对。比如，可以多用“我们”，“一起”等词语，进入一个协商的氛围。举个例子：“我们一起来看下这个问题”。少用”我觉得“、”我认为“；人都是有多面性的，针对不同的情况和场景，可能会表现出不同的特质，这会影响到双方的沟通。比如有的人在生活中很温和，但在工作时非常严苛，要求很高，这就是激发了不同的特质。类似的，为了激活程序员的积极性，你可以在当下需要他发挥的地方吹捧一下。比如，你觉得某个程序员做的东西质量一般，小问题比较多。那么你在和他聊的时候特地捧一句，“我知道做程序员的都或多或少有完美主义倾向，对细节很关注。我这个功能设计的细节可是想了好久呢，不过对你来说应该很容易搞定吧。”「说」是说服的意思。想要让对方从心底里的认同你，单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。重视数据的产品经理有可能是优秀的产品经理，但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务，并且还不能仅仅懂个皮毛。比如，你得知道哪些环节产生的数据是关键。
多个数据之间的间接关系和影响是什么。
你设计的每一个功能会如何影响这些数据。
……
心里一直有着这些概念，程序员还会吐槽你提的需求价值低？「让」是谦让的意思。俗话说，“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。大多数的产品设计背后有很多的知识是通用知识，每个人的生活经历都能成为经验。而每个人的生活经历又是不同的。
专业不同，哪怕站的视角相同，看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发，提出的观点可能会让你眼前一亮。
以上就是「齐、拉、捧、说、谦」五点。最后再送给你一句话：非必要情况，一定不要用“这是老板的要求“！，重复，重复。重要的事情说三遍。还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如，在领域驱动设计范畴中Event Storming。它就非常适合在前期的需求评审环节去使用。这篇呢，Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。先明确大方向，并与程序员达成一致。
将产品经理范畴内的事情做到极致
运用一些沟通技巧解决「确认偏误」现象。
关于第二点，给出的具体措施是。以User Story为核心，做好Use Case的编写工作，而不是花很多时间在原型上。关于第三点，总结了五个动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。
推荐阅读：
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」