技术管理案例课_19_18_组织管理如何突破团队效率提升的三大关
你好，我是许建。
今天我们来谈谈如何提高团队效率。
关于提高团队效率这个话题呢，我先跟你分享一个故事吧。
这次新冠疫情期间，我回顾了自己这八年做云计算的经历，我觉得我们的团队做的非常累。
我们团队的工作时长在易贝，中国研发中心一定是排在前面的，但是我们的口碑却不一定是最好的。
为什么这么说呢？因为同僚和领导承认，我们很辛苦，却不觉得我们很优秀。
从客户满意度工程卓越性来说，我们取得的成效都和我们的付出不成正比。
为了提高效率，我们也多次抓过可靠性、代码质量搞CICD,连执行组织形式也尝试过多次变更。
但是我觉得做这些事情都不是最最关键的。
事实上呢，当我们去总经理那里汇报组织提效方案时，得到的反馈是没有触及灵魂。
这个反馈对我的触动还是蛮大的，我开始认真的思考反思，组织没效率问题，到底出现在哪里呢？我这个人呢很喜欢从历史里汲取教训。
于是呢我就把我们这三代云计算系统的经历排了一遍，分析哪些事情做得好，哪些事情做的差，然后对比他们之间的区别。
最后总结了提高组织效能的三个关键问题。
接下来我们就来详细聊一聊吧。
踏上管理岗位以后呢，你有没有意识到你的一个决定下去会直接影响？扫着几个人，多则几十个人，少则几个月，多则半年甚至数年的投入呢。
很多时候做正确的事情远比正确的做事更重要。
做经理的想要提升团队效率，首先就要看清楚我们身在何处，又想去往哪里，那怎么定义什么才是正确的事呢？我给你分享一个思路，就是做决定时反问一下，如果这是你自己拥有的公司员工的工资都是你自己掏的，你还会这么决定吗？我回顾云计算，这些年在易倍的变迁，我们不是做的太少了，而是做的太多了。
我们有的项目是技术驱动，然后绑架客户来用，而不是真的客户需要。
接下来我就给你分享三个具体的故事来说明这一点。
第一件事儿就是我们把内部的云计算CICD从jinkings改成了pro,这事儿呢投入了我们很大的精力。
我认为啊影响云计算团队交付效率的，关键在于测试环境不够稳定。
边界测试和性能测试的测试框架不够健全，我们总可以列出pro优于jenkings的点，但这是解决团队交付效率问题的核心吗？第二件事儿，我们启动了account resource corar.我承认，公有云系统的资源都是属于account的，我们也列了很好的交付目标。
比如可以让每一个业务部门自己管理自己的预算，从而帮助capacity团队提高管理效率。
但后来capacity团队的负责人却告诉我，他们最大的痛点不是缺乏按账户管理，而是如何在保证资源利用率的前提下，加快业务部门获取资源的速度。
这就是说，如果财务模型不转换成每个部门单独结算的话，就算我们把系统做成按每个部门的账户结算，也不会提高资源利用率。
单单从account角度变更capacity的管理方式，但没有解决用户真正的痛点。
第三件事情是这样的，我们做了好几代网络管理系统了。
在这个过程中呢，模型驱动这个问题是不停的在强调的一个标准。
模型驱动其实没有问题。
但问题是，花了这么大力气，做系统变更以后，长期困扰我们的难点做没有得到解决。
并且我们在搞出新系统的过程中，并没有干掉上一代系统，甚至更上一代系统。
现在还在生产环境运行。
从刚才讲的三件事儿呢，你可以看得出来，我们只是在积极的做事儿，但并没有选择做正确的事儿。
这些事儿的共性就是投资收益比不高，却白白花费了团队很多经历。
所以啊在我们做决策之前，必须先理清楚做什么才是正确的事儿。
那什么叫正确的事情呢？我认为啊正确的事情就是在做决策的那个时刻，管理者所能选择的可以最大化交付业务价值的事情。
并且这个业务价值不是管理者主观认定的业务价值，而应该是客户认可的业务价值。
其实我自己整理了一个文档，帮助我理清思路。
文档里的例子还不止上面这些，也不仅仅限于云计算部门。
这里的关键点是第一出发点的选择问题。
也就是说啊技术经理要从客户认可的最终业务价值考虑，而不是把技术先进性当做第一出发点。
只有从最终的业务价值出发，我们后面的努力才有意义，组织效率才能真正提高。
凡是可以从根本上提高组织效率的事情啊，都不简单的。
那么我们想干掉那些不正确的事情，难点在哪里呢？主要有这样两个难点。
第一个难点是这样的，凡是有能力在组织内提出新项目，甚至有能力组织一部分员工做雏形系统的人，一般都是组织内能力较强的人。
如果技术经理经过评估后，要关停这些人的项目，也不支撑这些项目的资源，很大可能会让这些骨干很不爽，那我们有没有这个感情长度和能力落实呢？第二个难点呢，就是也不乏有些项目，就是我们技术经理自己启动的。
我们有这个凄量承认自己之前错了，然后纠正自己的错误，而不是不停的去找理由证明自己是对的嘛。
难点列出来了，我们要怎么解决呢？虽然有些一言难尽，但这里的本质问题就是做好冲突管理。
我们要在组织内部统一思想和认识，有魄力下刀。
所以我们一旦确认了某些事情不是我们选择的方向，那再做这件事情不仅毫无意义，而且还会浪费企业的资源。
要知道，在错误的路上走得快，还不如在原地不动。
所以我们必须删除这些项目。
前面说的留下高收益比的项目是决定了我们到底做什么。
那么选出合适的技术方案就决定了我们怎么做。
我先给你说说方案选择的关键原则，技术方案的选择，请务必制指核心问题的解决，不要打移动靶，不要去追求技术的纯粹性，导致不断扩大战局，最终造成投入成本的快速增长。
为了让你理解这一点，我就拿c rory到test的迁移为例做个说明吧。
假设c rree环境下呢，我们要创建一个带有一百个虚拟机的应用。
那么就要先准备一百个虚拟机，然后一个批量操作，把负载均衡器给配置好。
所续部署代码的时候呢，重用这一百个虚拟机。
也就是说多次代码部署的时候，不需要重建虚拟机或者更改IP.可是迁移到test以后，每一个pod创建完成都会触发一次负载均衡操作。
Test不是fine and forget模统，而是不停的进行reconcile. Commodative native每次部署时，都会重新创建所有的pod.而在胖容积环境更换image,也是需要重建全部pod的。
但在这个过程中，其实API的调用次数是明显高于原来的CC环境的现实情况是这样的，所以整个生态都已经在test上了，我们还有重建外围系统。
所以我们耗费了大量时间试图解决性的问题。
我跟你说说，当时我们的尝试过程吧。
第一回合，首先我们把test调用LBMS的方式换成book call,并且让LBMS去除了多余的输入有效性检查，用这个方式来换取性能，但还是不行。
于是我们又联系了数据中心，添置了额外的LB硬件设备来分摊调用量。
第二回合，硬件扛住了，可是我们的配置管理系统CMS think在高压下还是会出现数据不一致的问题。
我们改了好几版，才解决了这个问题。
第三个回合呢解决了数据不一致。
我们又发现重建port后的胖容器还需要重新部署代码，于是CM pass的schedule性能问题，因为不堪重负而暴露出来。
看到这么多回合，你是不是也会这样想呢？我们本来只是上一个新系统，结果变成了要改造整个生态。
在这个过程中，我们的实施成本成倍增长，最后的交付时间一拖再拖，回过头来看我们是不是需要思考一下。
当引入一个新的系统的时候，到底最看重的是什么？当我们看中dock的build ones run everywhere,也就是一次编译，随处运行，结中读错了重来。
当我们看中dock的build ones run anywhere,也就是一次编译随处运行，看中了cobintist的specdriven,也就是规范驱动。
好在这个例子里，rolling upgrade是否需要兼持pod和对应的IP重建呢？这个问题值得商榷。
很巧合的是，类似事件屡见不鲜，所以我们一定要提高警惕。
最近我还跟总部一位同事讨论我们一个项目的核心，只是为了给squreet的proxy加上ACL.但是为什么谈着谈着就变成要把整个squreet集成换成invoid集群呢？这么多年来，这样的事情发生的太多了。
这些事情的模式如下，一开始呢我们要解决问题a大家都认同a是值得解决的。
接下来解决问题时，我们偏向新技术，觉得能搞定新技术，结果在过程中而还想顺带解决别的问题，而且搞定新技术的时间超过预期。
再然后啊业务突然有需求，新技术战还没有好，只能让老技术站来扛，这是人手以调往新技术站。
最后啊总是祸不单行，老技术站扛不住业务突发需求，于是把我们拖死。
所以呢我来给你简单总结一下，做技术经理的一定要时刻提醒自己，我一开始启动这个项目的初衷和想解决的问题是什么？我够不够专注，特别是在项目推进中碰到周围干扰时，我有没有坚持足够专注，有没有把一开始想要解决的问题踏踏实实的解决彻底。
刚才我给你讲了，方案选择的关键原则，不打移动吧，专注于一开始要解决的问题。
但除了这个原则，我们还需要解决关键瓶颈，怎么突破的问题。
要知道啊，决定整个战役成败的往往就是那一两场关键战斗。
我先给你分享一个故事吧，我们的监控组只付matrix耗时四年。
记得对这件事做复盘的时候呢，副总觉得最最关键的问题是团队不够专注，所以他决定停掉监控组所有的项目强迫监控组只关注matrix这一件事上。
但我跟副总说，对于监控的复盘，我有不同的看法的。
关键瓶颈没有突破，就算停掉，所有的工作专注于matrix还是不行的。
我为什么读出这样的看法呢？我们先来看看监控组在matrix上的历程吧，第一版是基于storm来实现的流式处理引擎。
第二版呢我们发现眼下flink才是趋势，并觉得flink有很多优点，但是因为改造成本过大，于是选择了storm on flink的方式，它的第三版又有变化。
因为第二版走到后来，我们发现storm on flink有很多限制，于是决定走native flink的模式。
第四版的这是美国的一位资深架构师。
M指出，公司里已经有很多部门在使用普罗米修斯了。
我们也意识到，我们基于flink实施方案，需要自主开发处理各种时序数据的函数，但我们没有足够的投入去开发这么多各式各样的函数。
于是啊开是转为解决普罗米修斯的高扩展现象的性能问题。
这四版的历程呢，我刚才给你交代的时候只是简短的几句话。
但实际过程都是我们团队以年为单位技术的成本投入。
直到第四版的方向确立后，架构师m亲自实施了普罗米修斯的扩展原型，性能调优落实到米修斯的内部实现，最终论证了可行性。
这个关键技术瓶颈解决后，监控组半年就交付了可投入生产环境的成熟的持续数据监控方案。
其实整个监控promaticrips交付核心问题就是这个高可扩展现下的性能问题。
整个团队耗时三年半，却没有交付，但最后半年就交付施的根本原因是什么呢？在我看来，就是因为一个高水平技术人员在关键点做了突破。
后来又是这位架构师，确立了使用click house来构建我们下一代events的监控方案，可扩展性和性能的问题也并并决决的。
我的的事情还有很多的，这些都让我深深意识到，从事基础架构工作中要去找关键瓶这类类难题，只靠对更多的人是不行的，就是需要高手，要么外面引进，要么内部有合适的人能空间。
我一直强调人和事的变形，我们找了高手，也总得搞清楚关键瓶颈在哪里吧。
那关键瓶颈到底怎么找到呢？我一般会用这两个问题来帮助自己整理定位关键瓶颈。
第一个问题是这样的，我们的着眼点是不是足够聚焦不停，逼问自己哪一个突破点可以极大提升产品竞争力，注意就只挑一个点。
第二呢就是确认问题，真的是关键瓶颈吗？关键瓶颈啊一定不能轻易解决，要么是技术难度极大，要么是关系很复杂，要么需要耗时很久。
刚才说的这个思路怎么落地呢？我们还是用一个实际的案例来说明。
比如我们监控组目前在做异常检测平台需要解决的问题，看起来有这三个问题。
一呢根据当前选定的一两个业务的实际生产环境，找到一个可以符合性能和精度要求的算法问题。
二是这样的算法精度所依赖的底层数据质量不过关。
所以我们需要增强算法的鲁棒性问题。
三呢就是找到一种可以快速自适应不同场景，并且能保证一定精度的算法。
这三个问题啊，第一眼看上去都很重要的。
但是如果我说强制说一个一定要排一个优先级，并且推断出最高的优先级，就会迫使我们进一步分析筛选。
我们的目标是构建一个平台，产品的竞争力到底在哪里呢？就是异常检测问题解决的投入产出比。
也就是说我们选择突破的点，一定是能够让大批客户上线适用的问题。
一啊能够让一两个用户上线，但是无法实现大批客户上线的啊，不能让我们的异常检测成为平台去服务很多人，也就是解决方案的覆盖面不够广。
问题。
二呢单独看着挺重要的，但如果和三对比一下，我们就能找到它的不足了。
问题二其实是问题三的必要条件，而不是充分条件。
因为即使解决了二还是不能达到大批用户可以上线试用的平台要求。
所以啊最终我们确定了关键瓶颈是三。
因为这是将易备的大量对异常检测有需求的场景进行平台化解决的关键确定了团队做什么和怎么做。
既然是经理，最终还是要回到人这个话题上来。
刚才啊在突破关键瓶颈的问题上，我也强调了高级别人才的关键作用。
那我们经理要怎么激励他们呢？接下来我结合自己的感受给你说一说。
在相当一段时间内，易被中国研发中心都很忌讳讲ownership这个词，我们只强调responsibility,原因是美国有些领导觉得中国动不动就要跟他们谈ownership,他们感觉这就是要抢活，没有wteam mindset.我最近啊对这件事情有了新的看法，我跟总部的副总和诸多领导都直说了。
我觉得只谈责任，不谈权利、不谈担当是不符合人性的。
而且我不认为和ownerwanting mindset有什么冲突。
就拿我自己来说，副总啊，最近让我全权负责云计算产品的入口体验，我对这个事情的投入程度和你让我辅助别的领导来做。
就是不一样的我不是说我辅助别人就不卖力了，但是卖力程度可以。
不一样的我和我百分之一百的力气，你也说不了我。
什么问题是你怎么能让我花百分之一百二十甚至百分之两百的力气呢？其实答案很简单，就是信任和授权给高级别员工授权，让他们去独立负责一个大项目，给他们自由，让他们按照他们的方式去实现目标，用尽理的信任去换取他们的承诺。
对于部门里我们看好的有潜力的员工，要敢于给机会，要高标准，要求出了问题，我们也要兜着。
因为对于经理来说，这些潜力股未来的成长更重要。
最后啊，如果他们真的高质量达到高标准，不要吝惜奖励，并且要以超出常规的方式去奖励他们。
我对比我们部门和数据基础架构部门新人培养速度的差异，为什么他们不断的有明星员工浮出来呢？我觉得关键的点就在这里，我对我们部门有潜力的员工的要求不够高，而且在奖励上不够刺激。
最后啊就是淘汰部门内业绩差潜力差的员工，具体的操作方式。
我在裁人那一片谈过了，新要辞刀要快。
有些事情我们也不喜欢做，但是为了这个组织能够有更好的发展，就是需要去做那些不开的事情。
而且级别越高的经理，最后留给我们去裁的人越难办。
总之，能者上、庸者下，为了团队效率的提高员工激励这件事情的原则就是赋能有潜力的人才和淘汰业绩差的员工。
好了，今天的内容讲完了，我们来做个总结。
组织管理上，我们可以定一个基调，所有能从根本上提高组织效率的事情，都是一定是高成本、高难度的一招鲜、吃遍天下的绝技，不存在赋下掉馅饼的好事，更不会存在高光时刻的背后，更多的是在整个过程中，无数个频凡的日日夜夜的坚持。
在我们成功之前，也要做好，没有多少鼓励和关注的心理准备。
在提高组织效率的路上，我们有三大关卡要突破，选择做正确的事情，确定合适的技术方案以及激励好员工。
首先啊正确的事情就是在做决策的那个时刻，管理者所能选择的可以最大化交付业务价值的事情。
要注意这个业务价值不是管理者主观认定的，而应该是客户认可的。
想要干掉不正确的事儿，要么会动骨干的蛋糕，要么就是纠正自己的错误，本质上是我们做冲突管理，需要有足够的魄力去落到。
然后呢，决定了做什么后，把具体实施过程中要不停的提醒自己目标是什么，然后不停的质问自己。
我们的技术方案不否始终聚焦在最开始的那个问题上面，不要打移动霸，而是要聚焦，尽量减少依赖，不要轻易扩大问题范围。
总之啊就是要减少变量数目，关键技术类的突破对交付效率的影响是决定性的。
我建议你啊把自己发现的问题写出来，做比较分析，结合产品竞争力定位最关键的问题，然后通过外部引入或者内部资源寻找高手空间。
在人的问题上，我给你分享了三点心得。
第一是给高级别技术人员授权，并且给决定权。
第二，给高潜质员工更高的标准和火线提拔的。
第三，要淘汰组织内业绩和潜力差的员工。
最后我再强调一下，留给我们解决的问题大多是硬骨头，没有轻轻松松可以提高组织效率的事情，这也正是需要你来做经理的原因。
最后呢我给你留两个思考题，公司里说要提升效率，于是提出测试代码覆盖率、CD覆盖率、手动重复劳动、自动化率等指标，并要求各部门执行。
你怎么来看待这些提效的举措？我们说到给予高级别员工决定权，你怎么来平衡给予下属的决定权和你作为部门主管经理的控制力。
如果他们做出的技术决策跟你想的不一样呢，欢迎在留言区晒出你在组织管理方面的经历和疑问。
如果有收获，也欢迎你把这篇文章分享给你的朋友。