你好！

本周作客大咖对话的嘉宾是华为云 DevCloud 首席技术布道师徐毅，也是华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，拥有 10+ 年行业经验。今天，我们跟他聊了聊高效研发团队打造相关的话题，以及华为在这方面的相关实践。

极客时间：您好，能先简单介绍⼀下您和您⽬前主要负责的⼯作⽅向吗？

徐毅：感谢极客时间的邀请，很高兴能够跟大家分享我们在技术领导力方面的经验。

目前，我在华为公司担任华为云 DevCloud 的首席技术布道师，以及负责我们的专家服务相关的工作，之前是在公司的研发能力中心负责团队及个体效率提升的研发能力工作。

布道师这个头衔在国内可能还属于比较新鲜的事物，所以我先稍微介绍一下。DevCloud 是我们将华为 30 年研发能力积累对外开放的一个出口，我们也称之为是软件开发云，从名字就可以看出来，它跟云有很大的关系。云计算近些年发展得很快，在云上进行软件开发相比以前在 PC 机上进行软件开发，研发的环境和人员的技能等各方面都发生了变化，当然，更大的变化是业务形态。

由于有这么多的变化，对我们的主要受众，也即软件研发人员和企业来讲，DevCloud 背后所承载的理念可能是一种颠覆性的理念，而这种理念的转变，对于更好地理解和使用软件开发云是至关重要的。布道师的工作，顾名思义，也就是去传播这种理念、思想，让更多人接触、了解和理解这种新颖的研发方式，学会和掌握使用我们的软件开发云产品。而专家服务，则是通过为企业提供更全方位的从规划到落地的完整的培训、咨询等各种服务，配合产品的使用，更顺畅地实现研发的转型升级，提升研发效率。

极客时间：关于打造⾼效的研发团队，可否分享⼀下您的实践与经验？应该从哪⼏个维度出发呢？

徐毅：先简单铺垫一下，我的经验来看，做任何事情，道法术器各个层面都不可缺。

首先，在道的层面，我认为高效的团队和个人是提升研发效率的关键。这么说不是否认整体研发方法论的重要性，只是想强调，任何的方法论都依赖于基层执行人员的能力和纪律，所以说打造好基层的团队和个人是方法论生效的基础。比如前些年敏捷热门的时候，大家就很纠结说敏捷到底对人的能力素质有没有要求。其实我觉得这个事情很简单，如果把方法论比喻成算法，比如说加法、乘法、幂，那么 1+1+1=3、2+2+2=6，1_1_1=1、2_2_2=8，每一个团队和个人更强了，整体的效率和产出肯定会更高一些。

明确了这个理念之后，我们再来看法的层面。华为的风格是先谈问题，再谈方案。效率这个事情，我们也是先从收集影响效率的问题出发，大家反馈的问题非常多非常全面。进行一定的梳理和分类之后，我们发现最常见的是如下四类问题，我在之前的文章中也提到过：

1. 软件工程师不能聚焦编码，被各种非编码活动影响：我们在一些团队进行了时间统计分析，各种日常事务里面，团队周边协作与支撑工作是消耗时间占比最高的，跨团队的联动开发等一些工作也非常消耗时间、效率也很低；

2. 打断问题：员工工作的时候经常被突发事务打算，然后就需要去处理，一些团队的统计数据显示，平均每个小时打断 7 次以上，平均编码持续时间不到 10 分钟，这个可能大家也有所耳闻，前段时间还有朋友圈文章调侃华为非著名提示音“Welcome to Join the Conference”，而关于打断的危害，有个调查认为 3-5 分钟的打断，会需要 23 分钟才能恢复到原来状态，大家可以想想看这个对效率的影响有多大；

3.P L（Project Leader）直接价值贡献少：作为基层项目团队的 Leader，PL 不仅要管好项目执行、管好团队，我们也希望他们能够有大量时间投入到特性交付，毕竟 PL 都是团队里面技术能力相对拔尖的人，不写代码的话就太可惜了。但实际情况是 PL 被很多事务所牵扯，在项目管理和团队建设方面投入很多时间，而特性交付只有不到 20% 的时间占比；

4. 新员工写代码、老员工解问题：这个估计在很多地方都是常见问题，原因嘛也很简单。交付压力大，谁上？熟练肯定做得快，那就老员工上。新员工干嘛呢，自己写代码，可能就挖出很多坑，有了坑出了问题，肯定要赶紧解决问题啊，那谁能够更快的解决问题呢？老员工。但这样，一方面不是最有效地发挥老员工才干和作用的方式，另一方面也不利于维护老员工的动力和积极性。还有另一个统计数据是，我们发现高职级的人员代码产出相比低职级人员没有优势。

这些问题肯定要解决，但怎么解决呢？我们结合自身的效率问题，以及业界罗伯特·凯利（Robert Kelley）教授的研究成果，选择从如下五个维度去提升研发团队和个人的效率：
1. 活力：也就是人的动力动机，如果一个人没有主观能动性，我们给他们再好的方法、工具，恐怕都没有用，如果下面四个维度构成了效率之轮，那么活动这个维度就是让轮子滚动起来的动力之源；

2. 贡献：包括硬产出和软影响力多方面，主要思路是希望通过更好地汇集和展示团队与员工的贡献情况，一方面是提升员工的成就感，增强周边的认同，另一方面也是帮助员工观察自己情况、持续改进；

