当 996 无法再提升团队效能,CTO 该怎么办?

阅读数:2050 2019 年 10 月 8 日 11:40

当 996 无法再提升团队效能,CTO 该怎么办?

Editor‘s Notes:
CTO 都是一群“善变”的人,上半年还在为了“996”是否合理吵得天翻地覆,下半年就开始琢磨除了 996,还能怎样提升团队效能。其实这也不怪 CTO 们,当下时代技术开发的核心词就是“快”,敏捷开发、快速反应,只是“快”也要讲求合理高效的方法。

9 月 22 日,二维火 CTO & TGO 鲲鹏会杭州董事会小组委员芦宇峰出席杭州分会活动《技术团队效能提升的创新与突围之道》,分享主题《通过强化组织、过程提升技术团队效能》,从将组织系统化、量化工作过程两个维度阐述了提升团队效能的实践经验。当 996 的效果不再明显,项目时间越来越紧张,你或许应该读读这篇分享。

编者注:查看芦宇峰完整版 PPT,请在 TGO 鲲鹏会公众号回复“杭州”自动获取。

当 996 无法再提升团队效能,CTO 该怎么办?

芦宇峰现场分享

大家好,自我介绍一下,我叫芦宇峰,现任二维火 CTO。

今天我要分享的是如何提升技术团队效能。其实话说回来,我觉得加班就是提升效率最快的途径。加班能不能提升效率?从我的角度看是可以的,每天多干一两个小时,其实你付出的时间本来就比别人多,如果再保持一定的效率,那就一定会提升。当然了,长期看肯定是不科学。

如果大家不太赞成这个方案,我们继续往下看。

首先我们讲到组织,其实大家都听说阿里巴巴的组织能力很强。一个事情、一个调整,随时可以到位,不像很多团队应对变化的压力很大,其实组织也是由人组成的,调整组织就是在调整人。那么人在这个过程中怎么合理地组织和调整?首先要说一下我对组织理解:

组织是战斗的阵型。我们面对的变化太多了,市场不断变化、客户需求不断变化,老板一天到晚折腾,团队产品经理有些有新的想法,甚至工程师也有自己的新想法,有这么多变化,我们想用一套阵型包揽天下很难。那么怎么面对这些情况及时做调整,使用什么样的调整方法?

这时就会出现很多阵型,根据不同情况变化阵型,没有听说哪个团队就是冲锋就是干。战场的情况这么多变,我们也要及时调整。当然了,也有传说中最牛逼的阵型——八卦阵,可攻可守,但八卦阵本身的原理就是利用变化来应对变化。如今唯一不变的事情就是“变化”,我们要学的是背后的方法论,就是主动拥抱变化。

当 996 无法再提升团队效能,CTO 该怎么办?

一、如何将组织系统化?

组织结构是一种组织形式,是一种阵型。把整个组织系统化是应对市场和公司变化的一个有利手段。所以接下来我主要聊怎么把整个组织系统化的过程。

很多组织会纠结是职能化还是垂直化,垂直化就是将很多工作直接和业务单元耦合在一起,每个人的责任就和业务单元绑定了。当然,职能化也有好处,同样专业领域的人在一起,可以更好协调资源和分工。

我们都经历过创业,可能手上写 Java 的就 5 个人。当面对变化的时候,今天这个人干 A 项目,3 天以后不管他的代码有没有测试完成,他都要去做 B 项目。如果人是资源,可以放在一个池里调整,作为管理者会非常系统。同一个工种在一起成长性会很好,不然有一些技术的话题,大家的关注点不一样;同样专业的工程师在一起成长性会好一些。垂直化的好处就是资源直接面向业务负责,所有的人背同样的 KPI,这会使业务更好地去落地。

当 996 无法再提升团队效能,CTO 该怎么办?

关于组织系统化,我提出三种方式:

第一,整个组织结构要向软件系统一样灵活;

第二,组织结构要像城市交通系统一样;

第三,组织结构要像人体的生态系统一样。

我分别讲一下这三种系统的形式。

1、组织架构像软件系统

这种结构强调大中台、小场景、重突破、轻边界,可以根据客户需求和商业场景快速落地。

像现在比较流行的中台策略,其实不仅仅指的是把我们的系统,软件的架构去中台化。更重要的是提出一个组织保障,如果我们把中台做得足够强大,我们可以说中台变大业务场景变小,每个场景会更灵活,当然边际也很清楚,可以根据不同的场景进行落地。去年,我们公司遇到一些危机,大家突然发现原来我们面对商业的场景很单薄,面对门店和连锁的总部,在原来的产品的基础上挖掘出很多的场景,使原来的产品和系统变成中台的支撑。同时,我们看到所有的场景可以基于中台快速构建,不是说现在把大量的人投入到这个场景,商业的场景需要尝试,试成功才有然后,如果走不下去,这个场景很快就销毁掉。

