微信支付团队精益研发实践总结

标签: dev | 发表时间:2021-12-10 00:00 | 作者:
出处:http://itindex.net/relian



作者:宿海成

微信支付爆发式增长下潜藏怎样的效能「危机」?研效提升过程中,微信支付的策略及措施?人与工具如何有机结合,实现“稳又快”的精益研发?揭秘微信支付的精益研发破局之道。

一、背景介绍

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

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

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

1.2 精益研发的核心

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

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

1.3 精益实践成果

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

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


二、精益研发体系的概览

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

2.1 精益实践的框架

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

其中包含了五个步骤:

  • 定义价值:迭代对齐需求价值
  • 借助 TAPD 价值流看板,透明价值流动过程
  • 拆解任务,小批次拉动生产
  • 利用敏捷任务看板、TAPD 机器人,聚焦交付,及时暴露问题规避风险
  • 复盘结合指标引领持续改善

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

2.2 精益的实现方式

a. 效能指标体系

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

b. 复盘改善文化

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

c. 可视化管理系统

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

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


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

3.1 基本概念简介

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

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

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

  • Project Owner(PO):负责提任何有价值的需求
  • FeatureTeam Leader(FTL):交付需求,任务分解&分配的负责人
  • Developer/Engineer(DE):最不应该被打断的核心生产力

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

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

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

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

3.3 敏捷看板同步进展

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、总结与心得分享

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

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

最后,希望能和大家一起在实践中成长,协同共建高效能的精益团队,共同促进研效升级!

近期好文:

梳理正则表达式发展史

程序员妈妈的“work-life balance”,直面想象中的困难

浅谈 K8s 网络模型CNI协议


腾讯程序员视频号最新视频

相关 [微信 团队 研发] 推荐:

微信支付团队精益研发实践总结

- - IT瘾-dev
微信支付爆发式增长下潜藏怎样的效能「危机」. 研效提升过程中,微信支付的策略及措施. 人与工具如何有机结合,实现“稳又快”的精益研发. 揭秘微信支付的精益研发破局之道. 1.1 微信支付爆发式增长下的效能问题及解决思路. 微信支付有着持续保持金融级高可用和业务高速发展双重要求. 随着业务复杂性的提高和技术债务的不断增加,质量和速度在发展上的矛盾被不断激化,解决“效能问题”,提升系统应对不确定性的能力成了微信支付研发团队的燃眉之急.

【ifanRank】2011 年度最佳团队:微信团队

- 【虎.无名】 - 爱范儿 · Beats of Bits
2011 年,移动互联网的风行涌现出了如 Color 般疯狂的点子,也有像 Flipboard 那样细心耕耘的产品. 当好主意付诸于现实,市场会做出最冷静的判断. 但是它也仅仅只是公众视野中的表象. 一个新产品的成功,不能脱离眼界宽广、长袖善舞的核心团队. 2011年,我们关注了不少出色的团队,Google+ 团队颠覆了人们对 Google “社交无能”的认知,并用精巧地整合了大量自有产品;小米团队用它的市场触觉及侵略性,搅动了国内移动市场;唐茶在电子阅读市场精益求精,走出了内容发布的新模式;知乎用做媒体及点对点的邀请的方式运营精品社区,实现真实沟通的价值;Square 用完美的软硬件设计,用小额支付的切入点实现技术与商业的结合.

研发团队的绩效考核(一)

- - ITeye博客
我和大家分享的内容主要包括以下三个方面:. ① 研发团队的绩效考核的方式. ② 研发团队绩效考核KPI如何评估. ③ 如何让绩效考核发挥作用. ① 研发团队的绩效考核的方式. 很多人觉得研发团队的绩效考核很头痛,甚至不想做绩效考核,其实研发团队绩效考核我认为是需要的,因为绩效考核实际是一个“指挥棒”,它会引导研发团队朝着企业认为最佳价值的方向,通过团队/个人自己的努力达到,而不是管理者通过“管理”的方式获得,这样的效果会更好.

研发团队的绩效考核(二)

- - ITeye博客
我和大家分享的内容主要包括以下三个方面:. ① 研发团队的绩效考核的方式. ② 研发团队绩效考核KPI如何评估. ③ 如何让绩效考核发挥作用. ② 研发团队绩效考核KPI如何评估. 团队部分KPI指标的评估方式:. 每次迭代的交付物是否可以被接受:以需求提出者对本次开发迭代交付物的评价为标准,分为“接受”和“拒绝”两种.

从Rails聊聊小公司的研发团队建设

- corleone1969 - robbin的自言自语
JavaEye的PV到了140万了,一年前才100万出头,增长算不错的. 仍然是单台Web服务器,Rails处理动态请求超过340万,除了真实用户访问,还有API,RSS以及很多爬虫的请求. 看JE的alexa排名,CN排92名,全球790名,不过就2台服务器(1个web+1个DB),2个程序员而已.

Google Search By Image 中国团队完成一半以上研发

- Doublel - 谷奥——探寻谷歌的奥秘
当你郊游时,突然发现一种不知名的小花,很想仔细了解它的名称、种类和特性. “五个花瓣”、“半尺高 绿叶白花”. 这些文字肯定不能帮你准确描述出详细特征,你也不大可能凭借这些只言片语在搜索框中得到准确的答案. 确实,目前用户在使用图像搜索时经常碰到的问题是经常看到一张图片,比如一个景点或不知名的事物,想要知道它的详细信息或要找到其他尺寸图片时,文字并不能完全准确表达用户的需求.

[原]国内研发团队普遍常见问题

- - 阿朱=行业趋势+开发管理+架构
以下是国内研发团队普遍常见问题,大家说说各个岗位怎么提高质量和效率吧. 1、业务没啥清晰的战略核心主干与目标,业务需求不会解构洞察,客户提什么就做什么,业务需求和软件功能要求混在一起. 2、不会建立业务模型和产品模型,客户提什么就做什么. 3、不会理性需求排级,不做数据度量论证/也没有数据可度量/也不知道度量哪些合理数据,客户谁权力大谁态度恶劣谁叫的声大,就先满足谁的需求.

如何提高一个研发团队的“代码速度”?

- - 博客园_知识库
  阿里妹导读:Code Velocity(代码速度),体现了一个研发团队快速响应业务需求的能力. 如果做得好,代码从 commit 到上线可能平均只需要两三天时间,甚至连紧急发布都不怎么需要了.   今天,蚂蚁金服国际事业群技术风险部研究员南门,将和大家聊聊 Code Velocity,希望能在团队效率问题方面,为你带来一些启发.

[原]敏捷开发团队管理系列之七:大型研发管理团队的切分(二)

- - 陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》
这是敏捷开发团队管理系列的第八篇( 团队管理栏目目录). 还是敏捷开发一千零一问的第二十八篇( 在这里提问, 之一, 之二, 之三, 问题总目录). 还是敏捷开发松结对编程系列的第十三篇( 松结对编程栏目目录),与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系.