产品交付管理
产品交付管理流程(MP)的目的是控制项目经理(PM)与团队经理(TM)之间的关联。通过就专业成果物的接受、执行、报告及交付要求达成一致,实现可靠的成果物提供。
本流程从团队经理的视角审视项目(阶段控制流程则从项目经理的视角审视)。
目标
通过以下事项确保遵循质量和计划的交付。
- 建立共识:分配给团队的成果物相关工作已获授权并达成一致
- 明确理解:团队了解需要创建的内容以及所需的工作量、成本和工期
- 遵守质量和容忍度:计划的成果物满足预期质量,并在容忍度范围内提供
- 管理期望:以约定的频率向 PM 提供准确的进度信息,使 PM 能够恰当地管理期望
定位
TM 的工作方式
TM 作为团队代表,通过以下步骤管理成果物的创建。
-
准备与规划:从 WP 达成一致到工作开始的一系列准备工作
- 接受 WP:就内容达成一致后,接受 PM 授权的工作包(WP)
- 制定团队计划书:基于 WP 制定具体的团队计划书(可与阶段计划书制定并行进行)
- 维护关系:维护 WP 描述书中定义的开发、运营与维护之间的关联
-
开发与质量管理:按照指定方法创建并质量确认专业成果物
- 遵循方法:按照指定的开发方法开发成果物
- 证明质量:使用成果物描述书中规定的质量方法,证明每个成果物符合规格
-
提交:获得批准并将成果物移交给 PM
- 获取批准:就完成的成果物从指定的批准权限人处获得正式批准
- 交付成果物:按照 WP 描述书中规定的程序,将批准的成果物提供给 PM
实施要点
- 自主性与避免微观管理:通过向 TM 适当授权保护团队生产力
- 权限委托:PM 基于 WP 描述书中确立的容忍度和信任,给予 TM 充分的自主性
- 防止副作用:PM 的微观管理会导致团队挫败感和工作延误——应避免这一点,专注于实现所要求的成果
- PM 视角与 TM 视角:两者的角色视角不同,各有侧重
- PM(阶段控制):俯瞰整个阶段是否运转良好
- TM(产品交付管理):专注于能否按时按质完成分配的成果物
- 团队计划书的灵活性:可根据合同、规模和复杂性选择形式
- 简单情况:在 WP 描述书中增加进度安排即可
- 复杂情况:类似阶段计划书的详细结构
- 涉及合同的情况:WP 本身有时作为合同的一部分发挥作用
主要输出
| 输出 | 内容 |
|---|---|
| 团队计划书 | TM 为完成 WP 而制定的执行计划,包含团队结构、进度安排和工作安排 |
| 专业成果物 | TM 团队开发并提供的专业性成果物 |
| 检查点报告 | TM 定期向 PM 提供的进度报告 |
活动

