企业级敏捷转型三部曲

阅读数:1061 2019 年 10 月 21 日 14:28

企业级敏捷转型三部曲

企业级敏捷转型三部曲

本文根据宁锐和张迎辉 TiD2019 分享话题《数据驱动的企业级敏捷转型》整理,经嘉宾授权进行刊发。

很荣幸有机会跟大家交流,今天分享的内容分为四部分:

  • 背景
  • 效果
  • 方案
  • 总结和展望

背景

剔除股权激励费用后,2018 财年阿里健康首次扭亏为盈。实现这个突破,需要开辟新业务,同时老业务要提效。这些最终都会落到产品技术上。阿里健康的技术负责人给我们一个愿景,就是研发绝对不能拖业务的后腿。这是敏捷转型的大背景。具体来讲,阿里健康敏捷转型主要为了解决研发过程中出现的不透明、不准时、响应慢的问题。

不透明

有个团队,研发同学说产品经理不关心研发进展,交付了就行。实际上产品经理自己维护了一个 Excel 表格,记录需求的排期计划和当前进展。产品经理要逐个问研发,才能获得最新进展。还有一个团队,业务想了解研发进展,分头找开发负责人和产品负责人,得到两份不同结果,都不知道该信哪一个。敏捷转型后,研发进展一目了然,这些问题都解决了。

不准时

有些业务线延期的情况比较严重,不是延期几天,是延期几周甚至几个月。改进之后,业务同学反馈延期情况大有改善。

响应慢

以前大一点儿的需求基本都要一个多月才开始交付。改进后,基本一周内有交付。

效果

给大家看一下敏捷转型的效果。

我们从质量、响应力和准时性三方面来看。

2018 年 11 月才有数据,给大家看的是从 2018 年 11 月到 2019 年 2 月的数据。

质量

企业级敏捷转型三部曲

我们主要看线上问题的数量。2018 年 12 月有一条业务线做了比较大的技术改造,线上问题比较多。除此之外,线上问题很少。

响应力

我们看两个指标:周发布需求占比和平均交付时长。

企业级敏捷转型三部曲

“周发布需求占比”统计一个月内,7 个自然日内发布的需求(从开始开发到发布结束)占所有当月发布需求的比例。左侧是整体指标,右侧是各业务线指标。2018 年 10 月我们定的目标是周发布需求占比达到 40%。2018 年 11 月的基线数据是 4.5%,2019 年 1 月达到了 64.2%,2019 年 2 月进一步提升到了 68.9%,而且各业务线周发布需求占比都达到了 40% 以上。

企业级敏捷转型三部曲

“平均交付时长”统计一个月内,发布需求的平均周期时长(从开始开发到发布结束)。2018 年 11 月的基线数据是 20 天,2018 年 12 月提升到了 8 天,2019 年 1 月和 2 月也保持了这个水准。各业务线的平均交付时长有起伏,基本趋势在下降。

准时性

企业级敏捷转型三部曲

我们看需求交付累计偏差。

“需求交付累计偏差”统计一个月内,需求的实际交付日期与承诺交付日期的偏差之和。偏差为正,延期较多;偏差为负,提前较多。2018 年 11 和 12 月延期比较多,2019 年 1 月和 2 月稍有提前。这个指标越接近于零越好,说明交付既准时又靠谱。

以上是敏捷转型的效果。

方案

我们怎样做到,接下来看一下方案:

  • 透明过程,获取基线
  • 建立反馈环,自驱改进
  • 立体式辅导,赋能团队

这就是企业级敏捷转型三步曲

按时间顺序,这个方案挺容易理解:

一开始先摸一模情况,就要提升透明性。

然后,根据愿景定远期目标。远期目标一步到不了,先看下一步去哪里,就有了近期目标。研发过程透明了,随时知道现状。现状跟目标有差距,尝试改进。改进一段,看看现状:离目标近了,改进有效继续保持;离目标远了,改进无效尝试新招。这样就建立了一个基于反馈的改进环。不用敏捷教练推动,团队自己就能往前走。

