阿里云「飞天发布时刻」2024来啦!新产品、新特性、新能力、新方案,等你来探~ 了解详情
写点什么

满帮集团李昊:“996”追求的是资本效益最大化

  • 2019-05-28
  • 本文字数:4330 字

    阅读完需:约 14 分钟

满帮集团李昊:“996”追求的是资本效益最大化

由 TGO 鲲鹏会举办的“全球技术领导力峰会—杭州站”于近日圆满落幕,会上,独角兽企业满帮集团高级技术总监李昊带来的《高品质交付:如何同时追求质量、效率与员工满意度》主题演讲给与会会员们留下了深刻印象。做好高品质交付不是一件容易的事情,中间涉及到许许多多的流程和利益协调,李昊以贴合实际、贴合大家关心的热点话题“996”为切入点,深度剖析了在质量、效率与员工满意度之间该如何平衡的问题,以下是他的分享内容,希望他的经验能为技术管理层的你带来启发。6 月 14-15 日,由 TGO 鲲鹏会举办的 GTLC 全球技术领导力峰会总站将在上海举行。


一个很有争议的问题

虽然有几十万 star 的 996.icu,但维护“996”正确性的人还是不少的,主要是下面几种观点。


一是有追求的人比 996 还忙,“码农”不用矫情而是应该珍惜奋斗机会,老板比员工辛苦多了,还扛着风险;


这当然是不太靠谱的观念。老板和管理层的收益没有办法完全和普通员工分享,压力和风险也就不要希望普通员工来分担。我见过很多公司,要做什么,究竟怎么做没想清楚,CEO 焦虑得不行,就去要求大家 996,这其实只是在传递自己的焦虑而已。


二是认为程序员目前处于整个产业的最底层,按照马克思主义经济理论,当生产力过剩的时候,生产者拿到手的回报就会下降,并且你不做这个工作,还有其他人等着做。


这也是不太靠谱的观念。做技术的真烂大街了吗?从我几百场的面试下来,感觉靠谱的程序员仍然是“卖方市场”:他们的机会很多。另一方面,如果你觉得他们是产业工人,上班对他们就是工作,大家的要求也不过是“依法办事”。


其实我感觉可以冷静地看一下这究竟是一个什么样的问题,不要一上来就是那么对立的姿态。

高强度工作不是一个现在才有的问题

1928 年冬天,凯恩斯发表了一篇文章,题为《我们后代的经济前景》(Economic Possibilities for Our Grandchildren)。文中凯恩斯预测到 2028 年,因为生产力不断发展,人类每周只需要上 15 小时班。


罗素不但在《幸福之路》里说,“一个人觉得自己工作重要是精神失常的前兆”,他甚至在 1930 年专门写了一篇《闲暇颂》歌颂慵懒的生活状态。


这两位都觉得,当时的文化痴迷于将工作本身视为崇高追求,而不是将其视为一个完整生活的一部分,对文明的发展大大有害。


利兹大学商学院经济学教授大卫斯宾塞后来研究说,公司高管、经济学家和政治家赞美痴迷工作的这种姿态至少可以追溯到 16 世纪欧洲重商主义的兴起:“雇主一直在努力消解工作无法吸引人的本性,希望通过各种宣传让大家喜欢甚至追求它。”

高强度工作不是一个中国才有的问题

不管是 Amazon 的高压管理制度,还是每天睡 4 个小时每周至少一个通宵产假休 11 天的梅姐,还是 Musk 在 twitter 上教育大家 40 个小时一周的工作无法改变世界实际上,全世界都有一些很拼很疯狂的人。


这么一个古老,又普遍的问题,为什么是中国软件行业爆发了 996.icu?要回答这个问题,我们首先看看,为什么是软件行业,再看看为什么是中国。

为什么是软件行业

因为软件的复杂度,我们很多时候不知道怎么度量和改进软件团队的效率和质量,如果靠经验估计出来的时间点等得不到老板和相关利益方的信任,就只能以加班来“拼”。


为什么是中国

主要原因当然是我们还很落后。这些年国内的研发水平有了长足进步,但是工程能力和组织能力还是有很大提升空间的,特别是大多数的中小公司,这属于发展中的问题。


另一方面,有时候国内这种拼法,多少有把名利上的成就作为成功的唯一标准的原因。这也属于发展中的问题。


发展中的问题,只能靠继续发展来解决。

怎么办

怎么解决呢?靠信任是不行,靠信念也是不行的,还是要讲究科学的方法。


你只能去管理你能度量的东西。


那么该怎样发展我们的管理手段,解决这里面的问题?




首先什么是效率?究竟怎么去度量一个软件开发的效率?以前有很多办法:数代码的行数,记 Time records。一个团队一个迭代能做什么,其实算的是这个团队的容量,并不能直接体现你的效率。还有一个问题是它关心的是个人不是团队,如果大家喜欢看篮球足球就知道,现在很多统计都是看团队而不是看球星的,软件开发作为一个复杂的社会化活动,只看个体的效率,这个是不对的。



