Tips 参与文末话题讨论,即有机会获得异步图书一本。
作者介绍:
去哪儿网研发项目管理平台负责人,曾先后任职于华为终端公司质量部和去哪儿网过程改进团队。对过程改进和工程效率提升有丰富经验。在去哪儿网任职期间,组织建设并实施了公司的项目管理平台,并成功将项目管理系统同配置管理、发布系统等研发工具打通,实现研发过程规范化、自动化。同时结合其他敏捷实践,有效提升团队的响应速度及交付效率。
案例背景
去哪儿网作为国内领先的在线旅游平台,在2013年之后,随着业务迅速发展,研发团队的规模也快速扩张。随之而来的如何降低项目管理成本、提升研发人员工作效率、保证项目交付质量等问题变得日益重要。
我所在的qunar研发支持团队,尝试对“需求-开发-发布”整个链条中的各种流程、工具、数据进行打通及自动化处理,以此减少研发过程中的各种浪费,提升整个研发体系的效率。
配合开发的几个团队目前有什么进展?什么时候能联调?在当时,作为项目经理想准确获得自己项目的这些相关信息只能选择当面沟通、打电话、聊天群、邮件等“人肉”方式询问。
这样的结果是:不但沟通效率低,还导致开发人员的工作经常被打断。
由于各团队的项目信息管理方式、信息存放载体各不相同,同一个需求,不同时候问不同的人,得到的信息可能是大相径庭甚至互相矛盾,如果想校准信息,又是一波“人肉”确认环节……
当时公司有一套老的项目管理系统,但大家都觉得不好用,所以实际上还是各自采用“Excel+邮件”的方式来管理自己团队的项目,导致在系统中记录的项目数据跟实际进行的情况差异很大。
当时去哪儿网每天并行开发的需求有上百个,一旦出现紧急需求插队或某个需求变更的情况,对后面需求的计划调整、影响关系人识别、影响周知,都是一场灾难……
为了解决这些沟通协作问题,我们设计并实施了去哪儿网的项目管理平台(基于JIRA开发,同时结合研发过程改进、组织结构优化等实践一并实施)。
在解决项目管理相关问题之后,我们又进一步将项目管理系统同公司原有的工程类系统(GIT、Jenkins、CI等)打通,从打通“项目管理信息”,提升为打通“产品研发全过程信息”,帮助研发工程师一站式完成项目全过程的各种操作和相关信息查询。这一解决方案不止提升研发效率,还有效减少了信息传递不一致导致的人为出错。
这个阶段主要围绕降低项目管理成本展开,关键目标及实施的主要特性如下。
去哪儿网的组织结构是BU制,我们按照部门/团队的维度来划分项目池(如图8-1所示)。
图8-1 项目池划分
(1)易于理解,在录入项目信息时,只需要在自己所属部门的项目池内录入就可以,不用做过多区分;
(2)体现了组织结构的概念,不同团队在操作权限、团队管理上的差异性需求,可以很方便的基于项目池做功能开关;
(3)团队的变化相对稳定,项目池调整维护的工作量比较小,不像按项目划分,需要经常为新项目增加JIRA项目池。
-
产品业务需求;
-
技术优化需求;
-
线上问题处理;
-
日常任务;
-
测试阶段bug。
这样就把研发团队要做的所有类型的事情在一个系统内集中管理起来,这样做有以下几个好处。
(1)
统一
“
语言和工具
”
。
不像之前,要在不同系统和工具中记录项目信息,导致不同团队间沟通项目信息时因需要各种“翻译”而产生浪费。
(2)
统一入口。
对研发人员来说,可以一站式管理自己所有类型的任务,统一入口。
(3)
统一数据。
后续做开发计划制订、开发进度跟踪等项目管理相关活动时,直接基于一个系统生成报表和统计视图,不会出现跨多个系统做统计时数据不一致的问题。
在以前的研发过程中,不同角色在研发流程中的各个环节使用不同工具管理自己的任务信息,如图8-2所示。
这样导致的结果是:对一个需求来说,需要到多个系统中重复录入信息,而且由于系统是多个,还会经常出现各系统中信息不一致的情况。
我们的做法是:在项目管理系统的工作流中打通研发流程,一个需求(也就是一次业务发布)用一条系统记录跟踪到底。
如图8-3所示,对一条需求的记录加入了工作流和状态的概念,同时所有环节的信息都在这一条系统记录里。从需求创建开始,产品先录入需求,然后流转给开发记录开发计划,设计方案,开发完成后流转给测试……随着项目向后进行,不同角色在工作流中录入相应环节的项目信息。
这样就确保了不同角色对这个需求的信息获取是一致的,而且不用像以前那样在多个系统重复录入。
此外,工作流的概念实际上等于是把公司的研发流程沉淀在工具中。只要大家适应工具,也就是习惯了公司的开发流程,这样流程的实施成本就会大幅降低(之前需要定期进行研发流程培训以及定期检查,要耗费项目管理人员大量的时间)。
有个很实际的问题:很多公司都做了一套“线上项目管理系统”,但实际上大家还是习惯使用Excel,不喜欢用官方的项目管理工具,因为觉得麻烦。时间长了,官方的项目管理工具就成了“摆设”。
造成这种结果的原因何在?我们认为,除了工具的场景设计(工作流、视图)同实际情况不匹配,还有一个很主要的原因就是工具的易用性不好。因此,我们在细节上,对易用性方面做了许多改进。
-
尽量简化字段和工作流
,控制研发人员使用项目管理工具的时间。首先,工作流中只保留研发流程的关键环节(需求-需求评审-计划-开发-测试-发布),尽量减少员工走流程的操作次数。其次,尽量精简每个环节填写的字段数量。不要为了项目管理人员的需要,在系统中增加大量的统计分类字段让大家填写。{1[最早我们设计的工作流,最长流程一共要走21个状态,经过反复讨论后认为过于复杂,最终核心状态精简到7步。]}
-
从用户角度出发,
提供面向用户的
“
自适应
”
视图
—看板、日历、面板。如图8-4至图8-6所示,除了为管理者提供各种统计视图外,还设计了各种根据当前用户姓名自适应显示的各类视图,以便于用户无需进行复杂的查询操作,就可以查看与自己相关的任务信息。
图8-4 例1:团队看板中点击“我的项目”,即可自适应过滤当前用户的任务信息
图8-5 例2:自适应显示与当前用户相关的开发项目日历
图8-6 例3:自适应显示与当前用户相关的开发中项目、过去7天内发布项目等
这里使用一个JIRA插件“Agilecard”解决了这个问题,这个插件可以很方便地批量打印卡片。每天站会后(站会沟通时会更新卡片状态)对物理白板拍照,然后在JIRA中上传照片,这样就可以批量更新卡片状态,使之跟物理看板保持一致。本质上来说,相当于提供了一种低成本的方式保证物理看板和电子系统中信息一致。
在实现了项目信息的集中管理后,接下来仍然从消除浪费、简单易用两个角度去进行尝试,把改进范围扩大到整个研发工具链(
数据展示
+
操作入口
),通过把项目信息和工程类系统之间的数据打通,以及对研发过程中的工具链进行操作入口整合,来提升工程师的工作效率。
我们发现,工程师在项目开发过程中,以及同各种工程系统打交道的过程中,依然面临着系统间信息不一致、信息搬运和操作复杂等问题,如图8-8所示。
(3)每次提交代码都要到CI平台下面不同系统中(Sonar、UT、自动化测试、代码评审等)输入分支名称,查看检查结果。
(4)开发完成,开发自测的时候,到发布平台把相关的工程、分支名称、各种发布参数填到发布平台,发完开发环境。
(5)再回到CI平台里,不同系统查看代码评审、自动化测试、数据库慢查询报警、SQL审核结果。
(6)提交测试,QA人员手工把相关的工程、分支名称、各种发布参数填到发布平台,再去CI里查看各种质量检查结果。
(7)在整个过程中,开发和QA人员还要记住定时去项目管理平台更新项目状态。
-
项目各种信息分散,获取困难。
-
操作入口多,麻烦,易出错。
-
影响工作效率,容易导致流程跳步。
解决方案如图8-9所示,当开发拉出开发分支的时候,相应需求的项目管理信息会和相关的工程信息整合,统一在一个页面中展示。
-
自定义上线步骤。
-
汇总工程、分支等工程信息。
-
点击超链接可直接跳转到各工程系统。
-
代码质量结果实时预警。
-
点击按钮执行发布操作。
如果质量检查结果有问题,右侧“!”图标,会变成红色,然后用户可点击红色按钮,直接切换到质量详情页面,如图8-10所示。
旧系统新系统各种信息,如工程/分支名称、需求JIRA号、标签信息等,需要在各系统中重复复制和粘贴,而且容易手误粘贴错误信息,导致操作失败信息打通,无需在各系统中重复填写要在各系统间来回切换,经常要开多个浏览器窗口一站式完成研发相关操作(项目管理+工程类)每次代码提交,需要“人肉”到各CI子系统中查询执行结果按需求维度,聚合并实时反馈软件质量信息;提交代码后,刷新JIRA需求页面就可以看到检查结果—数据打通后,数据完整度和准确度都会有大幅提升,可以为后续数据统计度量打好基础
实现上文中提到的效果,最关键的一步是要把研发各系统间的数据打通。而在打通数据的环节中,最重要的是建立需求和代码间的映射关系。这两个概念属于两个维度,它们之间不具备天然的映射关系。
首先规定分支命名规范。要求所有开发分支的名称中必须包含对应需求的JIRA编号。{2[因为去哪儿网主要的分支策略是分支开发和主干发布,所以对我们来说,大多数情况下,一个开 发分支会对应一个需求。因此,我们的分支命名规范是基于这个前提制订的。]}
然后在后台增加监控程序。当一个新分支拉出时,自动解析分支名称中的需求JIRA编号,并把它们之间的映射关系记录在数据库中。
如图8-11所示,这样需求同各类工程类信息之间的映射关系就完整建立起来了。
数据打通之后,剩下的工作主要是把各系统的操作界面进行统一,以及用脚本来串联各系统间的调用逻辑。针对这一点我们做了以下几个方面的工作(如图8-12所示)。
-
各工程系统前后端分离、提供API,供互相调用。
-
用户交互的部分重新设计交互和前端,并统一到项目管理系统界面中。
-
专门开发一个消息中心(IC),用于各系统间通信(类似事件广播的方式进行通信),任何一个系统发生变化时,都会“广播”发出一条事件,其他系统监听到这条事件后,会根据自身逻辑做相应处理。
-
专门做了一个数据中心(DC),把各系统数据汇总到一个库里提供一站式查询,这样各系统需要读取其他系统数据时,可以直接到数据中心获取完整的数据,而不用到各系统中分别调取。
-
持续集成相关系统,为了满足快速检查代码质量、实时反馈的需求,要持续对速度做优化,正常情况下各检查点要做到分钟级反馈质量检查结果。
(1)
项目管理平台首先应该满足
“
把项目管好
”
的需求。
对一线研发人员来说,系统简单、易用永远是第一位的,其次才是管理层的各种“统计度量”需求。如果为了给老板做各种报表,要求员工花时间在系统中填写很多分类字段,这样反而是本末倒置。
(2)
系统的设计,要结合公司的实际情况,匹配大家日常执行的研发过程。
比如,文中的项目池划分、工作流状态、系统字段,都是根据去哪儿网的特点重新定义的,这样员工使用项目管理系统时才不会有陌生感,系统才能起到承载公司研发流程的作用。
(3)
当团队规模变大后,管理层需要从系统中获取数据来实现对团队各方面状态的报表可视化。
这种管理需求是正常的,但不能只考虑管理需求,应同时考虑是否会导致团队的项目管理成本上升(比如各种字段的填写、检查和确认等),所以用自动化手段获取所需的统计数据是最好的选择。
(4)
无论是项目管理系统,还是工程类系统,都应该遵循一个原则:让用户少花时间做低层次操作(如各种复制和粘贴,各种
“
人肉
”
切换和查询),消除各种人为等待。
这样才能让研发人员把更多精力放到设计和编码这类高层次的脑力活动上,进而提升研发效率。
(5)
好的研发工具只是建设团队的一方面,实施过程中还需要配合组织结构、流程、文化建设等。
多方面齐头并进才能有效建设和改进团队。比如,在实施项目管理平台过程中,还要并行开展全功能团队建设、需求拆分等其他方面实践。
本文摘自:
《管理智慧:成功研发团队的18条管理启示》
yft 腾讯 蚂蚁金服 用友 ThoughtWorks 平安科技 去哪儿网等17家国内外大型技术型企业内部的实例解析 各企业管理人员效仿学习的典范。
本书分为工程文化、效率提升、团队组建、技术领导力4个版块,汇集了来自17家国内外知名互联网企业的实践经历,覆盖技术型团队全生命周期的管理参考指南。对创业型企业技术团队的搭建过程、大型企业高效能团队的建设困扰,书中根据实践案例出发,给予技术管理启示,从细节入手,对OKR、敏捷等技术管理理念与方式如何提升技术团队的效率、挖掘创意给予帮助,指引团队管理落地执行。
说说你遇到过的最棘手的项目是什么?有什么奇葩故事截止时间3月19日17时,留言+转发本活动到朋友圈,小编将选出1名读者赠送异步新书一本。
小学生开始学Python,最接近AI的编程语言:安利一波Python书单
一本基于Python语言的Selenium自动化测试书
Python
|
机器学习
|
Kotlin
|
Java
|
移动开发
|机器人
|
有奖活动
|
Web前端|
书单
在“异步图书”后台回复“关注”,即可免费获得2000门在线视频课程;推荐朋友关注根据提示获取赠书链接,免费得异步图书一本。赶紧来参加哦!