摘要

本文为网易有道企业发展高级效能项目经理张浩然《研发效能实践助力互联网行业项目管理“行之有效”》的演讲内容,围绕研发效能的实践和项目管理两个主题展开。

我写分享PPT的时候,起初想的是针对于互联网行业的项目管理。但现在不止是互联网,传统行业也在做数字化转型。所以,这个项目管理是全行业都可以一起探讨的。我之前做研发,后面主要做项目管理,过程中做过一段时间的产品管理。目前主要在网易有道企业发展部,做整个研发效能的推广和项目管理的提升。

我将从四个部分来阐述下自身的分享主题。

1.互联网项目管理面临的常见挑战

目前我们处于一个乌卡时代,不光是互联网,传统行业也处于这个时代。任何一个时代到来,都不会抛弃任何一个人,这个时代有哪些特殊性?——易变,不确定性,复杂性和模糊性。

所谓易变,就是每次迭代开发要快,因为市场变化很快,我们其实也不确定产品的下一步方向在哪,用户有哪些新的诉求;

而复杂性是说现在产品的形态、架构很多,不能像以前一样用一套标准的解决方案满足各个客户的需求。因为客户也学聪明了,我们需要去应对一些更复杂且不明确的诉求。模糊性更好理解,一些大厂如阿里是电商出身,百度是搜索引擎,但是越往后,每一块垂直领域市场趋于饱和,大家在各自的边界越来越模糊。所以,我们要不断地让我们的MVP产品快速推出,在乌卡时代取得先机。
图片
项目管理,能在这个时代帮助企业降本增效,快速验证。但是我们在管理整个软件研发团队时,多少会遇到一些问题或困扰。比如现在有一个想法需要做,我们组建了一个团队,快速地做研发迭代。为了赶进度,大家还要加班。很辛苦,但真正交付产品的时候,还是会出现延期交付。

在研发过程中,为了赶进度多少会产生一些质量问题。在整个过程中,为了弥补延期和质量差的问题,会去抓人效,抓的过程中又容易引起团队里的一些反驳,导致士气低落,如果在上线以后,我们的产品再不被市场接受,整个团队久而久之士气更加低落。

有人说我是一个经验很丰富的项目管理或者产品经理,或者技术领导,我在整个排期或者任务分配的过程中都没有问题。那我们如果有跨团队协作,比如说网易有一个A团队,很重视测试环节,在测试环节分为好几轮,并且用网易易测平台去扫描检查代码。另外一个B团队,业务形态没有那么复杂,只是简单地走完测试流程就OK了,过程中没有很多自动化工具,可能还在用XMIND等思维导图写用例,线下做管理。但如果B团队的伙伴去支援A团队的项目,对于A团队的工具、流程都不熟悉,怎么能够快速让B团队融入A团队,快速产出,这都会成为阻碍团队高效产出的问题障碍。
图片
常见的挑战
我们现在的挑战是会遇到交付过程慢的问题。因为我们的产品线越多,需要交付的产品就越多。在不同的过程中,针对于某一个产品有一些新的需求,需求过来以后就会建立很多版本分支。这个过程中,比如我正在开发A版本的过程插入了新需求,要新开B版本,从A切到B的时候其实是对开发有影响的。同时,比如项目前期,大家都在做一些调研,然后再开发,这个阶段测试人员在等待开发完成才能进入测试,等待时间过于长,导致整个交付比较慢。质量差也是一个问题,研发之前没有测试的意识,只写好自己的代码就提交了,可能有些为了赶进度都不自测。排期不合理,大家有可能经常会遇到这种问题。排期就是把研发的时间排出来,把剩下的时间压缩为测试时间,测试很大的一部分功能模块也就几天,三四天,小功能的话半天就得赶紧测完要上线,所以为了去赶进度,牺牲了质量。

协作难这个问题,有多个团队缺少标准的流程工具。在整个过程中一是出现人员的协作、项目切换难;二是遇到一些问题的话,可能会出现扯皮;最后,就是少度量。如果没有度量的话肯定是不行的,项目经理包括管理层不知道整个团队目前的现状,包括技术领导也肯定没有办法合理地做任务分配。整个过程度量的缺失,就没有办法去衡量大家的绩效。现在在推行OKR,其实也是有度量的,也就是KR的达成程度怎么样。这些常见问题时压在团队身上的几座大山。

