• 时间:
  • 分类: AI创业
  • 标签: None
  • 阅读(236)
  • 👍推荐(4)
  • 评论(0)

1944 年，美国中央情报局 (CIA) 前身的战略情报局 (OSS) 编写了一本《简单破坏现场手册 (Simple Sabotage Field Manual)》，用以协助海外官员在挪威和法国等被占领国家培训「公民破坏分子」。

手册中为潜伏者列出了一些破坏当地公司生产力的方法，其中一些建议至今仍不过时。比如关于「干扰组织和生产」的部分：

  • 坚持所有事情都要走「正规渠道」，绝不允许为了加快决策速度而走捷径。
  • 尽可能频繁且冗长地发表「演讲」，用长篇故事和个人经历来说明你的「观点」，别忘了加几句「爱国」评论。
  • 把所有事情提交给委员会「进一步研究和考虑」，并试着让委员会尽可能臃肿，至少 5 人以上。
  • 尽可能频繁地提出不相关的问题。
  • 对通信、会议记录、决议的措辞斤斤计较。
  • 回顾上次会议已决定的事项，并试图重新讨论这些决定的可行性。
  • 提倡「谨慎」，保持「理智」，并敦促同事们避免可能导致尴尬或困难的匆忙行动。
  • 担心任何决定的适当性——质疑这些行动是否在小组的管辖范围内，或者是否可能与上级政策相冲突。

现在，假设你受雇为一家互联网/AI 创业公司的 CTO，想在不被发现的情况下尽可能长时间地破坏这家公司的生产力。你不能做出一系列明显的错误决定，因为这样很快就会被解雇。我们真正的目标是慢慢地削弱公司的生产力，同时保持表面上的合理和正常。

你需要怎么做？

01 技术：让技术开发尽可能复杂

  • 加入公司时，要求用 6-18 个月的时间重写核心系统，并把责任推给前任 CTO。
    鼓励每个人使用自己喜欢的语言和框架。
  • 将系统任意分割为多部分，涉及特定功能的系统越多越好。
  • 鼓励复杂的开发设置：至少运行一个有十几个服务的服务网格。
  • 确保生产环境与开发者环境尽可能不同。
  • 尽可能少地发号施令，主张对决策保持极端谨慎，利用任何生产问题作为「刹车」的理由。
  • 为代码变更和常见工作流引入非常复杂的流程，并归咎于「安全」或「合规」。
  • 确保每个任务都在系统中被跟进，并经过至少 5 人的审查、优先排序和签字。
  • 禁止任何超出原任务范围的事项，例如代码清理或其他偶发性改进。
  • 内部开发所有非核心竞争力的东西，并以「避免供应商锁定」为理由。
  • 坚持在所有事物上添加抽象层，使用本身就抽象的供应商，然后再添加额外的抽象层。
  • 鼓励基于极乐观的扩展预期做出技术决策，计划至少比现有负载高出三个数量级。
  • 鼓励系统的共同所有权，确保没人对维护负责。
  • 坚持将几乎所有系统和功能都集中化为「平台」，由专门的平台团队负责。让平台团队人手不足，阻止其他团队开发任何可能属于平台的东西。
  • 让平台团队频繁迭代 API，并要求其他团队尽可能频繁地重构代码以适应最新版本。
  • 雇用「架构师」，要求任何大小变更都要进行「架构审查」。
  • 要求即便是小变更也要进行「安全审查」。

02 产品：主推大战略、大规划

  • 以学术理由（例如「有偏」或「滞后指标」）忽略有用的指标。
  • 选择与业务价值相关性低且噪声大的虚假指标。
  • 坚持将任何举动都当作「大赌注」，坚持把所有工作做完才上线产品。
  • 认为每个功能都是「必备」的，并且是「版本零（首个版本）」的关键部分。绝不妥协。
  • 制定极其详细的「战略」计划。
  • 频繁转向。
  • 将明显的改进视为「局部优化」。
  • 利用最新趋势来占据资源。启动一个看似合理但空洞的「AI 战略」，在这些方面花大钱请供应商和顾问。
  • 鼓励产品经理将大部分时间花在「战略」和「规划」上。
  • 让工程师和产品经理很难/无法在内部使用产品。
  • 在部门内部把用户视为「愚蠢的」。

03 领导层：让汇报关系尽可能复杂

  • 将薪酬与头衔挂钩，并将头衔与团队规模挂钩，以激励团队膨胀。
  • 大谈策略、功能或技术复杂性。
  • 进行昂贵的收购以进入新产品领域，并以「协同效应」为由，关闭收购的产品。
  • 在汇报结构中使用大量虚线，让汇报关系尽量复杂。
  • 尽可能让员工向其他团队、地点或职能部门的经理汇报。确保经理没有能力监督他们的下属。
  • 频繁将表现不佳的员工重新分配到其他团队。
  • 将高业绩员工分配到投机性高且交付成果不明确的研发项目上。
  • 任何决策都要开会，无论决策内容多么微不足道。
  • 坚持每个「利益相关者」都要出席会议。

04 招聘：尽量把合适的人排除在外

  • 创建一个看似客观但实际上主观的招聘流程。
  • 以「文化不适」或其他模糊标准为由拒绝最好的人。
  • 根据「潜力」或「态度」或其他模糊标准雇用最弱的候选人。
  • 招募非常贵的高级领导，并对其承诺大量的人员编制。
  • 使用夸大的头衔和虚构的职位来吸引机会主义者。
  • 雇用高度专业化的「专家」，搞点无关紧要的项目来防止他们辞职。
  • 以专业化为借口，雇用更多专业「互补」的人。

05 项目管理： 尽量跨部门合作

  • 要求对任何项目进行非常详细的财务预算。
  • 鼓励尽可能多的团队参与项目，最好在不同地点。
  • 添加仰赖于其他团队工作的新需求。
  • 频繁使用昂贵的代理机构，让项目范围模糊，并将未完成的原型交给内部团队完成。
  • 为其他团队中的利益相关者构建复杂的「自助」系统。

执行这些破坏任务并不容易！但如果你能进入竞争对手的战线后方，得到 CTO 的职位，就能实现这些目标。

对于非破坏者（真正的创业者）来说：显然，这其实是在讲如何最大化团队的产出。生产力的问题通常是由无数小问题累积而成，这些小问题本身并不会毁掉生产力。但是，生产力是按对数尺度增长的，也就是说，所有这些问题会以乘法的方式复合累积。基本上，如果你做了 100 件事，每件事都让生产力降低 5%，你就把整体效率减慢了 131 倍！唯一能让工程师们满意的方法，就是拒绝那些看起来合理但实际上有害的 100 个小问题，让团队尽可能的专注和高效。

原文：https://erikbern.com/2023/12/13/simple-sabotage-for-software.html