另外,我们很多时候通过排 story points 等方法,追求对研发资源的利用率,把产品、开发、测试、设计等各个团队的工作都排得满满当当。这种做法是不是就会提高效率呢?我们可以看看下面这个排队理论里面的数学原理,叫做“Little’s Law“。



这个定理揭示了,如果你队列的资源占用率非常高,那就很容易出现死锁。公司把各个职能的团队在迭代里面都排得非常满,出现任何变化都插不进去新任务,就会死锁。所以在公司里应该注意:一是减少资源的使用率,留出空档做技术建设或者是临时需求;二是通过看 WIP 的数据,跟踪每一个员工同时进行的任务是不是太多,会不会有上下文切换太频繁的问题。


我们公司衡量效率的指标一是 Lead Time,二是部署的频次。Lead Time 是指从用户提出一个需求,到这个需求被满足的时间。在软件开发的上下文里面,我们主要是记录从需求确认,到功能被开发出来并经过测试验证,最终上线到用户可用的时间。


部署频次可以很好到反应工作效率,并且也体现公司整个基础设施建设到质量。能够按需随时发布版本的公司,在国内还是不太多的。




质量怎么样衡量呢?我们在公司里面衡量质量有两个:一个 MTTR,就是你的系统出问题之后从感知到恢复正常需要的时间。第二个是变更的失败率,就是针对生产环境(包括了灰度环境)的变更(包括 release 和配置两个维度的变更)失败率(是否导致了服务降级,服务失效,需要 hotfix/rollback/patch)。


我们选定了这四个指标来衡量我们的效率和质量之后,还做了很多的脚本和工具,把这些数据自动的收集起来,生成一个 dashboard,投到公司研发团队办公区的墙上,让大家一起来追求和提升。实施了一段时间之后,可以明显看到公司不仅仅是效率提高了,整个质量也有了明显的提高。但是这里要提醒一点,要做这样的动作,对公司文化是有要求的。如果公司的文化不是一个很开放,允许犯错的文化,收集的这些数据可能就会是假的。

员工满意度

我们最后来说说员工满意度。要做员工满意度,我们首先要关注研发团队的文化。这实际上也是可以度量的,下面是北欧的社会学家 Ron Westrum 给组织的分类,一种是谁的权力大谁说了算,组织里面对信息的分享和流动有恐惧感,会因为政治原因隐藏或者是更改信息。


第二种是讲规则。这种是国内大部分公司的状态。每个部门都希望能够按照自己的规则来,哪怕这是影响最后的结果交付的。


第三种是面向效率,关注如何达成目标的组织状态。


很多时候,你对自己的组织属于哪一类有数了,就知道怎么去改进它了。



然后,我们很多公司没有做职级体系,没有明确什么样的行为会获得奖励,什么样的行为会被惩罚。作为公司的管理者一定要建立一个公平、公正的环境。我们经常说勤奋的工作不会“杀人“,但是环境不公正其实会。


另外作为一个技术管理者,一定要把员工当作一个产品去做。这个在国内的公司里面确实做得不太好。关注员工,投资员工,让员工获得发展,其实是比投资某些技术或者固定资产,要划算的。


最后就是每一个技术管理者要切实落地最佳实践,特别是技术的最佳实践。在敏捷流程推了这么多年以后,我们和很多同行都发现,技术上的最佳实践发挥的效果仍然是比流程上的最佳实践要大的。当公司有良好的 code review,有完备的 CI/CD,有优秀的基础设施和编程框架,员工每天都是按照行业的最佳实践进行生产工作的时候,满意度自然就上来了,他会觉得自己在一个很好的研发团队,他会产生 identity。


退一万步讲,如果没有办法很快在组织、技术上有提高,你仍然可以做一些事情,比如把自己要做什么想清楚。作为管理者要常常问自己以及直接汇报给自己的人,你的目标清晰吗?你做的东西是服务于目标的正确的事情吗?你要做的下面的人非常明确并且有能力完成它吗?

“996”本身不是合理的做法,它追求的是资本的效益

我是反对 996,特别是强制长期 996 的。核心的原因是,本来社会上的劳动力是足够多的。公司“招一个人给两个人的工资干三个人的活”,背后的原因无非是,人多了,沟通和运营的成本会高很多,要保持高的效率也需要很多基础设施的投入和组织能力的建设。


所以 996 不是合理的,只是对公司而言合算:它追求的是资本和公司的效益最大化,牺牲了员工的很多生活之外,更侵占了员工学习和发展的时间。


一个人如果觉得他累了,或者他有名利之外别的追求,我们要能够接受和尊重。不能把年轻人当成燃料,要当成产品去打磨。如果光讲拼搏,我们有过比 996 更狂热的时期,不是吗?我们做一个组织、一个公司,本身还是希望让那些平凡的人干成不平凡的事,而不是要求每一个员工变成马云。今天到场大多数人是公司里面的技术管理者,这是我对大家的一点呼吁!


