技术领导力实战笔记_178_大咖对话_|_徐毅：打造高效研发团队的五个维度及相关实践
你好，本周做客大咖对话的嘉宾是华为云DF cloud首席技术辅导师徐毅也是华为cloud BU软件开发云产品部华为研发能力中心特聘敏捷专家顾问，前IBM大中华区敏捷及devops卓越中心主管前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练。
前诺基亚网络全球敏捷转型中心精益及敏捷教练拥有十多年行业顾问。
今天我们跟他聊了聊高校研发团队，打造相关的话题，以及华为在这方面的相关实践。
即刻直接问，您好，能先简单介绍一下您和您目前主要负责的工作方向吗？徐毅回答，感谢即刻时间的邀请，很高兴能够跟大家分享我们在技术领导力方面的经验。
目前，我在华为公司担任华为云DF cloud的首席技术布导师，以及负责我们的专家服务相关的工作。
之前是在公司的研发能力中心，负责团队及个体效率提升的研发能力。
工作布道师，这个头衔在国内可能还属于比较新鲜的事物。
所以我先稍微介绍一下def cloud是我们将华为三十年研发能力积累对外开放的一个出口，我们也称之为是软件开发。
云从名字就可以看出来，它跟云有很大的关系。
云计算近些年发展的很快在云上进行软件开发，相比以前在PC机上进行软件开发，研发的环境和人员的技能等各方面都发生了变化。
当然，更大的变化是业务形态。
由于有这么多的变化，对我们的主要受众以及软件研发人员和企业来讲，DF cloud背后所承载的理念可能是一种颠覆性的理念。
而这种理念的转变，对于更好的理解和使用软件开发云是至关重要的布道师的工作，顾名思义，也就是去传播这种理念思想，让更多人接触，了解和理解这种新颖的研发方式，学会和掌握使用我们的软件开发云产品。
而专家服务则是通过为企业提供更全方位的从规划到落地的完整的培训、咨询等各种服务，配合产品的使用，更顺畅的实践研发的转型升级，提升研发效率。
即刻时间问，关于打造高效的研发团队，可否分享一下您的实践与经验，应该从哪几个维度出发呢？徐毅回答，先简单铺垫一下我的经验，来看做任何事情。
道法、受气各个层面都不可缺。
首先，在道德层面，我认为高效的团队和个人是提升研发效率的关键。
这么说，不是否认整体研发方法论的重要性，只是想强调任何的方法论，都依赖于基层执行人员的能力和纪律。
所以说，打造好基层的团队和个人是方法论生效的基础。
比如前些年敏捷热门的时候，大家就很纠结，说敏捷到底对人的能力素质有没有要求？其实我觉得这个事情很简单，如果把方法论比喻成算法，比如说加法、乘法幂，那么一加一加一等于三二加二加二等于六一乘以一乘以一，等于一二乘以二乘以二等于八。
每一个团队和个人更强了，整体的效率和产出肯定会更高一些。
明确了这个理念之后，我们再来看法的层面。
华为的风格是先谈问题再谈方案。
效率这个事情我们也是先从收集影响效率的问题出发，大家反馈的问题非常多，非常全面进行一定的梳理和分类。
之后我们发现最常见的是如下四类问题。
我在之前的文章中也提到过，一、软件工程师不能聚焦编码，被各种非编码活动影响。
我们在一些团队进行了时间统计分析，各种日常事务里面团队周边协作与支撑工作是消耗时间占比最高的，跨团队的联动开发等一些工作也非常消耗时间，效率也很低。
二、打断问题员工工作的时候，经常被突发事故打断，然后就需要去处理一些团队的统计数据显示，平均每个小时打断七次以上，平均编码持续时间不到十分钟。
这个可能大家也有所耳闻。
前段时间还有朋友圈文章调侃华为非著名提示音，welcome to joined conference.而关于打断的危害，有个调查，认为三到五分钟的打断会需要二十三分钟才能恢复到原来状态。
大家可以想想看，这个对效率的影响有多？大三PL project leader直接价值贡献少。
作为基层项目团队的leader, p二不仅要管好项目执行，管好团队，我们也希望他们能够有大量时间投入到特性交付。
毕竟PR都是团队里面技术能力相对拔尖的人，不写代码的话就太可惜了。
但实际情况是，PR被很多事务所牵扯，在项目管理和团队建设方面投入很多时间。
而特性交付只有不到百分之二十的时间，占比四新员工写代码，老员工解问题，这个估计在很多地方都是常见问题，原因嘛，也很简单，交付压力大谁上了，熟练肯定做的快。
那就老员工上新员工干嘛呢？自己写代码可能就挖出很多坑，有了坑，出了问题肯定要赶紧解决问题啊。
那谁能够更快的解决问题呢？老员工，但这样一方面不是最有效的发挥老员工才干和作用的方式，另一方面也不利于维护老员工的动力和积极性。
还有另一个统计数据是，我们发现高职级的人员代码产出相比低，职级人员没有优势，这些问题肯定要解决，但怎么解决呢？我们结合自身的效率问题，以及业界罗伯特凯利、robert kelly教授的研究成果，选择如下五个维度，去提升研发团队和个人的效率。
一活力，也就是人的动力。
机器。
如果一个人没有主观能动性，我们给他再好的方法，工具恐怕都没有用。
如果下面四个维度构成了效率之轮，那么活动这个维度就是让轮子滚起来的动力之源。
二、贡献包括硬产出和软影响力多方面。
主要思路是希望通过更好的汇集和展示团队与员工的贡献情况，一方面是提升员工的成就感，增强周边的认同。
另一方面，也是帮助员工观察自己情况，持续改进。
三、能力识别出我们需要具备的技能和能力项，持续的度量，以及采取针对性的措施去提升技能能力水平。
这会涉及到知识、管理和应用方面的内容。
四、管理团队和个人的时间、管理工作、任务、管理等方面的管理水平。
通过推动优秀实践、优秀工具等方法来提升改进。
五、协同协同协作，很难简单的说越多越好或者越少越好，都是要看具体的情况，但一定要减少不必要的协作浪费和投入。
即刻时间问，您提到从这几个维度去提升研发团队和个人的效率。
那在具体实践中，你们是怎么做的呢？徐毅回答，这些维度，我们在具体操作中也有各不相同的方式。
其中一种是从时间记录和分析开始，也是前面提到过的。
我们会在一些团队进行时间统计分析，然后就从最希望优化的时间入手。
比如说我们发现团队被打扰，被打断的情况很严重，比重到有的工程师戏称说自己是白天抽空编码。
于是，现在一些团队试点静默时间固定上午或下午一个时间段是静默时间，IM工具下线，专心干活。
当然，在开始静默之前，都要告知周边团队和一些相关人员，让大家知道我们在这个时间段会静默，而且也建议团队选择一位联系人。
在静默期间处理紧急问题，可以隔一段时间再轮换尝试之后，试点团队的反馈很好。
所以后来这个时间也被大范围的推广了，甚至由整个研究所整个产品部集体静默的静默时间。
能够给我们的工程师尽量的挤除一整块，一整块的时间可以专心使用。
但也一定要想好如何利用这块时间，以及如何做好紧急事件的处理计划。
有些比较积极的团队参与了我们的试点，安装了时间，统计工具运行在后台统计不同应用程序消耗的时间。
然后我们再把这个时间统计进行汇总分析，从中寻找改进的机会点。
其实我们前面提到的很多问题，也都是通过这些时间统计工具得到的时间数据来说话的改进方面。
方法上主要还是推荐时间管理的方法、技巧、经验以及提供时间数据给参与试点。
安装了工具的员工，帮助他们了解自身的情况。
从影响范围更大的角度来看，更有效的还是给大家推荐好用的工具。
工欲善其事必先利其器，我们目前并不缺少好的工具，但可能很多人并不知道有更好的工具可以使用。
那我们就可以根据得到的信息定点推给具体某位员工，建议他或他可以使用某款工具。
比如某产品线在分析试点团队的时间数据时候，发现有的员工有百分之十的时间都花费在了explorer点EXE上。
那员工使用文件资源管理器干嘛呢？极大可能是要在电脑里寻找某个文件，但是我们为什么一定要找呢？可以搜嘛，所以就通过邮件推送信息给这些员工，建议他们使用everything软件。
除了这类小工具，更重要的还是员工每天工作需要使用的作业工具。
大家可能因为种种原因，并没有使用最新最好的工具，很有可能因为彼此的配置、环境等各方面的差异，而导致研发过程中浪费很多时间。
在集成联调等环节。
在这方面的问题上，我们发现云化研发这个场景还是有不少的优势。
如果把大部分的研发工作都放在云上，而不是每个人的本地环境，那么一致性以及工具，最新版本的升级等各方面的问题都会更容易解决。
华为内部就有专门的工具团队，开发基于云化场景的研发工具链。
从项目管理、需求管理到编译，构建流水线，到部署发布全流程，打通同一个研发团队或开发部的人员，都在同一套云化工具链上进行开发。
同时在工具链的背后，是我们云化研发的方法论和能力在支撑。
当我们把整个作业过程全部都放到云上之后，我们会发现能够更容易去度量一个需求的周期时间以及各个环节的问题，以此来牵引团队的改进。
相比刚才讲的小工具，这个就是大工具方面的改进。
我目前所在的DF cloud可以简单理解为就是这套工具链和能力方法体系的对外输出版。
感兴趣的话，华为云官网上就有入口，可以尝试使用。
另外一方面，目前公司整体都非常重视优秀工程师的作用，强调搞技术也可以到很高的职级。
在职业发展上铺平道路，还通过内部刊物等各种手段，宣传介绍优秀工程师的事迹和经验，营造氛围，也鼓舞更多的工程师积极向上，磨练自身的能力，加注优秀工程师的行列。
也有部分研究所在研究所范围内组织高校工程师的专属俱乐部，把当地的优秀工程师聚集起来，定期交流。
彼此的经验也会邀请公司内部和业界大牛给他们开小灶，也在尝试是否可以在研究所地域层面给这些高校工程师提供一定的优待，比如专属的停车位等。
还有一些产品部，对大家公认的高校工程师会奖励机器、键盘、大屏幕显示器、专体工程、座椅、专用鼠标垫等各种优厚待遇，鼓励大家向榜样学习。
在具体工作任务层面，有的产品部针对前面提到的老员工问题。
在部门层面，把部分优秀员工从p二团队拎出来，组成首席工程师，团队不在p二团队承接任务，而是在部门层面自行挑选工作任务，给予他们相当的自主性，可以自己选择去解决难题，或者挑选自己比较感兴趣的工作任务。
很好的激活了老员工的工作动力。
公司各团队在这方面的积极性非常高，产生了很多的实践。
我们内部还总结成册，出了这么一本打造高效研发团队的内部实践册，以供有需要的团队参考使用，也建立了内部的实践社区，供大家交流补充。
最新的实践也会有定期的内部大会研究所，各产品部的优秀团队，大家会聚集在一起，分享各自的经验交流学习。