你好，我是王海亮，上一篇文章中，我与你分享了我在技术团队效率提升上的一些思考与实践，其实大的原则就是，以数据分析为基础，让团队多做有效工作，减少时间浪费。但在具体实践中，就需要我们从组织、流程、做事方式、专注度、代码质量等诸多可能影响效率的方面入手，不断优化提升团队效率。今天，我就将根据以往的实践，与你分享我们在做事方式、专注度、代码质量等方面的经验。

关于做事

做正确的事与正确的做事也是影响效率非常重要的点，我们知道，事情要从重要程度、紧急程度、成本大小等多方面去考虑，再按优先级顺序处理。优先级最高的应该是紧急重要且成本低的，但这里需要注意的是，这个紧急重要是你认为的，还是需求部门认为的？千万不要陷入到“你以为”的紧急重要中去，即使是技术上真的紧急重要的事，也要和业务连起来，直接或间接的体现出业务价值，否则，业务人员会各种抱怨，甚至可能会出现老板也不知道技术团队一天到晚在忙什么的情况。这点可以通过定期沟通的方式来解决，要做到对上与对外的充分沟通。

需要注意的是，团队要按优先级处理紧急重要事情，但管理者要更关注重要但没被定为紧急的事，因为团队往往会将很重要但不好实现的事情定为重要不紧急，而这些事情又往往会关系到团队或业务未来的发展。

做事情时，我经常会强调以下几点：
1. 强调目标，目标一般为解决业务问题或提升效能等最终目标，而不是完成某个功能或搭建某个技术框架等过程目标。目标要大胆，就像特斯拉创始人埃隆·马斯克那样，事情要做到十倍好，只有大胆的目标，并且相信能做到，为此去找方法，才能激发团队的创新，不止于在原有的思维或经验中徘徊。绝大多数人都是在原有的思维和经验中线性思考，比如项目要早点上线，就想着要么加班，要么增加人员，陷入到自己的心智模式中，只有给他更大胆的目标，很难用原有的思路和方法解决时，才能促使他去改变、去创新。

2. 强调 2/8 原则，强调先用 20% 的精力解决 80% 的用户需求，比如微信，你 80% 的时间在用什么功能？用的这些功能可以理解为 80% 的用户需求，这 80% 的用户需求往往只占微信所有功能中 20% 的工作量，那么，先做这 20% 的工作量来满足 80% 的用户需求，这就是 2/8 原则。

3. 强调适用原则，不要让目标脱离实际，也不需要最好的方案，只要最适合自己的方案，适合的才是最好的。比如，当你在为你产品的吞吐量提升做技术选型或架构设计时，先看看你产品的 QPS、TPS 等现状是什么样的，业务规划的预估是多少，再按实际选择能满足近半年或一年的业务需求即可，而不一定选择吞吐量最大的方案，避免杀鸡用牛刀的情况，浪费资源。

4. 强调 MVP 原则，快速上线最小化可行产品，比如用户需要一个交通工具以提升出行效率，这时你应该先做一个滑板车，快速交付用户，再造自行车，快速迭代，而不要想着一口气造一个跑车，或分阶段先造一个跑车轮子。

5. 强调技术实现也用最小化可行原则，快速迭代，每次实现一个小点，测试可用后再实现下一个小点，要避免技术人员的完美主义或钻牛角尖带来的时间浪费，避免重复造轮子，多借外力，比如使用公有云产品，成熟的开源方案等。

6、强调技术的简单可控，保持简单非常重要，因为，系统越复杂，依赖越多，越容易出故障，要确保不出故障，就必须加入更多功能，导致系统更加复杂，陷入恶性循环，所以，做任何会让系统变复杂的事情，我们都会特别慎重。

其中技术的简单可控是我强调最多的，也是我发现问题最多的点，因为技术人员经常会为了解决某一问题引入新的技术，甚至会因为某一技术流行或为了学习某一新技术而将其引入到项目中，最终导致项目非常复杂，陷入到各种 Bug 之中。最常见的就是这几年非常火的微服务架构，经常会遇到一个团队不管项目阶段、组织架构、团队规模和人员能力，就将系统设计为微服务架构，并且拆分的非常细，然而，没有做服务治理，没有分布式事务，自动化水平很低，且一个人维护好几个微服务，结果处理各种 Bug 的时间比写业务逻辑的时间还多。

在做事的过程中不断强调这些要点，并不断贯彻落实，到最后，说得多了、做得多了这些就成了你团队的文化，而文化的重要性不言而喻。

关于专注

专注是大家谈的最多的，也是影响效率最严重的原因之一，为了保障技术团队不被打扰，保持专注，我们从组织层面组建了技术支持团队，专门处理业务反馈的技术问题，比如线上问题的排查与解答，数据的提供与处理等。

这个团队独立于技术团队，只有该团队解决不了的技术问题才会提交给技术团队。同时，我们的研发流程采用敏捷方法中的 Scrum 框架，我们给每个冲刺都会预留 2 到 3 名技术人员不参与到 Scrum Team 中，我们将预留的人员叫救火团队，随时处理技术支持团队处理不了的问题或紧急需求。救火团队采用轮值方式，因此，他们熟悉整个团队的业务，也随时可被打断，目的就是为了确保 Scrum Team 的专注。如果仍然需要 Scrum Team 的协助，也是由 Scrum Master 处理，因此，Scrum Team 内是非常专注的。

在沟通协作上面，Scrum Team 成员不建议登录即时通讯工具，禁止各种即时通讯工具的群聊，对外的事情由 Scrum Master 沟通，团队内部和 Scrum Master 一起面对面沟通，Bug 处理通过项目管理工具协作，其他协作均通过项目管理工具或邮箱沟通。我们不建议通过即时通讯工具沟通而转向协作工具或邮件沟通，就是让技术人员尽可能的在自己适当的时刻拉取信息，而避免被随时推送来的信息打断思路，从而确保专注。

