PMI PMP: 团队领导力与资源管理 — 学习指南

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

属于 PMP — 学习指南. 使用经过验证的答案练习： PMI 考试中心, 或参加限时模拟考试： ExamRoll.io.

团队组建、章程与角色清晰度

每个高绩效团队的起点都是一个精心设计的组建仪式，而不是第一次的状态会议。团队章程是团队的创始文件——一份由团队共同创建的文档，其中记录了团队的共同价值观、决策规则、跨时区的工作时间、沟通节奏和上报路径。与项目章程（用于授权项目并指定发起人）不同，团队章程是由团队为自己编写的。其力量在于共同创作这一过程：当一名开发人员后来打断同事或错过站会时，项目经理不是动用个人权威，而是指出团队自己建立的规范。

除了章程，基本规则将日常纪律具体化：例如设计评审时开启摄像头、回顾会议期间禁止处理多任务、口头更新遵守两分钟规则、决策在24小时内记录存档。基本规则应该清晰可见（张贴在团队活动室或固定在协作频道中），并在每次迭代或阶段关口开始时重新审视。一份躺在无人问津的 SharePoint 文件夹里的章程只是摆设；一份每周都被引用的章程才具有约束力。

明确的角色分工是团队组建的第三个关键点。通过 RACI（或其变体 RASCI）矩阵，将可交付成果与负责（Responsible）、当责（Accountable）、咨询（Consulted）和知会（Informed）方对应起来，可以消除“我以为你做了”这种失败模式。当项目经理接手一个已经数周缺乏领导、方向不明的团队时，正确的首要步骤既不是激进地重新规划，也不是立即与发起人重新协商进度。而是召集团队，倾听他们认为受阻的地方，并重新构建团队章程和角色矩阵。团队之所以感到迷茫，正是因为缺少了这些主心骨。

根据成熟度调整领导风格

情境领导理论将领导风格视为一个可变因素，而非一成不变的个性。经典的 Hersey-Blanchard 模型将领导风格与下属的准备度对应起来：

服务型领导姿态——即移除障碍、为团队屏蔽干扰、优先考虑团队成员的成长——是对此模型的补充，但不能取代情境判断。服务型领导不等于放纵型领导。当团队偏离方向时，服务型领导者仍然会进行指导；他们这样做只是为了团队的成功，而不是为了凸显自己。

在没有方向的团队中采用放任式领导是一个常见的失败陷阱。当团队对工作没有共同的认知模型时，袖手旁观并“让团队自组织”只会导致混乱、遗漏依赖关系和士气低落。自组织是团队成熟的结果，而不是初始条件。相反，对已经多次交付类似工作的高级工程师进行微观管理，则会传递不信任的信号，抑制其主动性，并导致人员流失。一个明显的迹象是：项目经理在审查领域专家的代码提交级细节，却忽略了在项目组合层面的风险讨论。

加入一个资历混杂的团队时，起手式应该是一轮一对一沟通，并结合举办一个工作协议研讨会。这能揭示每个成员在准备度谱系中所处的位置，从而可以针对个人调整领导风格，而不是一概而论。

辅导、一对一沟通与绩效管理

定期的一对一沟通——通常是每两周30分钟——是进行辅导、早期问题发现和职业发展的主要渠道。这不是状态会议。议程应由团队成员主导，项目经理在70%的时间里应以倾听为主。沟通主题可以轮流涵盖当前的障碍、技能成长、双向反馈和团队士气。

绩效问题必须在初次观察到时就提出，而不是积攒到正式的评审周期再说。推迟艰难的对话是项目领导中最具破坏性的模式之一：表现不佳者直到为时已晚才学到教训，高绩效者看在眼里并逐渐脱离，而团队士气则在无声中被侵蚀。反馈应基于可衡量的指标——例如缺陷逃逸率、用户故事周期、代码审查周转时间、会议出席率、承诺可靠性——而不是主观印象（“你看起来不太投入”）。可衡量的指标将对话锚定在可观察的行为上，并为团队成员提供一个具体的目标。

只有在辅导、明确设定期望以及有记录的绩效改进沟通都失败后，才有理由上报给职能经理，或最终要求更换资源。跳过这些步骤会损害信任，并且通常会违反 HR 政策。

冲突解决与团队建设

人际冲突若不加以解决，便会恶化扩散。当一个团队成员在短期项目中被同事孤立时，项目经理的对策既不是等待项目结束（因为项目结束时，这种紧张关系也无法自行化解），也不是公开对抗整个团队（这会羞辱对方并使立场更加强硬）。正确的模式结合了三个步骤：与受影响的个人进行私下沟通以了解其经历；与表现出排斥行为的同事单独交谈，指出观察到的行为模式及其影响；以及通过团队章程和有引导的团队建设活动来强化包容性规范。记录干预过程至关重要，以备需要上报给 HR 的情况。

托马斯-基尔曼（Thomas-Kilmann）的五种冲突模式——协作、妥协、迁就、强迫、回避——为选择应对方式提供了指导。协作（解决问题以寻求双赢）通常是长期团队中人际和技术争议的首选方式，而强迫可能仅在涉及安全、道德或有硬性截止日期的决策时才是合理的。

