76

迭代中加需求,如何不被打?

 5 years ago
source link: http://www.chanpin100.com/article/107324?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

采用敏捷迭代开发的互联网公司,往往在每一个迭代开始前,产品、开发、测试会通过需求会、冲刺会,评估该迭代的需求和工时,保证在该迭代内把所有明确的需求完成开发和测试。然而,相信很多产品都经历过在迭代进行中加需求的情况,那么如何可以保证向开发、测试加需求时不被打呢?

1.为什么会在迭代中加需求

从紧急重要四象限需求分析方法来看,在迭代中需要加的需求,一定是紧急重要(也许并非真的“重要紧急”)的需求,那么这类需求大致可分为以下两个维度:

(1)老板的需求

在迭代中的某一天,老板找到你说,某某功能体验不好、改一改啊。你心想,老板好不容易加一次需求,虽然这个需求看起来并不靠谱,但是也不好拒绝呀,就说好。然而老板的下一句话让你瞬间崩溃,“我觉得这个功能需要赶紧改,两天后上吧”。“What the f*”。相信你的内心一定是这样的,但是你又无法拒绝,只能加班设计解决方案,然后胆战心惊的去找开发、测试哥哥姐姐们聊聊“家常”。

其实上面这种场景很常见,至少我就遇到过很多次,老板提的需求有的很靠谱,有的却很扯,当然最关键的是老板的需求都很急。如果老板的需求是在迭代周期刚开始提出来还比较好解决,但是如果老板的需求在迭代的中后期提出来并且要求紧急上线的这种,对产品来说才是最难受的。

但是请记住一句话, 老板的需求,再不合理,还是要做! (对于不合理的需求,如何在做完再和老板沟通,在本文最后会通过一个案例进行复盘)

(2)对用户体验,对公司收益造成重大损失

这类紧急需求更容易让团队成员接受,在线上运行的产品,突然出现了某一个对用户体验造成重大伤害或对公司收益造成重大损失的问题,那么设计解决方案并紧急安排开发上线,这种场景对于大多数人来说都是比较容易接受的。

2.如何保证加需求不被打

(1)以理服人

首先,需求的解决方案一定是可实现的,比如前两天某安的产品与开发大打出手,就是因为需求的不可实现性。先不去看需求是否合理(毕竟老板提的不合理需求你也是要满足的),要保证的是给开发的解决方案是可以实现的。

其次,从5W2H的角度与开发、测试沟通需求,需求的背景,即谁提出了一个什么样的问题,这个问题在某个端(PC、小程序、APP等)对用户或公司造成了什么样的影响,影响有多大。再提出你的解决方案,即通过什么方案去解决这个问题,能达到什么样的效果,希望什么时间上线。

最后,就是与开发和测试确认时间点,对于用户体验和公司损失的问题,团队成员都容易理解,通过加班等方式也会尽力去保证及时上线。对于老板的需求,多多少少都会有些抵触心理,那么产品在这中间就要做到协调,尽可能让老板和团队开发、测试都满意,如何做到就是下面要说的学会向上沟通。

(2)学会向上沟通

对于老板提的不合理或者不靠谱的需求,前面说了,一定要做。那么接下来就是具体的方案和时间点,通过与开发、测试沟通好方案后,也许这个方案与老板要求的上线时间点不一致。

这个时候就要去和老板沟通,摆事实、讲道理,和老板沟通为什么不能在有限的时间点内完成并上线。罗列解决方案的复杂性,开发、测试资源的不足等等,老板也是从普通员工做起的,我相信只要你说的有道理,老板不会蛮不讲理的。

向上沟通,就是要保证团队成员和老板都尽可能的满意,不能完全压榨团队的积极性去一味的拿老板的需求当尚方宝剑,这样起到的作用也许适得其反。

3.案例复盘

最后通过一个案例来聊一聊,面对老板提的不靠谱需求,你应该如何合理的处理。这个案例是这样的:

用户在购买服务后并没有立即支付,对于未支付的订单会在30分钟后自动取消,那么为了做到对用户的提醒,提高支付成功率。系统会对下单后未支付超过10分钟的用户进行短信提醒,短信中会加入订单详情页链接,引导用户点击继续支付。某一天老板用了一下这个功能,发现通过点击链接进入订单详情页时要先登录,再点击去支付跳转收银台才能支付。于是老板提了一个需求说,链接直接跳收银台让用户支付就好了,为什么要加那么多繁琐的步骤,影响用户的继续支付意愿。

本质上来说,这样一个优化点是有些不合理的,在电信诈骗猖獗的今天,用户通过短信链接直接支付而不做任何提醒,对用户来说是有疑问的,用户可能不会轻易去支付。但是老板提了需求,就要做,3天时间开发、测试、上线。为了保证老板能看到上线后的效果,以及想让老板了解,这个需求也许并不是那么合理。通过在页面埋点以及从后台提取数据,分析对比了一下功能优化上线前后的数据效果,从继续支付的数据上看,效果并没有明显提升。通过页面打点来看,用户通过短信链接进行继续支付的几乎没有,通过分析和猜测,可能更多的用户还是在看到短信后继续登录了app进行继续支付,短信链接直接跳收银台的优化理论上没有起到任何正向的效果。

通过这样一个案例可以看出,老板也许只从个人的角度去看待功能的优化,并未考虑用户以及环境的因素,那么提出了这样一个不算合理的需求,作为产品经理,不仅要对老板负责,还要对更广大的用户负责,在满足了老板的需求后,也要通过上线后效果去提醒老板,也许还有更好的方案去提升用户继续支付成功率的指标,而不是通过现有的方案。

专栏作者

文/记小忆,产品壹佰专栏作者,野蛮生长的产品经理,运营商大数据产品实践者,擅长从0-1搭建产品经理知识体系。公众号:PM龙门阵。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK