技术领导力实战笔记_202_第163讲_|_王海亮：提升技术团队效率的5个提示（下）
你好，我是王海亮。
上一篇文章中呢，我与你分享了我在技术团队效率提升上的一些思考与实践。
其实大的原则就是以数据分析为基础，让团队多做有效工作，减少时间浪费。
但在具体实践当中呢，就需要我们从组织流程、做事方式、专注度、代码质量等诸多可能影响效率的方面入手，不断优化提升团队效率。
今天我就将根据以往的实践与你分享我们在做事方式、专注度、代码质量等方面的经验。
先来看关于做事做正确的事与正确的做事，也是影响效率非常重要的点。
我们知道，事情要从重要程度、紧急程度、成本大小等多方面去考虑，再按优先级顺序处理。
优先级最高的应该是紧急重要且成本低的。
但这里需要注意的是，这个紧急重要是你认为的还是需求部门认为的，千万不要陷入到你以为的紧急重要中去。
即使是技术上真的是紧急，重要的事情也要和业务连起来，直接或间接的体现出业务价值。
否则，业务人员会各种抱怨，甚至可能会出现，老板也不知道技术团队一天到晚在忙什么的情况，这点可以通过定期沟通的方式来解决，要做到对上与对外的充分沟通。
需要注意的是，团队要按优先级处理紧急重要事情，但管理者更要关注重要，但没被定为紧急的事，因为团队往往会将很重要，但不好实现的事情定为重要不紧急。
而这些事情又往往会关系到团队或者是业务未来的发展。
做事情时呢，我经常会强调以下几点，一强调目标目标一般为解决业务问题或者是提升效能等最终目标，而不是完成某个功能，或者搭建某个技术框架等过程。
目标目标要大胆，就像特斯拉创始人埃隆马斯克那样，事情要做到十倍好，只有大胆的目标，并且相信能够做到为此去找方法，才能够激发团队的创新，不至于在原有的思维或者经验中徘徊。
绝大多数人都是在原有的思维和经验中线性思考。
比如项目要早点上线，就想着要么加班，要么增加人员陷入到自己的心智模式中，只有给他更大胆的目标，很难用原有的思路和方法解决的时候，才能够促使他去改变、去创新。
二强调八分之二原则，强调先用百分之二十的精力去解决百分之八十的用户需求。
比如微信，你用百分之八十的时间在用什么功能？用的这些功能可以理解为百分之八十的用户需求。
这百分之八十的用户需求往往只占微信所有功能中的百分之二十的工作量。
那么先做这百分之二十的工作量，来满足百分之八十的用户需求，这就是八分之二原则。
三、强调适用原则，不要让目标脱离实际，也不需要最好的方案。
只要最适合自己的方案，适合的才是最好的。
比如，当你在为你产品的吞吐量提升，做技术选型或者是架构设计的时候，首先要看看你产品的QPSTPS等现状是什么样的。
业务规划的预估是多少，再按照实际选择能够满足近半年或者一年的业务需求即可，而不一定选择吞吐量最大的方案，避免杀鸡用牛刀的情况浪费资源。
四、强调MVP的原则，快速上线，最小化可行产品。
比如，用户需要一个交通工具，以提升出行效率。
这时，你应该先做一个滑板车，快速交付用户，再造自行车，快速迭代，而不要想着一口气造一个跑车，或者分阶段，先造一个跑车轮子。
五、强调技术实现，也用最小化、可信原则快速迭代，每次实现一个小点测试可用后再实现下一个小点。
要避免技术人员的完美主义或钻牛角尖带来的时间浪费，避免重复造轮子，多借外力。
比如使用公有云产品成熟的开源方案等。
六、强调技术的简单可控，保持简单非常重要。
因为系统越复杂，依赖越多越容易出故障，要确保不出故障，就必须加入更多功能，导致系统更加复杂，陷入恶性循环。
所以做任何会让系统变复杂的事情，我们都会特别慎重。
其中技术的简单可控是我强调最多的，也是我发现问题最多的点。
因为技术人员经常会为了解决某一问题，引入新的技术，甚至会因为某一技术流行，或者为了学习某一新技术而将其引入到项目当中。
最终呢会导致项目非常复杂，陷入到各种bug之中。
最常见的就是这几年非常火的微服务架构。
经常会遇到一个团队，不管项目阶段组织架构、团队规模和人员能力就将系统设计为微服务架构。
并且拆分的非常细。
然而，没有做服务治理，没有分布式事务，自动化水平很低，且一个人维护好几个微服务结果处理各种bug的时间比写业务逻辑的时间还多。
在做事的过程当中不断的去强调这个要点，并且不断的贯彻落实。
到最后呢说的多了，做的多了，这些就成为了你团队的文化，而文化的重要性就不言而喻了。
再来看关于专注，专注是大家谈的最多的，也是影响效率最严重的原因之一。
为了保障技术团队不被打扰，保持专注，我们从组织层面组建了技术支持团队，专门处理业务反馈的技术问题，比如线上问题的排查与解答，数据的提供与处理等。
这个团队独立于技术团队，只有该团队解决不了的技术问题，才会提交给技术团队。
同时，我们的研发流程采用敏捷方法中的screm框架，我们给每个冲刺都会预留两到三名技术人员，不参与到screm team中。
我们将预留的人员叫做救火团队，随时处理技术支持团队处理不了的问题，或者是紧急需求。
救火团队采用轮值方式，因此他们熟悉整个团队的业务也随时可被打断。
我的就是为了确保screm team的专注，如果仍然需要screm team的协助，也是由screm master处理。
因此，screm team内是非常专注的。
在沟通协作上面的。
Screm team成员不建议登录即时通讯工具，禁止各种即时通讯工具的群聊。
对外的事情由screm master沟通，团队内部和screm master一起面对面沟通bug处理，通过项目管理工具协作，其他协作均通过项目管理工具或者是邮箱沟通。
我们不建议通过即时通讯工具沟通而转向协作工具或者是邮件沟通，就是让技术人员尽可能的在自己适当的时刻拉取信息，而避免被随时推送来的信息打断思路，从而确保专注。
很多时候大家都在谈专注的好处，以及我们怎样才能够专注。
但需要注意的是呢，作为管理者一定要认识到专注的坏处。
例如当你在工位非常专注的写着代码的时候，你的老板从你身后走过，你会不会发现？如果你真的专注，我想你肯定是看不到老板的。
而当你是管理者或screw master时，你必须要尽可能多的了解团队的所有信息，以及外部对团队有价值或者是有影响的信息。
但是如果你过多的时间的专注在执行层面的事情的时候，这些场外信息你就无法获取。
而没有全面的信息，你又如何引导团队呢？如何把握方向呢？因此我们不建议screw master做太多执行层面的事情。
因为他需要获取更多的信息团队。
在专注的做完一个迭代的时候呢，我们也会让团队停一停做下回顾，聊一聊做的好的不好的和建议，再聊一聊迭代，以万的信息技术对业务产生的价值等等，这个停是非常重要的。
能够让团队停下来反思，获取更多信息，了解团队及个人的价值。
因为大家在专注的做事情的时候呢，是会忽略这些信息的。
长期下来就会导致团队成长缓慢，士气低下。
所以团队也需要和产品一样不断的迭代升级。
每次的停顿就像竹子的节一样，如果迭代少，竹子就容易断，但迭代多就长得太慢。
所们团队的这个结，就是迭代后的回顾。
会议频率是每两周一次。
再来看关于代码质量，我相信改别人的代码是很多程序员最痛苦的事情之一，也会导致效率非常低下。
主要有业务和技术两方面原因。
比如别人写的业务，我不知道别人的技术实现，我不熟悉，别人的代码风格，我不习惯等等。
关于这个问题，我们先是通过流程来解决信息透明问题，让团队中每个成员都清楚大家的业务逻辑、解决方案以及进展。
再通过统一框架与代码规范，确保实现统一风格统一。
最后通过代码评审确保执行结果。
关于流程，我在上一篇文章中已经有过分享了。
你可以回顾一下关于框架与规范，我们组建了基础框架团队、基础框架团队提供统一的API框架、后台管理系统框架以及各前端框架，并且提供详细的demo,制定每个框架的编码、规范以及数据库规范。
每个业务开发团队必须使用统一框架，进行业务系统开发。
如果业务开发团队需要引入新的技术，必须向框架团队提出申请。
新技术。
引入到框架之后才可以线上使用，确保团队内部技术站统一，实现方式统一、编码风格统一。
关于代码评审，我们是整个scorme team一起评审，实间上有两种方式，一种是由开发者讲解自己的代码，团队成员提出建议。
另一种是互相交换每个人都讲解别人的代码，其他人提出建议，如果讲的人讲不明白或者是很吃力，就必须修改。
我们评审的主要原则是实现简单、逻辑清晰、严谨，遵守编码规范。
实践下来，第一种方法效率更高。
第二种方法质量更好，让大家把代码拿出来讲，大家心里面就会有压力，会尽可能的将代码写好。
评审的时候呢，发现有问题的点也需要及时修改，这样能够确保代码质量，也是团队很好的学习与交流的机会。
关于代码注释，我们有一个规定，不管是新增还是修改，代码，必须有注释。
注释必须包含作者时间及背景。
背景主要是需求来源及简短说明，以确保以后看代码的人能够方便的找到原需求。
除此之外呢，我不建议过多的注释，并且写注释一定要慎重，这点可能和很多人的建议不同。
因为我认为啊代码是程序员自己的语言。
这个语言除了和计算机沟通之外，还需要频繁的和团队其他成员沟通。
如果你无法用自己的语言讲清楚你的目的，那就需要尝试换一种思路去讲，而不是换种语言去讲。
你的语言必须简洁，而且要通俗易懂。
但有的时候呢确实有一些非常精妙的设计，需要新人有一定背景或者深度思考才能够明白。
这这个时候才需要注视注释，需要说明背景以及设计思路，而不要过多的去说实现。
因为你的实现必须是简洁，而且是通俗易懂的。
我建以慎用注释，还有一个很重要的原因是当注释过多的时候呢，维护注释与代码逻辑的一致性，也是一个不可忽视的工作量。
特别是由于某次疏忽导致注释与代码逻辑不一致的时候，你到底是以代码为准，还是以注释为准呢？可能你的第一反应是以代码为准。
但是仔细想一想，你真的能够确保代码是正确的吗？在我们的实际工作当中呢，这种不一致的情况不止一次发生，每次都非常痛苦。
下面还有一些其他建议。
除了以上提到的组织流程、做事方式、专注度、代码质量等五个方面之外，影响团队效率的，还有很多其他方面的因素。
这里再给你几个建议，希望能够对你有用一招最优秀的人才，四花，四个人的钱招三个人，做五个人的事情。
三、尽可能的工具化、自动化，避免重复工作。
四、建立愿景，反思与系统化学习机制，打造学习型组织。
五、建立知识库，确保知识与经验的积累和传承。
六、建立工作清单，让每个事件或过程都使用清单的方式，简洁的列出，就像书的目录一样，确保不会漏掉重要的事情。
七、淘汰绩效差的人员，招聘更优秀的人员，给团队输入新鲜血液，确保团队良性发展。
八、采用深度聆听团队共创法等方式，让团队参与和决策，尊重并认可团队，保持团队的开心与激情等。
总而言之呢，任何管理方法都有前提，我提到的方法不适合所有情况，但是道理越基础越通用，感谢收听，我们下期再见。
如果你觉得这篇文章对你有帮助的话呢，也欢迎把它分享给更多的朋友。