项目人力资源管理怎么分工不打架？

项目开始后常见的场面，不是没人干活，而是几个人同时觉得自己该管，另几件事却没人接手。需求变更时，产品等开发评估，开发等测试确认，测试等产品拍板，会议开了几轮，交付时间还是往后挪。在项目管理中，项目人力资源管理要解决的，正是“事由谁定、活由谁干、出了问题找谁”的问题。分工不打架，靠的不是把职责写得越长越好，而是先把目标、角色、责任和协作规则对齐。

项目管理协会 PMI 在《职业脉搏调查》中给出过一组数据：在项目开始前明确项目收益，有 74% 的项目能够达成目标和商业意图。目标清楚，分工才有共同的判断标准；目标含糊，角色写得再细，也会在变更时打回原形。

下面按“先定事、再定人、再定规则、最后用计划执行监控校正”的顺序拆开。

一、先定范围和目标，分工才有共同基准

分工的第一步不是排人，而是把项目本身说清楚。输入包括立项背景、业务目标、关键干系人的期望、预算与时间约束；动作是把交付物、验收标准、明确不做的内容、主要假设和外部依赖写下来；产出是一份团队都能复述的范围与目标说明。

范围说明要回答四个问题：交付什么、达到什么标准算完成、哪些不在本期范围、哪些外部条件会影响交付。比如“上线一个客户自助开户功能”只是方向，写成“支持身份证与银行卡两类认证，单笔开户在 3 分钟内完成，覆盖 5 个试点城市”才具备验收条件。

这一环节是后续返工的高发点。很多团队习惯先拉人开会，再边做边想目标，结果角色刚定完，范围又变了。规避方式不复杂：在立项会上让项目发起人确认目标和验收口径，把“不做什么”写进同一页文档；范围发生变化时，不在群里口头答应，统一走变更评估。

目标写清楚后，下一步才是识别角色。

二、按任务识别角色，不按部门凑人头

项目角色分工不是部门点名。部门回答“人归谁管”，角色回答“这件事谁负责”。项目人力资源管理在组建团队时，先看任务需要什么能力、需要谁做决定，再看现有人力如何匹配。

可以先把角色分成三类：决策角色、执行角色、支撑角色。决策角色包括项目发起人、项目负责人和业务负责人，对目标、资源和重大变更拍板；执行角色包括产品、研发、测试、实施等，对具体交付物负责；支撑角色包括架构、安全、配置、采购等，在特定节点提供专业支持。一个人可以承担多个角色，但同一件事上不能同时出现两个“最终负责人”。

这一步的输入是范围说明和任务清单，动作是按任务识别角色、写清职责边界，产出是角色清单和接口人名单。

输出一份角色清单，每个角色只写四件事：对什么结果负责、能决定什么、不能决定什么、出现分歧向谁升级。跨部门协作多的项目，还要指定接口人。接口人不是传话人，而是能代表本部门给出明确答复的人。

角色清单完成后，进入容易产生争议的一步：把责任和决策权落到具体任务上。

三、用责任分配矩阵把“谁拍板、谁执行、谁被咨询”写清

责任分配矩阵，也就是常说的 RACI 矩阵，是项目里常用的分工工具。R 是执行，负责把事做完；A 是最终负责，对结果拍板并承担后果；C 是事前咨询，在决定前提供意见；I 是事后知会，只需知道结果。四个字母不是职级，项目经理在技术方案上可能是 C，技术负责人在自己模块上就是 A。

使用 RACI 有三条硬规则：每项任务只能有一个 A；R 可以多人，但必须落到具体的人；C 和 I 要克制，不要把所有人都写进去。A 多了等于没人负责，C 多了决策会变慢。

这一步的输入是角色清单和关键任务清单，动作是逐项填写 RACI、确认每项任务只有一个 A，产出是责任分配矩阵和关键决策权限说明。

下面用一张表把关键任务的 RACI 落到角色上，具体人员按项目实际情况替换。

这张表只做示例，实际项目按任务粒度调整。表的价值不在填得漂亮，而在于让每个任务都能回答三个问题：谁执行、谁拍板、意见找谁。A 和 R 可以是同一个人，但责任不能省略。

第二个高频返工点就出在这里：只写了执行人，没有写最终负责人。 任务延期时，执行人说“我在等确认”，确认人说“我以为他会先做”，最后还是项目经理临时协调。把 A 明确到人，并给变更、排期、上线这三类决定设定统一的工作流入口，扯皮会明显减少。