当 996 无法再提升团队效能,CTO 该怎么办?

当然缺点很明显,比如我们现在抽离一个中台的团队做这个事情。如果给中台投入的资源过少,中台会变成整个效率的瓶颈。早期遇到这个问题时,我们抽掉了订单中心,结果导致所有的需求都会涉及这些系统的改动,这些工程师比以前更忙,其中就涉及到怎么划分业务颗粒度的问题。如果用此类办法,一定要在中台上投入更多的人。

我刚到二维火时,我们的研发团队就 20-30 个人,很简单的组织结构。最早按照职能划分,大家先按照自己职能工种打散组织在一起。有一定规模后将数据独立出来,自己写了数据库的中间件,自己搭搜索引擎,探索底层的应用,当然这个时候有新的部门叫 PMO。后面我们开始将整个业务中台做成基础产品,包括之后的事业部都是指刚才提到的小场景。

当 996 无法再提升团队效能,CTO 该怎么办?

你会发现每一个小的场景都涉及到一个或多个产品的组合,面对不同的场景有自己的解决方案和落地的方式。如商务谈判的方式不同,门店是只负责收银和取餐柜的场景,零售是负责收银和供应链管理的场景。我们发现这样拓展开来,整个业务场景变多,客户群也变多了。

前两年,面对美团的市场竞争,打得很凶残,后来我们发现拼餐饮门店是拼不过的。于是我们换了个方法,绕过去,通过智慧商圈直接触达商场。商场在接受 CIM 和管理系统之后,会主动将所有门店的收银 POS 机换成二维火。很多问题从另外一个维度看一样可以解决,就像在这里,不是一对一和品牌门店谈,而是和虚拟连锁的共同体谈。

所以在组织结构设计方面,我们依据市场环境做了调整。在事业部,我们都招聘了很多 BD 销售人员。但在基础产品部也投入了部分研发力量。这么看会发现,组织结构也是根据中台化的原则进行划分,所以我们将组织结构以这种方式抽象,就像软件系统来设置,这就是实践的过程。

当 996 无法再提升团队效能,CTO 该怎么办?

2、组织架构像城市交通系统

交通系统型组织架构适合有大量常规工作,又需要快速响应的团队。

这一类指的其实是项目管理体系。项目管理体系每天有大量日常常规的项目在操作,又要面临海量突发事件,做好紧急响应的准备。

为什么我形容它是城市交通系统呢?在二维火,我们经历过最高并发 120 个项目的情况,其中 70-80% 的项目是常规型的,即客户提需求,商务、研发联合评估,最后按照研发计划推进。这些项目就像公交体系,我们知道它什么时候发车,经历哪些站点,最多延误几分钟到达目的地,可以衡量可以预期。而对于“市长”来说,他一定希望公交体系承担交通体系的大部分运载任务,这样才可以缓解拥堵现象。

除了公交体系,出租车体系也可以因为借鉴,当有大客户到来,他需要从出发点直到终点,中途不停靠。当然,除了公共交通体系,还有一些私家车。在组织体系内,“私家车”是服务老板的。我们的 CEO 经常会有很多新的商业想法,不管靠谱不靠谱我们都要做,他希望有直接指挥的权利,在公共体系之外,直接调度人员,分配职责。

公交 + 出租车 + 私家车,就构成了基本的交通体系。这种体系的优点是资源利用率高,规划清晰;缺点就是对项目管理能力有相当的要求,需要专职的项目经理。相比工程师,项目经理带团队更专业一些。很多工程师、架构师在带领项目的时候,会局限于写代码,技术攻坚等一系列问题。我们从 2016 年开始设置专职 PM,效果非常不错。

当 996 无法再提升团队效能,CTO 该怎么办?

3、组织架构像生态系统

像生态系统一样是说要让组织快速分裂、自主进化、强调结果、优胜劣汰。这样做的优点是既能改善自上而下的官僚主义风气,又能解决自下而上的效率问题。同时也缩小了团队规模,使之更加灵活聚焦。缺点是资源较为分散,沟通成本上升。