最后我想跟年轻人说一些话。把事情做到极致的人,大多数都有一种拼劲和韧性。究竟该怎么活,自己真正享受什么,喜欢什么,很多时候不是通过循规蹈矩的生活就能弄明白的,总得为什么东西拼过。


所以我们看待工作,也不能只算报酬。工作除开金钱上的回报之外,还是一个机会,认识创业伙伴,认识花花世界的运作方式,更重要的是,认识自己的机会。


同时,它也是绝大多数人通往更理想的工作或者人生,唯一的机会。所以,只要环境是公平的,只要你做着正确的事情,拼点儿真没什么。


嘉宾介绍:


李昊,满帮集团高级技术总监 ,曾在 IBM,Ericsson,Myriad 等公司从事嵌入式、服务器端和客户端系统的开发和团队管理工作。2013 年开始创业,后加入 TestBird 担任副总裁;2016 年加入货车帮,担任高级技术总监,货车帮与运满满合并成立满帮集团后,负责满帮的云原生平台、中间件、基础服务、运维安全、DevOPS 工具开发等工作,同时分管金融、能源、导航等业务板块的研发工作。




技术管理的干货还没看过瘾?没关系,2019 年 6 月 14-15 日, 由极客邦科技旗下 TGO 鲲鹏会主办的 GTLC 全球技术领导力峰会将正式在上海举行,我们精心策划了技术、思维、战略、管理、视野及领导力等六大专场,并邀请行业内最有话语权的大咖加入讲师天团阵营,他们将通过体系化、有洞见的分享来帮助技术您成为一名全能型技术人。


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


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


2019-05-28 07:006161

评论

发布
暂无评论
发现更多内容

产品经理训练营第一章作业

阿波

成年人最渴望的奖励就是成功 Jan 20, 2021

王泰

28天写作

两万字长文总结,梳理 Java 入门进阶那些事

程序员小跃

Java redis 架构 后端 面向对象编程

谈谈统计学正态分布阈值原理在数据分析工作中的运用

vivo互联网技术

大数据 正态分布 核心

产品经理-第一周作业

LLL777

对容器镜像的思考和讨论

阿里巴巴云原生

Docker 容器 开发者 云原生 CloudNative

项目管理全史(持续更新)

Ian哥

28天写作

[讨论]几个能有效应对 35 岁危机的办法

穿甲兵

uni-app的发展和应用

anyRTC开发者

uni-app 音视频 WebRTC sdk 安卓

招投标挖坑、防坑指南

浪潮云

tob 招标 投标

时间是最大的变量

石君

时间 28天写作

详解MySQL执行事务的语法和流程

华为云开发者联盟

MySQL 数据库 事务 服务器 SQL语法

C2C场外交易系统APP开发|C2C场外交易软件开发

系统开发

透过现象看本质:Java类动态加载和热替换

华为云开发者联盟

Java JVM 插件 类加载器 热替换

豆瓣9.5分,它是Scala领域当之无愧的王者之作!

博文视点Broadview

scala 编程语言 豆瓣高分

Soul 学习笔记---数据同步 websocket 连接建立过程分析(五)

fightingting

Soul网关

迟到的年度总结-数据的人生

松子(李博源)

大数据 数据中台 总结 年度总结

2020年中国DevOps应用发展研究——艾瑞咨询报告总结

禅道项目管理

DevOps 行业资讯 趋势

花一分钟体验大数据任务调度系统 - Apache DolphinScheduler 第一个官方 Docker 镜像

代立冬

大数据 workflow 任务编排

“数据库网络故障”愁坏了头,五种方法带你解难题

华为云开发者联盟

数据库 数据 GaussDB 网络故障 丢包

交易所APP系统软件开发案例

系统开发

SpringCloud 从入门到精通 13---Nacos集群搭建

Felix

如何 3 步一键部署开源容器应用?

binggg

Docker 开源 Serverless 云开发 应用

智汇华云 | ArcherOS Stack利旧FC-SAN存储

华云数据

存储

如何成为分享高手(上)

熊斌

个人成长 28天写作

Soul 网关实践 05|sofa服务&SpringCloud服务接入网关

哼干嘛

NanoDet:这是个小于4M超轻量目标检测模型

华为云开发者联盟

PyTorch 目标检测 yolo nanodet

送你一个造梦机器,然后入眠「幻想短篇 12/28」

道伟

28天写作

张小龙关于微信十年的产品思考 | 视频号 28 天 (13)

赵新龙

28天写作

20 行代码:Serverless 架构下用 Python 轻松搞定图像分类和预测

阿里巴巴云原生

人工智能 机器学习 深度学习 Serverless 云原生

长文攻略|如何打造一键部署的云开发应用

binggg

小程序 大前端 全栈 开发应用 云开发

满帮集团李昊:“996”追求的是资本效益最大化_技术管理_Echo Tang_InfoQ精选文章