在像Anthropic这样的公司，卓越的项目管理是一项极具杠杆效应的技能，而且不仅限于危机时刻：我们的工作有着大量的活动部件，它们之间存在复杂且不明显的相互依赖关系和严格的时间限制，这意味着组织这些工作本身就是一项巨大的任务，如果做得好，可以节省数周的延误。

尽管这里的许多例子来自危机项目，但我尝试管理任何项目时，大多数原则都是相通的，只是程度不同。

我认为卓越的项目管理也比实际需要的更为罕见。

在危机项目期间，我并不觉得自己做了什么特别令人印象深刻的事情；主要感觉是付出了很多工作，但做的事情相对直接。另一方面，我经常看到其他人错过做这些事情的机会，也许是因为缺乏见过好的操作手册。

所以这是我尝试描述我在项目管理方面较为强硬时的操作手册。

（我上面将我所做的描述为"协调"，但这有点低估了；对于这个操作手册来说，重要的是我有足够的技术背景和组织信任，可以自主做出关于项目的大多数优先级决策。有时我们会尝试让受信任的决策者不要过多参与管理执行工作，而是将其外包给上下文较少或不太受信任的项目经理，以节省受信任决策者的时间，但在我看来，对于那些至关重要的需要良好执行的项目，这通常是一种虚假的经济效益。）

专注

对于每个危机管理项目，我完全清空了日程安排以专注于它们，最终每天花6+小时组织这些项目。

这有点反直觉，因为我习惯于认为信息处理基本上是免费的行动。毕竟，你"只是"在将信息从一个地方移动到另一个地方，而不是做像编码这样的实际工作，对吧？

但如果你把所有事情加起来——主持会议、询问更新、消化Slack线程、再次询问更新、思考接下来的步骤、第三次询问更新等——这些确实非常耗时。

比腾出时间更重要的是，清空日程确保了项目成为我思想中的最重要想法。如果不这样做，我很容易让项目"自动运行"，我只是让它们继续进行，却不主动花时间思考像是否应该改变目标、增加或放弃优先事项或做其他"不明显"的事情。

对于非危机项目，每天花6+小时进行项目管理通常是不可行的（或者不是正确的优先次序）；但事实仍然是，如果你集中精力并将其作为头等优先事项，你可以极大地改善执行情况，例如，每天专门留出时间检查状态、思考优先事项、广播更新等。

维持详细的计划

我发现对于保持方向感和快速更新至关重要的一个具体工具是详细的计划，即一个尽可能具体的步骤列表，以目标实现结束。

计划很重要，因为我们是否实现计划是了解事情进展如何的最佳方式。了解事情进展如何很重要，因为它告诉我什么时候该开始寻求更多支持、缩减范围、上报问题以及发出更多警报。

大型项目最常见的失败模式之一是没有足够早地提出警报，而拥有具体计划是最好的解决方案。

作为一个正反两面的例子，在最近一次发布新模型实现的冲刺中，我们详细盘点了所有我们认为必须完成的工作。

从积极方面来看，这让我们在发布前三个月就清楚地知道时间会非常紧张，这使我们能够向另一个团队寻求帮助，他们借给了我们一个人，这大大加快了项目进度。
从消极方面来看，我们也严重低估了项目的几个组成部分，因此我们在最后仍然面临很大压力。

如上例所示，有计划并不能完全拯救你，如果你低估了计划中所有步骤所需的时间。

但它肯定有帮助！我感觉在上述情况下，更有帮助的主要事情是：

我们在估计任务时缺乏经验，特别是与新模型实现相关的任务（大多数团队成员太新，以前没有做过），我们太胆小，没有在计划中添加必要的"松弛度"。
一旦制定了计划，我们没有足够频繁地检查进度，或者在偏离计划时没有足够早地发出警报。

运行快速的OODA循环

OODA代表"观察、判断、决策、行动"——换句话说，就是根据新信息更新计划和行为的过程。

我参与过的大多数大型项目都以信息不完整为特征：

我们的集群网络出现问题，但我们不了解原因。
我们有一个正确性错误，但我们不知道在哪里。
我们需要重写系统，但我们不完全确定重写应该是什么样子。

事实上，我想做一个更强的断言：通常获取完整信息就是项目的难点，消耗了整体关键路径时间表的相当大一部分。

例如，以最近一个启动训练运行的项目为例。关键路径可能是这样的：

训练运行所需的芯片已交付
我们运行一些测试
我们发现性能的一个方面出乎意料地差
我们向计算合作伙伴上报问题
计算合作伙伴组织大规模调试工作
我们意识到我们给计算合作伙伴的是过时的基准测试，导致他们针对错误的改进方向
计算合作伙伴更换基准测试并优先考虑不同的改进
我们与计算合作伙伴共享基准，让他们运行与我们完全相同的代码
计算合作伙伴推出改进
我们测试改进
性能仍然不佳，我们告诉他们这一点
重复步骤8-10，直到最终足够好