过程中出现一些问题,可能是团队缺少全局视角或没有经验,敏捷教练要及时引导。还有一些具体技能,比如,怎么把大需求拆小,需要帮团队快速 get 起来。这就需要赋能团队。

透明过程,获取基线

先给大家介绍第一步“透明过程,获取基线”。

透明过程

先看“透明过程”。

企业级敏捷转型三部曲

所谓“事在人为”,要做事,先圈人。首先,识别干系人,把关键的干系人都动员起来,围绕共同的愿景和目标一起来做这件事。其次,明确角色和职责,大家分工协作,一步步推动目标实现。

有一些新角色,给大家介绍一下:

  • 产品负责人 - Product Owner

产品负责人是产品团队的领导者,负责产品的大方向和价值排序。

  • 特性负责人 - Feature Owner

如果把实现复杂特性当做一个项目,特性负责人(以下简称 FO)就是这个项目的项目经理。FO 起到穿针引线的作用,不是所有事情都自己做,而是把不同角色的工作串在一起,使得协作更顺畅,风险更可控。

企业级敏捷转型三部曲

FO 什么时候进入?基本上产品经理有了需求的概要设计,就可以跟技术团队的负责人申请 FO 支持。FO 由开发或测试自愿兼任,一般选择相对熟悉这个特性的同学。FO 会参与需求的全流程,从需求分析,到排期计划、交付上线,直至效果验证。FO 的工作像空气,平时不容易感到它的存在,缺了它却难受至极。不少同学说工作特别忙乱,却不知道从何处下手,也许就是缺了 FO 带来的清新流畅。

  • 团队教练 - Team Coach

我们是公司层面的敏捷教练,团队教练是团队层面的敏捷教练,帮助所在的团队提效。团队教练也是开发或测试自愿兼任。

大家也许会好奇,FO 和团队教练一样要干活,也不多拿钱,谁愿意做呢?有经验的工程师都知道,做一个需求,写代码只是其中一部分,沟通协调常常花掉更多时间。项目要成功,团队需要有人擅长沟通协调。做 FO 和团队教练可以很好地锻炼沟通协调能力。做得好,团队会认可,将来遇到合适的机会就有更多的发展空间。另外,我们经常给团队教练和 FO 开小灶,帮助大家发展各种软技能。因此,还有挺多同学自愿举手的。

以需求评审为分界点,之前是需求规划阶段,之后是需求交付阶段。需求规划阶段产品经理主导。需求交付阶段 FO 推进。

新角色到位,各司其职。我们看一下需求规划和需求交付过程中,大家怎么分工协作?

企业级敏捷转型三部曲

需求规划阶段,我们建议让 FO 早点儿进去。为什么呢?我们的业务挺复杂。如果开发在评审时才第一次看到需求,很难在短时间内理解这么复杂的东西。这个评审可能进行得不彻底,很多东西没聊明白,就糊里糊涂进开发,开发过程中就会有很多问题冒出来。因此,我们建议 FO 作为先遣部队早点儿进去。

那 FO 都协助产品经理做什么呢?归根结底一句话,帮助产品经理提升需求的质量。比如需求颗粒度比较大,FO 可以跟产品经理建议拆一拆。产品经理赞同的话,FO 可以组织一个用户故事地图工作坊。做完工作坊,需求按用户场景拆开了,优先级也明确了。然后按优先级逐步澄清需求,滚动进入开发。需求颗粒度合适了,需求澄清到位了,进入开发后很少出现反复,交付过程更顺畅,大家都觉得很舒服。

图中的树状视图,帮我们保留了需求之间的层次关系。有了这棵树,拆分后我们仍然知道为什么要做这些叶子需求,能跟最终的业务目标挂上钩。

企业级敏捷转型三部曲

需求通过了评审,研发同学会把它接过来。为了接得好,FO 要做不少工作。

第一个是做计划。需求评审后开工前,FO 要组织相关的开发、测试、依赖方一起制定排期计划,并请产品和业务同学确认交付日期能够满足业务需要。

