产品经理怎么改需求，才不会被研发“砍死”？
听说因为随便改需求，某公司产品经理被愤怒的程序猿砍成重伤，至今昏迷不醒！
经常在网上看到，在产品研发的过程中，发生了需求变更。研发同学辛苦写的代码泡汤了，测试同学好不容易找出的 bug 得重新再找，每个人心里边都有一股怨念，产品经理作为需求的管理者，很容易承受人民群众的怒火，千夫所指，惶惶不安。一旦处理不好，很容易导致同事间的矛盾。
有人尝试着消灭需求变更的可能性，但很快会发现，需求变化很多时候根本不是产品经理自己就能控制的，甚至它就是产品发展过程中必然的经历。所以，需求变化必须纳入管理，我们称之为需求变更管理。
今天我们谈的需求变更管理方法，必须要明确两个前提：
适用于产品、研发能够畅通沟通的团队。对于外包项目等需求与开发负责人不在同一团队的情况，仅供参考。适用于研发周期短，快速上线的产品迭代。对于研发周期动辄大半年的软件工程项目，需要引入更复杂的需求变更流程。同样，对于产品整体方向上的大调整，也不适用文章中提到的方法。需求伊始充分沟通
互联网产品的研发是一次团队满足用户需求的体验之旅。既然是集体活动，事前约法三章非常重要，开始旅行之前，团队的每一位成员都需要就一些基本问题达成一致：
尊重团队的工作成果，每一次需求变更都意味着团队努力的消耗，不能接受随时随地都在发生的变化。产品经理作为需求的把控方，不能每天换个花样，今天要方的明天要圆的，提前想清楚自己要什么，拒绝拍脑袋做决策。
需求最好少变，但必须接受变化的存在。产品经理不是神，无法全知全能，团队需要对产品经理的工作保持一定的容忍度，无须谈变更就上板砖。我的习惯是和新团队合作，一定会找研发的同事们开诚布公一次，明确告知我能力有限，一定会发生需求变更，但是我会控制，不给大家瞎指挥。适当降低大家对自己工作的预期，有助于提高大家的满意度。
开始研发之前，产品经理有义务就本次研发的目标、手段和衡量方式，与整个团队达成一致。团队对需求的理解，直接影响着业绩达成。很多团队的产品和研发的关系都停留在产品经理写需求，研发团队做需求，至于为什么做，如何做，双方很少沟通，把办公室搞成了拧螺丝的流水线。
分享一个我常用来和团队伙伴沟通目标、手段、衡量手段的方法：BML 模型，即在什么样的背景下，作为产品经理，我依托什么逻辑设计了这样一套解决方案，上线之后我会去关注哪些节点的数据表现，什么样的数据表现会继续迭代这个方案，什么样的数据表现会考虑转型。
不要把所有问题都推到需求定义阶段。事前沟通再详尽，也会有疏漏和遗忘。过程中的沟通，有助于改善团队环境。对熟悉度很高的团队，很多事情可以靠眼神交流。如果还存有陌生感，一定要多聊，产品经理可以在午餐、晚餐及其他休息时间找研发同事听听他们对需求的理解，能够避免理解不一致带来的更改。
分清需求变化是如何发生的
再优秀的需求定义阶段，也顶不住来自时间的冲击。需求终究还是会发生变化的。那么处理的第一步，是弄清楚它是怎么发生的。常见的可能有以下几种情况：
1、自己没想清楚
这种情况对于天天都在看新东西的产品经理来说经常会发生。刚做好的设计，刚做完评审第二天就发现了新的方案。
2、老板/业务需求方变了
有的产品经理自己不会拍脑袋，但是架不住老板日理万机爱拍脑袋，胳膊拧不过大腿，只好变更。关于老板的需求处理，可以参见之前的一篇文章《报告老板，你的需求不靠谱》。
3、环境变了
产品还没上线，发现市场已经发生了变化。市场机会瞬息万变。比如之前本来稳扎稳打地做着百度云，忽然金山说我永久免费了，360也说我永久免费360G了，这时百度云也没法坚持原来的研发节奏。
4、以为变了
这种情况也经常发生，很多团队的沟通存在盲区，每个人都在瞎子摸象，对于最后的结果没有统一的目标，当发生不一致时，大家就会说这是需求变化了。
判断是否发起需求变更
推荐阅读/观看：成都网站建设 http://cdwzjs.net.cn
