首页  ·  知识 ·  研发管理
微信支付团队精益研发实践总结
宿海成  腾讯技术工程  产品研发  编辑:沉吟至今   图片来源:网络
微信支付爆发式增长下潜藏怎样的效能「危机」?研效提升过程中,微信支付的策略及措施?人与工具如何有机结合,实现“稳又快”的精益研发?揭秘微信支付的精益研发破局之道。

一、背景介绍

1.1 微信支付爆发式增长下的效能问题及解决思路

微信支付有着持续保持金融级高可用和业务高速发展双重要求。随着业务复杂性的提高和技术债务的不断增加,质量和速度在发展上的矛盾被不断激化,解决“效能问题”,提升系统应对不确定性的能力成了微信支付研发团队的燃眉之急。

为了从根本上改善研发效能,微信支付研发团队参考了来自丰田公司的精益思想,经历一年的本地化实践, 形成了集文化、工程、管理模式有机结合的精益研发。本文将介绍其中的核心思路和实践经验。

image.png

1.2 精益研发的核心

想要解决效能问题的第一步是要达成精益研发的共识。精益是以价值为中心,围绕着价值不断地做交付。在交付的过程中,要持续做出改善,同时也要精简流程去除不增值的浪费,保持流动顺畅。价值、改善和流动形成了一个闭环,这也是精益研发的核心。

精益研发有几个关键词:一是低成本、高质量,这区别于敏捷,敏捷有时是冒着巨大的风险交付,但精益首先是要确保高质量;二是共识,最大化的共识能简化信息传达过程、减少错误的发生,很多棘手的问题只有在有共识的前提下才可以得到解决;三是透明,透明化一切进展、流程和所碰到的问题;四是改善,要在过程中持续改善。精益研发是一套管理哲学,同时也是包含着很多指导工作的方法工具箱,可以帮助解决很多工作中的具体问题。

image.png

1.3 精益实践成果

在达成精益的共识之后,还需要尽快尽早低成本地明确问题。通过调研调查,我们把存在问题分成了两类,一类是研发流程、方法以及能力方面,另一类是工具的使用上。微信支付团队有很多使用统一工具的良好习惯和要求,因此能很快地达成共识。

围绕着问题,团队进行了一系列的推广和实践。一年来,已有 14 个中心、80+个团队升级为精益研发模式,显著提升了价值交付能力。在指标成效的背后,对于团队来说,精益研发实践的最大收获是所有的团队是以价值最大化的共识开展工作的,同时每个团队在此过程中形成了小问题自我闭环修复解决的习惯。

image.png

二、精益研发体系的概览

在介绍具体的实践和方法之前,首先通过精益研发体系的框架、度量、改善、可视化管理和原则来了解下什么是精益研发体系。

2.1 精益实践的框架

我们借助包括 TAPD 在内的一系列工具,围绕精益的闭环,搭建了精益实践的框架。

其中包含了五个步骤:

  • 定义价值:迭代对齐需求价值

  • 借助 TAPD 价值流看板,透明价值流动过程

  • 拆解任务,小批次拉动生产

  • 利用敏捷任务看板、TAPD 机器人,聚焦交付,及时暴露问题规避风险

  • 复盘结合指标引领持续改善

使用可靠的系统,低成本、无缝地让价值流转起来,帮助团队解决问题,这也是精益的精髓之一。

image.png

2.2 精益的实现方式

a. 效能指标体系

同时,为了去度量改善的效果,搭建了相应的指标体系。指标主要分为价值指标和过程指标。价值指标主要是衡量每个迭代和交付的产出、时效性、成功率等;过程指标则更关注过程中可能会产生的点状问题。每个人对度量的理解不同,对微信支付团队而言,度量更多是改善自身的目的。

image.png

b. 复盘改善文化

