面向工程团队的项目启动会议程

启动会跳过的那个问题

一场进行顺利的项目启动会，会让团队就要构建什么、谁做什么、什么时候到期达成一致。这份一致通常能维持大约三周。然后范围开始蔓延，某个干系人改变了对某项核心假设的看法，一个依赖延误了，团队这才发现他们从未就"当两个讲道理的人意见相左时由谁拍板"达成过一致。

大多数启动会议程跳过的那个问题是：当出岔子时，这个团队将如何做决策？不是项目计划——而是决策框架。当某个功能需要被砍掉时，谁掌管范围？当一个技术约束使某项产品需求作废时，团队怎么办？当两个部门想要不同的东西时，哪个干系人有最终决定权？

这些问题在启动会上很容易回答，因为此时还没有什么利害关系。而到项目中途，当每个人都有了立场时，它们就难回答得多。下面的模板在困难部分开始之前为它们预留了时间。

议程（复制粘贴即可）

时长： 60–90 分钟，视项目复杂度而定
形式： 有人主持；所有关键干系人和贡献者到场，或在开始前异步审阅过

第一节 — 项目目标与范围（20 分钟）

用一句话陈述目标：成功看起来是什么样的结果，尽可能可衡量
范围之内：项目将交付什么，要具体点名
范围之外：这个项目明确将不做什么——至少列出三件事
成功标准：团队如何知道项目做完了？
工程经理或产品经理掌管这一节；如果所述范围与可行性不匹配，工程师要提出异议

第二节 — 角色与归属（15 分钟）

对每条工作流，指定一名负责人——不是一个团队，而是一个人
谁对以下事项做最终决定：产品范围、技术架构、对外沟通？
在每类重大决策上，谁是被告知方、谁是被咨询方、谁是决策人？
指定那位在其他一切都不清楚时负最终责任的项目负责人

第三节 — 约束与风险（15 分钟）

硬性约束：截止日期、预算、合规、对其他团队的依赖
已知风险：可能让这个项目脱轨的头三件事是什么？
对每个风险：可能性、影响，以及缓解措施的负责人
什么会导致项目被取消或大幅缩减范围？现在就点明它

第四节 — 沟通计划（10 分钟）

团队多久同步一次？以什么形式？
谁会收到状态更新，怎么收到？别假设干系人都想要同一个渠道
项目文档存放在哪里？
如果有什么阻塞了项目，升级路径是什么？

第五节 — 悬而未决的问题（15 分钟）

列出团队今天回答不了的每一个问题
对每个：指派一名负责人，以及一个需要拿到答案的日期
没有日期和负责人的问题，到项目过半时仍会是悬而未决的

第六节 — 后续步骤（10 分钟）

为了开始真正的工作，未来五个工作日内必须发生的三件事
每个后续步骤都有唯一的负责人
确认启动会回顾将如何分发、发给谁

为什么值得把启动会笔记做好

启动会文档是任何项目中被引用最频繁的产物。当范围出现争议时、当有新成员加入时、当干系人问"我们在启动会上不是决定了 X 吗？"时，人们查的就是它。一份文档完备的启动会，就是一个更容易管理的项目。

Pavleur 会自动捕捉完整的启动会：按陈述记录范围、按分派记录角色、按点名记录风险、带负责人的悬而未决问题、带负责人和日期的后续步骤。如果有人在会议中途共享了项目简报、一张图示或一份需求文档，那份视觉内容会连同讨论一并写进报告。纯音频工具给你的是谁说了什么；当技术负责人描述那个依赖时，它们捕捉不到屏幕上的架构图。由此产生的报告从第一天起就充当项目的唯一事实来源文档。想了解这与传统会议记录工具相比如何：Pavleur 与替代方案对比。

关于出席的一点说明

每一个被期望在这个项目上做决策的人都应当出席启动会，或在工作开始前审阅完整的录像和书面摘要。一个错过启动会、两周后才非正式地得知范围的干系人，就是一场蓄势待发的项目中途范围争议。启动会的职责是构建共享的背景，而共享的背景只有在相关人员都在场时才存在。