内容来源:2020年7月24日,拉勾教育One Club|ONE·案例公开课
分享嘉宾:薛军,雪豹学院创始人兼CEO,17年移动互联网从业经验,敏捷专家,前腾讯P12专家、前腾讯项目管理通道委员会会长、微信“摇一摇”奠基人。
今天我分享的主题是“企业的敏捷转型”。
首先讲讲我的经历。
我参与过很多收购项目,经常和企业的 CTO(首席技术官),研发总监,还有首席架构师交流。
当我问他们:咱们公司是做什么行业的?
关于公司所在的行业,公司有什么产品和服务,他们都说得很清楚。
有意思的是我再问他们:咱们公司的研发模式是什么呢?
大部分人在这种情况下都有点茫然,好像都没有想过这个问题。只知道客户是谁,产品和服务是什么,要如何努力地去服务客户。
但是,从未想过整个公司的研发模式是否适应客户,能不能更好地交付产品和价值,以及应该用什么样的方式弄清企业的研发模式。
这是现在很多企业面临的一个问题。
当企业家有了相关的意识之后,那么他们就会去思考,应该是用传统的研发模式,还是用最新的敏捷模式。
我先介绍2个定义。
敏捷转型是指某个团队或某个公司从瀑布研发模式向敏捷研发模式转变的过程。敏捷管理是指帮助团队高效应对市场不确定性的管理方法。
一、敏捷转型企业的特点
首先,我讲一下适合敏捷转型的企业应该具备什么样的特点。
第一点,企业所处的行业是一个快速增长的行业。
行业不是一个存量市场,而是一个增量市场。我们比的是谁能够更快地跑马圈地,能够更快地圈住更多用户,圈住更大的市场份额,服务更多客户。
第二点,价值体系明确。
公司从上到下都能非常清晰地描述客户的价值是什么,产品对客户最有价值的功能什么,用户最愿意买单的服务是什么。
为什么价值体系对于做敏捷转型的企业非常重要?
因为我们在转型的时候,相当于是把整个组织“打散”了,是小团队运作。
假设你是一个300人的公司,按照我们敏捷转型的要求,大概要拆分成20多个15人左右的小分队去作战。
从一个“大金字塔形”一下子转变成了“20多个非常灵活的小团队”,如果说大家不知道公司目标是什么,那就是乱跑。
因为原来是“金字塔”,大家的“脑袋”都往上看,都由上级领导一级一级地传递命令和任务,大家只管照搬做就行。
但是,转变成敏捷组织时,提倡的是“自组织,每一个团队自主定目标,定计划,然后自主执行”。
在这种情况下,价值体系就像黑暗中的灯塔或者火炬的作用。
当我们把价值体系摆在所有人面前时,虽然20多个团队可能按照自己的节奏,方法,从不同的角度或方式去努力,但是它知道要朝灯塔或火炬去前进,所以这是价值体系一定要明确的原因。
第三点,价值创造,我们需要一个有创造性的团队。
什么是具有创造性的团队?
就是所有的人努力认真地去做事和敷衍地去做事之间的巨大的绩效差异,而且成员是否努力这件事情,只有成员自己知道,外界很难用一套简单的指标体系去度量。
最后我们做一个简单的概括,适合敏捷转型的企业应具备以下特点:在一个快速增长的增量市场里,企业能够非常清晰地把价值体系梳理清楚,然后依赖很多小的创造性团队去实践。
二、一定要敏捷转型吗
可能有的企业家对照条件一看,认为转型条件满足,现在要和友商比拼的是速度,想要更快地去满足用户的需求,要“快鱼吃慢鱼”。
那在条件都满足的情况下,传统模式不行吗?为什么一定用敏捷模式呢?
我认为有以下4点原因:
第一,现在大家所熟知的国外企业,无论是大企业,还是硅谷的创业公司,都是采取的敏捷管理。
比如,微软做了敏捷化的转型。
微软这几年的股价触底反弹,涨得非常凶。
核心原因就在于它把所有的业务云化,原来还是卖软件,现在变成了通过云接口随时调用,“以租代卖”。
其次,微软的团队也实行了敏捷化,国内像腾讯也一样。
外界觉得腾讯的产品做得好,但可能不知道是腾讯的敏捷实行得好。这才是腾讯在移动互联网时代能够取得领先的非常核心的一个点。
第二,当下全球信息化扁平竞争非常激烈,所以企业间竞争也非常激烈。
之前,美国的商业模式还领先国内大概2、3年,也就是说美国出现一些新的模式,差不多2、3年后,国内才引入,消费者顺势接受,所以那个时候经常叫CTC叫“copy to China”(从美国复制模式到国内)。
比如,早期的千团大战。
美国有一个官方网站搞了一个团购,国内一看觉得还不错,就开始copy了。国内团购网站在高峰期有6000家,最后活下来的只有美团和点评,最后还合并,在短短的三年时间内,从6000家竞争成了2家,竞争非常激烈。
现在,全球都不存在信息差,甚至出现了国外复制中国的优秀的商业模式。
比如,共享单车对我们来说都已经玩上瘾了。现在已经没什么竞争了,就剩几家。可现在在国外,包括美国,已经不是共享单车,而是共享平板车,但他们的充电的模式还是工厂模式。
所以,三年的时间,如果你发布的产品是传统模式,按月计算,最多能发30多个版本。
可是,如果按照我的理解的话,一年内最快两周发布1个版本就可以发22个,三年可以发60多个。
如果用更敏捷的web(网页)小程序来做,你一周可以发1个版本,那么一年可以发45个,三年可以发120-135个版本。
因此,当你的版本数是别人的大约3-4倍的时候,企业进化的速度,适应市场的速度就会比别人快很多。所以在竞争激烈的情况下,敏捷的效率更高。
第三,“敏捷”经过了不到20年的磨合已经是一个相对成熟的管理制度了。
最后,“敏捷”涉及整个公司的所有角色。
“敏捷”需要产品经理设计师,前台开发、后台开发、架构师,运营,测试,项目管理,甚至包括财务等等去适应,包括组织结构都要改变。
如果今天你要去创业,或者说今天你是一个人员数已经配备齐全,业务模式已经清晰,作为快速奔跑的公司来说,一定是要做敏捷。
三、敏捷转型的时机
关于敏捷转型的时机,有以下3点:
第一,快速成长,行业成长的时候;
第二,与友商竞争激烈的时候;
第三,企业人效出现下降的苗头的时候。
我们通过例子,分别来看一看。
1.“海盗来了”
“海盗来了”是个小游戏,面世后用户增长很快,从2018年4月21日到2018年5月9日,它的 DAU(日活跃用户数量)就从500万涨到了1500万。
“海盗来了”为什么能够取得这么好的成绩?因为它每天都要上线一个新版本。
小游戏本来就是用户用来休闲的,是非常零散的一种游戏玩法。也就是说,用户今天来玩一会,可能过几天才会再来。
每天发布新版本,用户每次来的时候都能够玩到新东西,用户就会觉得这个游戏更好玩。
当小游戏处在高速发展的过程中,谁的玩法能够持续更新,对玩家来讲就会觉得这个游戏更好玩,玩家的留存就会高,游戏开发商的DAU(日活跃用户数量)就能很快地涨上去。
当企业所处的行业高速发展的时候,就必须用敏捷的方法来做。
2.小米
小米是雷军做得很成功的手机。MIUI的第一版是在2010年的8月16号发布的,而2010年的8月12号是安卓手机大爆发的前夕。到今天为止(之前举例时间2020年4月27号),是“MIUI 1212”的版本推出的日子。
小米做得最厉害的一点是什么?
就是 MIUI从第一个版本开始,他们一直坚持做一件事情——每一周都发布一个版本。
用过MIUI的人就知道,每一周发布的版本是“实验版”或“开发版”。
也就是说明确地告诉你这个版本是“不稳定,有问题”,但是这个版本有三个新功能,“你想玩,你就先安装这个版本”。
如果你说“不要,我要稳定,安全,我希望这个版本做得更好一些”。
没问题,小米保证每个月出一个稳定版本。
尽管每周发布的版本不稳定,但它会不断地把更新新功能。
我认为,小米手机能够在中国市场占据一席之地的一个非常重要的原因就是在激烈的手机市场竞争过程中,用了这一招。
因为,小米线下不如OPPO和vivo,硬件不如华为,小米就是靠持续的更新来快速响应用户的反馈。
所以,很多小米的粉丝很喜欢小米的风格,不断地尝鲜,用到了一些新的功能就觉得更炫酷。
3.腾讯
腾讯2004年上市,股价在2007-2008年来回波动,但不往上走,腾讯是很痛苦的。
而且上市之后扩张了很多业务,业务多了,团队就多了。
但在2007年,我们发现一个问题:虽然人多了,事多了,可是公司绩效在下降,公司的收入增长不明显,处于一个很“梗”的状态。
2007年初,腾讯启动了链接转型,然后用了两年多的时间,就实现了敏捷转型。
到了2009年的时候,腾讯开始爆发,再加上2011年微信面世以后,腾讯的发展变得一发不可收拾。
一般来讲,企业会遇到一些困难,实际上管理者是很难痛下决心的,可能还是要撞一下南墙。
所以,当我们面对激烈竞争的时候,我们能不能用敏捷的方式转型来战胜它。
因为各种原因,企业基本上坐到风口上了。
遇到了风口,这时候靠什么?
就是要靠快速发布产品,能够更高效地去发挥团队的力量,给到用户更好的功能。
比如,今年的疫情,就对能够做在线协同的软件公司提出一个很大的要求,以前“你”让别人用,别人都不用,现在别人天天找着用。
从国内情况来看,疫情持续三个月左右,我们就能控制下来,所以给你的窗口期就是3-6个月的时间。
如果说1个月才出1个版本,怎么赶得上市场的变化?
好,接下来我讲讲敏捷转型的三种模式。
四、敏捷转型的三种模式
1.敏捷转型的步骤与宣传首先,我们在敏捷转型的步骤上,通常会找一些小的团队去做试点,或者可能整个公司直接全面转型。
那么,小团队试点优点是什么?
第一,试错成本低;
第二,因为是小的团队,所以公司可以挑选合适的业务,给更多的资源来确保成功;
第三,小团队作为试点团队可以规避一些风险,减少压力;
第四,因为只是涉及一小部分团队,所以我们不需要变革企业组织。
全面转型也有其优势。
全面转型减少了所有的阻力,不存在一部分人做,一部分人不做。因为如果只是一部分人用敏捷,一部分人不用敏捷,用敏捷的这部分人会显得很奇怪。
还有就是关于要不要公开。
公开的话,好处就是更容易坚持,彻底地告诉全公司“我们要干这事”。让所有人都意识到,公司已经明确了方向,目标更坚定更明确。此外,组织之间相互支持,更好的协调。
也有一些公司会去选隐秘的行动,一般是小团队的时候可以考虑。
第一个好处就是避开一些反对声音的干扰。
比如,我们单独挑选一支队伍,这支队伍可能离大部队较远,平时别人都不知道他们是有名气的,大家都不知道,所以就没有那么多的反对的声音。
第二个好处,因为是隐蔽的行动,团队可以避免一些额外的压力。这样的话更容易集中精力。
最后一个好处,就是隐秘的行动的时候,可以集中一些资源,确保敏捷转型更成功。
2.敏捷转型常见模式第一种模式叫“先拆分,后播种”。
假设有一个6人的彼此熟悉、经过各种培训且有经验的敏捷团队,我们可以把“6人团队”变成2个“3人小组”,然后去搭配。
将不太懂敏捷的3个人搭配成新的团队,这样的话把掌握了敏捷的人作为种子,去孵化或影响还没有掌握敏捷的这些人。
这个我们把它称为“先拆分,后播种”方式来操作,这是常见的敏捷转型的一个方法。
第二个模式叫“先成长,后拆分”。
一个6人的敏捷团队组成了以后,如果去拆分,可能他们人数就变少了,而且其中3人还要去影响其他3人,阻力会比较大。
换一种方式,在原来的团队持续地、慢慢地加人,从6个人变成12个人,成长到一定程度之后,再把它拆分成两个6人的小组。
这样的话,后期拆分的6个人都是已经彻底掌握了敏捷的能力的人,这是常见的敏捷转型的一个方法。
所以这种模式叫“先让团队成长,然后再拆分”。
第三个模式叫“敏捷教练辅导”。
就是有一个团队,他们都很熟悉敏捷。还有很多的团队,他们其实不太懂,我们就从敏捷团队中派出一个人给不熟悉的团队当敏捷教练,来指导不敏捷的团队进行敏捷转型。
以上,是三个常见的敏捷转型的模式。
通常在实践中,因为前面两种都涉及到人员组织结构的调整和调动,一般多用于部门内部,在很多组织内部,如果同部门大家都能接受。
但是,如果部门内部培养的人才要去帮助公司其他部门的人或团队,有时候部门领导很难过得了自己的心理门槛。
所以“敏捷教练辅导”模式就比较适合整个公司的敏捷转型,比较更容易地用公开化的方式来运作。
最后,我们讲讲案例。
五、敏捷转型的成功案例
第一个案例是腾讯,为什么给大家分享这个呢?
第一,因为腾讯的敏捷转型是我所知的中国软件企业互联网行业里头最早的企业;
第二,腾讯敏捷转型做得最彻底。从2009年以后,腾讯所有的业务团队都是用敏捷的方式来运作,包括微信和王者荣耀。
第二个案例是某AI企业。
该企业是我2018-2019年的咨询客户,他们也是在我的帮助下来实现了敏捷转型。
所以,是一个大公司,一个小公司,一个很早就做了敏捷转型,一个是刚做的敏捷转型。
1.腾讯的敏捷转型2003年-2006年,腾讯员工的数量增长极快。
2006年年底,老板就已经发现整个腾讯公司出现了3个很不好的情况:
第一,决策越来越慢;第二,流程越来越长;第三,团队离我们的用户越来越远。
第一点,以前,公司团队小,大家都坐在一起,就算需要老板决定,也可以传到办公室以后直接就说有什么事。我们遇到困难时,大家马上开个会,讨论完就可以决策实行。
后来,人多了,为了管理就必须要设各种各样的组——有产品组、研发组、质量组、测试组、设计组、网站组等等。
当你有各种组织的时候,决策就没法快,很多事情都要去找各个部门的领导来一起商量。
第二点,早期因为我们是“野路子”,虽然大家觉得效率高,但是不正规。于是后来我们引入了各种各样的审批流程,公司正规化运作。
但是,因为组织结构的人员多了以后,组织层级的增加,审批流程是越来越长,就导致流程越来越长,很多事情都是按周走,没有办法按天走,更不可能按小时走。
最后一点,因为团队人多了,内部各种各样的会议就比以前更多,导致团队没有时间去跟我们的用户进行直接的接触,我们的团队离用户就是越来越远。
这就是2007年腾讯决定转型的背景,总而言之就是我们的人效在降低。
一开始,我们仍是一个小团队的概念,全公司挑了6个业务来做试点,那个时候实际上我们有点偏秘密行动,并没有公开地说要做转型,是一个秘密的协作。
等到做了两年多以后就有一些成果了,也就是说这些业务团队都取得了业务上的成功,而且也做了很多好的做法可以进行试点了。
于是我们就公开在公司内部进行倡导,公开敏捷转型。
实际上早期的时候也引入了很多外部教练,同时我们一直在做内部教练培养。
后期我们就全部用内部的教练在内部来培训,原因是因为外部教练对我们的业务还是有一些不理解。
尤其腾讯内部的业务类别跨度非常大,所以我们当时实际上还是需要内部教练来做很多事情。
此外,腾讯还采取了其他措施。
第一是公司专门设置了一个大奖,叫做“卓越敏捷研发奖”。而且对于团队和个人,分别设置了在敏捷团队上做得好的团队以及在敏捷研发上做得好的个人的两个奖项。
比如,QQ邮箱。当时中国基本上没有人用QQ邮箱,是广州的一个很小的团队,被选来做试点,希望通过敏捷转型的方式实现业务快速的成长。
每年研发团队里头,我们评奖的时候,第一个就是研发进度的偏差,也就是发布的成功概率要高,且能够按时发布。
因为是公司的年度大奖,所以公司这两个奖其实分量很重的。而且每半年会做一次评审,甚至有的时候评审标准的严格程度会导致奖项无人获得,未来肯定还是要把标杆拔高,鼓励大家去做敏捷的研发。
第二是“文档精炼,评审高效”,也就是说团队内部文档并不是越多越好,而是精炼,但这并不影响对业务的理解。
内部的流程的决策速度更快,同时要求在敏捷的过程中不能有重大的质量事故。此外,你要积极地去应用,当时腾讯内部研发了一个叫“tpp”的敏捷研发平台做产品开发。
第三是CE敏捷度,也就是为用户创造价值,快速响应用户需求的能力。
最后,就是团队能够深刻理解,并积极地分享好的敏捷实践到公司的其他团队。而敏捷研发的个人,我们也会要求是要能够带领团队实现小步快跑,关心公司的产品。
腾讯最终做得好的有5件事情:
第一件,混合的小团队作战。
整个公司都是小团队作战,每一个小团队又是一个混合团体,它会包含产品经理、设计师、开发人员,运营人员,做某一个功能的人混合在一起作为一个统一的小团队;
第二件,稳定的发布节奏。
也就是说我们发布节奏两周就是两周,一周就是一周,要在1-2年内的时间里长期坚持;
第三件,灰度发布。
为了能够解决快速研发过程中的质量问题,避免伤害和骚扰用户,我们用灰度发布的方式来做发布的优化,降低质量问题对用户造成的损失;
第四件,提倡和坚持持续集成。
代码这一层做了非常多的小工具来帮助团队去做这件事情;
第五件,特别强调的用户反馈的变化。
很多人都觉得BAT三家里头腾讯的产品做得最好,但我个人认为腾讯做得最好的是从运营到产品的闭环。
当我们去做运营,能够在海量的反馈里找到有效的、有价值的反馈,迅速地回归到产品特性这里,推进了产品的成功。
也就是说,我们在创造用户需求的时候,特别尊重用户的反馈。提出好的点子不能靠闭门造车,而是需要和用户互动,反馈,总结提炼。
腾讯敏捷转型的成果都公开发布过的,所以大家可以自行去看。
2019年年底,腾讯公司针对整个公司的很多团队,做了一个调研,我们可以看到2件事情:
第一,就是保持小团队,整个腾讯公司里头60%的团队规模都是小团队;
第二,47.8%的产品迭代周期都是在一周,接近20%多是在两周之内,极少数才在4周以上。一周和两周的迭代期占比达到70%,用户侧平均每天完成3800个需求,28%的需求能够在一天内得到响应。
当然,从长期健康的角度来讲,我们并不提倡所有的需求都是一天性的需求。
因为这往往说明你对需求的思考不深刻。但是客户需求能够被更快的响应这件事情一定是我们关注的重点。
还有,46%的bug(漏洞)能够在一天之内解决,近78%的 bug能够在一周之内解决,82%的bug能够在一周的时间解决,这就是对质量快速反应的要求。
持续交付方面,每周构建次数是80万次,平均一个项目的年交付次数是3000次。
一年里工作时间就220多天,每个项目年交付次数是3000次,意味着我们每一天想要发布一个版本,几乎都是可能的。
因为有时候用户也不希望我们那么快,所以我们一般是按一周或两周交付,好处就是我们的代码质量会持续的得到一个保证。
敏捷转型从2007年开始,到2019年年底总结:通过敏捷转型,腾讯有了良好的快速应对能力。
所以,俗话说得好“天下武功,唯快不破”。
假设腾讯和你同时做产品,腾讯用敏捷你不用敏捷,最终的结果就是所有人能力一样的情况下,腾讯的产品可以是你的几倍的进化速度,甚至一个月就能调整4次。腾讯两个月可以调整8次,你只能调整两次,所以它就更容易接近真正的需求。
而你还在试错的过程中,它可能试了8次以后就找准了方向,从此以后就是一路的狂奔。
而你可能两个月还摸不着用户的情况,可能也需要8次才能摸到,或者你6次摸到,半年都过去,它都已经沿着那条正确的路狂奔了。
大家同时看到机会的时候,你的速度比它慢多了。
2.某AI公司的敏捷转型AI公司当时找到我就是谈论3个问题:
第一个是存量用户的活跃度不高;
第二个是用户的付费转化率较低;
第三个是公司的产品发布总是没有承诺性,开发团队总是延误。
最终,经过商讨,我们决定一定要敏捷转型。
第一是因为它面临一个激烈的友商竞争;
第二个是当时对这家公司我们采用的是直接进入全面转型的方式,同时是直接公开的。
因为是全面转型,公司内所有的团队都要去转型,必然就是公开的转型。
之后,他们正式外部聘请我来给做指导。
当然,他们内部也想培养一个培训教练,通过这种方式来进行转型。
我们最终做了4件事情:
第一件事情,APP的固定发布时间为两周;
第二件事情,确保每天都能根据故事墙来做晨会;
第三件事情,及时地去做每一次迭代后的总结;
第四件事情,要求迭代内的需求优先级必须是个金字塔。
为什么要求迭代期内所有的需求的优先级必须是金字塔呢?
如果说这个需求全部都是高优先级的,那么,此时此刻你去做任何的取舍,不仅团队答应不了,而且用户的感受也很不好。
但是如果说我们高优先级只有2个,中优先级只有3个,第一个条件就有5个。
那么在这种情况下,首先要求在迭代期内先做高优先级的,等快结束时,如果真的有完成不了的,我们再砍掉一些低优先级的。
对整个团队来讲,这是大家可以接受的一种模式。同时对用户来讲,伤害也是很小的。
所以,我们当时也额外做了一个要求去避免早期团队出现不成熟的举动,
我们是2018年11月中旬介入的,当时他们的用户活跃度一路走低。我们介入之后,就要求保证(第二个版本开始)两周一发布的节奏。
我们实现了连续5次的版本按时迭代,整个数据开始回升,用户活跃度开始在往上走,开始持续向好。
敏捷转型之后,我们当时为了解决支付成功率低的问题,逼迫产品经理去做调研,去研究“到底为什么学生的付费支付成功率这么低,只有30%”,逼迫他们不断进化,思考,会用数据做分析。
最终,他们得到一个结论:作为学生,虽然有钱,但是学生购买产品的时候,觉得这个钱应该由自己的父母来出。所以,当时学生自己支付的成功率很低,只有30%。
后来,根据分析,我们迅速做了一个功能叫“家长代付”,也就是说学生可以一键把支付链接通过微信或者其他方式发送给家长,家长一看这是学习型产品,对孩子的学习有帮助,支付率一下子提到71%。
而且支付占比从“原来学生100%,变成了学生支付比55%,家长的代付比占45%”。
新的支付渠道,一下子就把支付成功率的问题很好地解决掉了。
以上,我们举了一个大公司(腾讯)的敏捷转型和一个小公司(某AI企业)的敏捷转型,他们在不同的敏捷转型的时机点引入了敏捷转型,最后都取得了不错的效果。
我的分享就到这里,谢谢大家。
【微信客服】:122285053
【微信公众号】:MHJY1998
【咨询电话】:13684609885 0451-88342620
【咨询教师】:王海涛 王耀辉 郑毅
【美华官网】: www.mhjy.net