实际上，这些步骤都是关于信息处理，而不是编写代码！即使是计算合作伙伴在他们那边调试问题的步骤本身也受到信息处理速度的限制，因为有数十人在调试工作上协作，在他们之间协调/共享信息很困难。

总的来说，项目时间表严重受限于信息在我们计算合作伙伴的大规模调试工作、通过他们的技术负责人、我以及Anthropic的大规模调试工作之间往返的速度。

这种模式适用于我参与的大多数项目，因此，我最有效的项目管理习惯之一是尝试运行尽可能快的OODA循环。

我发现有几件具体的事情有帮助：

**花时间在上面：**运行OODA循环需要时间，这是我上面提到的，如果项目处于危机模式，我通常每天花6+小时来管理大型项目的主要原因之一。
**不舒服地多沟通：**对于训练运行调试，为了尽可能减少组织之间的往返时间，我每天与计算合作伙伴的对应人员进行多次通话（上午9点和下午6点）。对于模型实现工作，我基本上不断地在不同的调试组之间来回跳跃，询问更新并处理这些更新。
**跟踪并优先考虑最大的未解决问题：**对于大多数大型项目，我维护一个包含所有关于项目最大的未解决问题排名列表的实时文档。解决或降低这些不确定性基本上变成了项目的优先级列表。理想情况下，有足够多的人在项目上工作，我们可以并行解决多个不确定性，因为这是加快速度的最佳方式之一。（对于"危机模式"下的项目，如果我们的顶级优先事项比目前参与问题解决的人员能并行处理的还多，那也是决定是否引入更多人员的好测试。）
**经常退一步重新判断：**除了询问更新外，我花时间最多的就是重新判断——查看我们的优先级列表，问自己它们是否仍应该是顶级优先事项，然后查看人们在做什么，确保这些事情在攻击顶级优先事项。我可能每天多次回顾项目的优先事项，尽管我经常不会因此而做出改变。
- （请注意，过于频繁地改变人们的工作内容是可能的，因为切换任务是有代价的。如上所述，并行处理前几个优先事项会有所帮助，因为如果你决定优先级#3现在是#1，但每个上面都有2个人在工作，那么没有人需要切换任务。真正会杀了你的是当没有人在新的优先级#1上工作。）

过度沟通

仅仅让我个人运行快速的OODA循环是不够的——在一个大型团队中，每个人都需要自主地做出频繁、高质量的局部优先级决策，而不需要通过我来回传递。为了达到这一点，他们需要环境意识到：

他们周围发生的其他事情，这样他们可以协调并根据新信息快速更新（"哦，我们计划在三天内开始下一次降低风险的运行，所以我必须准备好我的新强化学习环境并进行测试"）
他们的目标如何融入整个项目，这样他们可以对他们的方法细节做出正确的决定（"我们现在正尝试尽可能扩大规模，所以这个方向不值得追求，因为它永远不能提供我们需要的数据规模"）

我通常发现，为了创造正确水平的环境意识，我必须比我直觉上期望的重复相同的事情更多次。

这大致上是上面相同的"不舒服地多沟通"原则，但应用于广播而不仅仅是一对一对话。

例如，虽然我在Anthropic管理的第一个团队最初每天进行一次异步站会，但我们发现同步会议对于创建共同知识和重新定向更有效，所以我们改为每周两次同步站会，这在当时的Anthropic可能算是"不舒服地多"的同步沟通。

拆分为子项目

一旦一个项目超过10人左右，我就无法自己以足够详细的方式跟踪所有内容来管理整个项目。此时，委托变得至关重要。

这里我指的是委托项目管理，而不仅仅是执行（那是我要委托给前10个人的）。这是我需要其他人帮助分配工作、监控和沟通进度、上报阻碍等的时刻。

委托项目管理时，我尝试记住几点：

委托的理想单位是一个清晰、简单、高层次的目标，与其他工作流重叠有限。（这与例如任务列表如"看看X是否有帮助"不同。）好的例子："在Y网络协议上以Z吞吐量实现X训练技术"，"在模型实现A和B之间获得相同的评估"。坏例子："遵循这个10步清单，我们希望这会导致训练成功"，"尝试这3种技术来调试损失评估"。
最好的项目经理通常不是最强的技术个人贡献者（IC）。相反，最重要的特质是他们高度有组织性，擅长集中注意力于最终目标，甚至可能为此而令人讨厌。IC深度有帮助，我永远不会拒绝它，但这不是我最优化的方面。
运行子项目的人可能也在做很多我做的相同事情，特别是花很多时间在上面。这意味着他们的IC生产力会受到很大影响。这是预期的，通常是值得的。"方向比大小更重要"——通常一个低速度但工作在正确事情上的项目，比高速度但指向错误目标的项目要好。

