在过去的半年多时间,丁香园前端团队通过对「研发流程的规范和自动化改造」,保守估计「每个月公司前端技术团队相比于年初节省了 1/4 的工作时间」(每个月可以节省一周左右的工作时间)。
本文是在第二届缤纷·滨江前端沙龙直播分享对应的文字稿,希望直播+图文的形式可以尽可能的把「研发效能提升」过程中的思考和实践讲清楚,同时让观众/读者有真实的收获。
这似乎是一件不容易的事情。难点在哪里呢?
但是我还是想试一试,因为这样的一个过程真切的对一个 50 人规模的前端团队带来了积极正向的变化(甚至助力到了到了非前端的技术同学)。我希望「以故事的形式」能给大家带来触动,引发一些思考和共鸣。
接下来我们「以时间线为切入点」,一起来感受一下「Jarvis 提效之旅」这个故事。
在故事开始前,我们先来了解一些故事的背景,以便于有更深入一些的代入感。
为什么需要在背景中介绍一下组织架构呢?因为不同的组织架构可能会导致故事沿着不同的路径发展。
介绍主要前端项目,一方面是相对丰富的项目类型和数量提供了各种想法落地的肥沃土壤;另一方面研发效能提升是以以每个项目类型攻关的方式推进的,这些项目在某种程度上也是一个抓手。
技术团队研发效能提升是一个很大的话题,我们可以从前端工程师的日常工作着眼。首先抛出一个问题:前端工程师从「需求开始开发」到「需求成功发布」的过程中,通常需要经历几个阶段以及多少个环节?
前端工程师工作中必经的阶段是容易回答的,因为「每一个软件工程师都会经历这4个阶段:准备阶段、开发阶段、测试验收阶段、发布阶段」。在这4个阶段基础上,「如果只有1名前端工程师在支持业务需求」,那么「他会经历」如下「9个环节」。随着业务需求的增多,会出现1名工程师不足以支持所有业务需求的情况。此时,前端工程师难免需要与他人协作来一起完成业务需求的交付。涉及到多人协作,流程的复杂度就会上升,同时会需要制定一些基础的统一的协作规范,来保证协作流程是顺畅的。此时,「为了确保前端协作流程是顺畅的,每一个前端工程师的工作至少会经历如下13个环节」。丁香医生的前端团队,经历了随着业务发展团队人数逐步增多的阶段,同样我们也面临过业务快读迭代对前端团队交付能力的挑战。在面临快速交付业务需求的挑战时,我们会发现在上述多人协作过程中的13个环节中存在着一些问题。面临的问题可以细化为:
基于上述问题,我们不断完善优化前端工作流程(比如:前端工作流程中引入了 CodeReview 机制并坚持认真去做 CodeReview),同时开始逐步统一团队内部的基础规范(比如:落地小程序研发体系等)。大概在 2019 年 Q3,通过技术产品团队的紧密配合以及前端团队内部对规范、流程的不断优化,做到了可以持续顺畅的常规产品需求每周发布 1~2 次。此时,丁医前端团队内部的工作流程中至少有 27 个环节。
虽然通过 CodeReview 机制、统一基础规范、优化并标准化前端工作流程带来了交付效率的提高,但是也带来了「新的问题」,并且有一些「顽疾问题」并没有被解决。
新的问题是由于增加了基础的协作规范、技术规范,导致「工作流程中环节较多」。环节增多,意味着「人为失误」的概率提高了。
顽疾问题是流程中「某些环节的操作是繁琐的」。典型的例子是微信官方提供的小程序“分布式”构建发布能力,在多人协作中不仅操作步骤多,还容易出现构建失败等问题。再比如:前端工程师的「研发辅助工具分散」,需要不断的在代码编辑器、GitLab、Wiki、企业微信、项目管理软件等系统中切换,每一次的切换其实都在消耗前端工程师的工作时间。
这些问题是单一前端团队中可能存在的问题。2020 年公司前端团队经历了两个跨团队的前端项目,一个是疫情地图项目,另一个是丁香直播项目。由于我亲身参与了两个项目研发工作,深感不同前端团队在项目管理方式、技术规范、协作规范等方面的差异性。这些因素给跨团队协作项目带来的一定的成本。
综上,前端团队工作中主要存在如下痛点:
在了解了故事背景后,我们的提效故事正式开始。
Jarvis 是一个 B/S 架构的系统,下图是 Jarvis 的工作台页面:
我们先来看一下 Jarvis 在技术同学研发工作中所处的位置:
接着,我们看一下 Jarvis 包含了哪些功能:
最后,我们来看一下 Jarvis 大致的技术实现方案:(在此,我们只是看一下 Jarvis 技术方案的概览,未来或许会针对技术实现细节做一个分享。)
接下来我们一起看一下 Jarvis 是如何诞生及成长的。
故事要从丁香医生前端团队讲起,记得那是 2018 年的第一场雪,比以往来的更晚了一些。在 Q4 尾巴的时候,我被问到了一个问题:**我对丁香医生业务的价值是什么?**当时我的回答大概是:我做了 XXX 等具有较高复杂度的需求,我带领团队做了 XXX 的事情,跨部门做成了 XXX 事情。但是这个答案似乎没有让提问者满意,于是我陷入了持续的思考中。
从「我对业务的价值」这个问题出发,引发了「技术的价值是什么」、「技术人的价值是什么」、「接下来我做什么事情才是有价值的」、「技术与业务的边界在哪里(比如:业务创新技术要不要负责)」?等一系列思考。坦言,曾经迷茫过一段时间,想不清问题的答案。
不仅自己有困惑,此时技术团队也在面临着来自业务方一些挑战(重点关注绿色背景部分):
困惑虽在,可时间依旧在往前走。在这个过程中,尝试去做了几件事情。
虽然做了点事情,但是心中的困惑并没有完全得到答案。只能带着困惑继续前行。
在 Q3 发生了几件事情,给我以及团队带来了启发。
这些事情碰撞交织在一起,冥冥之中起了化学反应。热血青年们感觉热血沸腾,按捺不住心中的想法,个个撸起了袖子摩拳擦掌。
理想是丰满的,现实是骨感的。从 0 到一个成熟的构建系统之间,绝不是仅有热血激情就够了。我们面临的问题是如何在业务快速迭代过程中,找到一个可以撬动“地球”的支点。「想都是问题,做才有答案」。最终,我们决定先做一个小程序自动构建的命令行工具,并且将工具推广到兄弟团队使用。有了这个命令行工具 weapp-release
后,依旧需要在开发者的机器上进行构建、上传,还是存在出错空间(比如:不同在开发者去负责构建上传时开发者工具及构建环境的差异性、同一个开发者偶尔的操作失误)。兄弟团队也在面临同样的困惑。
于是不同的前端团队产出了自己的解决方案:
团队 | 方案 | 服务端 | 部署机器 |
---|---|---|---|
丁香医生 | 基于「weapp-release」的构建服务 + jQuery 操作页面 | Node.js | 内网 Mac Mini |
CHD | 基于「weapp-release」的构建服务 + React 操作页面 | Go | 内网 Windows 台式机 |
toH | 基于「weapp-release」的构建服务 + VS Code 插件 | Node.js | 内网 树莓派 |
在日常工作中,大家体会到了小程序构建服务「自动化」带来的便利后,每次构建成功后需要人主动去查看构建结果。恰好企业微信开放了企业微信机器人的通知能力,于是我们扩展了小程序构建服务,支持了构建结果自动通知给开发者。这样的尝试得到了团队成员的一致肯定,我们尝到了「自动化」带来的甜头。
随后我们发现小程序开发日常工作流程的 Code Review、发布后通知等操作同样具备「流程相对固定、操作重复性较高、人为操作容易出错」等特点,就有了把工作流程进一步「规范化」、「自动化」的想法。
当把小程序项目从开始开发到发布的工作流程「标准化」「自动化」之后,会发现 web 等其他类型项目也是可以这样做。于是我们扩展了服务,让小程序类型和 Web 类型项目均享受到便利。
「自动化会激活技术人员的创造力」。甚至让我产生了一种我们团队「想把一切工作全部自动化」的幻觉。
我们发现技术同学、业务方同学较频繁需要应用的路由说明文档、用户行为埋点说明文档,完全依靠技术同学手工维护也是有成本且易出错,于是我们把原本需要手动维护的文档也全部自动化生成了。
慢慢的,我们把最初的小程序构建服务做成了一个包含小程序自动发布、工作流自动化、文档自动化等能力的服务,同时也把客户端从一个简单的 jQuery 页面升级为了基于 AntDesign 的 Web 应用。团队伙伴受到了钢铁侠助手名字的启发,给这个服务起了一个名字叫做 Jarvis。 图片来源于网络
在这个过程中,面临过几个选择。我把它们称为故事的插曲。这些选择如今看上去没什么,不过当时做选择时还是经历了一些心路历程的。
在 Jarvis 演进的过程中,公司的前端基础平台也在开发一个名为 Dust 的系统,目标也是提升前端同学的工作效能。虽然两个系统的起点不一样(Jarvis 以小程序自动化构建为起点,Dust 以改善 Web 项目发布为起点),但是随着系统各自的的迭代,终究会有功能重叠的情况出现。
此时面临的是 Jarvis 的定位以及要不要做下去的问题。促使做出最终选择有以下 3 个方面的思考:
综合考虑后,最终的决定是:
更多关于这个选择的思考可见《Jarvis vs Dust》 。
明确了会继续做下去以及自身定位后,其实还不够。还要回答的一个问题是:接下来如何做才可以变得更好?当时我们给出的答案是:
当 Jarvis 已经在丁香医生前端团队良好落地后,我们会发现公司其他前端团队的伙伴在工作中仍然面临着一些我们已经解决过的问题,于是萌生了让 Jarvis 服务于更多前端工程师的想法。经过和前端基础平台及各业务线前端团队的深入沟通后,我们启动了 Jarvis 共建计划,旨在让更多的前端工程师工作更加顺畅、愉悦感更多一些,从而提升公司前端团队的研发效能。
共建两个字说起来容易,真正实施起来还是具有一定的挑战的。在共建想法诞生之初,我们进行了一定的心理建设,确定了如下共建原则:
接着,就是需要将想法付诸实际行动了。起步阶段,我们主要做了如下几件事:
为了共建工作可以有序的开展,我们制定了如下的共建计划。计划中明确了目标、如何做以及各个子阶段的关键结果。
关于 Jarvis 的项目管理,我们采用了基于 GitLab Issue 管理工具的看板机制。这个做法使得项目的进展情况一目了然,相关 Issue 的讨论会即时记录下来以便于后续的回溯。基于 GitLab 做项目管理的另一个好处是,我们可以将 Git 仓库相关信息(版本信息等)方便的在 Jarvis 中进行呈现,可以让用户了解到系统最近的变化:
经过 Q2 的持续沟通与付出,成功的将各个前端团队全部的/活跃的项目接入 Jarvis,Jarvis 在公司前端团队全面落地。
我们可以看一下 2020.07 的 Jarvis 使用数据:
事项 | 总次数 | 日均次数 |
---|---|---|
发布 | 3207 | 107 |
通知 | 6128 | 204 |
服务不可用 | 0 | 0 |
发布节省时间(以1min计算) | 3207*1/60=53.45h=2.2天 | 1.4h |
通知节省时间(以2min计算) | 6128*2/60=204h=8.5天 | 6.8h |
这些数据正是前文提到的「保守估计「每个月公司前端技术团队相比于年初节省了 1/4 的工作时间」」这个结论的基础。
当时间到了 2020 Q3,我们的重心确定为让 Jarvis 变得更稳定、更易用,此外我们开始希望可以让 Jarvis 能够帮助更多的技术同学。于是我们做成了如下这些事情:
在 Jarvis 落地的过程中遇到了一些困难和挑战,在此不一一赘述,毕竟凡是过往皆为序章。
接下来是基于 Jarvis 成长过程的复盘,内容可能会有些抽象。如果疑惑或者认为不正确的地方,欢迎交流。
我们先来看一下 Jarvis 的发展过程,来系统性的看一下事情的全貌:
听了这样一个故事,当面对其他技术团队需要提升研发效能的场景时,我们可以如何思考呢?
针对前端(软件研发工程师)工作中存在的痛点,可以将其大致归类为4个方面的问题:研发效率、交付质量、交付过程、团队协作。我们可以选择「分而治之」的思路,针对每一类的问题明确解决思路:
我们可以进一步将解决思路抽象为几个关键词:
「标准化、自动化、统一化」对于技术人来说,比较好理解。以人为本想传递的是:前端团队对每一位前端工程师工作体验的重视。我们终究要做到视人为人,让每一个软件研发人员尽可能的全情投入、愉悦舒心的去工作。
前文提到的问题:
你的答案会是什么呢?
以有限的阅历,目前我给出的答案是:
如果仅仅说「技术的价值在于持续交付」,太过于抽象了。实际上,持续交付这件事情是可以分层来看待的。我会把它分成渐进的 4 层来看:
不同层级的价值的关注点不一样,对技术人的能力要求也不一样。在一定程度上可以对标到目前市面上不同公司职级体系中的职级级别。
文字洋洋洒洒写到这里,终于到了故事的起源:研发效能。如果不知道研发效能意味着什么、该如何定义研发效能,那么最好还是不要急着去提升它。
如果纯粹的去看研发效能这四个字,会相对的空洞。目前我倾向于将研发效能定义为「技术产品团队持续顺畅优质高效交付有效价值」的能力。这个定义中有四个关键的点,分别是:「聚焦于交付质量的「优质」、聚焦于交付效率的「高效」、聚焦于交付过程的「持续顺畅」以及聚焦于业务需求价值的「有效价值」」。从图中可以看出,Jarvis 立足于交付质量、交付效率和交付过程,在提升技术团队研发效能的路上努力前行。
当我们去做一件事情时,通常会希望去度量事情的结果。研发效能这种相对抽象的概念,虽然没有办法做到精准衡量,但是还是可以通过一些数据指标来侧面印证。
以下衡量指标目前还没有在 Jarvis 中全部得到实践,在此列出来仅供参考。
在不同的场合下,都需要去回答「Jarvis 的价值」这个问题。坦言,感觉这个问题不好回答。因为千人千面,每个人对 Jarvis 的理解和使用程度不一致、对研发工作中痛点的感触不一致、对技术价值的追求度不一致、所处职位(公司价值体系的落脚点)不一致,借此文字梳理的机会,进行一个正面的回答。
首先,对于公司的价值
其次,对于前端团队的价值
最后,对于个人的价值
虽然可以从三个维度来阐述 Jarvis 的价值,但是现实中也收到了类似这样的反馈:
收到这些反馈时,有时候是做不到心如止水的。不过没有变过的是,我们最终依旧选择让 Jarvis 继续成长下去。希望可以让初心走的更远些,希望 Jarvis 可以帮助更多的技术人员工作更顺畅更舒适。
Jarvis 当下是具有一定的局限性的。未来还有很长的路可以走。
首先是系统功能本身的局限性。第一,Jarvis 尚未支持 Java 项目的提效,而在实际业务的技术项目中 Java 项目占比较高。第二,Jarvis 尚未支持前后端项目整体的联动提效(比如:与运维、DBA 的各个系统打通)。这些事情目前在推进,但是遇到了一些新的困难。
上面提到的困难,在某种程度上来说是好解决的。Jarvis 真正的局限性在于,研发效能终究是在说一个团队的做事效率。一个团队中可以有各种各样的规则来确保大家行为一致,但是这其中最大的变量是团队中的人。工具和系统再好用,也抵不过人为的效率瓶颈。并且即使工具和系统在一个团队进行了统一,但是使用者在使用时并不理解、在意其带来的价值,这也会使研发效能打折扣。让一个软件工程师全情投入的去工作,仅仅通过工具是不够的,还需要整个技术团队的文化建设和团队氛围建设。那么,技术团队的文化好氛围佳就可以了吗?其实也不是,最好是再辅以业务上的持续创新和成功,给到软件工程师持续的业务输入和业务反馈。如此这些要求,对一个组织来讲是一个较高的标准了。即使困难,技术人还是可以考虑朝着这个方向去探索去破局,想尽办法去成就业务成就自己。
研发效能提升、技术同学成长是永恒的话题,需要技术人持续去探索和实践。技术人要助力业务成功,这是宿命;技术人要为自身技术成长负责,这也是宿命。希望通过 Jarvis 的故事可以:
由于笔者阅历有限,以上关于研发效能的思考与实践,仅抛砖引玉,欢迎多交流。
最后,向《研发效能提升和敏捷实施 36 计》这门课程及讲师致敬,深深感谢为 Jarvis 成长贡献力量的伙伴们。