3. 能力：识别出我们需要具备的技能和能力项，持续地度量以及采取针对性的措施去提升技能能力水平，这会涉及到知识管理和应用方面的内容；

4. 管理：团队和个人的时间管理、工作任务管理等方面的管理水平，通过推广优秀实践、优秀工具等方法，来提升改进；

5. 协同：协同协作很难简单地说越多越好或者越少越好，都是要看具体的情况，但一定要减少不必要的协作浪费和投入。

极客时间：您提到从这几个维度去提升研发团队和个人的效率，那在具体实践中，你们是怎么做的呢？

徐毅：这些维度，我们在具体操作中，也有各不相同的方式。其中一种，是从时间记录和分析开始，也是前面提到过的，我们会在一些团队进行时间统计分析。然后就从最希望优化的时间入手，比如说，我们发现团队被打扰、被打断的情况很严重，严重到有的工程师戏称说自己是“白天抽空编码”，于是先在一些团队试点静默时间，固定上午或下午一个时间段是静默时间，IM 工具下线，专心干活。

当然，在开始静默之前，也都要告知周边团队和一些相关人员，让大家知道我们在这个时间段会静默。而且也建议团队选择一位联系人，在静默期间，处理紧急问题，可以隔一段时间再轮换。尝试之后，试点团队的反馈很好，所以后来这个实践也被大范围的推广，甚至有整个研究所、整个产品部集体静默的。静默时间能够给我们的工程师尽量的挤出一整块一整块的时间可以专心使用，但也一定要想好如何利用这块时间，以及如何做好紧急事件的处理计划。

有些比较积极的团队，参与了我们的试点，安装了时间统计工具，运行在后台，统计不同应用程序消耗的时间，然后我们再把这个时间统计进行汇总分析，从中寻找改进的机会点。其实我们前面提到的很多问题，也都是通过这些时间统计工具得到的时间数据来说话的。

改进方面，方法上，主要还是推荐时间管理的方法、技巧、经验，以及提供时间数据给（参与试点安装了工具的）员工帮助他们了解自身的情况。从影响范围更大的角度来看，更有效的，还是给大家推荐好用的工具。

工欲善其事必先利其器，我们目前并不缺少好的工具，但可能很多人并不知道有更好的工具可以使用，那我们就可以根据得到的信息，定点推给具体某位员工，建议他 / 她可以使用某款工具。比如，某产品线在分析试点团队的时间数据时候发现，有的员工有 10% 的时间都花费在了“explorer.exe”（我们工作环境以 windows 为主）上。那员工使用文件资源管理器干嘛呢？极大可能是要在电脑里寻找某个文件，但是我们为什么一定要找呢，可以搜嘛，所以就通过邮件推送信息给这些员工，建议他们使用 Everything 软件。

除了这类小工具，更重要的还是员工每天工作需要使用的作业工具。大家可能因为种种原因并没有使用最新、最好的工具，还有可能因为彼此的配置、环境等各方面的差异，而导致研发过程中浪费很多时间在集成、联调等环节。

在这方面的问题上，我们发现云化研发这个场景还是有不少的优势，如果把大部分的研发工作都放在云上，而不是每个人的本地环境，那么一致性以及工具最新版本的升级等各方面的问题都会更容易解决。华为内部就有专门的工具团队，开发基于云化场景的研发工具链，从项目管理、需求管理到编译构建、流水线到部署、发布全流程打通，同一个研发团队或开发部的人员都在同一套云化工具链上进行开发。同时，在工具链的背后，是我们云化研发的方法论和能力在支撑。

当我们把整个作业过程全部都放到云上之后，我们会发现能够更容易去度量一个需求的周期时间以及各个环节的问题，以此来牵引团队的改进。相比刚才讲的小工具，这个就是大工具方面的改进。我目前所在的 DevCloud，可以简单理解为就是这套工具链和能力方法体系的对外输出版，感兴趣的话，华为云官网上就有入口，可以尝试使用。

另外一方面，目前公司整体都非常重视优秀工程师的作用，强调搞技术也可以到很高的职级，在职业发展上铺平道路，还通过内部刊物等各种手段宣传介绍优秀工程师的事迹和经验，营造氛围，也鼓舞更多的工程师积极向上，磨炼自身的能力，加入优秀工程师的行列。也有部分研究所，在研究所范围内组织高效工程师的专属俱乐部，把当地的优秀工程师聚集起来，定期交流彼此的经验，也会邀请公司内部和业界大牛给他们开小灶，也在尝试是否可以在研究所地域层面给这些高效工程师提供一定的优待，比如专属的停车位等。还有一些产品部，对大家公认的高效工程师，会奖励机械键盘、大屏显示器、人体工程座椅、专用鼠标垫等各种优厚待遇，鼓励大家向榜样学习。

在具体工作任务层面，有的产品部针对前面提到的老员工问题，在部门层面，把部分优秀员工，从 PL 团队拎出来，组成“首席工程师”团队，不在 PL 团队承接任务，而是在部门层面自行挑选工作任务，给予他们相当的自主性，可以自己选择去解决难题或者挑选自己比较感兴趣的工作任务，很好地激活了老员工的工作动力。

公司各团队在这方面的积极性非常高，产生了很多的实践，我们内部还总结成册，出了这么一本“打造高效研发团队”的内部实践册，以供有需要的团队参考使用。也建立了内部的实践社区，供大家交流，补充最新的实践。也会有定期的内部大会，各研究所各产品部的优秀团队，大家会聚集在一起，分享各自的经验、交流学习。