职场怪诞 1

这个班就上得很有乐趣。以下都是我的幻觉，纯属创造。

大老板被骗子和废物团团围住，他只能透过被修辞过的 ppt ，来艰难地了解想看到的“真相”。因为怕被夺权被架空、没有安全感，只能提拔多个奴性十足的无用之材，牺牲整体的效率来换得自己位置的稳固。until 外部给一记耳光。

中高层们互相制约，scope 交叠，从而无人通吃、人人有关，从而形成一种平衡的、三个桌腿通心粉局面。两个 VP 在例会上说的永远都是对方在自己项目上投入不足，第三个 vp 是管项目的，结论是线下你们再对一下，

各个部门之间的职级 level 并不能拉齐，往往是彼之专家，吾之助理。很多领导喜欢让自己的下属去跟隔壁部门领导沟通，这样等回敬时，既保留了解释权，又能俯视。

部门内各职级的能力，从高到低按强-弱-强-弱-强-弱弱弱的 pattern 隔代遗传。毕竟强的领导只喜欢听话认真做事的下属，必须干掉有想法的。弱的领导喜欢会争地盘、能出结果的下属，太废的容易共鸣。

飞书最革命的功能，是它弱化了 top down 的组织关系，削弱了权力带来的义务。这种“赋能”使得每个底层员工，都有一种可以自己去 own 一件事的错觉。于是乎在组织内，出现了不同的人在不同的时间针对同一件事，拉个新的飞书“讨论群”开始指点江山，然后隔几周再重启宇宙，重新拉个飞书“项目群”。

部门 A 一定要去 lead 本该由部门 B 主导的跨部门合作项目，然后就出现了这样一个循环的奇幻现象：牵头人的下属拉个新群 => 没人说话、问题没解决 => 牵头人@各种人，没人理睬 => 牵头人拉各部门领导，问题没解决 => 成为死群，没人说话 => 牵头人的下属拉个新群。这个项目的群总数大概已 30+，进入新一轮循环后，新人们但凡说点什么办法，牵头人一定要加以补充，使得清晰的解决路径模糊化，走向死群。

部门 C 的负责人喜欢先在老板面前做好宣讲，抢好地盘，不允许别的部门做，只有他可以要项目、要资源。然后会后，这个负责人就开始给其他部门提需求，交付不了就是其它部门的问题，交付成功了就是他们部门的业绩。

部门 D 的同学喜欢申请各种权限，偷偷蹭用部门 E 的服务。结果部门 E 有一次服务升级后他用不了了，他就跳出来投诉说为什么没通知他，结果被部门 E 的管理员骂了。部门 D 的领导说，把事实放一放，沟通不要带有情绪。后来部门 E 做事的人都需要保留邮件证明，只有拍在部门 D 的脸上他才能承认。但现在部门 D 被拍了也不承认。睁着眼说瞎话的天花板。

部门 F 流动率很大，除了离职的人，有些事情根本没有人知道。不久将来，很快，只有将入职部门 F 的人知道了。

能力不行的部门就只能向上下游传递压力，因此部门间的职责分工明确不了，也不敢明确。做项目管理的会抨击别的团队怎么项目交付延期了。做测试的说自己是支持和职能部门，认为产品的质量要靠研发自测。相信过不了多久，做研发会跟产品部门说请自研，做产品设计的会跟用户们说请自我满足。

平行宇宙落地在我司。审批一件事能不能做、这件事要做什么、执行做这件事，这三个是可以同步进行的，因为后墙太赶；汇报中的项目节点、预想的项目节点、实际发生的项目节点是三个永不相等的状态，因为听众不同吧。

按照客观定律，成本/时间/质量只能三选二。所以就很难想象，在严控成本甚至不惜省钱买烂货（不然某些部门会没有绩效）的前提下，交付节点时间不能妥协，上线后必然是质量问题频发；然后今年在不停修复旧的问题、交付高阶功能的时候，却砍预算了，那能挪交付时间吗？

从第一个版本开始，项目就没有如期保质量交付，丧失了专业信任，只能不断提出新的计划，定期开全员大会发发小奖励和小奖状，中层们誓师承诺、底层们喊口号，激发员工斗志，然后继续不断延期交付，不断提出新的计划。但也从不复盘不换人。甚至有一版到了上线节点，研发也不知道为什么要上线，测试不知道要上线什么功能，只好默认跳过。

之前在一个项目里，供应商 H 没签合同的时候被要求先干活。最近给他们安排了个新的项目，人家被白嫖了一次后学聪明了，至今没有任何动静。部门 I 慌了，在例会上公然向部门 J 大放厥词，真的就说出了“你们谁去给供应商 H 画个饼”这句话。

在飞书群里，部门 K 的对接人和供应商 L 都在问对方，“方便你自己改一下吗，我们这边都在忙”，同一句话来来回回，极限拉扯犹如糖醋小排。

