裁员为什么会降本增笑？

大家好，我是煎鱼。

最近互联网公司放烟花的次数有些高，基本都扎堆 Q3~Q4 出现各类事件/事故。吃瓜都快跟不上了。

作为互联网民工，为什么裁员后会导致降本增笑呢？今天我们一起来聊聊。

各种事故烟花

现阶段各大厂都领上号了，阿里先崩，再到滴滴，接着腾讯。涉及到产品至少有：

除了各种吃瓜以外，可以学习的地方是可以看看滴滴的 K8s1.12 升级 K8s1.20 的技术方案和选型思考。

以下图片来源自滴滴技术的文章截图：

请细品。最终选型了 “原地升级” 的方案，给出的原因是：“从方案可落地以及成本角度”。

裁员怎么增笑

“开猿节流，降本增笑” 是当红的流行语。

软件复杂度上升

在以前互联网公司飞速发展的阶段，很多业务需求和商务，会把各产品打包、关联起来卖。期望这样可以一篓子就捅进去卖了。

此时大量的系统规模、软件架构、应用程序都会交织、掺杂在一起。也有了更多的开发同学一起在这添砖加瓦。

这不，突然来了车轮式的裁员。

裁员时间选项

裁员的时间节点，以下两种选项居多：

• 
  
• 当天谈，当天离职：当天早上一上班，就会突然约谈，直接现场完成必要的文书类签署，结束后当天马上走。
  
• 灵活安排一个月，再离职：提前数周或是一个月进行谈话，告知并要求 xx.30 走入。期间时间要打卡上班，但内容可以自由安排。
  

也有一些变形，常见的无非是多留几天。少留几天。因为这几天，系数有些变化。争取争取年假等。

听说高级别的，就是看谈的条件了。也有直接放一个月，不需要打卡上班（不坐班），自己任意安排。工资照发。

怎么裁员就裁出问题了

节了流，就要增笑了。很多风险逐渐暴露。

原本这一个大系统 10 个大模块，可能是 7~8 个人在一起维护的。各自有专门负责的领域，一般是与相近临模块迭代着。

这不，一轮轮 330、630、930、1230 的大力度裁员。团队直接剩 2~3 个人。人都当天排队离职，工作内容是都没有交接的。

古老沉香的老代码关联了多少其他业务模块，埋了多少 “坑”，平时修数据、HACK 代码又有多少。基本没啥人知道。

此时就会明显出现：产出效率变低，事故率增高，小事件不断。很容易使不对劲。

就像滴滴在选择技术方案时，可能也会更趋向于即使要冒一定的风险，也会选择更低成本、低开销的落地方案。一切就在就在一念之间。

这时就更容易出现事故了，因为很多成本高的方案，就是因为多做了一套冗余，这样可以确保出现意外时的稳定性。

总结

人是环境的反应器，潜移默化的，就导致了许多选择和思路的转变。在企业管理中，老板们最容易看到的就是经营成本，每个月都要给员工发工资。

当看不到进一步更大的发展前景和规划时，向往收缩时就会进行 “开猿节流”。走了的同学领了大礼包，留下的同学也背负了更多的开发任务和风险。

这两天还看到技术群的同学在讨论 “防御性编程”，以防被裁员。在这块，平时可能及时做好技术类文档，留存，交叉。可能对还在的同学会更好。