资源分配、平衡与容量规划

资源管理既是算术，也是谈判。资源平衡通过延长排期来解决资源过度分配的问题；资源平滑则保持结束日期不变，在浮动时间内进行调整。当关键专家任务过重且质量可能受损时，选择资源平衡；当项目有合同规定的截止日期时，选择资源平滑。

当职能经理在 Sprint 中期重新分配一名共享的架构师时，项目经理应使用数据进行谈判：当前承诺、对关键路径的影响以及下游的延迟成本。只有在尝试直接谈判并记录在案后，才适合将问题上报给发起人或指导委员会。未先尝试解决问题就直接向上级抱怨，会消耗政治资本。

知识转移与交叉培训

单点依赖是项目中最可预测的风险之一，也最常被忽视。当某人是某个子系统的唯一负责人并住院两个月时，失败的根源并非这次意外，而是事先缺乏缓解措施。预防性实践包括配对编程或配对辅导、轮换待命（on-call）职责、将不成文的隐性知识强制记录到运行手册中、录制知识转移会议，以及交叉培训轮岗，让第二负责人观摩并实践专家的任务。新员工的入职计划应明确指派一名伙伴，并制定一份 30-60-90 天的能力成长路线图。

团队层面的继任规划旨在确定谁可以接替每个关键角色，以及他们需要弥补哪些能力差距。这些信息记录在一个每季度审查一次的技能矩阵中。

会议引导与认可

会议消耗了团队中最显而易见的一部分产能。会议纪律要求：有明确的目标、提前分发有时限的议程、邀请合适的（而非最多的）参会者、明确记录决策和行动项（包括负责人和日期），以及一个用于处理离题讨论的有效“议题暂存区”（parking lot）。没有决策产出的例会应当取消。

最后，认可是不可或缺的——对团队的胜利进行及时、具体、公开的表彰；对个人的辅导则私下进行——这并非可有可无的客套。与团队章程价值观一致的奖励，会强化产生这些成果的行为。在评审中进行一次简短的公开表扬、与职能经理协调发放一笔即时奖金，或者给某人的直线经理发一封表扬便条，这些成本很低，但在提升士气和员工留存率方面却能产生显著的复利效应。

实践问题：用例场景

场景： Priya Kapoor 刚刚被任命负责一家中型区域性银行的“Meridian”支付现代化项目，该项目预算为 420 万美元，时间表为 14 个月。这个 11 人的团队横跨三个时区：五名开发人员在班加罗尔，三名业务分析师在伦敦，以及一名 QA 主管、一名架构师和 Priya 本人在多伦多。项目开始两周后，班加罗尔的开发人员构建了一个原型，但被伦敦的业务分析师（BA）以不符合他们“想当然地认为所有人都已阅读过”的合规性要求为由而拒绝。同时，多伦多的架构师声称，在技术栈决策上从未有人咨询过他。

挑战： Priya 必须重新设定团队的运作规范和角色清晰度，以防止项目进一步延误，同时又要避免显得像是在为这次沟通不畅而指责任何一个团体。

推荐方法：

1. 暂停当前开发工作，举行为期两天的线上团队组建研讨会，安排重叠的工作时间（多伦多时间上午 7:00–10:00 / 伦敦时间下午 12:00–3:00 / 班加罗尔时间下午 4:30–7:30），以便所有 11 名成员都能实时共同编写交付成果。
2. 引导团队共同创建一份团队章程，内容涵盖共享的重叠工作时间、决策权、对“咨询（consulted）”与“通知（informed）”的定义、针对异步决策的 24 小时响应规则，以及最终上报至项目发起人的升级路径。
3. 针对 WBS 中的 18 个主要可交付成果建立一个 RASCI 矩阵，与团队一起逐行审阅，确保“问责（Accountable）”角色始终是唯一的指定人员，并且在任何技术栈决策中，“咨询（Consulted）”角色都明确指定了架构师。
4. 建立基本规则——设计评审时开启摄像头，决策需在一个工作日内记录到 Confluence 中，在重叠工作时段内举行每周 30 分钟的跨时区同步会议——并将这些规则置顶在团队的 Slack 频道中。
5. 与业务分析师（BA）和开发人员一起重新制定原型范围，使用新明确的 RASCI 来确定在编写代码前由谁来签核。
6. 在每次迭代的首次回顾会议中，增加一个固定的 10 分钟“章程检查”环节，以便随着团队的成熟而修订规范。

为何这样有效： 共同创作将章程从一项强制命令转变为同级成员间的承诺，这使得项目经理（PM）在不依赖职位权力的情况下，也能有立场去执行这些规范。RASCI 消除了导致合规性失误的“我以为你负责了”这类认知差距，而每次迭代都重新审视规范，可以防止章程变成一件装饰品，而不是一份持续有效的活协议。

← 相关方参与与沟通 · 所有领域 · 敏捷、Scrum 与混合交付 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →