如果你想拥抱异步工作，需从会议驱动转向任务驱动
Source: Dev.to
Summary
- 传统工作是会议驱动的：讨论和结论在会议中自发产生。
- 这看起来很容易，因为只要按计划进行（连小孩都能做到）。
- 会议驱动的方式不支持异步工作，因此需要新的模型。
- 采用任务驱动的方法：把所有工作和行动视为任务，通过系统进行管理，并更新任务页面。
- 许多人已经通过 GitHub Issues 熟悉这种形式。
背景
我们希望实现异步工作，但常常因为以会议为驱动的文化而未能落实。作为工程师，我们珍视在自己喜欢的环境中工作而不受打扰、没有办公室噪音或持续的喧闹的自由。偶尔的会议对于深入讨论是有价值的，但许多组织仍然回归到在办公室工作的模式，即使是那些声称支持远程工作的公司，也严重依赖线上会议。
为什么我们无法摆脱同步工作？罪魁祸首在于工作模式：我们是 meeting‑driven。
需要新的模型
Meeting‑driven 工作依赖会议来开展业务。它有两个主要特征：
- Spontaneous communication – 讨论和决策在会议现场即时进行。
- Passive execution – 工作遵循日历安排。
这类似于学校的课程表——你按时间表出席并跟随主持人的情绪。甚至孩子都能做到，因此这是一种极其简便的工作方式。然而，由于这种方式依赖会议，无法容纳异步工作。需要一次根本性的思维方式转变。
任务驱动方法
A task‑driven approach treats all work as tasks, manages them through a system, and aims to close them.
- 将所有工作（包括活动和操作）视为任务。
- 在允许异步访问的系统中管理任务（例如工作区）。
- 基于工单的格式，如 GitHub Issues，非常直接。
- 任务有“状态”，在关闭时视为完成。
If you’re familiar with GitHub Issues, this concept should feel natural—it’s essentially turning everything into an Issue.
任务驱动工作所需的技能
以会议为导向的工作强调沟通和用于协调会议的“社交”技能。
相比之下，任务驱动的工作需要强大的任务管理技能：
- 能够通过自我管理处理数十（甚至数百）个任务。
- 具备阅读和写作能力，以有效记录任务。
Before / After
Before
Morning schedule for Manager M (meeting‑driven):
- 9:00 – 检查聊天、邮件及其他通知
- 9:30 – 项目 P1 的每日会议
- 10:00 – 与 A 的一对一
- 10:30 – 会议 1
- 11:00 – 会议 2
- 11:30 – 工作
四个会议占满了 9:30 – 11:30 的时间段，每个会议提供 30 分钟的即兴讨论和决策窗口。虽然易于遵循，但日程缺乏弹性，安排和参加会议需要相当的精力。
After
Example of a task‑driven day:
- 9:30 – 项目 P1 的每日会议
Agenda (10 min): 分享昨天完成的工作以及今天的计划（参与者：A、B、C、D）。
Discussion (20 min): 提出议题，进行辩论并得出结论。
在任务驱动的方式中，同一个会议可以拆分为离散的任务：
- 任务：“发布今天的计划”
- 任务：“发布对议题 1 的意见”
- 任务：“对议题 1 达成结论”
- 任务：“发布对议题 2 的意见”
- 任务：“对议题 2 达成结论”
- …
这些任务可以在 GitHub Issues、维基、笔记或任何支持打开/关闭状态的独立页面的工具中进行管理。创意的表现形式（例如在标题中添加勾选框）同样可行。任务一旦进入系统后，可异步更新；也可以通过提及发送提醒。
在 After 场景中能完成工作吗？
答案： 是的。
如果你对此存疑，说明你仍然在以会议驱动的思维方式工作。任务驱动的工作依赖于自我管理和文档编写能力。熟练掌握 “After” 工作流至关重要——这些软技能常常被低估，即使是工程师、经理和高级员工也普遍存在不足。
这也是我发起 Soft Skills Engineering 的原因。