责任矩阵不是贴在墙上的表格。项目进入执行后，任务会增减、人员会调整，矩阵也要跟着更新。更新时机通常放在里程碑评审和重大变更之后。

四、把分工放进计划、执行、监控三个动作

角色和责任写清楚，只是分工的静态部分。真正决定会不会打架的，是计划、执行、监控三个阶段有没有按同一套规则运行。

计划阶段：把责任写进基线

输入是范围说明、角色清单、RACI 矩阵和任务估算；动作是把项目拆到工作包，排出里程碑、依赖关系和资源日历，同时确定沟通节奏与变更流程；产出是进度基线、责任矩阵和沟通计划。计划不是项目经理一个人的文档，关键角色要确认自己承担的交付物和时间点。判断计划是否可执行，可以看一个信号：每个角色都能说出自己最近的三项交付，以及遇到阻塞时找谁。

执行阶段：按接口交付，减少口头改派

输入是工作包、基线和责任矩阵；动作是任务派发到人，例会只看偏差和阻塞，需求或排期变化走统一入口，重要决定留记录；产出是任务状态、变更记录和决策日志。执行阶段常见的问题是“顺手帮个忙”式的口头改派，事情做了，责任却没转移。跨角色交接时，至少确认交付物、完成标准和下一位接手人。

监控阶段：用偏差校正分工

输入是进度、质量、返工和等待时间等数据；动作是对照里程碑看偏差，区分是能力不足、资源不够，还是接口不清，再决定补人、调序或改责任矩阵；产出是纠正措施和更新后的分工说明。监控不是追责，而是验证当前分工是否仍然匹配任务。如果同类冲突反复出现，优先改接口和决策规则，不要只换人。

五、两个高频返工环节，提前设护栏

项目人力资源管理里，返工往往不是执行慢，而是前面两件事没做透。

处理这两个环节，输入是冲突信号和返工记录，动作是先判断问题出在目标还是责任，产出是相应的护栏规则。

第一个环节：范围和目标没定清就分工。 典型信号是需求反复、做完再改、验收时各说各话。护栏是三样东西：一页纸目标与验收标准、明确的“不做什么”清单、变更影响评估。变更不是不能有，而是要让提出变更的人看到对时间、成本和质量的影响。

第二个环节：责任矩阵只写执行，不写决策。 典型信号是会议很多、结论很少，跨部门都在等指令。护栏是每项任务一个 A、一张关键决策权限表、一条有时限的升级路径。升级不是打小报告，而是当接口人无法在约定时间内给出答复时，把问题交给更高一层决策者。

这两个环节的共同点，是把“以为说清楚了”变成“写下来并能被复述”。分工不是一次会议的结果，而是一份会随项目推进更新的约定。

六、让分工在工具里可追踪：禅道的承接方式

分工如果只停在文档里，执行时很容易回到口头协调。工具的价值，是让角色、任务、交付物和状态变化留在同一套记录里。

禅道集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，内置项目集、项目、产品、执行四个管理结构，并以需求池、需求、用例、任务、Bug 等核心概念串起研发交付。团队可以把“谁负责哪项需求、哪项任务卡在哪个状态、哪个 Bug 由谁处理、验收依据是什么”放到同一套项目结构中，减少信息散落在群聊和表格里的情况。

对中大型企业和规模化研发团队，禅道支持稳态与敏态双模管理，也能按项目集、项目、执行分层组织工作。工具不能替代责任约定：先把目标、角色和 RACI 定清楚，再用项目管理功能承载任务与交付；需求变化较多时，用需求池统一收集和排序；变更与审批路径需要固定时，用工作流把规则落到流程；需要复盘返工和等待时，用效能分析看数据，而不是凭印象判断。

回到开头的问题：项目人力资源管理怎么分工不打架？答案不是把职责表写得更长，而是先定事、再定人、再定规则，并在计划、执行、监控中持续校正。选一个正在进行的项目，用一页纸目标、一张 RACI 表和一条变更入口做试点，跑完一个里程碑再复盘，分工才会从纸面变成团队的习惯。

参考资料：PMI 中国《职业脉搏调查》，https://pmichina.org/PulseoftheProfessionzymbdc/index.jhtml