有人说敏捷不需要计划,走哪儿算哪儿。今天一看交不了,就找产品经理说我们遇到困难了明天交付。明天遇到困难就后天交。这样开发是挺爽,产品和业务怎么办?可以说,只要跟别人合作,就需要计划。有了计划,大家才能更好地协同。困难在于,做软件是一个跟意外做斗争的过程,很少有需求在做的过程中没有任何意外。所以,计划不能没有,但是可以调整。

企业级敏捷转型三部曲

认为计划定了就不能调,恐怕是把计划和承诺混为一谈。其实,计划和承诺是有区别的。

不出现严重的不可抗力,一定要按承诺日期交付。图中的期望日期就是承诺日期。研发的交付日期可能会影响到产品和业务同学的工作安排,所以承诺日期一定要跟产品和业务确认。出现风险时,也要第一时间跟大家商量。

计划则是在当前情况下根据了解的信息做的一个最好猜测。情况发生了变化或者有了新的信息,计划当然要跟着调整。

为了达成承诺,在计划交付日期之外可以留几天缓冲。还有很重要的一点,不要过早承诺。需求评审通过了,说明需求聊得比较清楚了,方案也比较可行了,这时候再去承诺比较靠谱。对需求还不了解,就盲目地拍一个承诺日期,对团队和业务都不好。

另一个是推动进展。研发过程中遇到困难,团队是想办法还是找理由,结果还是挺不一样的。我们鼓励团队优先想办法,努力达成承诺。实在不能按期交付,可以先舍弃部分低优先级功能,仍然按期交付最重要的功能。对于潜在的风险,要主动识别并制定预案。自己做足功课,而不是把结果交给运气。

有了前面的铺垫,研发同学只要及时更新需求状态,干系人就可以随时了解研发进展。

获取基线

再看“获取基线”,这里主要介绍研发过程的度量。

其实度量的方法取决于目标。如果减肥的目标是变苗条,就要度量身体的维度。如果减肥的目标是变健康,就要关注体脂率。从这个角度看,度量是客观世界的反馈,帮你看看是不是走在接近目标的方向上,离目标还有多远。

企业级敏捷转型三部曲

这是我杜撰的:SMART goals,REAL data : )

  • Relevant

目标来源于想解决的问题,度量指标则取决于目标。有句话说:“度量什么,就得到什么”。其实也可以反过来,想得到什么,就度量什么。

  • Easy To collect

我们只选择那些容易获取的度量指标。最理想的情况下,研发正常做自己的工作,不需要任何额外的开销,度量指标自动就获取到了。现在研发只要更新需求的状态,就能自动获得度量指标并生成报表。

  • Accurate

我们只选择那些能说清楚的、大家有共识的指标。我们曾经想统计发布频率。可是怎样才算一次发布呢?是发布一次变更还是一个完整功能?如果一个功能涉及到多个应用,算一次发布还是多次发布呢?既然一时说不清,我们只好先舍弃这个指标。

  • Least side effects

我们希望度量如同一面镜子,给团队一个客观反馈。要做到这一点,需要一个合理的指标体系。比如前面提到的需求交付累计偏差,团队多留一点缓冲肯定都准时交付了。不过这样一来,交付时长就会增加。

企业级敏捷转型三部曲

有效的反馈一定要及时。目标可以按月定,却不能月底时才看指标。因为为时已晚,想努力也来不及了。我们做了一个工具,可以自动发日报。如果觉得日报还不够及时,可以在网页上随时看查看最新的度量数据。

我们还嵌入了一些简单的规则,比如需求进入开发时要填写排期计划。没填的话,工具会标红提醒。另外,开发中和测试中停留时长特别短,可能没及时更新状态。这种情况会提示需求时长数据不准确,时长再短也不会计入周发布需求。

企业级敏捷转型三部曲

企业级敏捷转型三部曲

企业级敏捷转型三部曲

