ARTICLE · 1259687
软件公司里的垃圾人
软件公司里的垃圾人软件公司里有一类人，技术未必有多强，职位也未必有多高，但只要掌握了某些关键权限，就能让周围的人苦不堪言。 他们有一个共同特点：在最大程度麻烦别人和给别人一点方便之间，他们总是稳定地选择前者。 这不是偶尔的疏忽，而是一套长期稳定的行为模式。 别人的 MR 跑完流水线，还要等他审批才能合并。他自己的 MR 却可以走捷径直接合并。 结果就是，别人反复遭遇代码冲突，反复解决本来可以避免的问题，而他不需要承担同样的成本。 他未必违反了什么明文规定。甚至，他可能正是规则的执行者，或者拥有规则例外的特权。 问题在于：他要求别人遵守规则，却把自己放在规则之外。 这种人最擅长的事情，就是把自己享有的特权包装成理所当然，把别人承担的额外成本视为理所当然。 他经常已读不回，几个小时没有任何回应。 但是，如果别人没有及时回复他的消息，他就会觉得对方不积极、不配合，甚至影响工作。 一个按钮明明只需要几秒钟就能点击，他却可以稳定地让你等上一到三个小时。 最后，他轻描淡写地说一句：“这个我做了，你没看到吗？” 你很难指责他，因为从字面上看，他确实完成了任务。 但问题是，你等待的那几个小时也是成本。 你可能需要重新安排工作、打断思路、等待依赖解除，甚至因为一个简单的操作而无法推进整个任务。 这些成本不会出现在他的工作记录里，却真实地发生在你的工作中。 他只对自己的工作是否完成负责，却不对自己的工作方式给别人造成了多少损失负责。 当别人向他请教问题时，他表现得不耐烦，恨不得对方赶紧结束对话。 当他需要别人解释问题时，却要求对方提供完整背景、详细过程、充分证据，最好把所有可能的疑问都提前回答。 他当然可以要求信息充分。 但如果他自己不愿意付出同等的沟通成本，那么这就不是对工作质量的要求，而是双重标准。 他希望别人理解自己，却不愿意花时间理解别人。 他希望别人尊重自己的时间，却不认为自己有义务尊重别人的时间。 他希望别人提供高质量的协作，却不愿意为协作付出相应的成本。 他追求的不是互相配合，而是别人配合自己。 因为他很少做出一件明显违规、足以让人抓住把柄的事情。 一次不回复，可以说自己在忙。 一次审批延迟，可以说自己在处理其他事情。 一次代码冲突，可以说是正常的开发问题。 一次敷衍的解释，可以说自己表达能力有限。 每一件事情单独看，都有理由。 但如果这些事情长期、反复地发生，而且总是对自己有利、对别人不利，那么就不能只看单次行为，而应该看整体模式。 他可以在每一次具体事件中为自己辩解，却把所有事件叠加起来的成本留给周围的人。 更麻烦的是，他往往掌握着某个关键节点的权限。 他不必明确拒绝你，只需要晚几个小时响应；不必公开阻挠你，只需要让你反复等待；不必否定你的工作，只需要让你的工作始终无法顺利进入下一步。 最后，事情没有推进，他却未必需要承担责任。 这是一种成本极低、效果显著，而且很难被明确追责的阻挠方式。 为什么这种人能够长期存在？ 因为在很多软件公司的组织结构里，权限和责任并不对称。 一个人可以审批 MR、控制配置、决定发布、操作关键按钮，但他不一定需要为别人等待了多久、返工了多少次、损失了多少开发时间负责。 他制造的成本，由其他人承担。 他获得的便利，却由自己独享。 如果组织只考核他自己的任务有没有完成，而不考核他是否降低了整个团队的协作成本，那么他完全可以在个人层面表现得很高效，同时让整个团队的效率下降。 更糟糕的是，这种行为甚至可能带来个人收益。 别人越依赖他的权限，他就越有控制力；别人越需要反复催促，他就越能决定工作节奏；别人为了避免冲突而迁就他，他就越没有动力改变。 于是，一种极其糟糕的均衡形成了： 他没有动力给别人方便，别人却不得不想办法适应他。 这不是单纯的个人品德问题，也是组织设计的问题。 遇到这种人，很多认真负责的工程师会本能地选择一条路：催促、协调、解释、返工，想尽办法把事情推进下去。 MR 卡住了，反复催审批；代码冲突了，自己想办法解决；配置迟迟没有修改，就一直盯着消息；任务无法推进，就挤占自己的休息时间补回来。 最后，项目可能按时完成了。 管理者看到的是任务完成，却看不到背后有多少额外劳动被消耗掉。 而那个制造障碍的人，甚至不需要改变自己的工作方式。 你越努力兜底，系统就越不容易发现自己的问题。 因此，更现实的做法不是无限催促，也不是期待对方突然改变，而是重新划定自己的责任边界。 第一，不再额外贡献那些无人认可的劳动。 职责范围内的事情，认真完成；合理的协作，正常提供。但对于那些没有明确授权、没有合理回报，实际上是在替低效流程擦屁股的额外劳动，不再无条件承担。 不因为别人迟迟不回复，就一直保持待命状态；不因为审批迟迟不通过，就反复打断自己的工作；不为了掩盖流程的问题，长期透支自己的精力。 第二，不主动替组织承担它自己不愿意解决的低效成本。 既然某个关键节点必须等待，就把等待纳入正常的工作安排。能做其他事情，就做其他事情；条件具备了，再继续推进。 对方可以控制任务的放行时间，但不应该免费获得对你整个工作节奏的控制权。 不必故意拖延，不必报复，也不必制造无效工作。按照实际优先级安排任务，按照正常节奏完成职责范围内的工作即可。 如果组织因此发现吞吐量下降，那是实际运行结果，不需要你通过个人透支把它掩盖掉。 第三，不再把自己的工作热情建立在别人会公平协作的假设上。 你可以保持专业，但不必无限付出；你可以配合工作，但不必替别人承担所有后果；你可以希望组织变好，但不必把改变组织当成自己的私人使命。 如果组织长期容忍这种行为，就要接受一个现实：你未必有能力改变它，你能做的首先是保护自己的时间、精力和职业状态。 这不是消极怠工，而是停止一项长期没有回报、甚至会反过来伤害自己的补贴。 你不是要把自己变成一个低效率的人，而是拒绝继续做那个用个人效率掩盖组织低效率的人。 软件开发本来就是一项高度依赖协作的工作。 代码需要评审，变更需要合并，配置需要发布，问题需要排查。任何一个关键节点的低效，都可能沿着依赖关系传导，最后拖慢整个团队。 一个好的工程师，不仅要把自己的代码写好，也应该尽可能降低其他人的协作成本。 反过来，一个人即使技术不错，只要长期把权限当作特权，把别人的时间当作免费资源，把双重标准当作理所当然，他对团队造成的损害就可能远远超过他创造的价值。 而一个组织如果长期依赖少数认真负责的人，去补偿另一些掌握权限却不愿意配合的人，那么认真负责的人越努力，组织越不容易发现自己的问题。 直到这些人不再额外兜底，真实的系统效率才会显现出来。 技术能力决定一个人能完成什么，协作方式决定他能让多少人顺利完成工作。 软件公司最应该警惕的，不只是能力不足的人，而是那些拥有关键权限、能够改善协作，却持续选择把事情变得更麻烦的人。 因为低效率至少还可以通过技术和流程改进。 而一个从别人的低效率中获得控制感、又不需要为此付出代价的人，没有充分的理由主动改变。 真正需要改变的，最终是让这种行为长期有利可图的组织结构。
