10 KiB
第162讲 | 王海亮：提升技术团队效率的5个提示（上）
你好，我是王海亮，非常荣幸收到极客时间的邀请，与你分享我对技术团队管理的一点思考与实践。
任何管理方法都有前提，所以，我先聊聊技术团队的一些差异。
技术团队的组建分两个方向，比如刘国梁团队与西游记团队，刘国梁团队是通过层层筛选，都是精兵强将，而西游记团队则是各有亮点，互为补充。
技术团队做的事也分两个方向：项目方向与产品方向，项目方向如甲方委托乙方按要求开发应用；产品方向如给自己公司开发自己运营的产品。
对具体事情的要求也可以分两个方向：追求质量与追求效率，追求质量如硬件驱动、飞机发动机等；追求效率如互联网应用。
这样的分法，相信大家能分出很多，但是请注意，我所说的都是方向，没说具体是什么，因为事情不是非黑即白的，我不建议大家给自己或团队贴一个标签。试想一下，如果我们给自己打上某个标签，我们思考问题或选择方法时就很容易受到标签的影响，将思维局限在某一个区域，但高效最重要的是选择最适合自己的流程与方法来达到比之前更理想的效率，选择时需要穷尽尽可能多的方法，而不要局限在自己的标签里。举个例子，比如你是做电商平台的，属于互联网应用，但是，如果像互联网应用那样就只追求效率，可能就有问题了，因为电商平台中有和钱相关的，和钱相关的部分还是要关注质量，只追求效率，就可能会出现由于系统或流程漏洞而导致巨额亏损。
所以你必须清晰，你当前的团队和所做的事在哪个度上，再根据不同的度选择最适用的方法。
高效的定义
每个人对高效的理解不同，所以，你必须知道你的团队成员、你的上级、你的服务对象等相关人对高效的理解是什么？他们对你团队现在的效率能打多少分？
这些可能每家都不一样，需要你全方位了解你所在的场景，如果大家认为效率低，除了团队自身效率外，还需要考虑你沟通是否充分或反馈是否及时，是否做了大家认为最紧急重要的事情，大家对你工作是否了解，大家对你的预期是否过高等等。
关于沟通的问题，极客时间已经有很好的分享内容，这里，我只是聊聊团队自身效率的提升。
要提升效率，我会先了解影响效率的因素，你可以记录团队每个成员所做的工作与耗时，每周分析一次，如果你对时间与工作内容记录的足够细，相信你一定能分析出哪些是无效或可以不做的工作，哪些是可以节省的时间，效率=有效工作量/工作时间，注意，是有效工作量，不是总工作量，那么，多做有效工作，减少时间浪费，就一定能提升效率，这个道理非常简单。
下面，我分享几个我的一些思考和实践。
关于组织
我想先通过微软的例子说明下组织对效率的影响，不知道大家是否感受到，Windows7以前，微软的软件质量相当高，很少出现Bug，但发布频率很低，到了Windows10以后，Bug明显增多，但发布频率也变高了，那么，微软到底发生了什么？
进入软件行业比较早的人，可能听过微软“三权分立”的组织架构，有开发、测试和程序经理，程序经理负责设计详细的需求规格说明书，开发负责实现需求，测试负责验收需求。这三者是人事层面的三权分立，他们各司其职，互相制衡，带来的好处是能够确保项目质量，因为如果有任何质量问题，测试就不会通过，无法发布，但带来的问题是各自目标不同，互相扯皮，效率低下。
后来微软做了一次意义深远的工程师体系改革，把开发部门和测试部门合并，这样做大大提升了研发效率，加快了发布频率，能很快的响应市场变化，但带来的问题就是大家感受到的Bug量明显上升。
基本道理也很简单，就是越集权越高效，但风险越高，反之亦然，没有对错，只有是否适合。比如我们曾经采用过研发和测试一个团队，产品独立团队的组织架构，也采用过产品、研发和测试合并为一个全职能团队的组织架构，并没有好坏对错之分，只看是否适合当时的团队和所做的事。
关于流程
流程和组织架构一样，不同的流程对效率的影响也很大，选择适合的流程非常重要，比如追求质量的和追求效率的需要不同的流程，计划驱动的和拥抱变化的也需要不同的流程。
举个例子，2013年之前，我用的是CMMI模型，它更适合计划驱动、对质量要求高、需求变化少、团队规模大的项目，2013年后转入敏捷方法中的Scrum框架，它更适合对质量要求相对较低、需求变化频繁，团队规模小的项目。如果你认为你的团队介于某两者之间，也可以将多种方法结合，选取适合自己的流程。
道理也很简单，流程越短效率越高，但风险越大，反之亦然。
近几年我做的都是互联网项目，用的都是Scrum框架，我就从Scrum中选几点分享下我在流程方面的思考与实践。
Scrum中有三个角色，Product Owner，可以简单理解为产品经理，但比产品经理要求更多的一点是，他需要将产品需求拆解成一个个独立的、可协商的、有价值的、可估算的、很小的、可测试的用户故事，以确保每个迭代都能够上线有价值的产品功能；Scrum Master，可以理解为教练，站在场外，观察并引导每个队员按规则在最佳状态推进工作；Scrum Team可以理解为球场上的球员，各有分工，但目标一致，实际项目中就是开发、测试、设计等人员，每个Team一般为6到8人。
Scrum有5大会议，在计划会议中，我们会将本次迭代要做的用户故事拆解为具体要执行的任务，团队一起讨论设计方案，再使用扑克牌估算法，估算出每个任务的点数，点数就是这个任务工作量的大小。在对某个任务估算时，所有参会人员使用Scrum Poker选择自己认为该任务应该具有的点数，然后将扑克反面放在桌子上，确保不被他人看到自己的点数，当大家都估算完后，由Scrum Master发出翻牌指令，大家一起亮牌，由估算点数最小的和最大的人分别说明自己估算的原因，团队再次交流，解决大家的疑问，然后再继续一轮扑克牌估算，直到大家亮牌的点数一致。
这样做有几大好处，首先，大家的参与度很高，能够挖掘出更多的细节；其次，大家对需求与实现的理解基本一致，定下的工作量也是大家认同的。
我们对估算点数的大小也有要求，当估算的点数大于13时，任务必须拆分或简化，建议控制在8以内。这样做主要有两个目的，一个是要尽可能的确保功能或实现简单，再一个是为了让一个任务尽可能不跨天完成。当然，点数是个相对度量单位，每个团队可能都不同，所以请根据自己团队的实践确定。
我们会将分解的任务用便贴纸按任务状态以列的形式贴在一个物理白板上，便贴纸上包含用户故事编号，优先级编号，任务名和点数。每日例会时，Scrum Team和Scrum Master一起围绕在这个白板前，每个人说下他昨天做了哪些，今天要做哪些，有什么障碍，大家按任务优先级顺序领取任务，承诺预计完成时间，并在领取的任务便签上写上自己的名字，再将便签移动到对应的状态列。
这样的好处是每个人都知道任务当前的状态，是由谁负责的，信息完全透明，同时，任务都是每个人自己领的，时间也是自己承诺的，工作内容与工作量也都是大家认可的，并且有签字仪式，这样承诺意识会更强，。
每个迭代完成后，我们会开回顾会议，回顾会议中，我们会先回顾上一次回顾会议的会议纪要，再让每个人花几分钟写出自己认为本次迭代做得好的和不好的，以及对下次迭代的建议，然后逐个按自己写的内容发言，每个人必须发言，最后再聊聊其他信息，对会议做下总结归纳，形成会议纪要。让每个人先写这点非常重要，不然可能会出现“我和他说的差不多”或发言没有重点等情况。
在回顾会议上，我们不建议上级管理者参加，Scrum Master不是管理者，他是教练，只是不同的角色，该角色是为Scrum Team服务的，所以他要参加。试想一下，如果上级管理者参与，大家可能会无法敞开心扉，因为上级管理者往往和团队成员的利益有关，且上级管理者专注于具体的执行时，也容易忽略掉更重要的场外信息。
那么，管理者要干什么呢？管理者要去建立并不断的优化制度、流程与机制，去创造这个场景，并将团队带入到场景中，然后自己出来，将场景交给团队。
小结
本文分享了我对技术团队管理，尤其是团队效率提升的一些思考与实践。其实道理很简单，通过数据分析，让团队多做有效工作，减少时间浪费，就一定能提升效率。但在实践中，却需要我们从组织、流程、做事方式、专注度、代码质量等诸多可能影响效率的方面入手，通过有针对性的迭代、优化，不断提升团队效率。
受限于篇幅，本文主要分享了我在组织和流程这两个大方向上的实践，下一篇文章中，我将根据以往的实践，分享我在做事方式、专注度、代码质量等方面的经验，欢迎持续关注。
感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
作者简介
王海亮，TGO鲲鹏会北京会员，10年技术团队管理经验，先后任职于Newegg.com Team Leader，九州通集团C端技术总监，烽泰科技技术总监。