给大家看一下日报的汇总、在研需求进展和已完成需求详情。这些都是工具生成后自动推送到邮箱的。

建立馈环

接下来给大家介绍第二步“建立反馈环,自驱改进”。

组建改进小组

这次敏捷转型涉及到 3 个事业部,覆盖 7 条业务线。这么大的范围,一定要上下结合:既要获得决策层的支持,又要得到一线团队的认可。

为了把大家团结在一起,我们组建了周发布小组。这是一个虚拟的小组,成员包括各业务线开发负责人、测试负责人、职能经理和团队教练。这个小组对公司层面的改进目标负责,帮助团队解决问题移除障碍。

周发布小组每两周碰面,回顾上一期的 action,review 近两周的研发效能指标,确定下一期的 action。Review 效能指标时,每个团队都跟两周前的自己比。有些团队进步很大,就跟大家分享经验。有些团队遇到了困难和瓶颈,大家一起帮忙分析原因想办法。令我们感动的是,阿里健康研发部负责人挤出时间参加周发布小组的会议,认真倾听团队遇到的问题,主动帮忙推动解决,给了我们极大的支持。

引入丰田改进板

企业级敏捷转型三部曲

丰田改进板与普通的改进环有一个不同,就是团队要先有一个愿景。这个愿景必须是团队非常想要的。我们一般会问团队:先不考虑眼前的困难,真正想要的理想状态是什么?想得越清楚细致越好,最好活生生的画面就在眼前。为什么要让愿景变成活生生的画面?因为这样才有动力。如果先去想有多少困难和问题,团队动能很低,容易被困在原地;如果先去想一个很美好的未来,团队动能很高,愿意去行动。美好的愿景通常一步到不了,就需要一步步分解成够得着的目标。想想下一步可以到哪里,做什么才能往前走。

这里是一个团队的丰田改进板。上面有到 2019 年 3 月底的财年目标,还有分解到每个月的月度目标。团队教练每周会更新这个板,绿色说明进展很顺利,红色说明有风险。比如最近研发过程的缺陷比较多,理想目标是研发过程零缺陷,第一步先减少会 block 测试的严重缺陷,对应的 action 就是提高提测质量,确保自测用例通过。

立体式辅导

最后,我们来看一下“立体式辅导,赋能团队”。

企业级敏捷转型三部曲

通过前面两步,团队有目标了,也知道差距在哪儿,还能能想出一些不错的改进方法。不过团队可能缺少经验,比如不知道需求该怎么拆,不知道怎么高效开会,甚至都不知道自己不知道什么。这时敏捷教练要及时辅导。团队处在不同的阶段,辅导方式也不同。

一开始找对问题很重要。2018 年 10 月,我们访谈了很多人,包括业务、产品、开发、测试,有 leader 也有一线员工。搜集的问题和建议我们反馈给研发团队。团队感到很意外,因为有些问题他们从未意识到。有团队交付了一个功能给业务小二用,研发挺开心的以为可以帮助业务提效。业务反馈说功能有了,体验真的有点坑。操作起来非常复杂,本来十分钟可以搞定,现在要一个小时。经过这件事,研发和业务的联动密切了,研发经常往业务那边跑,看看业务同学到底是怎么操作的。这时,敏捷教练相当于一个桥梁,把问题带回来,看有哪些改机的机会。可喜的是,很多研发 leader 现在会主动跑去问产品经理和业务同学,最近上线的功能好不好用,研发这边有什么需要改进的。摸清了问题,就知道劲儿往哪里使,改进目标就清晰了。

每个团队的问题不一样,目标也不一样。结合团队的目标和实际情况,我们会出一个建议方案。最终采不采纳,由团队决定。只要能达成目标,团队完全可以决定改进方案和落地节奏。

辅导团队的过程中,我们发现对于什么是敏捷以及为何要敏捷,大家还不是很清晰,就做了一个敏捷导入培训,帮大家澄清敏捷的理念和原则。到了具体的技能,我们发现培训效果不是特别好,反而是实战效果更好。比如用户故事地图,我们就拿真实需求来拆解。先是敏捷教练引导,然后教会团队教练,团队教练再教 FO,会的人越来越多了,这个实践就扎实了。