| 输入 | 活动 | 输出 |
|---|---|---|
| WP 授权(触发本流程)、WP 描述书(审查) | ① 接受工作包 | 团队计划书(创建/更新) |
| 团队计划书(审查)、WP 描述书(审查) | ② 执行工作包 | 项目日志(更新)、专业成果物(创建) |
| 团队计划书(审查)、WP 描述书(审查)、项目日志(审查) | ③ 评估工作包状态 | 检查点报告(每期创建)、项目日志(更新) |
| 团队计划书(确认)、WP 描述书(确认)、项目日志(审查) | ④ 通知工作包完成 | 团队计划书(更新)、工作包(已完成)、WP 完成通知(触发阶段控制) |
各活动详情
① 接受工作包
在工作开始前,就交付内容、约束条件、程序和计划的有效性,在 PM 与 TM 之间形成完全共识的活动。
理解内容并制定计划
- 理解内容:审查 WP 描述书,准确把握成果物内容和交期
- 制定团队计划书:在遵守约束条件的前提下制定具体的团队计划书(如使用敏捷方法则在时间盒内完成)
- 确认符合标准:就团队计划书是否可行以及是否符合供应商标准,与项目保证(供应商)进行协商
质量和日志管理
- 确认质量体制:就是否需要额外的质量审查员与项目保证协商;更新项目日志(质量登记册等)
- 确认程序:在 WP 描述书中确认更新项目日志的程序
批准与风险评估
- 获取计划批准:就团队计划书获取必要的批准(在客户-供应商商业关系中 PM 批准不适当的情况下,由高级供应商进行审查和批准)
- 审查风险:基于团队计划书进行风险审查;如识别出新风险,通知 PM,经许可后直接更新项目日志
- 最终共识:一切条件具备后,正式同意提供 WP
② 执行工作包
按照授权 WP 的要求,实际开发并监控专业成果物的活动。
实施要点
- 自主管理:在设定的容忍度范围内,TM 可以自主实施工作和采取纠正措施
- 基于预测的行动:只要预测 WP 能在容忍度内完成,TM 就继续自主控制
- 偏差报告:预测 WP 将超出容忍度时,TM 不擅自处置,而是迅速向 PM 提起课题;后续措施由 PM 决定
- 确保心理安全:维护团队内部能够及时分享课题和风险而不加以隐瞒的环境,是交付成功的关键
TM 的推荐行动
- 管理开发并报告进度:按要求推进工作,及时向 PM 共享发生的情况
- 遵守要求:根据 WP 描述书和团队计划书,带领现场确保成果物正确创建
- 信息反馈:识别出新的课题、风险或教训时通知 PM,并确保执行 PM 认为必要的措施
- 质量管理与记录更新:记录并报告质量活动的完成情况和成果物的批准状态
- 报告质量活动完成:每次计划的质量活动完成时通知 PM;将质量登记册更新至最新状态
- 批准与登记:就完成的成果物从批准权限人处获得正式批准;更新成果物登记册中的状态
③ 评估工作包状态
TM 按 WP 描述书规定的频率自行审查 WP 进度,并向 PM 报告的活动。
运营要点
- 多维度审查:不仅确认进度安排,还要确认质量、风险、课题和教训等 WP 相关的各方面,确保信息的准确性
- 供应商独有管理:在 TM 隶属供应商组织的商业情况下,评估时可能使用与整体项目日志分开的本公司专有管理工具和登记册
- 项目支持的活用:项目支持角色有时会从整体项目日志中提取该 WP 相关信息并提供,支持 TM 的评估工作
推荐行动
- 审查状态:报告前全面确认各日志和登记册,掌握 WP 的整体情况
- 与计划比较:审查 WP 描述书和团队计划书;比较预期进度与实际进度
- 确认日志:确认课题登记册、风险登记册和教训日志;整理影响 WP 的事项
- 确认质量与成果物:确认质量登记册(活动状态)和成果物登记册(含批准记录的完成状况)
- 报告状态:通过规定手段将掌握的情况传达给 PM
- 正式报告:将掌握的状态汇总为检查点报告,提供给 PM
- 拉动系统:采用敏捷方法时,不发送报告,而是维护 PM 能够直接查看看板和燃尽图等进度图表的环境
④ 通知工作包完成
向 PM 正式告知 WP 中所有工作已完成、所有成果物均已获批准,并进行移交的活动。
运营要点
- 质量保证:这不仅仅是工作已完成的报告——需要证明已达到规定的质量标准并获得必要的批准
- 共享例外事项:明确完成时残留的风险和规格外项目,使 PM 能够作出下一个判断(虽然理想是一切完美完成,但也有在了解轻微缺陷的前提下给予批准的情况;重要的是不加以隐瞒,而是突出传达这类未解决的课题和风险)
TM 的推荐行动
- 提供成果物并确认:按规定程序移交成果物,验证所有批准均已完成
- 按规定程序提供:按 WP 描述书中约定的程序,将完成的成果物提供给 PM
- 最终验证批准:审查批准记录,确认 WP 提供的所有成果物均已获得适当批准
- 更新记录并审查:更新团队计划书和项目日志,记录完成状态
- 完成团队计划书:更新计划书,记录该 WP 已完成
- 日志全面审查:审查项目日志(风险登记册、课题登记册、教训日志);整理与 WP 相关的未解决事项和所获知见
- 向 PM 报告并发出最终通知:在说明绩效和残余事项后正式通知 WP 完成
- 说明绩效:向 PM 说明实际工作绩效(工期、成本、质量等)与 WP 描述书中约定内容的比较情况
- 突出残余事项:向 PM 突出传达与完成成果物相关的未解决课题(如规格外项目)和仍然存在的风险
- 正式完成通知:经过上述确认后,正式向 PM 通知 WP 完成
流程应用
一般注意事项
推荐最大限度发挥专业知识、重视团队自主性的控制方式。
- 活动的灵活运用:活动可根据情况合并、拆分或同时执行,但必须始终注意与阶段控制流程的可靠衔接
- 适合专业方法的管理:专业工作采用适合其种类的交付方法(如敏捷等)和尺度;PM 与 TM 就此达成一致并反映在 WP 描述书中,与整体项目管理方法保持一致
- WP 的层级化与治理:WP 不一定是小规模的。处理大规模 WP 时,TM 可以进一步细分为更小的 WP 分配给团队成员,构建适当的控制环境
- 协作文化:TM 与成员的关系应是协作性的。TM 不只是发号施令,而是作为促进成员主人翁意识的引导者,支持其为项目目标作出贡献
角色裁剪
可根据组织规模和复杂性灵活构建管理体制。
- TM 的角色与代行:TM 对流程的全部活动承担执行责任,但 PM 可以兼任 TM 角色
- TM 的层级化:大型项目中,可将 WP 拆分给多个 TM,并将汇报线层级化。此时,上级 TM 承担整体执行责任,向 PM 进行报告
- WP 描述书的灵活性:只要 PM 和 TM 就内容达成一致,WP 描述书的创建、更新和批准负责人可根据项目需要灵活变更
职责
| 活动 | 业务层 | 项目执行官 | 高级用户 | 高级供应商 | 项目经理 | 团队经理 | 项目保证 | 项目支持 |
|---|---|---|---|---|---|---|---|---|
| ① 接受工作包 | — | — | — | — | A | R | — | I |
| ② 执行工作包 | — | — | — | — | A | R | C | C |
| ③ 评估工作包状态 | — | — | — | — | A | R | C | C |
| ④ 通知工作包完成 | — | — | — | — | A | R | C | I |
R = 负责, A = 问责, C = 咨询, I = 知会
将实践应用于流程
| 实践 | 在产品交付管理流程中的应用 |
|---|---|
| 业务案例 | 确保在执行过程中切实满足 WP 描述书中定义的收益和可持续性相关要求 |
| 组织化 | 遵守沟通、变更和商业管理要求。制定记录团队结构和工作安排的团队计划书,持续监控团队健康状况 |
| 计划 | 根据 PM 的要求,制定完成 WP 所需的具体团队计划书 |
| 质量 | 开发并提供满足 WP 质量要求的专业成果物。更新质量登记册,记录计划活动和实际情况 |
| 风险 | 在团队层面管理风险,保持风险登记册最新。必要时向 PM 升级 |
| 问题 | 在团队层面管理课题,保持课题登记册最新。必要时向 PM 升级 |
| 进度 | 根据成果物状态更新成果物登记册。按约定频率提交检查点报告;在教训日志中更新知见 |
与其他框架的比较
| 概念 | PRINCE2 | PMBOK | PgMP |
|---|---|---|---|
| 流程定位 | 产品交付管理(MP) | 项目工作的指导与管理 | (待补充) |
| 工作单位 | 工作包 | 工作包(WBS 最底层) | 组件 |
| 团队级计划 | 团队计划书 | (WBS 分解·活动清单) | 组件计划 |
| 进度报告 | 检查点报告 | 工作绩效数据与报告 | (待补充) |
喜欢的话,留下你的评论吧~