当 996 无法再提升团队效能，CTO 该怎么办？
CTO 都是一群“善变”的人，上半年还在为了“996”是否合理吵得天翻地覆，下半年就开始琢磨除了 996，还能怎样提升团队效能。其实这也不怪 CTO 们，当下时代技术开发的核心词就是“快”，敏捷开发、快速反应，只是“快”也要讲求合理高效的方法。
9 月 22 日，二维火 CTO & TGO 鲲鹏会杭州董事会小组委员芦宇峰出席杭州分会活动《技术团队效能提升的创新与突围之道》，分享主题《通过强化组织、过程提升技术团队效能》，从将组织系统化、量化工作过程两个维度阐述了提升团队效能的实践经验。当 996 的效果不再明显，项目时间越来越紧张，你或许应该读读这篇分享。
编者注：查看芦宇峰完整版 PPT，请在 TGO 鲲鹏会公众号回复“杭州”自动获取。
芦宇峰现场分享
大家好，自我介绍一下，我叫芦宇峰，现任二维火 CTO。
今天我要分享的是如何提升技术团队效能。其实话说回来，我觉得加班就是提升效率最快的途径。加班能不能提升效率？从我的角度看是可以的，每天多干一两个小时，其实你付出的时间本来就比别人多，如果再保持一定的效率，那就一定会提升。当然了，长期看肯定是不科学。
如果大家不太赞成这个方案，我们继续往下看。
首先我们讲到组织，其实大家都听说阿里巴巴的组织能力很强。一个事情、一个调整，随时可以到位，不像很多团队应对变化的压力很大，其实组织也是由人组成的，调整组织就是在调整人。那么人在这个过程中怎么合理地组织和调整？首先要说一下我对组织理解：
组织是战斗的阵型。我们面对的变化太多了，市场不断变化、客户需求不断变化，老板一天到晚折腾，团队产品经理有些有新的想法，甚至工程师也有自己的新想法，有这么多变化，我们想用一套阵型包揽天下很难。那么怎么面对这些情况及时做调整，使用什么样的调整方法？
这时就会出现很多阵型，根据不同情况变化阵型，没有听说哪个团队就是冲锋就是干。战场的情况这么多变，我们也要及时调整。当然了，也有传说中最牛逼的阵型——八卦阵，可攻可守，但八卦阵本身的原理就是利用变化来应对变化。如今唯一不变的事情就是“变化”，我们要学的是背后的方法论，就是主动拥抱变化。
组织结构是一种组织形式，是一种阵型。把整个组织系统化是应对市场和公司变化的一个有利手段。所以接下来我主要聊怎么把整个组织系统化的过程。
很多组织会纠结是职能化还是垂直化，垂直化就是将很多工作直接和业务单元耦合在一起，每个人的责任就和业务单元绑定了。当然，职能化也有好处，同样专业领域的人在一起，可以更好协调资源和分工。
我们都经历过创业，可能手上写 Java 的就 5 个人。当面对变化的时候，今天这个人干 A 项目，3 天以后不管他的代码有没有测试完成，他都要去做 B 项目。如果人是资源，可以放在一个池里调整，作为管理者会非常系统。同一个工种在一起成长性会很好，不然有一些技术的话题，大家的关注点不一样；同样专业的工程师在一起成长性会好一些。垂直化的好处就是资源直接面向业务负责，所有的人背同样的 KPI，这会使业务更好地去落地。
关于组织系统化，我提出三种方式：
第一，整个组织结构要向软件系统一样灵活；
第二，组织结构要像城市交通系统一样；
第三，组织结构要像人体的生态系统一样。
我分别讲一下这三种系统的形式。
这种结构强调大中台、小场景、重突破、轻边界，可以根据客户需求和商业场景快速落地。
像现在比较流行的中台策略，其实不仅仅指的是把我们的系统，软件的架构去中台化。更重要的是提出一个组织保障，如果我们把中台做得足够强大，我们可以说中台变大业务场景变小，每个场景会更灵活，当然边际也很清楚，可以根据不同的场景进行落地。去年，我们公司遇到一些危机，大家突然发现原来我们面对商业的场景很单薄，面对门店和连锁的总部，在原来的产品的基础上挖掘出很多的场景，使原来的产品和系统变成中台的支撑。同时，我们看到所有的场景可以基于中台快速构建，不是说现在把大量的人投入到这个场景，商业的场景需要尝试，试成功才有然后，如果走不下去，这个场景很快就销毁掉。
当然缺点很明显，比如我们现在抽离一个中台的团队做这个事情。如果给中台投入的资源过少，中台会变成整个效率的瓶颈。早期遇到这个问题时，我们抽掉了订单中心，结果导致所有的需求都会涉及这些系统的改动，这些工程师比以前更忙，其中就涉及到怎么划分业务颗粒度的问题。如果用此类办法，一定要在中台上投入更多的人。
我刚到二维火时，我们的研发团队就 20-30 个人，很简单的组织结构。最早按照职能划分，大家先按照自己职能工种打散组织在一起。有一定规模后将数据独立出来，自己写了数据库的中间件，自己搭搜索引擎，探索底层的应用，当然这个时候有新的部门叫 PMO。后面我们开始将整个业务中台做成基础产品，包括之后的事业部都是指刚才提到的小场景。
你会发现每一个小的场景都涉及到一个或多个产品的组合，面对不同的场景有自己的解决方案和落地的方式。如商务谈判的方式不同，门店是只负责收银和取餐柜的场景，零售是负责收银和供应链管理的场景。我们发现这样拓展开来，整个业务场景变多，客户群也变多了。
前两年，面对美团的市场竞争，打得很凶残，后来我们发现拼餐饮门店是拼不过的。于是我们换了个方法，绕过去，通过智慧商圈直接触达商场。商场在接受 CIM 和管理系统之后，会主动将所有门店的收银 POS 机换成二维火。很多问题从另外一个维度看一样可以解决，就像在这里，不是一对一和品牌门店谈，而是和虚拟连锁的共同体谈。
所以在组织结构设计方面，我们依据市场环境做了调整。在事业部，我们都招聘了很多 BD 销售人员。但在基础产品部也投入了部分研发力量。这么看会发现，组织结构也是根据中台化的原则进行划分，所以我们将组织结构以这种方式抽象，就像软件系统来设置，这就是实践的过程。
交通系统型组织架构适合有大量常规工作，又需要快速响应的团队。
这一类指的其实是项目管理体系。项目管理体系每天有大量日常常规的项目在操作，又要面临海量突发事件，做好紧急响应的准备。
为什么我形容它是城市交通系统呢？在二维火，我们经历过最高并发 120 个项目的情况，其中 70-80% 的项目是常规型的，即客户提需求，商务、研发联合评估，最后按照研发计划推进。这些项目就像公交体系，我们知道它什么时候发车，经历哪些站点，最多延误几分钟到达目的地，可以衡量可以预期。而对于“市长”来说，他一定希望公交体系承担交通体系的大部分运载任务，这样才可以缓解拥堵现象。
除了公交体系，出租车体系也可以因为借鉴，当有大客户到来，他需要从出发点直到终点，中途不停靠。当然，除了公共交通体系，还有一些私家车。在组织体系内，“私家车”是服务老板的。我们的 CEO 经常会有很多新的商业想法，不管靠谱不靠谱我们都要做，他希望有直接指挥的权利，在公共体系之外，直接调度人员，分配职责。
公交 + 出租车 + 私家车，就构成了基本的交通体系。这种体系的优点是资源利用率高，规划清晰；缺点就是对项目管理能力有相当的要求，需要专职的项目经理。相比工程师，项目经理带团队更专业一些。很多工程师、架构师在带领项目的时候，会局限于写代码，技术攻坚等一系列问题。我们从 2016 年开始设置专职 PM，效果非常不错。
像生态系统一样是说要让组织快速分裂、自主进化、强调结果、优胜劣汰。这样做的优点是既能改善自上而下的官僚主义风气，又能解决自下而上的效率问题。同时也缩小了团队规模，使之更加灵活聚焦。缺点是资源较为分散，沟通成本上升。
6 月份的时候，我去一个朋友的公司参访，这是一家即将 IPO 的大型公司，技术团队规模超过 2,000 人。他们基本将团队划分得很细，甚至有一个“袖珍”部门完全就是敏捷化团队，不超过 9 个人，负责快速推进不同的商业场景。而且大部分小项目团队都在盈利，发育得很好，我很佩服，但他们也存在问题。他们公司有大量共性的基础设施没有人研发，或者研发了以后没有人用，因为他们没有一个中台部门负责将这些需求抽象出来。
最后我想说如果说还是回到战争阵型上，兵无定式、水无常形，方法有很多，职能化、大业务小中台，大中台小业务，或者完全摒弃中台，都可以，只要对业务有好处就可以。以前反感组织结构调整，很折腾。结果当自己身处这个岗位上的时候才发现，不折腾是不行的。无论是外部还是内部问题，如果不去变化和调整，就会一直阻塞在这里。
我的老板每天都会问我：“研发效率可否提升一点？”
可我们现在的研发效率属于什么水平，我们都不清楚。通常我们要缩短交付时间，就是单纯的砍需求，或者多投入一些研发力量，很难做到细致的量化。这时候 CTO 和 CEO 的博弈就很有意思，对于效率这个命题，没有证据，全靠揣测。但身为管理者，这其实是一种内耗，所以我们要学会发现过程中的问题。
2016 年，我曾接触过一个大客户，往往要求一个需求的上线时间就是一个月。我们迅速地组织了一个“出租车”团队，几个产品经理上车调研发现不难，产品与架构设计只花了一周时间，编码一周、联调一周、最后测试一周、完美上线四周，准时交付，客户很开心，老板也很开心，我们也很开心。于是召开了项目总结会，准备为我们这次快速响应表功。
总结会上，大家吃着火锅唱着歌聊着天，聊到一半项目经理杀进来，说项目进程有点混乱。说好的一个月，但事实上原定的联调时间只有两三天，编码要占用更长时间。本来看到编码效率加快了，很开心，但为什么联调需要一周呢？
于是，大家的笑容凝固在脸上，全都不想聊这个问题。可既然开了头也不好冷场，于是庆功会就变成吐嘈会，客户端的同学吐嘈服务端的大爷，写好的接口完全不按照文档来，出参入参都不太一样。最后编码效率虽然很高，加班热情高涨，但到了联调第三天就没有一个接口跑通。
我们当时就在想既然已经发现了问题，那么能不能去优化这个过程？
这就需要量化，最粗糙的量化方法就是时间。我们有个习惯，我们先给这个事情定了目标，提升研发过程的效率，关键结果是联调时间缩短一天，我们想看看我们能不能竭尽所能去缩短它。后来一位工程师引进了 Mock 工具，后来又强制调整了一些研发流程和研发手段，最后通过两个季度左右的时间，我们将服务端和客户端的联调时间缩短至一天。
所以，过程数字化的意义便在于衡量，进而便于去改进和优化。量化的目标是为了优化，量化可以很多，但优化得一件一件做，最后落在每项工作上有实实在在的改革措施。
关键结果一定是要数字化的，一些关键里程碑的时间、关键交付时间也需要数字化。以前我们不讲究成本，花投资人的钱比较随意。现在不一样，每个项目我们都讲成本，我们需要盈利，我们需要有更多的报价出去，全部数字化，这是最大的改变，用数字衡量方方面面。
其实说了这么多，效率的关键还是要回到人自身。包括团队文化，也是提高效率的重要手段，最终团队文化能否让成员保持高昂的士气，培养体系能否让成员能力逐步提升，都很重要。