评书大全：
快速导航：
播音员推荐：
按字母查询：
当前位置:&&&&&&&&&&
正在播放 最强挨揍系统完结第208集
穿越有声排行榜
皖ICP备号-1免责声明：我们拒绝任何色情小说，一经发现，即作删除！
本站所收录作品、社区话题、书库评论及本站所做之广告均属其个人行为，与本站立场无关
友情提示：如果你喜欢这里，别忘了推荐给你的朋友，或者在博客、空间上做上我们的链接。评书网宗旨把老祖宗留下的瑰宝评书发扬光大 ICP备号
如本站资源侵犯您的权利请告知，本站将立即予以删除。请试听后去购买正版光盘，其版权归相关影音公司所有.作品上传请给我们留言!?神话破灭！MMA顶级高手挨揍集锦！没有厉害只有更厉害！
话不多说，大家快点戳
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点& - && - && - && - &正文
身为产品经理，要怎么合理的跟程序员提需求呢？要怎么去处理才能很好的化解产品与技术的矛盾，而避免挨揍呢？
最近一个视频火遍了整个朋友圈，某公司的产品经理和程序员大打出手，据说背后原因竟是产品经理要求用户App的主题颜色能根据手机壳自动调整，可能是程序员觉得这个要求太过分了，于是一言不合打了起来。
产品狗和程序猿打架，谁会赢？真是看热闹的不怕事大！
作为产品经理的我，也觉得这个需求有点过分，但是也不至于就为这打起来啊，你看看其他团队人家开始寻找解决方案了。
尼玛，厉害！你咋不分析手机附近的光谱呢？
很佩服这个老哥给的解决方案，一个字：牛逼，两个字：真牛逼！
你咋不直接人工智能呢？如果你是程序员给出这个方案，在佩服你智商的同时，估计也要挨打了，还是下面的老哥给的方案靠谱啊
龙哥一句话，让整个空气都静止了，对啊，抛开需求的合理性，如果可以这样做那不就简单了。但是你如果碰到很轴的产品经理怎么办？
人家明明说的“根据手机壳的颜色自动调整APP主题颜色”，是自动调整！给你说三遍，是自动调整！怎么办？还能怎么办，揍他！！！（作为产品经理的我，都忍不住要揍他了，还是回去好好反思下你的需求吧！）
我本身程序员出身，做到技术总监，后来由于业务的需要，不得不做产品和运营。有过技术和产品的双重经历，我能深刻的体会到技术和产品的矛盾，也更了解如何去化解这个矛盾。
1、需求分析和描述不到位
程序员在流程的最下游
如上图所示，程序员处在流程的最底端，产品经理跟客户/用户/领导沟通的需求，最后传递到程序员这里，有可能变了味道。如果产品经理把握不好，可能最终结果跟客户想要的完全不一样。等到最终客户/用户/领导勃然大怒的时候，矛盾可能就激发了。
如何解决？
简单，一个杯垫搞定！尼玛，你咋不放把水果刀呢？
产品经理首先要了解业务，才能更好的理解需求。如果需求来自客户，那么一定要明确这个需求不是最终可用的需求，一定要做需求分析，帮客户梳理这个需求，弄清楚客户提这个需求的最终目的是什么？
客户的需求如果是“我要一批更快的马！”，也许他的目的不是要一匹马，而是更快的交通工具。产品经理一定不是客户的传话筒，他一定要将客户需求转变为产品需求或者系统需求。
2、产品需求经常变动
再变别跳楼啊，拿刀去砍他！
由于产品经理经常改动需求，导致程序员不得不把做好的东西重新再做，结果可想而知。有时候程序员加班加点刚做完的东西，产品经理说需求变动了，不能这么做，严重的时候连核心模块都完全大变样。就一直这样改完做，做完改，无限循环下去。
但是产品经理也有怨言，需求变化是正常的啊，老板的想法经常变，客户的需求经常变，我有什么办法？
产品经理必须掌握需求管理
需求变化从某种意义上来说是好事，有变化说明有进展或者有改进，我们不能避免需求变化，但是作为产品经理我们要学会控制需求，对需求进行有效的管理。
首先我们要做需求的合理性讨论，在这个阶段如果能让技术参与，发表意见，让他们感到被尊重，对于后期的需求支持是很有帮助的，切莫自己二话不说拍脑袋！确定需求必须要改变以后，我们要合理的管理这个变化。
产品经理必须得有版本的概念，当前已经开发的版本内尽量不发生变化，把新的变化规划到下一版本；如果实在必须要在当前版本需要变化，那就和技术沟通工作量和计划变更。
要么延长上线时间，要么替换其他需求任务，让需求的变化不影响技术的工作量和计划，技术又怎么能给你打架呢？
当然，由于老板的行政命令和对客户的承诺，你无法更改计划，那怎么办呢？
还是和程序员做朋友，做兄弟吧，如此也许一顿饭就搞定啦。
3、产品狗不懂程序猿
遇到一个像我这样很懂技术的产品经理不容易（有点超自恋O(∩_∩)O），程序员经常听到的一句话就是——“这么简单的功能为什么要这么长时间？”
这样的话令很多程序员恼火，是最能激发与产品经理矛盾的导火索。因为你不懂技术，你就和程序猿没有共同的话题，你就很难站在对方角度上去看这个问题，你也无法掌控程序猿对工作量的评估是否合理，总是以为他在骗你，如果是这样的状态，又怎么能不产生矛盾呢？
从技术转到产品的人，本身对技术了解，可以更好的跟程序员沟通想法，但是一定注意，千万不要反客为主，不要干涉技术。之前就碰到一个曾经做过技术的产品经理，对于技术的方案评头论足，甚至指导技术，搞的技术很郁闷，摔了一句：“既然你这么牛逼，你自己做好了”。
对于不懂技术的产品经理来说，建议要去了解一下基本的技术知识，不需要太深，但是要知道概念，知道大致的使用场景。别整出像“你是用Java还是SQL开发”，“Hodoop比你用Java开发好吧”等这样的概念性的错误，让程序员鄙视，啥都不懂，你还怎么质疑人家评估的工作量啊！
高山流水，知音难觅！知音不成，至少我懂！只有懂对方，才能在一个频道上沟通。
为了做一个不想挨揍的产品狗，一定要不断修炼上面说的一些能力。当然作为一个曾经的程序员，现在虽做产品但依然领导技术团队的我，也有必要给我们的程序员弟弟们点建议：
做好需求变化的准备，不要排斥变化。要提高代码的扩展性和维护性，用不变的架构应对变化的需求。
对需求理解透彻在开始写代码，要多和产品经理确认！我们经常碰到最后开发出来的跟产品经理想要的不一样，就是因为没有理解需求，或者理解有误，就开始做了。
评估工作量和计划时，一定要预留修改bug及其他突发事件的时间，给自己的工作留有余地。
#专栏作家#
菜根乱谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术总监等技术岗位，现在从事掌上医讯的产品运营和公司发展。关注医疗，早教领域，擅长技术应用型产品的设计和运营。
本文原创发布。未经许可，禁止转载
题图来自 Pixabay，基于 CC0 协议
你可能会感兴趣的
运营大牛推荐
必看运营干货
in_array() expects parameter 2 to be array, string given in /www/wwwroot/www.jxbin.com/wp-content/themes/lensnews/single.php on line 43}