企业级敏捷转型三部曲

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

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

背景

剔除股权激励费用后，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端用户做的需求，产品经理代表用户填。业务价值效果，一般由运营同学根据业务指标来填。需求发布了，我们还要跟踪效果，分析业务数据，优化产品，形成基于业务价值的反馈闭环。

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

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

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

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