我最喜欢让委托更容易的一件事是保持目标简单——如果它们可以在一条Slack消息中适应，同时仍然清晰地描述达到所需最终状态的路径，那么在目标上工作的人将能够更自主地确定优先级，并将他们的工作指向真正的最终目标，而不是因为他们没有想到的原因做一些最终无用的事情。

"保持目标简单"并不一定意味着"做得更少"——保持目标简单的最佳方式是找到能够实现干净递归分解为子目标的潜在结构。这通常需要欺骗性地大量工作——认知和动手键盘——来确定正确的中间目标，但我发现通过澄清什么是重要的工作，这极大地回报了。

享受过程

我在Anthropic的一些最喜欢的回忆是帮助这些大型项目。

虽然它们可能很激烈，但看到我们的团队如何团结起来也真的很鼓舞人心，成为一个由真正优秀的人组成的大团队的一部分，一起做一些雄心勃勃的事情的感觉可能真的很神奇！所以我尝试享受这种混乱 :)

附录：项目负责人入门工具包

这是我与团队中开始负责大型项目的人分享的内部文档。

所以你是一个项目的直接负责人（DRI）（或其中一部分）。具体来说，你做什么来"成为DRI"？

本文档是我对该问题的建议"入门工具包"答案。这里描述的习惯和仪式并不适合每种情况，但它们轻量级且普遍有帮助。我建议你将它们作为迭代的起点：试一试，然后根据需要调整。这是一个监督学习初始化；强化学习是你的工作 :)

本指南的目标

目标是帮助你完成DRI的工作——

让你的项目快速进行：
- 参与者深入理解根本目标，可以自主选择最重要的下一步工作
- 人们对其他人正在做什么有"情境意识"，快速了解相关更新，并在需要时快速协调
- 人们能迅速获得他们工作的反馈
- 如果进展不够快，你（DRI）可以快速注意到并纠正方向
"与其他人良好合作："
- 观察者可以知道去哪里跟进
- 相邻或交叉的人/项目不会错过重要更新或受到意外惊讶
- 如果项目落后或偏离轨道，人们会快速注意到，并能识别提供帮助的机会

——而不增加太多开销：

<1小时的设置来制作工作文档、安排每周会议等
每周30分钟的会议
每周15-30分钟写更新

（注：成为DRI仍然不可避免地会增加一些开销——例如，你必须跟踪其他人在做什么，委派工作，解除人们的阻碍，设定和沟通目标等。目标特别是流程/文书工作要最小化。）

每周会议

你应该安排至少一个30分钟的每周会议，所有在项目上工作的人都参加。

这个会议的目标是(1)作为任何需要进行但未异步进行的协调的后盾；(2)高效地创建目标、更新等的共同知识；(3)帮助你跟踪事情是否进展顺利。

入门工具包议程：
- [5分钟] DRI回顾上周的主要更新并设定下周目标
- [10分钟] 静默写作和评论讨论主题
- [10分钟] 同步讨论静默写作期间未解决的最重要事项
可能需要更多会议的迹象（例如，第二个每周站会）：
- 你有一个非常紧迫的截止日期，不能浪费时间
- 人们没有在做最重要的事情
- 人们需要频繁反馈
- 人们互相妨碍或错过互相帮助的机会
- 如果你们只是喜欢在一起 :)

项目主页/工作文档

有一个包含项目所有最重要信息的单一"主文档"对于可发现性和导航非常有帮助。当你让更多人参与时，他们可以阅读该文档以了解情况。任何想"我想知道X进展如何"的人都可以在那里找到。

为你的工作流创建一个文档，包含：

名称中的go/链接（如果是子项目，可能使用go/project/subproject）
- → 这使其更容易快速找到（搜索有点困难）
清晰描述具体的顶级目标以及它如何融入更广泛的目标
- → 这对参与者来说是关键信息，这样他们可以自主确定最重要的事情的优先级；对观察者来说，这样他们就知道期望什么结果。
**人员配置：**在项目上工作的人员列表，你作为DRI的名字，以及用于讨论的slack频道链接
**链接：**顶部相关链接的简短列表（工作跟踪器、项目的Slack频道、主要设计文档等）。如果需要，后面有一个更长的"文档/参见"部分链接到相关文档。
- → 否则真的很容易丢失相关文档！
带有中间目标和目标日期的路线图部分
- → 参见计划部分；这些将帮助人们理解项目的整体形状预期是什么。
"运行笔记"部分，包含每周会议（和任何其他临时会议）的会议记录和广播更新
- → 这真的有助于观察者和新加入者快速了解情况！
我喜欢维护一个重要开放问题/不确定性/风险列表并随时间更新。这帮助我保持专注于尽快从项目中消除风险。

