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