第163讲_王海亮提升技术团队效率的5个提示下.pdf

2019-1-24 上品科技技术负责人、TGO会员王海亮 你好，我是王海亮，上一篇文章中，我与你分享了我在技术团队效率提升上的一些思考与实 践，其实大的原则就是，以数据分析为基础，让团队多做有效工作，减少时间浪费。但在具 体实践中，就需要我们从组织、流程、做事方式、专注度、代码质量等诸多可能影响效率的 方面入手，不断优化提升团队效率。今天，我就将根据以往的实践，与你分享我们在做事方 式、专注度、代码质量等方面的经验。 做正确的事与正确的做事也是影响效率非常重要的点，我们知道，事情要从重要程度、紧急 程度、成本大小等多方面去考虑，再按优先级顺序处理。优先级最高的应该是紧急重要且成 本低的，但这里需要注意的是，这个紧急重要是你认为的，还是需求部门认为的？千万不要 陷入到“你以为”的紧急重要中去，即使是技术上真的紧急重要的事，也要和业务连起来， 直接或间接的体现出业务价值，否则，业务人员会各种抱怨，甚至可能会出现老板也不知道 技术团队一天到晚在忙什么的情况。这点可以通过定期沟通的方式来解决，要做到对上与对 外的充分沟通。 需要注意的是，团队要按优先级处理紧急重要事情，但管理者要更关注重要但没被定为紧急 的事，因为团队往往会将很重要但不好实现的事情定为重要不紧急，而这些事情又往往会关 系到团队或业务未来的发展。 做事情时，我经常会强调以下几点： 1.强调目标，目标一般为解决业务问题或提升效能等最终目标，而不是完成某个功能或搭建某 个技术框架等过程目标。目标要大胆，就像特斯拉创始人埃隆·马斯克那样，事情要做到十倍 好，只有大胆的目标，并且相信能做到，为此去找方法，才能激发团队的创新，不止于在原 有的思维或经验中徘徊。绝大多数人都是在原有的思维和经验中线性思考，比如项目要早点 上线，就想着要么加班，要么增加人员，陷入到自己的心智模式中，只有给他更大胆的目 标，很难用原有的思路和方法解决时，才能促使他去改变、去创新。 2.强调2/8原则，强调先用20%的精力解决80%的用户需求，比如微信，你80%的时间在用什 么功能？用的这些功能可以理解为80%的用户需求，这80%的用户需求往往只占微信所有功能 中20%的工作量，那么，先做这20%的工作量来满足80%的用户需求，这就是2/8原则。 3.强调适用原则，不要让目标脱离实际，也不需要最好的方案，只要最适合自己的方案，适合 的才是最好的。比如，当你在为你产品的吞吐量提升做技术选型或架构设计时，先看看你产 品的QPS、TPS等现状是什么样的，业务规划的预估是多少，再按实际选择能满足近半年或一 年的业务需求即可，而不一定选择吞吐量最大的方案，避免杀鸡用牛刀的情况，浪费资源。 4.强调MVP原则，快速上线最小化可行产品，比如用户需要一个交通工具以提升出行效率，这 时你应该先做一个滑板车，快速交付用户，再造自行车，快速迭代，而不要想着一口气造一 个跑车，或分阶段先造一个跑车 。 5.强调技术实现也用最小化可行原则，快速迭代，每次实现一个小点，测试可用后再实现下一 个小点，要避免技术人员的完美主义或钻牛角尖带来的时间浪费，避免重复造 ，多借外 力，比如使用公有云产品，成熟的开源方案等。 6、 强调技术的简单可控，保持简单非常重要，因为，系统越复杂，依赖越多，越容易出故 障，要确保不出故障，就必须加入更多功能，导致系统更加复杂，陷入恶性循环，所以，做 任何会让系统变复杂的事情，我们都会特别慎重。 其中技术的简单可控是我强调最多的，也是我发现问题最多的点，因为技术人员经常会为了 解决某一问题引入新的技术，甚至会因为某一技术流行或为了学习某一新技术而将其引入到 项目中，最终导致项目非常复杂，陷入到各种Bug之中。最常见的就是这几年非常火的微服务 架构，经常会遇到一个团队不管项目阶段、组织架构、团队规模和人员能力，就将系统设计 为微服务架构，并且拆分的非常细，然而，没有做服务治理，没有分布式事务，自动化水平 很低，且一个人维护好几个微服务，结果处理各种Bug的时间比写业务逻辑的时间还多。 在做事的过程中不断强调这些要点，并不断贯彻落实，到最后，说得多了、做得多了这些就 成了你团队的文化，而文化的重要性不言而喻。 专注是大家谈的最多的，也是影响效率最严重的原因之一，为了保障技术团队不被打扰，保 持专注，我们从组织层面组建了技术支持团队，专门处理业务反馈的技术问题，比如线上问 题的排查与解答，数据的提供与处理等。 这个团队独立于技术团队，只有该团队解决不了的技术问题才会提交给技术团队。同时，我