如果它是更大项目的一部分，你的文档应该嵌套在更大项目的工作文档中。

如果这对一个文档来说太多，你可以将这些分成子文档（特别是运行笔记和更新）。

计划/路线图/里程碑

在你的工作文档中，包括一个部分，其中有一些中间目标和你希望完成它们的日期。
- → 这主要有助于注意到你偏离轨道或落后，而不会被不知不觉地影响。
- → 或者当中间目标看起来不再好时，注意到你需要做出方向改变。
你可能会感受到一些添加虚假确定性或精确性的压力，但避免这种情况，对你的不确定性坦诚相待。对于许多研究项目，很难提前计划超过几周。你可以使超过这个时间的里程碑更模糊/更有抱负，或者干脆放弃它们。
- 我经常发现用概率和分布来表达里程碑很有帮助（例如"我对这个日期的90%置信区间是X-Y"或"我认为这种技术有75%的几率成功"）

谁在做什么

你应该在某处有描述人们在做什么的内容。
这个的最小可行版本是在你的工作文档中列出人们在做什么。
- 如果你最终有一组大型任务和大量积压工作，可能使用清单和/或移至子文档。
**对你的工作列表进行堆栈排名。**让人们了解优先级非常重要！
如果有更多不同的人/待办事项，我建议使用一些应用程序制作一个看板，包含"积压"/"即将开始"/"进行中"/"完成"列。
- 这可能对更确定性/可计划的项目最有帮助，这些项目有明确的积压工作+一系列未来任务，以及许多你需要记住做的事情。
如果你有一个外部任务跟踪器，在工作文档的wiki部分链接它。

Slack使用规范

在Slack频道（而不是私信）中进行关于项目的对话。
- 在你的工作文档中引用该频道。
- 在Slack频道书签中链接工作文档。
将笔记本文章和实验撰写交叉发布到频道中，这样观察者就不必关注大量笔记本频道。
**不要使用私信。**这些使信息难以被发现或进一步共享。
- 如果人们在私信中向你发送重要内容，请要求他们将其放在项目频道中。
- 如果你需要保密，创建一个私有频道。
**避免百条线程。**大多数≥10条消息的Slack线程如果改为~5分钟的Tuple会更好。
- （对于像高管这样参加大量会议的人来说，这很难做到。但你应该尝试为其他人这样做。）
- 如果你最终有一个百条线程，假设没有人会阅读它；之后将摘要发回频道。
偏向更少、更大、更嘈杂的频道。创建频道的正确时机是当讨论要么没有发生，要么正在丢失。
- → 太多Slack频道使管理成员资格、决定在哪里放置内容或找到讨论发生的地方变得更加困难。
频道组织和成员资格很重要。投入精力将对话路由到正确的地方并策划频道"架构"。

每周广播更新

每周一次，可能是在每周会议之前或之后，为更广泛的受众写一个简短更新，包括：
- 整体氛围
- 自上次更新以来的变化
- 接下来要做什么
写这些更新时，优化信噪比。
- 偏向简洁
- 不要说"我们致力于X"——告诉我"我们完成了Y"或"我们学到了Z"
- 记住你的受众（=不熟悉项目的人）
- 清晰具体地陈述事情（"X将评估Y提高Z点"，而不是"我们让X工作"）
- 省略任何不可操作的内容——你不需要详尽无遗
在你的项目Slack频道发布更新，并在必要时交叉发布到其他相关频道（例如更大的"大型项目"频道）。
- 如果你的项目是更大项目的一部分，这些更新可能会纳入更广泛的内容，如DRI的每周会议或汇总状态更新。

回顾会议

偶尔退一步问"过去X周可以如何做得更好？"
- 频率取决于正在发生的事情多少——如果有很多，每2周一次很好，对于较小的项目可能每4-8周一次
建议的会议格式
- 周五下午
- [13分钟] 异步头脑风暴2个项目列表："做得好的"/"我们可以改进的"
- [2分钟] 删除重复主题并通过在你同意的主题旁边放:heavy_plus_sign:进行表情投票
- 根据最高票数对"我们可以改进的"排序
- [10分钟] 同步讨论顶部要点（最高票或DRI标记的）；确定行动项目

感谢Kelley Rivoire对草稿的许多深思熟虑的评论！

Anthropic产品经理：我是如何管理项目的？

目录

专注