改善对每个管理者提出了要求:要走到一线去,不能只是用眼睛去看。通过观察现场和与现场人员进行沟通,第一时间掌握第一手信息,同时在过程中,保持一些增值的,及时去掉不增值的浪费、消除问题。改善不仅是一个步骤,也是一个团队文化,是促进团队持续变好的驱动力。

c. 可视化管理系统

我们还打造了可视化管理的系统,把所有想要呈现的指标都放在其中,包括团队的 OKR、故障情况、剩余的额度、DevOps 的整个过程等。借助 TAPD,我们搭建了团队的项目管理页面,利用 TAPD 提供的数据,及时透明地展示项目的进展和情况。每个成员都能在项目管理界面上进行评论和建议,因此很多过程中的问题都能及时的发现、尽早的改善。

image.png

微信支付团队需求和流程的统一管理都是在 TAPD 上实现的。精益研发离不开看板,通过价值流看板和敏捷看板能显著提升迭代效能。接下来将着重介绍如何借助 TAPD 的价值流看板、敏捷看板、自动化助手实现研发效能的提升。

三、如何借助 TAPD 实现精益研发

3.1 基本概念简介

首先,先了解一些精益研发中的基础概念。

精益 Feature Team(FT):有完整的单元级别交付能力,负责降低系统整体结构复杂性的团队。

在 FT 中会有以下三类角色:

  • Project Owner(PO):负责提任何有价值的需求

  • FeatureTeam Leader(FTL):交付需求,任务分解&分配的负责人

  • Developer/Engineer(DE):最不应该被打断的核心生产力

管理者(组长、总监、经理):管理资源、促进改善;迭代:基于价值场景的长期项目或专项;价值流图:交付价值过程中的关系分析梳理和消耗观测,具体的用法将在下文提及。

3.2 价值流看板透明化价值流动进程

价值流看板的有效利用可以减少产品与开发之间的沟通成本,避免过多的企微消息轰炸和消息遗漏,透明价值流动的过程,提高各成员工作的效率。价值流看板上最左边的是想做的,最右边的是已经做完了的。达成双向共识后,FTL 将需求从“规划中“拖入“已排期”。TAPD 的自动化助手可以设置状态的自动流转。验收通过后,PO 手动将需求拖入“已发布/完成”中。

从管理的角度看,价值流看板可以有效观察价值流动过程中的需求是否是最高优先级、是否有价值,同时还能检验安排的工作是否均衡、是否符合最大价值产出的原则。

image.png

3.3 敏捷看板同步进展

从看板模式中切换到“任务”就是 TAPD 敏捷看板,是一种适用于 scrum 敏捷模式的任务列表。开发同学可以通过筛选任务,明晰每日的目标。同时,任务列表联动了需求,完成任务会自动流转需求的状态。

敏捷看板适用于 FTL 和 DE 交付团队内部的事务管理,用于同步进展,记录各种任务,观察 WIP 任务是否均衡。要遵循拆解任务到小于 3 天、先建任务再干活的原则。

image.png

3.4 借助自动化提效并降低人因错误

纯靠人力推动很难实现标准化的目的,TAPD 机器人能有效提升基本动作矫正的效率。机器人会在群内通知迭代的开始、任务、结束。可以有效减少人力成本,形成消息的闭环。当有任务停留超过 3 天时(微信支付团队迭代中的任务颗粒度均要求不超过三天),机器人也会自动提醒相关团队,知会风险。

image.png

微信支付团队有比较特色的机器人归档能力,需求量很庞大,超过两年的需求会自动归档,利用脚本自动关闭一些过期的迭代和需求。同时机器人还能帮助互动沟通,例如有用户提了 ISSUE 时的自动提醒,能让沟通更好地形成闭环。

四、多团队复杂场景下的精益研发实践案例

接下来,将分享微信支付在精益研发过程中遇到的一些典型问题及解决思路。根据精益研发的要求,管理和测试的工作是需要团队内部解决的。因此,下面的三个典型案例是在没有项目管理和测试同学的情况下的实践。

4.1 需求如何进行拆解和沟通

