Fundebug
经授权转载，版权归原作者所有。
产品经理和程序员似乎是天生的一对死对头，在面对产品经理不断更改的需求时，脾气再好的程序员也会情绪暴走，如何巧妙地避免这种情况的发生呢？
众所周知，产品经理跟程序员属于死对头岗位，程序员跟产品经理因为需求打起来的新闻更是屡见不鲜，甚至还出现过程序员暴力砍人的事件，因此一干产品甚至开玩笑说产品这个行业属于高危行业，随时面临着被砍，被套麻袋，被群殴等各种问题。
虽说没有到描述的这么可怕，但是在面对不断更新需求即将爆发的程序，如何让他们放下手中的刀，确实尤为重要。
这里主要分析的场是
面对需求频繁更改已经处于暴走边缘的程序员如何安抚的场景。
造成需求不断更改的原因有很多：
-
客户突然更改的想法并且要求必须实现。
-
领导突然又看到了一个app并要求按照此app做出更改。
-
之前由于考虑不周后期需要填坑。
-
技术之前就没理解需求，出现了问题需要大改。
-
……
面对一改再改的需求，脾气再好的程序员也会变身暴躁龙，身为产品狗的我们为了需求能尽快落地，先稳住开发是非常重要的。
稳住开发是关键
1. 解释需求更改的原因，该认错认错，不是自己的错也先背着（毕竟产品背锅侠）。
需要更改一个需求之前，先让技术知道更改的原因，所有的需求调整都是有理有据，不是灵光一闪。
产品经理作为贯穿整个产品研发周期的责任人，不管产品出现什么问题，首当其冲站出来，能提高团队的信赖感。
2. 怀柔政策，可以跟技术表现同仇敌忾，一致对外。
这个让技术产生共情心理，告诉他们我们其实是一个战线的，让他们产生一种是自己人的感觉，在后续更好的去说服技术人员进行调整。
3. 肯定技术的能力。
技术是需要认同的，之前工作的心血因为一个调整可能就全部付诸流水了，心理难免要炸。所以一定要先肯定技术的能力，每个技术都是需要夸奖的，适当并且到位的夸奖能降低技术对需求更改的抵触心理。
4. 调整需求的时候，更多的让技术参与这个过程，让他们产生认同感。
我们在确认某个功能需求调整之后，可以先试探的性的跟技术沟通，对于这个功能是否觉得有不合理的地方，是不是应该进行一下调整会更好，让技术发表自己的意见然后慢慢引导，最终导向我们希望的结果，这个过程技术参与进来，会让他们产生一种认同感，这个能更好的让技术接受需求调整这个结果。
一个产品开发的生命周期会收到来自各个相关方的意见反馈，作为产品经理，除了不可抗力的更改因素外，更多的是要考虑产品的完善性，减少因为前期准备不足导致的后期修补性的更改，这些更改会造成人力成本的提高，以及项目团队的不和谐。
除了不可抗力因素外，产品能把控的就是在产品规划前期对产品需求的描述，这里会决定开发最终交付的成果是否能达到产品的要求。
我们分析一下产品跟技术对立对需求想法不一致的源头，两者所占的角度不同，看问题的点也不一样，所以我们最常听到的两者争吵的语句就是以下：
双方都有自己的立足点，看问题的角度不一样，开始可能是讨论，后面就可能演变为争论。
产品的立点：
技术的立点：
