← AI学习中心 / 项目与协作
项目启动会怎样梳理输入输出和责任
文中企业场景、人物与业务数字为教学示例，不是客户成果记录。
【直答】启动会要梳理的不是口号，而是一张输入—输出—责任表：每个交付物写清它依赖哪些上游输入、产出后交给谁、验收看什么、由哪一个人负责。会前把表填到能填的程度，会上逐行核对，缺口当场记为待确认项并指定补齐人，而不是留在口头。这样做的目的，是让每个与会者离开会议室时知道自己等什么、交什么、找谁。
【业务场景·合成演示】某企业官网改版项目，启动会前项目经理只在通知里写了目标是网站上线。会上设计问文案要栏目结构，文案问市场要品牌素材，开发问设计要视觉稿，两个小时反复确认的都是对方手里的东西，散会时没有任何一行被写下来。第二周同样的问题又被问了一遍，项目才真正开始排队等素材。
【具体做法】第一步，会前列出一级交付物清单，每个交付物拆成输入、输出、责任人三栏，先填已知项。第二步，输入栏必须写三个要素：来自谁、什么形式、什么时候要，写不出来源的输入就是第一号风险。第三步，输出栏写交给谁和验收标准，验收标准至少包含一个别人能检查的形态，例如确认稿、签字件、可运行版本。第四步，责任人只写一个具体的人，部门名不是责任人。第五步，开会时逐行读表，任何一栏空白或含糊，当场标待确认，写明谁去补、什么时候补齐。第六步，会后把这张表存成固定的模板文件放在项目共享区，下一个项目启动前先改表再定会。
【示例表·合成演示】官网改版项目启动会核对表：
| 交付物 | 上游输入 | 输出与验收 | 责任人 |
|---|---|---|---|
| 首页视觉稿 | 品牌色值与标识源文件，市场部提供，会前一周 | 确认稿一份，以客户书面回复为准，交开发 | 林晓（合成演示人名） |
| 栏目文案终稿 | 产品功能清单，产品组提供，启动会后三天 | 终稿文档一份，交设计排版 | 陈可（合成演示人名） |
| 上线验收单 | 测试问题清单清零的记录截图，测试组提供，上线前两天 | 签字版验收单一份，交客户方 | 周明（合成演示人名） |
【可复用空模板】
| 交付物 | 上游输入（来源、形式、时间） | 输出与验收标准 | 责任人 |
|---|---|---|---|
【反例·合成演示】另一个同类项目只写了设计负责视觉、开发负责实现，责任人栏填得很满，输入栏整列为空。开发到联调阶段才发现没人交过定稿视觉，返工挤占了自查时间。问题不出在人不负责，而出在表里根本没有输入栏，依赖关系全部隐含在大家的记忆里，谁也没义务主动想起来。
【常见疑问】问：某位责任人会上不愿确认输入时间怎么办。答：不现场争论，该项直接标待确认，写明答复期限和逾期后找谁升级，由项目负责人会后跟进。问：交付物太多、表太长怎么办。答：主表只保留一级交付物，二级细节放到各交付物的附件页，主表行数控制在一屏内，方便会上逐行过完。
【来源说明】本文模板与逐行核对的做法，受Google Workspace博客中把团队规则整理成参考文件并加以测试的思路启发（https://workspace.google.com/blog/product-announcements/teach-gemini-your-teams-know-hows-with-skills-in-google-workspace）。该来源描述的是规则模板参考文件与测试思路，不推断任何国内产品可用性；文中表格、场景与人名均为编辑设计的合成演示，未经实际运行验证，不声称任何省时或效果数字。
【收尾思考】回想你们最近一次项目启动会：哪一项交付物的上游输入，是直到卡住了才第一次被说清楚的？