身为产品经理，要怎么合理的跟程序员提需求呢？要怎么去处理才能很好的化解产品与技术的矛盾，而避免挨揍呢？
最近一个视频火遍了整个朋友圈，某公司的产品经理和程序员大打出手，据说背后原因竟是产品经理要求用户App的主题颜色能根据手机壳自动调整，可能是程序员觉得这个要求太过分了，于是一言不合打了起来。
作为产品经理的我，也觉得这个需求有点过分，但是也不至于就为这打起来啊，你看看其他团队人家开始寻找解决方案了。
很佩服这个老哥给的解决方案，一个字：牛逼，两个字：真牛逼！
你咋不直接人工智能呢？如果你是程序员给出这个方案，在佩服你智商的同时，估计也要挨打了，还是下面的老哥给的方案靠谱啊
龙哥一句话，让整个空气都静止了，对啊，抛开需求的合理性，如果可以这样做那不就简单了。但是你如果碰到很轴的产品经理怎么办？
人家明明说的“根据手机壳的颜色自动调整APP主题颜色”，是自动调整！给你说三遍，是自动调整！怎么办？还能怎么办，揍他！！！（作为产品经理的我，都忍不住要揍他了，还是回去好好反思下你的需求吧！）
1、需求分析和描述不到位
如上图所示，程序员处在流程的最底端，产品经理跟客户/用户/领导沟通的需求，最后传递到程序员这里，有可能变了味道。如果产品经理把握不好，可能最终结果跟客户想要的完全不一样。等到最终客户/用户/领导勃然大怒的时候，矛盾可能就激发了。
如何解决？
产品经理首先要了解业务，才能更好的理解需求。如果需求来自客户，那么一定要明确这个需求不是最终可用的需求，一定要做需求分析，帮客户梳理这个需求，弄清楚客户提这个需求的最终目的是什么？
客户的需求如果是“我要一批更快的马！”，也许他的目的不是要一匹马，而是更快的交通工具。产品经理一定不是客户的传话筒，他一定要将客户需求转变为产品需求或者系统需求。
2、产品需求经常变动
由于产品经理经常改动需求，导致程序员不得不把做好的东西重新再做，结果可想而知。有时候程序员加班加点刚做完的东西，产品经理说需求变动了，不能这么做，严重的时候连核心模块都完全大变样。就一直这样改完做，做完改，无限循环下去。
但是产品经理也有怨言，需求变化是正常的啊，老板的想法经常变，客户的需求经常变，我有什么办法？
需求变化从某种意义上来说是好事，有变化说明有进展或者有改进，我们不能避免需求变化，但是作为产品经理我们要学会控制需求，对需求进行有效的管理。
首先我们要做需求的合理性讨论，在这个阶段如果能让技术参与，发表意见，让他们感到被尊重，对于后期的需求支持是很有帮助的，切莫自己二话不说拍脑袋！确定需求必须要改变以后，我们要合理的管理这个变化。
产品经理必须得有版本的概念，当前已经开发的版本内尽量不发生变化，把新的变化规划到下一版本；如果实在必须要在当前版本需要变化，那就和技术沟通工作量和计划变更。
要么延长上线时间，要么替换其他需求任务，让需求的变化不影响技术的工作量和计划，技术又怎么能给你打架呢？
当然，由于老板的行政命令和对客户的承诺，你无法更改计划，那怎么办呢？
还是和程序员做朋友，做兄弟吧，如此也许一顿饭就搞定啦。
3、产品狗不懂程序猿
遇到一个像我这样很懂技术的产品经理不容易（有点超自恋O(∩_∩)O），程序员经常听到的一句话就是——“这么简单的功能为什么要这么长时间？”
这样的话令很多程序员恼火，是最能激发与产品经理矛盾的导火索。因为你不懂技术，你就和程序猿没有共同的话题，你就很难站在对方角度上去看这个问题，你也无法掌控程序猿对工作量的评估是否合理，总是以为他在骗你，如果是这样的状态，又怎么能不产生矛盾呢？
从技术转到产品的人，本身对技术了解，可以更好的跟程序员沟通想法，但是一定注意，千万不要反客为主，不要干涉技术。之前就碰到一个曾经做过技术的产品经理，对于技术的方案评头论足，甚至指导技术，搞的技术很郁闷，摔了一句：“既然你这么牛逼，你自己做好了”。
对于不懂技术的产品经理来说，建议要去了解一下基本的技术知识，不需要太深，但是要知道概念，知道大致的使用场景。别整出像“你是用Java还是SQL开发”，“Hodoop比你用Java开发好吧”等这样的概念性的错误，让程序员鄙视，啥都不懂，你还怎么质疑人家评估的工作量啊！
高山流水，知音难觅！知音不成，至少我懂！只有懂对方，才能在一个频道上沟通。
为了做一个不想挨揍的产品狗，一定要不断修炼上面说的一些能力。当然作为一个曾经的程序员，现在虽做产品但依然领导技术团队的我，也有必要给我们的程序员弟弟们点建议：
做好需求变化的准备，不要排斥变化。要提高代码的扩展性和维护性，用不变的架构应对变化的需求。
对需求理解透彻在开始写代码，要多和产品经理确认！我们经常碰到最后开发出来的跟产品经理想要的不一样，就是因为没有理解需求，或者理解有误，就开始做了。
评估工作量和计划时，一定要预留修改bug及其他突发事件的时间，给自己的工作留有余地。