6 月份的时候,我去一个朋友的公司参访,这是一家即将 IPO 的大型公司,技术团队规模超过 2,000 人。他们基本将团队划分得很细,甚至有一个“袖珍”部门完全就是敏捷化团队,不超过 9 个人,负责快速推进不同的商业场景。而且大部分小项目团队都在盈利,发育得很好,我很佩服,但他们也存在问题。他们公司有大量共性的基础设施没有人研发,或者研发了以后没有人用,因为他们没有一个中台部门负责将这些需求抽象出来。

最后我想说如果说还是回到战争阵型上,兵无定式、水无常形,方法有很多,职能化、大业务小中台,大中台小业务,或者完全摒弃中台,都可以,只要对业务有好处就可以。以前反感组织结构调整,很折腾。结果当自己身处这个岗位上的时候才发现,不折腾是不行的。无论是外部还是内部问题,如果不去变化和调整,就会一直阻塞在这里。

二、量化过程,从方法上优化效率

我的老板每天都会问我:“研发效率可否提升一点?”

可我们现在的研发效率属于什么水平,我们都不清楚。通常我们要缩短交付时间,就是单纯的砍需求,或者多投入一些研发力量,很难做到细致的量化。这时候 CTO 和 CEO 的博弈就很有意思,对于效率这个命题,没有证据,全靠揣测。但身为管理者,这其实是一种内耗,所以我们要学会发现过程中的问题。

2016 年,我曾接触过一个大客户,往往要求一个需求的上线时间就是一个月。我们迅速地组织了一个“出租车”团队,几个产品经理上车调研发现不难,产品与架构设计只花了一周时间,编码一周、联调一周、最后测试一周、完美上线四周,准时交付,客户很开心,老板也很开心,我们也很开心。于是召开了项目总结会,准备为我们这次快速响应表功。

总结会上,大家吃着火锅唱着歌聊着天,聊到一半项目经理杀进来,说项目进程有点混乱。说好的一个月,但事实上原定的联调时间只有两三天,编码要占用更长时间。本来看到编码效率加快了,很开心,但为什么联调需要一周呢?

于是,大家的笑容凝固在脸上,全都不想聊这个问题。可既然开了头也不好冷场,于是庆功会就变成吐嘈会,客户端的同学吐嘈服务端的大爷,写好的接口完全不按照文档来,出参入参都不太一样。最后编码效率虽然很高,加班热情高涨,但到了联调第三天就没有一个接口跑通。

当 996 无法再提升团队效能,CTO 该怎么办?

我们当时就在想既然已经发现了问题,那么能不能去优化这个过程?

这就需要量化,最粗糙的量化方法就是时间。我们有个习惯,我们先给这个事情定了目标,提升研发过程的效率,关键结果是联调时间缩短一天,我们想看看我们能不能竭尽所能去缩短它。后来一位工程师引进了 Mock 工具,后来又强制调整了一些研发流程和研发手段,最后通过两个季度左右的时间,我们将服务端和客户端的联调时间缩短至一天。

所以,过程数字化的意义便在于衡量,进而便于去改进和优化。量化的目标是为了优化,量化可以很多,但优化得一件一件做,最后落在每项工作上有实实在在的改革措施。

关键结果一定是要数字化的,一些关键里程碑的时间、关键交付时间也需要数字化。以前我们不讲究成本,花投资人的钱比较随意。现在不一样,每个项目我们都讲成本,我们需要盈利,我们需要有更多的报价出去,全部数字化,这是最大的改变,用数字衡量方方面面。

其实说了这么多,效率的关键还是要回到人自身。包括团队文化,也是提高效率的重要手段,最终团队文化能否让成员保持高昂的士气,培养体系能否让成员能力逐步提升,都很重要。

嘉宾介绍

芦宇峰,TGO 鲲鹏会杭州分会理事会委员,现任二维火 CTO,曾在阿里巴巴集团口碑网担任技术部经理,支付宝用户事业部技术负责人。

活动推荐

10 月 26 日,GTLC 成都站将在成都市高新区正式拉开帷幕。环球易购 CTO& 前苏宁科技集团副总裁乔新亮、TGO 鲲鹏会成员 & 知道创宇 CTO & COO 杨冀龙等一批业界优秀的技术领导者,将悉数到场,分享领先的技术管理思考与理念,从而为成都本地的技术人提供一次丰富的、深度的探讨学习及拓展人脉的平台或机会。点击「详情」查看 GTLC 成都站相关内容,现在购买 3 张以上门票还可以享受团购优惠——169 元 / 张,多买多优惠哦!

当 996 无法再提升团队效能,CTO 该怎么办?


TGO 鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。

评论

发布