阿里健康如何实现B2B团队敏捷转型的回顾

一、背景

2017年10月，应阿里健康研发部负责人邀请，我开始帮助阿里健康的研发团队敏捷转型。本文将介绍阿里的 敏捷管理案例 。

医药B2B是第一个吃螃蟹的试点团队。没想到，这个试点一点儿也不轻松：每次上线都出问题，好不容易BD来的客户都流失了，业务团队急得冒火；研发团队已经996超过两个月，辛苦又焦虑，竟然全都病倒了。

这是一个5月才上线的新业务，如果不能抓住机会证明自己，未来发展岌岌可危。幸运的是，我们挺过来了。经过3个月的持续改进，不仅质量、响应力和发布能力有了显著提升，业务也找到了突破口。

看到团队不断进步，如同医生看到病人渐渐痊愈，我由衷地高兴。不禁想到，敏捷教练辅导团队跟医生帮助病人康复有不少相似之处：

1. 二者都需要“望闻问切”，系统全面分析问题，才能做出正确判断。

2. 疗效如何要看病情是否缓解，要尽快建立反馈环，获得客观全面的反馈。

3. 有哪些治疗方案，各方案的好处弊端都要一五一十告诉病人，由病人选择治疗方案。病人做好准备再开始治疗，不可欺骗病人，更不可威逼利诱。

4. 治疗过程并非坦途，病人中途胆怯退缩在所难免。唯有热情鼓励和耐心引导，不可遇难而退。

5. 授人以鱼不如授人以渔，教会病人强身健体的方法，病人可以自助甚至助人，才是上佳结果。

让我们一起来看看，如何帮助敏捷团队摆脱困境，走出低谷。

注：本文根据TiD2018和RSG2018分享内容整理

二、问题和解法

10月我进团队调研时，发现问题真不少：

感谢团队信任我这个三脚猫大夫，大家一起摸索试错，终于找到了解药：

我为大家一一详述。

1. 建立稳定的特性团队

刚进团队时，我竟然找不到一个熟悉业务的开发同学。原来，职能经理每个月按需求分配资源，大家临时搭伙做项目。

B2B特别艰苦，开发同学坚持了一个月就要求换业务。业务同学最大的愿望就是研发同学稳定，不然总要给新来的开发讲业务，刚讲明白就换人了。

我跟职能经理一个个聊，终于各端开发和测试经理都答应未来三个月内现有研发同学至少50%的时间做B2B业务。

50%是个神奇的数字，如果一件事占到了50%以上的时间，就不能不重视它的结果并为之努力。研发同学开始关注业务指标了。

2. 目标对齐，过程透明

非常感谢B2B业务负责人的支持，特意出差过来给大家讲业务目标和业务打法。药品流通环节最多有7层，通过B2B平台，可以减少到3层。研发同学第一次感受到自己的工作跟千万人的生活息息相关。

一个区域内药品批发的龙头企业（大B）只有几家，做砸了一家，这个区域就很难开展业务了。零售终端（小B）非常分散，都是业务小二一家家跑下来的。

听到业务同学三伏天骑着电瓶车拜访客户中暑摔倒了，大家都有些动容。很快，研发团队立下了军令状：上线质量要好，交付速度要快。大家终于拧成了一股绳。

立了军令状还不够，做得怎么样，还要看反馈。工作项进云效（注：阿里一站式研发协同平台，阿里内部叫Aone），大家随时都能看到研发进展和度量数据。真正做到目标对齐，过程透明。

3. 打开范围锁，严把质量关

发布质量差导致线上问题多，修复线上问题打断了新功能开发。业务和研发团队之间还没有建立起信任，大家更像是合同博弈，上线时间和范围早早就锁定了。

没有持续集成和自动化测试，全靠手工测试回归，测试时间又一再被压缩，发布质量可想而知。本来可以白天发布，对质量没信心，推迟到半夜没有交易了才敢发布。发了改，改了再发，折腾到后半夜几乎成了发布日的惯例。

要打破这个恶性循环，先从打开范围锁入手。我跟业务团队商量，有严格截止日期的需求保证按时发布，其它功能符合发布标准才发布，不能让客户承担质量风险。业务团队答应试一个月。

我跟测试同学对线上问题做了回归分析，有针对性地增加了回归测试用例。发布前一天做上线评审，不符合发布标准的一律打回。符合发布标准的上线前都要有预案，代码回滚、数据订正都在预发环境演练过，避免出现问题时手忙脚乱。

试了一段时间，效果很明显。原本每次上线都出问题，11月发布成功率提高到了50%，12月更是17次发布100%成功。随着发布信心的提升，发布时间也改到了白天，发布日再也不用熬夜加班啦。

4. 协作澄清需求

正如质量不只是测试的事，需求也不只是产品经理的事。

做产品如同寻宝，产品经理好比向导，知道宝贝在哪里；技术同学好比驾驶员，最了解车子的性能。大家一起想办法，才能快速又经济地找到宝贝。

有些技术同学一心只想写代码，殊不知代码是客观世界的映照，符合业务模型才易于维护和拓展。更何况很多隐性的业务知识无法用语言传递，谈需求时好像都共识了，验收时才发现想的根本是两回事。

既然是一个团队，当然要协作。需求是源头，协作就从需求共创开始。业务和产品大致梳理出需求概要，就拉上技术同学一起梳理。全体都参与需求梳理不现实，业务、产品加上一位开发和测试组成跨职能的需求小组。先弄明白需求给谁做，解决什么问题，大家再一起寻找解决方案。

讨论过程中，大家不自觉就突破了角色的限制，研发开始关注业务价值，业务开始关注技术可行性。

好玩的是，B2B团队由开发同学讲解需求，产品经理补充答疑。团队先后做了两个营销玩法的需求。第一个需求，评审时技术同学才参与，上线半个月了还有各种问题。第二个需求，用共创方式，上线后立即就能做活动，活动效果也特别好。

工欲善其事，必先利其器。用户故事地图和实例化需求双剑合璧，是协作梳理需求的利器。

用户故事地图最大的好处是一张图看到全貌。此外，从用户角色和用户目的出发，逼得我们想清楚需求的价值。想明白了价值，再逐个场景梳理用户旅程，走完一个旅程就能帮用户解决一个场景的问题。

实例化需求最适合厘清复杂的业务规则。如图所示，PRD上两句话，深究下去，竟然要用8个例子才能说明白。看起来需求梳理花了一些时间，实际上开发过程会省时间。拿到需求就开始写代码，并不一定最快。有一个H5页面反复改了6次，两周才做完。如果想明白再做，最多半天就搞定了。

如果按照从简单到复杂，从主流程到异常场景的顺序梳理用户故事地图，很容易确定发布优先级。如同地铁可以分段通车，一个用户旅程的功能也可以分段交付，只要交付的功能对用户有价值就行。

图中的营销活动需求，就分了好几段交付：先上线给运营同学用的后台功能，可以创建活动、配置活动和展示活动，运营同学可以预热招商了；接下来支持正向和逆向交易的价格调整，用户下单可以享受折扣了；为了控制活动预算，活动中要实时展示预算消耗；最后，支持每月一次跟商家对账。对账是离线统计，只要在活动开始后第一个对账日之前上线就行。