摘要

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

我写分享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的。

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

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

范围、时间和成本这三块也要看，只是比重没有那么高，而是作为整个项目管理的约束条件，也就是说我们要在有限的范围、时间、成本里面寻求最有价值的部分。

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

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

于是我们改进了流程，减少了它的前置时间。PRD没有完全写好，但是用这种用户故事的形式，先给出整个用户故事的全貌。通过最终要做成什么样，拆出来最有价值的部分，后面UE和开发就可以先做这个部分的需求。最有价值的部分做完以后，可以实现优先级排序里第二有价值的功能。相当于把整个功能拆解完以后，后续的各个流程都可以直接接入。

另外根据项目管理计划，要做管理肯定要有一个度量体系，不然无法知道整个研发团队的效率点，或者工作饱和的情况。允许大家存在一定的“摸鱼”，但是要适可而止。有一些“摸鱼”明显不合理时，就需要做度量。

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

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

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

第三步，基于价值的度量。有了目标，但是这个目标只是说实现产品价值中间的过程，最终还是要实现有价值。以价值为导向，层层去过滤整个环节，单点去做还是通过迭代去做，层层拆解，逐步的消除。以价值的交付为导向，通过可视化的看法或者仪表盘逐步分解，分析，提高整个研发效能的效率和质量。

这样的结合路径会基于产品用户和市场三个层面做整体权衡，输出这次最有价值的点，相当于有一套自己的价值评估体系，会融入到整个产研体系。在产研过程中会去做一些需求规划、版本管理、时间盒，项目经理可以更有效地做过程把控。

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

4.研发效能的未来展望

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

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

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

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

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

今天我的演讲就到这里，谢谢大家！