部门 M 有一个不做设计、不写代码、不懂技术、只写情感小说类文档和做 ppt 的专家，他被领导要求 lead 几个团队来一起提升整个部门 M 的研发效率。有次开会，专家对他下属说我不可能讲这么细节，你们都是资深 xxx 你们应该自己会做。

部门 N 只做软件的表面，因为应用背后的所有问题，只能靠部门 O 解决。所以上半年必须交付不了新的表面，因为部门 N 资源不够。等下半年部门 O 做完了脏活累活，再申请和权限接入进来，有了“资源”，直接摘个果子。

部门 N 先把部门 O 的项目汇报成自己的成果，再把部门 O 的 head count 和做事的人都调转到自己部门，然后有新项目了，拉了个 3 人小群要部门 O 提供支持，因为老项目是部门 O 做的，“这次任务急，复用可以避免重新做保持一致”。部门 N 的 VP 在群里对部门 O 说，这个项目大老板很重视，希望大家紧密高效合作。但部门 O 连项目组成员也算不上，也从来没参加过新项目的会议。

部门 N 开发的软件是公司主打的工具类产品，想推广到集团。部门 N 又是招人占坑要资源，又甩锅白嫖领功劳，可惜一直都做不好。试想，公司内部都没用这个工具研发出牛逼的产品，别人为什么要用？差生文具多么。

部门 O 的研发效率长期卡在部门 N 的这个软件上。现在要提升整体研发效率，只能去推动部门 N 增加新功能。但是改皮上效果的作用毕竟有限，但是部门 O 又不能脱离这个皇家御用软件上，也不能重起炉灶做一套部门 N 的新功劳。在不能不用和不能用之间，终成死局。

部门 O 的资源分配的思路，如果一件事做好了，那是理所当然，因为它肯定没有难度，也不需要去管理。那些一直出问题的内部团队，才需要不停地投人力、投资源、给升职加薪。从而保证延期交付成了最佳选择。

一件事一直不做而让老板产生了“焦虑”，才说明它有真正的价值，有人开始组织专题刷存在感。预判问题并主动解决是不能存在的。

部门 P 用了部门 Q 的预算做事，欠了一家头部供应商 R 一笔钱已经快两年了。最近被催款，对接人希望供应商 R 去和部门 P 的负责人澄清下，因为部门 P 的 负责人不认同供应商 R 的 欠债要还钱的财税规定。供应商 R 认真地邮寄了个催款函给大老板，被部门 P 成功从 xxx 地方截胡了，部门 P 的负责人觉得供应商 R 这样做太不专业了。 P 部门 P 的一个车端软件会将某些数据高频发送到自己搭建的公网 IP 裸奔服务，最近有车卖到外国后，被安全部门发现了，确诊为最高等级的安全事故。部门 P 没法立刻关闭这个发送功能，因为不存在这个开关，而且关了所有国家的相关功能都不能用了。

部门 P 写的软件有个 bug 在 release 后才被发现，但是软件已经 OTA 出去了。各种拉会组群讨论汇报修复方案，结果一个开发说“好消息好消息，这个 bug 的功能开关在这个版本忘记打开了”，负负得正。

部门 S 不做设计和研发，但喜欢给技术部门提技术方案希望对方按这个实现，称之为业务需求。被对方质疑时，部门 S 义正言辞地问有什么难点。这个难点在于，如果你说他懂不懂技术，他就投诉 HR；如果你从了他，那上线后应该立刻就能把关联系统压挂、把链路堵住、把下游系统搞失联，一键三连。所以公司生存难题，是如何在不骂人的前提下拯救公司的业务。

部门 T 开发的车端软件在车辆还没下线，就耗光了流量，怎么都关不掉。于是部门 T 新增了一个业务需求，要求里程小于 xx 公里时不开启该软件。里程数也是部门 T 的软件里自己获取的。于是该软件就有了自己限制自己的能力。

部门 U 主导了一个项目，先成功验收了供应商 V 的方案设计，等供应商 V 开发完成后最近上线了。因为成功地在业务链路中拦截了一道，直接把所有下游都搞空转了。大家去找当时部门 U 验收的方案，发现其实就一页 ppt，还验收付了 xx 钱。下游某一负责人（来自部门 W ）说，上线后没问题啊；另一个下游负责人（来自部门 X）要去投诉，部门 U 的项目牵头人说，怎么就你事多。

部门 Y 为了应对可能到来的审查，要给部门 Z 访问日常工作需要的部门 Z 自己的资源设权限。但部门 Y 并不知道资源具体有哪些，于是开始收集访问需求，要部门 Z 的员工填写申请自己想要访问什么，从而能被限制访问权限。

部门 Z 有个小众的审批系统 A，一般遇到工作流都会用到，但从来没有被正式介绍过，导致非常隐蔽。有次部门 Y 的一个专家来“提需求”，系统 A 的对接人回复说“提个 A 申请权限”，专家问“这 A 是谁？通讯录能搜索到吗”。

FIN