项目发起人的分工，核心是把“为什么做、做到什么程度、谁有权拍板”与“怎么做、谁执行、谁验收”分开。发起人保留立项理由、目标与成功标准、资源承诺和重大决策权，项目经理、业务负责人、职能经理与治理机构分别承接执行、需求验收、资源供给和阶段评审。本文面向单项目，从立项到验收说明职责边界、协作节点与记录方式。
要点总览（TL;DR）
- 发起人的分工核心是保留四类职责：立项理由、目标与成功标准、资源承诺、重大变更与终止决策；计划执行交给项目经理，需求验收交给业务负责人，人员供给交给职能经理，阶段评审交给治理机构。
- 用一张角色职责表把每项活动的负责、参与、审批、知会写清楚，同一行出现两个“负责”时拆成两个活动，避免执行中互相等待或重复决策。
- 按立项、规划、执行、验收四个节点安排分工，每个节点明确输入、动作、输出和完成标志，角色是否到位在节点上就能检查出来。
- 变更走统一入口：提出方提交说明，项目经理评估影响，发起人决策，重大变更经治理机构审批，结论书面记录并知会相关角色。
- 分工是否落地看记录：负责人唯一、目标有基线、变更与验收有书面结论、交接有确认动作，缺一项就按问题类型整改后复核。
先划清发起人与其他角色的职责边界
发起人最容易出现的两种偏差，一是把项目接过来自己盯进度、改方案，二是批完立项就消失，等到出问题才被拉回来。要避免这两种情况，可以按三条线划分责任：决策权归谁、交付责任归谁、资源责任归谁。三条线分开之后，每个角色的动作就有明确归属，不必靠开会临时协调。
发起人保留的职责集中在四件事上：说明立项理由，即这个项目为什么值得投入；确定目标与成功标准，即做到什么程度算成功；做出资源承诺，即为项目争取并确认所需的人、预算和其他投入；对重大变更与终止做决策，即当项目偏离目标或外部条件变化时，由发起人决定继续、调整还是停止。这四项都属于方向性和授权性判断，发起人不宜把它们委托出去。
其余职责由对应角色承接。项目经理承接计划编制、执行推进、风险跟踪与沟通协调，对“按计划交付”负责；业务负责人承接需求确认与验收，对“交付的东西是否解决业务问题”负责；职能经理承接人员投入与专业资源供给，对“派什么人、什么时间到位、专业质量如何”负责；治理机构承接阶段评审与重大变更审批，对“项目是否继续获得授权”负责。角色数量可按组织规模增减，但决策、交付、资源三类责任需要有明确归属。
把上述划分固化成一张角色职责表，是让分工可执行的第一步。表格按活动逐行列出，每行标注负责、参与、审批、知会四类责任，并写明交付物。下表是一个单项目的最小示例，读者可据此增删活动。
| 活动 | 发起人 | 项目经理 | 业务负责人 | 职能经理 | 治理机构 | 交付物 |
|---|---|---|---|---|---|---|
| 提出立项理由与目标 | 负责 | 参与 | 参与 | 知会 | 审批 | 立项说明、目标与成功标准 |
| 编制项目计划 | 知会 | 负责 | 参与 | 参与 | 知会 | 项目计划 |
| 确认资源投入 | 负责 | 参与 | 知会 | 负责 | 知会 | 资源承诺记录 |
| 需求确认 | 知会 | 参与 | 负责 | 参与 | 知会 | 需求说明 |
| 执行跟踪与风险处理 | 知会 | 负责 | 参与 | 参与 | 知会 | 状态报告、风险登记 |
| 重大变更决策 | 负责 | 参与 | 参与 | 知会 | 审批 | 变更决策记录 |
| 成果验收 | 审批 | 参与 | 负责 | 知会 | 知会 | 验收结论 |
| 项目关闭 | 负责 | 负责 | 参与 | 知会 | 知会 | 结项报告 |
这张表的价值在于把“谁说了算”和“谁干活”分开写清楚。同一行里出现两个“负责”时，需要进一步拆成两个活动，否则执行中必然出现互相等待或重复决策。
按立项、规划、执行、验收四步落实分工
职责表解决角色维度的问题，项目推进还需要时间维度的安排。把分工挂到立项、规划、执行、验收四个节点上，每个节点明确输入、动作、输出和完成标志，角色是否到位就能在节点上被检查出来，而不是等到项目结束再复盘。
立项：把目标和授权定下来
输入是业务需求或问题描述。发起人据此编写立项说明，写清项目背景、预期收益、目标与成功标准、初步资源需求和主要风险；治理机构组织评审，判断项目是否值得投入、目标是否可衡量。输出是批准结论与目标基线，完成标志是目标与成功标准经过确认并可被后续验收引用。这一步如果目标写得含糊，后面验收时业务负责人和发起人都缺少判断依据。
规划：把资源和路径确认下来
输入是已批准的目标基线。项目经理编制项目计划，包括范围、里程碑、任务分解、资源需求和风险应对；职能经理确认可投入的人员与专业支持；发起人对资源承诺做确认，对超出原立项范围的资源需求决定是否提交治理机构。输出是经确认的项目计划与资源承诺记录，完成标志是计划中的每个关键任务都有负责人，资源到位时间与里程碑对得上。
执行：把跟踪和决策分开
输入是确认后的计划。项目经理按计划推进，跟踪进度、处理风险、组织沟通，定期输出状态报告；遇到超出授权范围的变更，例如范围扩大、预算追加、关键里程碑推迟，由项目经理提交变更说明，发起人做决策，重大变更按治理规则提交审批。输出是执行状态记录与变更决策记录，完成标志是每项变更都有明确的决策结论和责任人，未决事项有跟踪条目。
验收：把成果确认和目标确认分开
输入是交付成果与目标基线。业务负责人对照需求说明确认成果是否满足业务使用要求，出具验收结论；发起人对照目标与成功标准确认项目目标是否达成，决定关闭项目或转入后续阶段。输出是验收结论与结项报告，完成标志是验收意见书面留存，遗留问题有明确承接人。
| 阶段 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 立项 | 业务需求或问题描述 | 发起人编写立项说明，治理机构评审 | 批准结论、目标基线 | 目标与成功标准经确认 |
| 规划 | 目标基线 | 项目经理编计划，职能经理确认资源，发起人确认承诺 | 项目计划、资源承诺记录 | 关键任务均有负责人 |
| 执行 | 确认后的计划 | 项目经理跟踪推进，发起人决策超授权变更 | 状态报告、变更决策记录 | 变更均有结论和责任人 |
| 验收 | 交付成果、目标基线 | 业务负责人验收，发起人确认目标达成 | 验收结论、结项报告 | 验收意见书面留存 |
角色及交付物：谁在什么时点交什么
职责重叠往往源于交付物不清：两个人都在写需求，或者变更批了却没有记录。把每个角色的交付物和提交时点列出来，交接时按物核对，比口头确认更可靠。
| 角色 | 交付物 | 提交时点 | 确认方式 |
|---|---|---|---|
| 发起人 | 立项说明、目标与成功标准 | 立项评审前 | 治理机构评审通过 |
| 发起人 | 资源承诺书 | 规划阶段结束前 | 与项目经理、职能经理共同确认 |
| 发起人 | 重大变更决策记录 | 变更提出后约定时限内 | 书面决策并知会相关角色 |
| 项目经理 | 项目计划、风险登记 | 规划阶段 | 发起人确认、职能经理确认资源 |
| 项目经理 | 状态报告 | 按约定周期 | 发送发起人与业务负责人 |
| 项目经理 | 结项报告 | 验收完成后 | 发起人确认关闭 |
| 业务负责人 | 需求说明 | 规划阶段 | 与项目经理确认范围 |
| 业务负责人 | 验收结论 | 验收节点 | 书面签署并附遗留问题 |
| 职能经理 | 人员投入承诺 | 规划阶段 | 与项目经理确认到岗时间 |
| 职能经理 | 专业评审意见 | 关键交付物完成时 | 纳入交付物评审记录 |
| 治理机构 | 评审结论、变更审批记录 | 阶段评审与重大变更时 | 形成会议或审批记录 |
交接时点需要与项目节奏匹配。立项说明在评审前提交，资源承诺在计划定稿前确认，验收结论在关闭项目前签署。每个交接动作留一个确认痕迹，例如评审记录、确认邮件或系统中的审批状态，后续出现争议时可以回溯到具体时点和具体人。
示例：一个立项到验收的分工场景
以下为一个内部系统建设项目的演示情景，用于说明分工如何运行，不代表真实客户案例。
某部门提出建设一套内部审批系统，减少纸质流转。立项阶段，发起人（部门分管负责人）编写立项说明，写明业务痛点是审批周期长、纸质单据难追溯，目标定为“上线后三个月内，主要审批事项线上化率达到约定比例，平均审批时长较现状缩短”，并列出所需开发人员与预算。治理机构评审后批准立项，目标基线确定。此时项目经理尚未介入执行细节，业务负责人开始梳理具体审批事项。
规划阶段，项目经理编制计划，拆出流程配置、系统开发、数据迁移、培训上线四个里程碑，提出需要两名开发和一名实施人员。职能经理确认人员可投入时间，发起人确认资源承诺，计划定稿。业务负责人提交需求说明，与项目经理确认范围边界，明确哪些审批事项首期上线、哪些后续扩展。
执行阶段，项目经理按周跟踪进度，风险登记中记录“数据迁移依赖旧系统接口开放时间”一项，并推动相关方解决。中途业务部门提出增加移动端审批，超出原立项范围。项目经理整理变更说明，评估工期和资源影响；发起人判断该需求与目标一致但会推迟上线，决定纳入二期，并形成变更决策记录；治理机构对工期调整做备案。整个过程没有出现业务负责人直接要求开发人员改需求的情况。
验收阶段，业务负责人组织试用，对照需求说明确认首期审批事项可用，出具验收结论并列出二期需求；发起人对照目标基线确认线上化率和审批时长达到立项时的设定，签署结项报告，项目关闭。范围变更的决策路径可以概括为：提出方提交变更说明，项目经理评估影响，发起人决策，重大变更经治理机构审批，结论书面记录并知会所有相关角色。
这个示例可迁移的规律有三条：目标在立项时定清楚，验收才有依据；变更走统一入口，避免执行层被多头指挥；每个节点都有书面产出，角色交接不依赖个人记忆。适用边界在于，项目规模较小、角色由一人兼任时，可以合并角色，但仍需在职责表中写明兼任关系，避免决策与执行混在一起。
用协作工具承载分工与决策记录
职责表和节点清单写在文档里容易，难的是日常执行中每个人都能看到自己该做什么、哪些事项在等谁决策。把分工落到协作工具中，重点设计三类字段和记录：工作项上的负责人、审批人与知会人；立项与目标类文档的留存位置；变更与验收结论的状态流转。
具体做法上，工作项应明确单一负责人，审批人单独设置，知会人以订阅或关注方式接收进展，避免把知会人写成共同负责人。立项说明、目标与成功标准作为项目文档集中存放，后续验收和变更决策都引用同一份基线。变更申请与验收结论以独立工作项或审批记录存在，保留提出时间、评估意见、决策结论和决策人，形成可追溯链条。状态流转对应交接动作，例如“待发起人确认”“待业务验收”，状态变化即代表交接发生。
ONES 可作为承载这类分工记录的平台之一。其研发管理相关方案包含项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于把项目文档、工作项和审批记录放在同一协作空间中；在汽车软件研发等场景下，ONES 方案支持全生命周期流程活动与跨域协作过程的可追溯性。ONES 效能管理提供面向管理人员、项目经理等不同角色视角的预置仪表盘模板，并支持为不同角色配置读写权限，便于发起人、项目经理等角色按各自视角查看进展。上述能力的具体配置方式与可用范围以实际版本和采购方案为准；立项文档模板、审批流字段等细节需结合组织实际配置设计。
完成检查：分工机制是否真正落地
分工机制是否有效，不看职责表写得多完整，而看关键节点上是否有人负责、有人决策、有记录可查。以下清单可在项目立项后和每个阶段结束时逐项核对。
- 每个关键活动在职责表中都有明确负责人和审批人，没有一行出现两个“负责”或负责人空缺。
- 发起人对立项理由、目标与成功标准、资源承诺、重大变更与终止决策均有实际参与记录，未出现长期缺位。
- 发起人未直接指挥执行层调整方案或分配任务，执行中的调整由项目经理统一协调。
- 目标与成功标准在立项时形成基线，验收时可直接对照，未出现验收阶段重新解释目标的情况。
- 每项变更都有提出、评估、决策、知会的完整记录，重大变更经过治理机构审批。
- 验收结论由业务负责人书面出具，项目关闭由发起人确认，两者均有留存。
- 角色交接有确认动作，例如状态变更、审批通过或确认记录，不依赖口头约定。
- 项目经理、业务负责人、职能经理之间未出现职责空档，例如需求无人确认、资源无人承诺、风险无人跟踪。
核对不通过时，按问题类型整改：负责人空缺的，回到职责表补齐角色并明确单一负责人；发起人越位或缺位的，在项目例会上重申决策权限清单，把执行细节交回项目经理；变更与验收缺少记录的，补充书面结论并回溯知会相关角色；交接无确认的，在工具中设置对应状态和审批节点。整改后再按同一清单复核一次，确认分工机制在实际运行中成立。
常见问题
项目发起人可以兼任项目经理吗？
小项目中可以兼任，但要在职责表中写明兼任关系，并把决策与执行两类动作分开记录。发起人做变更决策时，应以发起人身份判断是否值得继续投入；推进计划和跟踪风险时，以项目经理身份执行。两者混在一起，容易出现自己批准自己调整的情况，验收时也缺少独立的目标确认环节。项目规模扩大或变更频繁时，建议把两个角色拆开。
发起人批完立项后还需要参与哪些节点？
至少参与三个节点：规划阶段确认资源承诺，执行阶段对超出授权范围的变更做决策，验收阶段对照目标基线确认项目目标是否达成并决定关闭。日常进度跟踪由项目经理负责，发起人通过状态报告了解进展即可。发起人长期缺位，变更决策会积压，验收时也容易对目标产生新的解释。
业务负责人和项目经理在需求上如何分工？
业务负责人对“需求是否解决业务问题”负责，提交需求说明并确认范围边界；项目经理对“需求如何纳入计划交付”负责，评估工期与资源影响并安排实施。需求发生调整时，由业务负责人提出，项目经理评估影响，超出原立项范围的按变更流程提交发起人决策。两者都参与需求确认，但负责的对象不同，职责表中应分别标注。
职能经理确认资源后人员仍不到位，怎么处理？
先看资源承诺记录中约定的到岗时间和投入比例，与职能经理核对偏差原因。若影响关键里程碑，由项目经理提交变更说明，发起人判断是调整计划、追加资源还是缩减范围。资源承诺在规划阶段以书面形式确认，正是为了在这种情况下有据可依。日常沟通中定期同步人员到位情况，比事后追责更有效。
分工机制在协作工具中至少要记录哪些内容？
三类记录最关键：工作项上的单一负责人与审批人，立项说明和目标基线作为项目文档集中存放，变更与验收结论保留提出时间、评估意见、决策结论和决策人。状态流转对应交接动作，例如“待发起人确认”“待业务验收”，状态变化即代表交接发生。ONES 的研发管理方案包含项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于把项目文档、工作项和审批记录放在同一协作空间；具体字段与审批流配置需结合组织实际设计，可用范围以实际版本和采购方案为准。