需求拆解是百分之百每一个团队都会遇到的问题。很多产品经理提出的需求可能需要花费两个月以上的时间去完成。但在精益的要求下,大的需求需要拆解成小的、能被验证的、有价值的需求。

image.png

在十年前,一句话需求在产品界还是很常见的,出现好的 idea 就急着去验证,往往还没有想好该怎么去做。但在现在精益研发的背景下,一句话需求是有很大风险的,需求提的不明确,接需求的人将不知道如何去做。

因此,PO 要把需求提清楚,需求应是简明的,需求的价值要是明确的。FTL 要把需求理解清楚,评估好成本,主动寻求协作资源。协同交付是当今精益背景下提倡的交付姿势。同时,PO 和 FTL 在投入之前需要达成价值共识,明确核心问题,再进行合理投入。另外,当有多个 PO 同时提需求时,要将需求按价值排序。

4.2 需求的价值如何达成共识

从精益的价值流图中可以看出,在多 FT 协作的场景中,需求的价值会被拆解,FT1、FT2 和 FT3 分别交付一部分的需求,同时 FT3 的需求被上游 FT 拆成为了一个实现型需求(例如接口 API),FT3 并不清楚整体的需求,实现上没有什么参考的场景,交付的目标和要求也不明确,不容易达成共识。这就是所谓的散装价值。

image.png

所以为了改善,团队改进成了专项视图。协作的各成员对需求都有一个明确的统一的价值共识,同时每个 FT 在过程中都能透明化自己的进展,促进更好地协作。专项模式的具体操作流程涉及到两次共识过程的对齐:第一次,PO 和 FT 之间需要对齐需求;第二次,FT 之间需要对齐任务和依赖。

image.png

采取专项模式后,我们也收到了一些反馈:大部分团队成员认为积极性被调动了,战斗力变强了,管理投入也变少了。

4.3 面对不确定风险时如何进行交付

从价值流图中模拟的场景如下:需求的价值由 FT1 一个团队来交付,但是 FT1 依赖的团队是很多的,包含 FT2、3、4......FT1 关联了很多的上游 FT 团队,每个依赖都会造成很多不确定的因素,虽然需求都已经对齐,但是真正落地执行时会遇到和预期不符的各种问题,这应该如何解决呢?

image.png

解决的方案是要对依赖进行管理。首先,将依赖进行分类,划分不确定的依赖团队和确定的。优先做确定的、能兑现价值的。不确定的依赖要尽早摸清,并把它转化为确定的。

单个迭代里需要尽量减少彼此的依赖。而强依赖的 FT 之间很重要的一点是需要对齐交付的时间线,甘特图是很好的对齐时间线的工具。TAPD 里的甘特图有两个入口:一是在导航栏的甘特图按钮,二是每个迭代里可以打开“甘特图视角”。通过对齐时间线,把不确定的尽早变成确定的,从而降低依赖的风险。

image.png

五、总结与心得分享

在精益研发实践的过程中,总结了一些交付的原则:质量,价值,共识,务实,均衡,透明等。这些原则就微信支付团队而言,质量是第一位的,交付要尽量保证零缺陷。同时,要用“每一次迭代都是在馈赠礼物”的心态去交付,更好地体现价值。共识则是二次双向共识,分配任务后要确保需求明确可达。改善是核心,要持续学习、反思和改善。

同时,在过程中还积累了一些心得体悟:要始终专注于价值和基本原则;多与团队成员沟通以达成共识和发现问题;保持稳定而持续的输出;让时间具有弹性和韧性;最后是要做好自己。

image.png


本文作者:宿海成 来源:腾讯技术工程
CIO之家 www.ciozj.com 微信公众号:imciow
    >>频道首页  >>网站首页   纠错  >>投诉
版权声明:CIO之家尊重行业规范,每篇文章都注明有明确的作者和来源;CIO之家的原创文章,请转载时务必注明文章作者和来源;
延伸阅读