很多时候，大家都在谈专注的好处，以及我们怎样才能专注，但需要注意的是，作为管理者，一定要认识到专注的坏处，例如，当你在工位非常专注的写着代码时，你的老板从你身后走过，你会不会发现？如果你真的专注，我想你肯定是看不到老板的。而当你是管理者或 Scrum Master 时，你必须要尽可能多的了解团队的所有信息及外部对团队有价值或有影响的信息，但如果你过多的时间专注在做执行层面的事情时，这些场外信息你就无法获取，而没有全面的信息，你又如何引导团队，如何把握方向呢？因此，我们不建议 Scrum Master 做太多执行层面的事情，因为他需要获取更多的信息。

团队在专注的做完一个迭代后，我们也会让团队停一停，做下回顾、聊聊做得好的、不好的和建议，再聊聊迭代以外的信息，技术对业务产生的价值等等。这个“停”是非常重要的，能够让团队停下来反思，获取更多信息，了解团队及个人的价值，因为大家在专注的做事情时是会忽略这些信息的，长期下来就会导致团队成长缓慢，士气低下。所以，团队也需要和产品一样，不断的迭代升级，每次的停顿就像竹子的节一样，如果节太少，竹子就容易断，但节太多，就长的太慢，我们团队的这个节就是迭代后的回顾会议，频率是每两周一次。

关于代码质量

我相信，改别人的代码是很多程序员最痛苦的事情之一，也会导致效率非常低下，主要有业务和技术两方面原因，如：别人写的业务我不知道，别人的技术实现我不熟悉，别人的代码风格我不习惯等等。

关于这个问题，我们先是通过流程来解决信息透明问题，让团队中每个成员都清楚大家的业务逻辑、解决方案及进展，再通过统一框架与代码规范确保实现统一、风格统一，最后通过代码评审确保执行结果。

关于流程我在上一篇文章中已经有过分享，你可以回顾一下。

关于框架与规范，我们组建了基础框架团队，基础框架团队提供统一的 API 框架，后台管理系统框架及各前端框架，并且提供详细的 Demo，制定每个框架的编码规范及数据库规范。每个业务开发团队必须使用统一框架进行业务系统开发，如果业务开发团队需要引入新技术，必须向框架团队提出申请，新技术引入到框架后才可以线上使用，确保团队内部技术栈统一，实现方式统一，编码风格统一。

关于代码评审，我们是整个 Scrum Team 一起评审，实践上有两种方法，一种是由开发者讲解自己的代码，团队成员提出建议；另一种是互相交换，每个人都讲解别人的代码，其他人提出建议，如果讲的人讲不明白或很吃力，就必须修改。我们评审的主要原则是实现简单，逻辑清晰严谨，遵守编码规范。实践下来第一种方法效率更高，第二种方法质量更好。让大家把代码拿出来讲，大家心理就会有压力，会尽可能的将代码写好，评审时发现有问题的点也需要及时修改，这样，能确保代码质量，也是团队很好的学习与交流的机会。

关于代码注释，我们有个规定，不管是新增还是修改代码，必须有注释，注释必须包含作者、时间及背景，背景主要是需求来源及简短说明，以确保以后看代码的人能方便的找到原需求。

除此之外，我不建议过多的注释，并且写注释一定要慎重，这点可能和很多人的建议不同，因为我认为，代码是程序员自己的语言，这个语言除了和计算机沟通外，还要频繁的和团队其他成员沟通。如果你无法用自己的语言讲清楚你的目的，那就需要尝试换种思路去讲，而不是换种语言去讲，你的语言必须简洁且通俗易懂。但有时，确实有一些非常精妙的设计，需要新人有一定背景或深度思考才能明白，这时才需要注释，注释需要说明背景及设计思路，而不要过多的说实现，因为你的实现必须是简洁且通俗易懂的。

我建议慎用注释，还有一个很重要的原因是，当注释过多时，维护注释与代码逻辑的一致性，也是一个不可忽视的工作量，特别是由于某次疏忽，导致注释与代码逻辑不一致时，你到底是以代码为准还是以注释为准？可能你的第一反应是以代码为准，但仔细想想，你真的能确保代码是正确的吗？在我们的实际工作中，这种不一致的情况不止一次发生，每次都非常痛苦。

其他建议

除了以上提到的组织、流程、做事方式、专注度、代码质量等这五个方面外，影响团队效率的还有很多其他方面的因素，这里再给到几个建议，希望能对你有用。

1. 招最优秀的人才；
2. 花 4 个人的钱招 3 个人做 5 个人的事；
3. 尽可能的工具化、自动化，避免重复工作；
4. 建立愿景、反思与系统化学习机制，打造学习型组织；
5. 建立知识库，确保知识与经验的积累和传承；
6. 建立工作清单，让每个事件或过程都使用清单的方式简洁的列出，就像书的目录一样，确保不会漏掉重要的事情；
7. 淘汰绩效差的人员，招聘更优秀的人员，给团队输入新鲜血液，确保团队良性发展；
8. 采用深度聆听、团队共创法等方式、让团队参与和决策、尊重并认可团队、保持团队的开心与激情等；

总而言之，任何管理方法都有前提，我提到的方法不适合所有情况，但道理越基础越通用。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

王海亮，TGO 鲲鹏会北京会员，10 年技术团队管理经验，先后任职于 Newegg.com Team Leader，九州通集团 C 端技术总监，烽泰科技技术总监。