产品经理该如何不让程序员那么暴躁？
众所周知，产品经理跟程序员属于死对头岗位，在面对产品经理不断更改的需求时，脾气再好的程序员也会情绪暴走。程序员跟产品经理因为需求打起来的新闻更是屡见不鲜，甚至还出现过程序员暴力砍人的事件。
因此一些产品经理甚至开玩笑说产品经理这个行业属于高危行业，随时面临着被砍，被套麻袋，被群殴等各种问题。
image
虽说没有到描述的这么可怕，但是在面对不断更新需求即将爆发的程序员，如何让他们放下手中的屠刀，确实尤为重要。
这里主要分析的是面对需求频繁更改已经处于暴走边缘的程序员如何安抚的场景。
造成需求不断更改的原因有：
客户突然更改的想法并且要求必须实现。领导突然又看到了一个app并要求按照此app做出更改。之前由于考虑不周后期需要填坑。技术之前就没理解需求，出现了问题需要大改。……
面对一改再改的需求，脾气再好的程序员也会变身暴躁龙，身为产品狗的我们为了需求能尽快落地，先稳住开发是非常重要的。
image
稳住开发是关键
1. 解释需求更改的原因，该认错认错，不是自己的错也先背着（毕竟产品背锅侠）。
需要更改一个需求之前，先让技术知道更改的原因，所有的需求调整都是有理有据，不是灵光一闪。
产品经理作为贯穿整个产品研发周期的责任人，不管产品出现什么问题，首当其冲站出来，能提高团队的信赖感。
image
2. 怀柔政策，可以跟技术表现同仇敌忾，一致对外。
这个让技术产生共情心理，告诉他们我们其实是一个战线的，让他们产生一种是自己人的感觉，在后续更好的去说服技术人员进行调整。
image
3. 肯定技术的能力。
技术是需要认同的，之前工作的心血因为一个调整可能就全部付诸流水了，心理难免要炸。所以一定要先肯定程序员的能力，每个程序员都是需要夸奖的，适当并且到位的夸奖能降低技术对需求更改的抵触心理。
image
4. 调整需求的时候，更多的让技术参与这个过程，让他们产生认同感。
我们在确认某个功能需求调整之后，可以先试探的性的跟程序员沟通，对于这个功能是否觉得有不合理的地方，是不是应该进行一下调整会更好，让程序员发表自己的意见然后慢慢引导，最终导向我们希望的结果。这个过程技术参与进来，会让他们产生一种认同感，这个能更好的让程序员接受需求调整这个结果。
image
一个产品开发的生命周期会收到来自各个相关方的意见反馈。作为产品经理，除了不可抗力的更改因素外，更多的是要考虑产品的完善性，减少因为前期准备不足导致的后期修补性的更改，这些更改会造成人力成本的提高，以及项目团队的不和谐。
除了不可抗力因素外，产品能把控的就是在产品规划前期对产品需求的描述，这里会决定开发最终交付的成果是否能达到产品的要求。
image
我们分析一下产品跟程序员对立对需求想法不一致的源头，两者所占的角度不同，看问题的点也不一样，所以我们最常听到的两者争吵的语句就是以下：
image
双方都有自己的立足点，看问题的角度不一样，开始可能是讨论，后面就可能演变为争论。
产品经理的立点：
产品定位；需求场景；用户体验；业务目标。
程序员的立点：
功能实现；开发难易；后期维护；改动成本。前期做好准备
双方站在自己的领域范围下，都是有理有据，但是放到一起，产品的开发过程就会举步维艰，产品经理要这个功能明天实现，程序员考虑这个功能起码一个星期甚至说这个需求根本不可能实现，要么砍需求要么改需求，产品经理也不会答应，你来我往，双方就此展开撕逼。
image
这里总结了几点产品经理在前期做好可以减少很多不必要的争吵经验。
1. 需求明确，逻辑清晰，思维缜密，不要让程序猜。
我们在制作产品原型以及编写PRD文档的时候，一定要清晰准确的描述需求目的，所有的需求都是从合理的角度出发，有理有据，减少带个人主观性的语言描述（比如我觉得，我认为），这样的描述会给程序开发人员留下一种产品没有从实际出发，所有功能都是拍脑袋想出来的，团队会存在不信任感，也会给程序员留下一种能力不行的印象，会导致后面的需求更难落地。
image
在对功能做描述的时候，尽可能详细的考虑到多种场景，减少程序员的想象空间，我们想的越多，考虑的越全，程序员在开发的过程中才能更贴近我们的原本需求。
比如对一个输入框做说明，我们要考虑的首先是字符长度边界、可支持输入的字符类型（比如手机号码输入就是数字型，但是备注输入就是没有限制）、是否必填、是否有默认值、是否有提示语、错误输入的状态提示等常规性的描述。
但是还有一些特殊场景，比如输入文本时，需要自动带出之前输入过的字符，支持直接快速选中快速录入，是否支持粘贴等这些也是要考虑进去的。总之产品前期考虑的越全，程序开发才会更容易，后期也不会因为产品漏了一些场景而产生不要的变更。
image
2. 尊重并理解技术人员。
调查了一下身边的程序员，最烦听到的来自产品经理的话语：“这个需求很简单……”荣登榜首，反思一下，主要是因为一部分产品不懂技术，仅通过主观臆断就决定开发周期的长短。
举个例子：需求是去超市买瓶水；程序员要考虑的可能就是路程有多远，走路合适还是需要坐车；一共有几条路可以到超市；水是只有一种还是有多种；如果有很多人一起买水是需要排队还是可以多线程…….
image
所以我们再给出需求之后，可以多听听程序员的意见，不要通过主观想法开口就是“这个需求很简单……”。同时我们也要多学习一点技术，不懂就问，平时可以多去一些技术论坛逛逛，也是为了避免一个需求评审完，程序员报了3天，结果两小时就做完了这种情况。
image
3. 小事线上沟通，大事当面沟通，所有的调整都要做好书面记录。
程序员在开发的过程中是需要大量进行思考，所以中途被打断，可能前面的准备就前功尽弃了。所有没有什么特别重要的通知的时候，可以通过线上交流，等技术忙完自然会去看。
对于很重要的事情，一定要当面沟通，不要因为害怕冲突就发邮件通知。书面内容每个人在理解的时候很可能产生误差，最后造成更大的问题。积极主动，加上真诚，和善的态度，是避免冲突的良好开始。
image
最重要的一点，所有的调整在通知并确定方案后一定要书面记录，程序员每天要接收很多讯息，很多需求我们在沟通后他们不一定会及时去处理，甚至小一点的变动可能会漏掉，所以在沟通清楚后，一定要记录在便于程序员查看的位置，也方便后面测试可以了解。
一般我们可以在原型前增加一页，专门用来记录调整的需求，并且对每个调整的页面后放置快速跳转链接，便于程序快速定位。如下图：
image
4. 私下交流，合理套路。
人都是有感情的动物，关系亲近也会有利于冲突的减少。
很多人喜欢把工作和生活区分对待，但实际上我们的生活大部分时间都在工作，工作中的程序员和产品经理私底下也可能是很好的朋友，了解每个人的工作方式和沟通喜好，更有利于对症下药，当对每个程序员进行性格的个体分析后，就可以合理套路了。
image
产品经理跟程序员没有职属关系，但是在推动研发按时交付时，就只能靠人格魅力了。平时大家关系很好点点滴滴都看在眼里，程序员自然也不想产品经理为难，能做的就做了，做不完的可能加班也给做了。
产品经理负责产品各项事物的协调和推进，需要有强大的心脏以及很高的情商，多站在对方的角度看待问题，做出正确的判断，专业素质越强，程序才能越信服，沟通才会更加顺畅。
image
