这种情况也经常发生

发布时间:2018-10-15 13:36:20
产品经理怎么改需求,才不会被研发“砍死”? 产品经理怎么改需求,才不会被研发“砍死”?

听说因为随便改需求,某公司产品经理被愤怒的程序猿砍成重伤,至今昏迷不醒!

产品经理怎么改需求,才不会被研发“砍死”?

经常在网上看到,在产品研发的过程中,发生了需求变更。研发同学辛苦写的代码泡汤了,测试同学好不容易找出的 bug 得重新再找,每个人心里边都有一股怨念,产品经理作为需求的管理者,很容易承受人民群众的怒火,千夫所指,惶惶不安。一旦处理不好,很容易导致同事间的矛盾。

有人尝试着消灭需求变更的可能性,但很快会发现,需求变化很多时候根本不是产品经理自己就能控制的,甚至它就是产品发展过程中必然的经历。所以,需求变化必须纳入管理,我们称之为需求变更管理。

今天我们谈的需求变更管理方法,必须要明确两个前提:

适用于产品、研发能够畅通沟通的团队。对于外包项目等需求与开发负责人不在同一团队的情况,仅供参考。适用于研发周期短,快速上线的产品迭代。对于研发周期动辄大半年的软件工程项目,需要引入更复杂的需求变更流程。同样,对于产品整体方向上的大调整,也不适用文章中提到的方法。需求伊始充分沟通

互联网产品的研发是一次团队满足用户需求的体验之旅。既然是集体活动,事前约法三章非常重要,开始旅行之前,团队的每一位成员都需要就一些基本问题达成一致:

尊重团队的工作成果,每一次需求变更都意味着团队努力的消耗,不能接受随时随地都在发生的变化。产品经理作为需求的把控方,不能每天换个花样,今天要方的明天要圆的,提前想清楚自己要什么,拒绝拍脑袋做决策。

需求最好少变,但必须接受变化的存在。产品经理不是神,无法全知全能,团队需要对产品经理的工作保持一定的容忍度,无须谈变更就上板砖。我的习惯是和新团队合作,一定会找研发的同事们开诚布公一次,明确告知我能力有限,一定会发生需求变更,但是我会控制,不给大家瞎指挥。适当降低大家对自己工作的预期,有助于提高大家的满意度。

开始研发之前,产品经理有义务就本次研发的目标、手段和衡量方式,与整个团队达成一致。团队对需求的理解,直接影响着业绩达成。很多团队的产品和研发的关系都停留在产品经理写需求,研发团队做需求,至于为什么做,如何做,双方很少沟通,把办公室搞成了拧螺丝的流水线。

分享一个我常用来和团队伙伴沟通目标、手段、衡量手段的方法:BML 模型,即在什么样的背景下,作为产品经理,我依托什么逻辑设计了这样一套解决方案,上线之后我会去关注哪些节点的数据表现,什么样的数据表现会继续迭代这个方案,什么样的数据表现会考虑转型。

产品经理怎么改需求,才不会被研发“砍死”?

不要把所有问题都推到需求定义阶段。事前沟通再详尽,也会有疏漏和遗忘。过程中的沟通,有助于改善团队环境。对熟悉度很高的团队,很多事情可以靠眼神交流。如果还存有陌生感,一定要多聊,产品经理可以在午餐、晚餐及其他休息时间找研发同事听听他们对需求的理解,能够避免理解不一致带来的更改。

分清需求变化是如何发生的

再优秀的需求定义阶段,也顶不住来自时间的冲击。需求终究还是会发生变化的。那么处理的第一步,是弄清楚它是怎么发生的。常见的可能有以下几种情况:

1、自己没想清楚

这种情况对于天天都在看新东西的产品经理来说经常会发生。刚做好的设计,刚做完评审第二天就发现了新的方案。

2、老板/业务需求方变了

有的产品经理自己不会拍脑袋,但是架不住老板日理万机爱拍脑袋,胳膊拧不过大腿,只好变更。关于老板的需求处理,可以参见之前的一篇文章《报告老板,你的需求不靠谱》。

3、环境变了

产品还没上线,发现市场已经发生了变化。市场机会瞬息万变。比如之前本来稳扎稳打地做着百度云,忽然金山说我永久免费了,360也说我永久免费360G了,这时百度云也没法坚持原来的研发节奏。

4、以为变了

这种情况也经常发生,很多团队的沟通存在盲区,每个人都在瞎子摸象,对于最后的结果没有统一的目标,当发生不一致时,大家就会说这是需求变化了。

判断是否发起需求变更

推荐阅读/观看:成都网站建设 http://cdwzjs.net.cn



独家出品

新闻由机器选取每5分钟自动更新

新闻搜索源于互联网新闻网站和频道,系自动分类排列,本站不刊登或转载任何完整的新闻内容