乐趣区

关于devops:DevOps峰会-研发效能实践助力互联网行业项目管理行之有效

摘要

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

我写分享 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,相当于开释整个产研侧的压力,齐全实现流水线自动化。

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

退出移动版