敏捷落地在神不在形,很多时候要根据具体的上下文检视和调整。我们没有把重点落在规范流程上,而是把重点落在培养人上。我们花大力气培养了团队教练和 FO,给他们开小灶,创造机会练习。比如,我先组织一个回顾会,我做你看。然后,我和团队教练共同准备下一个回顾会,团队教练来主持,你做我看。看完以后我给你反馈。下次你再做,就比之前进步了。越做越好,后来就放心让你独立做了。2019 年 3 月阿里健康举办了敏捷分享沙龙,很多团队教练从实践中悟出来独到的东西,非常接地气,引起了大家的共鸣。

敏捷教练不会永远在团队身边,发现团队越来越会自己走的时候,我们会逐步地往后退一些。以前发现问题我们会第一时间提醒团队,现在会等上几天,团队多半都会自己发现自己解决,这也意味着到了要放手的时候了。

以上是阿里健康的企业级敏捷转型三部曲。

总结和展望

我们先做一个简单的总结。

企业级敏捷转型三部曲

先看一下敏捷宜忌。

有些同学觉得做敏捷就是把需求拆小,让数据好看。其实我们不是为敏捷而敏捷,更不是为数据而敏捷。我们不断引导团队快速低成本交付价值,拿到业务结果,为价值而敏捷。

有些团队自我感觉很好,看数据的时候,才发现还有不少值得改进的地方。主观感觉有时给我们虚幻的安全感,客观数据可以把我们拉回现实。

甩锅给别人很容易,可是不解决问题。比如说需求太大,研发团队可以责备产品经理没有拆需求,也可以拉上产品经理一起拆。产品经理发现拆解过程中,需求梳理得更清晰了,下次就会主动邀请研发一起拆需求。从自己能做的做起来,做出效果,伙伴们也会受到感染一起做起来。

家里小朋友发烧了,是不是立马吃退烧药?多半不是。要查明原因,对症下药才行。我们看到团队的问题,通常也不会立马扑上去救火,而是挖掘深层次的原因,从根源上解决和预防。

企业级敏捷转型三部曲

接着,跟大家分享一下对未来的展望。

过去,我们的重点在提升效能。未来,我们的重点在助力业务。

敏捷转型从研发部发起,主要解决研发效能跟不上业务发展的痛点。当研发效能不再是瓶颈,我们要引导团队关注业务价值。从被动地接需求,到主动思考:这个需求给谁做,解决什么问题,对业务成长有什么贡献。

企业级敏捷转型三部曲

需求开工前,我们希望团队思考需求的价值。这是我们配置的一个模板,新建需求时自动引导大家去填写客户价值和业务价值。这个实践已经落地一段时间了。不少同学反馈:一开始填不出来,因为以前很少去想为什么要做这个需求,要达到怎样的效果,都是拿来需求就想怎么实现。深挖一下,最后发现是可以填出来的。这个过程中,开始从客户视角和业务视角来考虑问题。这是非常好的转变。

需求交付后,我们希望团队验证需求的效果。我们增加了两个属性:客户体验效果和业务价值效果。客户体验效果,给内部小二做的需求,由小二来填,给 C 端用户做的需求,产品经理代表用户填。业务价值效果,一般由运营同学根据业务指标来填。需求发布了,我们还要跟踪效果,分析业务数据,优化产品,形成基于业务价值的反馈闭环。

今天的分享就到这里。谢谢大家!

嘉宾介绍:
宁锐,阿里健康敏捷教练,全栈工程师。辅导阿里健康研发团队敏捷转型,支持阿里健康企业级敏捷转型。

张迎辉,敏捷教练,独立咨询师。开发和讲授阿里巴巴多门敏捷公开课,支持淘宝直播、优酷、阿里健康敏捷转型。TiD2018、RSG2018、PMI2017 项目管理大会讲者。

评论

发布