"不就是提个小需求么?你们怎么反应那么慢?”
"你们这个需求排不到程序里面,不予立项”
"你们产品写的需求文档不是我们要的效果啊,我们看重的是……”
"排队排队排的队,研发人不够,排期已经到下个月中了。”
"功能测试已经通过了,但是应用近期没有上线计划,上线要等到下个月初哈”
"特殊时期,包含该内容的应用一律不予审核通过”
........
太难了,一个需求从提出,到立项,到研发完成,到正式上的线,到底要经历多少艰难险阻吗?
比漫长的上线流程更扎心的,是好不容易上线的功能,错过了最佳窗口期,结果没有达到想要的效果。
就像这个流程图中所展现的,一个功能的上的线,就算再精简流程,受限于组织架构,软件架构,也很难提升到哪儿去。而与繁复流程相伴的,是愈加丰富的业务场景和诉求:
-
<李>
业务部门:市场千变万化,必须加快需求的响应速度,及时跟上市场热点
<李>运营部门:运营理论千千万万,应用无法获得用户画的像,就根本无法支撑精细化运营;而产品迭代速度又严重限制了运营计划的上线
<李>产品部门:需求如潮,水处理不完的优先级排序,一味跟随业务需求,又导致应用愈发冗余,缺少亮点
<李>研发部门:排期,缺人,赶工,不停的做需求,根本没有多余的精力审查代码,优化架构,提升性能
这真的就是一个死结么?就没有办法,能够同时满足多方诉求?
有!来试试灰度发布吧!
什么是灰度发布?
按照传统定义,灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B测试,即让一部分用户继续用产品特性,一部分用户开始用产品特性,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。(源自维基百科)
而在讲究”增长黑客”概念,需要精细化运营的今天,灰度发布不仅仅是一个发布方式,它可以:
-
<李>
快速验证营销计划或产品创想,用更低的成本实现更多的尝试
<李>为新功能验证提供数字证明,用科学实验代替主观判断
<李>提前“试点“新功能,通过实验组对比,得到更明确的下一步要做什么
<李>"摸底”用户反馈,将不受欢迎的功能“扼杀”在摇篮
<李>缩短研发测试流程,加快团队敏捷度
事实上,尽管灰度发布看起来十分“美妙”,但在真实环境中,受限于灰度实验设计流程的繁琐,极少有团队能通过灰度,提升应用整体转化。
这其中的难点包括:
-
<李>
由于灰度需要实验组和正常组,因此设计实验组的过程中,并不能直接降低研发工作量
<李>对应用缺少”数据抓手”,投放灰度后,很难获得有效,真实,及时的用户反馈
<李>灰度发布的可选项极少,应用本身只能通过有限工具,实现不可控的灰度范围
<李>灰度更适用于有限的小功能,如按钮颜色,文字微调,只能提升部分业务转化率
<李>如对大版本进行灰度,受限于工具,又进入了灰度范围难以控制的死循环
怎么做好一个灰度发布?
让我们再回顾一下灰度发布中的难点,总结起来,无非是:
-
<李>
灰度功能也需要开发,对应就是一个完整的开发流程,这一点看起来无法避免
<李>灰度发布需要更严谨的方案设计,针对什么人,灰度什么内容,如何分析并运用分析结果,这都需要精于业务,了解产品与用户的人去精心设计的
<李>灰度发布的覆盖人群应该更精准,覆盖方式必须多样且能满足灰度方案的需求
<李>