在这个过程中,会形成马太效应。每次质量差,上线以后有问题,运维工程师变成“背锅侠”;测试需要针对现有的问题尽快去验证,追着开发去修复,成了“追责侠”;最后我们的开发,只能加班加点去干,成了“加班侠”。这就是互联网时代“三侠”,工作很累,但是结果不理想,每天还吵得不得了
图片
图二 马太效应简示图

2.针对这种情况,有道怎么做探索和实践?

第一步,发现问题。

通过访谈或者观察的方式看目前是什么问题。访谈是一部分,观察也一定要有。因为整个研发团队在工作过程中是不希望被打扰的,如果打扰到他,一是可能配合力度不够,二是在访谈过程中可能会有一些答案是得不到的,所以在团队人员时间紧张的条件下,需要通过观察来发现问题。大家如果有时间,可以邀请去做共创,或者是内部的共创。同时可以把好的案例分享给我们团队,看看他们的接受程度。

第二步,收集到一些问题,对问题做进一步的分析和定位。

我们当时收集到了从需求到整个开发构建、测试、部署包括监控等多个环节的问题。

需求的话,一开始没有需求管理工具,大家靠书面记录,效率比较低,而且需求更新后,下游是不可知的。没有做需求变更管理就会导致快上线验收的时候才发现,开发的一些功能和实际想要的完全不一样,或者差异很大,这对团队是一个致命打击。包括开发构建、测试等环节也或多或少会有问题,针对这些问题我们做分析和定位,包括人、流程、工具各个方面。

针对这些,我们定了一个计划:

首先从业务到运维多个环节对单点的工具、流程进行一些优化,终极目标是建立一套能够从业务需求到上线发布的端到端,能够支持整个研发过程,快速高质量和持续发布的解决方案。

一是要快速,二是质量要高,三是持续交付。不能是一次快,或者是一次质量好,要持续达到这个目标。

第一步,引入敏捷开发模式
图片
图三 敏捷开发模式简示图
图片
图四 开发模式介绍图

第二步,从整个企业发展的层面去打造一套工具链,把全局拉通
图片
图五 工具链展示图

第三步,准备自建自己的DevOps能效平台,做一体化平台。

前期会通过一些流程规范,针对需求做基于流程的驱动。我们搭建了一套标准工作流,在这个工作流中基于不同的团队建分支流程,尽量落在这套标准的流程上。我们希望通过一些流程,来推动整个产研的过程,不管是通过卡片还是通过自动化的工具,或者说转化过程,通过工具去驱动,把这个数据沉淀下来。同时,在代码级别和测试级别,自己做了一些封装,有些是自己去做的。CICD方面后面讲,没有完全做成自建的,会做前端的封装。我们的产研团队的用户看到用的是一套平台,在一套平台上完全整个需求到上线的过程,对他们的感知比较友好。
CI/CD的核心流程,用tekton引擎去做的。通过一些pipeline组合,去完成整个流程管理,通过task的文件去做整个pod的调度,实现整个过程持续的流水线。
图片
图六 核心组件流程图
基于这个层面,已经从产品设计到需求、代码去做一些构建,发到对应的环境,去做自动化的测试,完全去实现全链路的拉通,包括上线以后有数据看板。有了这一套全链路的工具平台,就可以更好地去支撑我们的敏捷开发模式,最后一步卡在运维。

这样的话,通过这套平台可以得到一个需求,跑完以后快速上线,上线以后快速地验证。验证完以后,是否OK,具不具备发布条件,当期发布目前已经是OK的。
图片
图七 DevOps展示图

3.项目管理与研发效能的有效结合

把整个研发过程拉通,通过自建去做。我们的项目管理应该怎么去做一些切入?和研发效能做结合。首先,在项目管理方式上做一些改进,在传统的项目管理中有一个传统铁三角的概念。项目管理管理上,会针对项目的范围、时间、成本传统的软件行业,更注重这三块。比如我是乙方,给甲方签了合同,交付一些平台或者系统,在这个过程中会有严格的范围定位。我们的立项时间分几个月去交付,一期、二期、三期包括我们的时间、成本,甲乙方对接的时候更需要做成本控制。项目管理更多的是在这三个层面触发,然后在过程中去做过程管理。但是这种模式,其实是需要做一些改进的。因为现在是一个互联网时代,乌卡时代,大家不可能说在一开始就确定要什么,给你多长时间,给你多少预算做出来,所以需要做一个转变,这就是敏捷三角的概念.
图片
图八 项目关系管理改进图
范围、时间和成本这三块也要看,只是比重没有那么高,而是作为整个项目管理的约束条件,也就是说我们要在有限的范围、时间、成本里面寻求最有价值的部分

而在这个过程中,可以通过一些工具、流程把质量逐步提升。通过敏捷三角的项目管理方式,每次去交付最有价值,而不是全量的范围,可以基于价值每次去拆分最小的单元颗粒度做mvp,如果价值有变化,快速地做调整。

其次,项目管理过程中要做一些流程改进。从项目管理角度来说,原来是一个线性的流程,一般有了项目以后,要去做立项,做可研论证,可行性研究,做整个产品的设计,UE、UI的设计,研发、测试、上线,整个过程中都是线型的。存在一个问题,如果产品的需求PRD没有画好,UE是不是不能做?开发是不是也不能做?

于是我们改进了流程,减少了它的前置时间。PRD没有完全写好,但是用这种用户故事的形式,先给出整个用户故事的全貌。通过最终要做成什么样,拆出来最有价值的部分,后面UE和开发就可以先做这个部分的需求。最有价值的部分做完以后,可以实现优先级排序里第二有价值的功能。相当于把整个功能拆解完以后,后续的各个流程都可以直接接入。
图片
图九 项目流程改进图
另外根据项目管理计划,要做管理肯定要有一个度量体系,不然无法知道整个研发团队的效率点,或者工作饱和的情况。允许大家存在一定的“摸鱼”,但是要适可而止。有一些“摸鱼”明显不合理时,就需要做度量。

最后,项目管理里,我们也逐步找寻健康的度量方式和体系,逐步改进过程。

短期度量是第一步上来要做的,因为没有全流程的链路平台统计,都是基于过程的度量,只能单点收集需求、开发、测试、运维各个过程的数据。项目经理比较累,需要通过excel表,手动地去各个平台去扒,或者去其他的一些地方去问,这是比较难的。但是有了这个度量体系,基本上可以以此驱动。哪个数据现在大家看得比较重要,或者收集过程比较痛苦,就可以逐步做一些改进。

单点的数据有了,第二步就要关注交付的目标。比如这次需要交付5个还是交付10个的故事,这个过程基于整体的目标去做,在过程中会通过一些人员的效率,比如说周期,人均的效率包括缺陷的修复时间,通过整个迭代去看,而不是通过某个需求去看。另外,迭代发布的话,看一下发布频率或者发布前置时间。发布前可能涉及到环节没有准备好,因为遇到过一些情况,大家一开始着急开发,等到快上线的时候,给测试发申请,或者又在等一个机器配置什么的,很阻碍时间。发布时间就会拉得很长,导致最终整个迭代的版本上线就会很长。质量是会通过一些整个过程和迭代里面的冒烟驳回率、缺陷密度和缺陷漏测率和其他指标去做。

第三步,基于价值的度量。有了目标,但是这个目标只是说实现产品价值中间的过程,最终还是要实现有价值。以价值为导向,层层去过滤整个环节,单点去做还是通过迭代去做,层层拆解,逐步的消除。以价值的交付为导向,通过可视化的看法或者仪表盘逐步分解,分析,提高整个研发效能的效率和质量。
图片
图十 度量体系示意图
这样的结合路径会基于产品用户和市场三个层面做整体权衡,输出这次最有价值的点,相当于有一套自己的价值评估体系,会融入到整个产研体系。在产研过程中会去做一些需求规划、版本管理、时间盒,项目经理可以更有效地做过程把控。

我们的目标是希望通过整套能效平台,可以快速地探索和分析业务,形成一个MVP,快速实现MVP的上线和验证。

4.研发效能的未来展望

一、DevOps继续深入,重点还是整合丰富的数据源。

要关注数据是否有效,合理性怎么样,够不够丰富,要做这块的数据源整合,通过分析增加监控指标。这个深度需要更加合理,更加促进研发团队高效工作,不破坏团队氛围。

二、现在已经启动了,但还没有形成很大的规模的AIOps。

虽然我们公司也有AI的能力,AI的团队,但是AI要基于大数据去做。只有数据很丰富同时合理性高时,去做AIOps才会合理有效。因为只有对正确合理的数据进行分析,检测出的问题以及自动修复才是合理有意义的。用不合理的数据去做AI,方向就错了。

三、终极的目标是想做NoOps,相当于释放整个产研侧的压力,完全实现流水线自动化。

 

在这里插入图片描述

今天我的演讲就到这里,谢谢大家!