关于 technical-program-management
Technical Program Management 是用于协调多个项目或工作流共同交付成果的技能,帮助项目群经理管理依赖关系、共享约束、收益、证据和决策,同时保留各组件负责人的权限。
主要功能
- 01明确项目群边界与共同成果
- 02跟踪依赖、产能和综合里程碑
- 03管理收益、风险和决策记录
- 04按实际条件选择协调模式
- 05向利益相关者提供循证进展
适用场景
- 01诊断各项目状态良好但项目群偏离目标的原因
- 02解决跨项目依赖争议
- 03评估收益延迟和采用风险
- 04准备发起人决策或恢复方案
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ magnus919/ agent-skills --skill technical-program-management安装后在 Claude Code 中输入/technical-program-management确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdevals/evals.jsonreferences/assurance-and-intervention.mdbenefits-and-transformation.mdbenefits-dependency-and-tranches.mdprogram-control.mdresearch-ledger.mdtemplates/assurance-review.mdbenefits-dependency-map.mdintegrated-control.mdprogram-brief.mdstakeholder-update.md详细介绍
技术项目群管理
即使每个组件都按各自计划推进,项目群层面的管控仍可能失效。使用此技能来识别并管理各部分之间的衔接,而不是取代项目经理或产品治理。
首要任务:明确项目群边界
项目群并非规模更大的项目:只有当各组件之间的协调、共同约束或共同收益需要作出任何单个组件负责人都无权单独决定的决策时,才需要项目群。
在安排正式活动之前,先阅读现有战略、商业论证、组件计划、依赖关系记录、收益假设以及近期状态证据。明确:
- 共同成果,以及各组件为何要归为一组;
- 负最终责任的高级负责人和项目群决策权;
- 组件项目/工作流、负责人、接口和运营接收方;
- 预期收益、收益负责人、衡量指标、基线、时间安排和负面收益;
- 共同的产能、资金、架构、供应商、环境和政策约束;
- 当前阶段、关键决策、证据缺口,以及停止/重新审视的条件。
如果这项工作是一个边界明确的项目,请转至 technical-project-management。 如果这项工作只是一组互不相关的投资,请转至 product-roadmapping-and-portfolio 或 strategy-frameworks。
参考资料路由
仅阅读当前决策所需的内容:
| 情况 | 阅读 |
|---|---|
| 项目群授权、组件图谱或共同约束 | 项目群简报模板 |
| 综合状态、依赖关系、风险或恢复问题 | 项目群管控与故障排查 |
| 收益、治理或证据边界 | 研究台账 |
| 收益依赖关系映射、阶段决策或负面收益 | 收益依赖关系与阶段管控 |
| 采用情况、运营模式变更或收益偏移 | 收益与转型 |
| 需要填写综合管控记录 | 综合管控模板 |
| 面向特定受众的状态或决策更新 | 利益相关方更新模板 |
| 独立保障或陷入困境的项目群干预 | 保障与干预 |
| 单个项目需要详细管控 | technical-project-management |
| 产品组合或资本分配决策 | product-roadmapping-and-portfolio 或 strategy-frameworks |
转至相关技能
- 对于单个边界明确的项目的里程碑、预测、依赖关系、恢复或收尾,请使用 technical-project-management。
- 对于产品路线图和产品组合排序,请使用 product-roadmapping-and-portfolio。
- 对于常设的产品决策权和产品治理,请使用 product-operations-and-governance。
- 对于企业目标状态架构或架构治理,请使用 enterprise-architecture。
- 对于已批准的工作分解和详细推出计划,请使用 implementation-planning。
项目群运作循环
- 明确任务。 确认预期成果、组件边界、权限、资金期限、成功指标和假设。没有承担责任的发起人,就不要把战略愿景转化为已批准的项目群。
- 构建工作架构。 定义组件章程、接口、共享里程碑、集成证据、决策权和升级路径。保留适合各组件的交付方式;协调成果,而非仪式。
- 建立集成视图。 维护一份项目群控制记录,涵盖依赖项健康状况、集成里程碑、共享产能冲突、收益、风险/问题、决策、预测和变更。链接到组件记录,而不是复制其内容。
- 管理衔接点。 按提供方、接收方、就绪定义、验收证据、所需日期、备用方案和升级责任人审查跨项目依赖项。某个组件标记为绿色,并不意味着未满足的项目群依赖项也为绿色。
- 依据证据引导。 将实际情况和预测与项目群基线及收益假设进行比较。立即指出偏差、信心下降、收益偏移和新出现的不利影响。缺少证据意味着未知,而不是绿色。
- 权衡取舍。 针对范围、顺序、产能、资金、质量、风险、采用情况和收益提出选项。损害共同成果的局部优化属于项目群问题。任务或基线变更时保留历史记录。
- 实现收益并完成过渡。 协调采用、运营模式变更、能力移交和收益衡量。当组件必须分阶段共同产生收益时,使用 收益依赖关系与阶段控制。当证据、治理或集成成果存在重大争议或偏离轨道时,使用 保证与干预。只有在明确成果决策、剩余责任归属、运营交接和收益后续跟进后,才能关闭或调整项目群。
方法选择
采用满足需求的最小项目群模式。治理与组件节奏应分开。
| 条件 | 项目群模式 | 首要检验 |
|---|---|---|
| 成果稳定、外部关卡固定、组件分阶段交付 | 预测式/阶段治理型项目群 | 结合实际产能,组件接口和决策关卡是否可行? |
| 解决方案或收益不确定,学习结果必须改变路线图 | 迭代式/适应型项目群 | 是否有证据检查点可用于调整资金或范围? |
| 多个产品或团队向同一能力发布增量 | 增量式/发布列车协调 | 每个增量是否可用,集成证据是否逐步累积? |
| 依赖关系密集且共享专家资源 | 流程/网络协调 | 依赖项的老化时间、产能争用和升级情况是否清晰可见? |
| 涉及硬件、软件、供应商、监管或组织变革的混合情形 | 混合型项目群 | 是否有一个集成决策视图来衔接不同节奏? |
不要仅因项目群使用多个团队,就指定某种品牌化方法。应说明取舍、权限、节奏、证据和重新审视的触发条件。项目群经理负责协调;他们不会因为跟踪组件工作,就取得组件负责人的架构、产品、工程或风险接受权限。
沟通约定
针对利益相关方的决策,调整同一组证据的呈现方式:
- **赞助人/高管:**结果信心、重大偏差、可选方案、建议、所需决策、最晚有用决策日期,以及延迟决策的后果。
- **组件负责人:**依赖关系变化、接口验收、共享产能取舍、所需决策,以及哪些事项仍在其权限范围内。
- **运营/采用负责人:**能力就绪情况、培训/流程变更、支持模式、采用证据、剩余风险和交接日期。
- **供应商/合作伙伴:**提供方和接收方的义务、就绪定义、证据、商务/技术限制、升级路径和下一个检查点。
- **受影响的用户或客户:**变更内容、时间、影响、支持、不确定性,以及反馈如何影响计划。不要发布不适合该受众的内部风险详情。
切勿用组件仪表板、会议次数或完成百分比代替项目集健康状况。应按维度报告健康状况:结果、进度、依赖关系、产能、质量、采用、收益和风险。
故障排查模式
- **所有项目都显示绿色,但项目集显示红色:**检查集成、共享产能、收益归属和采用情况;不要对组件状态取平均值。
- **依赖关系存在争议:**重建提供方/接收方约定和相关证据,然后升级处理本地负责人无权决定的事项。
- **交付物陆续发布,但收益正在延迟:**验证收益假设、采用情况和运营假设,以及负面效益;应重新确定范围或停止,而不是宣称交付物等同于价值。
- **项目集变成了项目清单:**重申共同成果,移除无关组件,并将独立投资提交至投资组合治理流程。
- **赞助人在项目推进过程中改变方向:**保留原始授权和偏差记录,记录新决策,评估对组件和收益的影响,并且仅在获得授权后重新设定基线。
- **共享团队成为瓶颈:**展示相互竞争的需求及其后果;不要承诺增加工作或会议就能创造产能。
- **转型阻力:**识别受影响的岗位、决策权、激励措施、培训、反馈渠道和采用信号。将组织设计工作交由 org-design 处理;在此处继续开展项目集协调。
- **多次审查后仍无证据:**经过三轮仍无法收敛的诊断后停止,明确指出缺失的证据和决策负责人,并升级处理或暂停。
路由表
| 需求 | 路由 |
|---|---|
| 单个项目的里程碑、供应商交接、预测、恢复或收尾 | technical-project-management |
| 将已批准的需求转化为工作分解和推出计划 | implementation-planning |
| 产品押注、路线图排序或组合分配 | product-roadmapping-and-portfolio |
| 产品决策权和定期产品治理 | product-operations-and-governance |
| 企业能力、目标/过渡架构或架构决策权 | enterprise-architecture |
| 技术采用立场或标准治理 | technology-radar |
| 发布机制或上线授权 | release-engineering 和 production-readiness |
| 正在发生的服务中断或响应人员指挥 | site-reliability-engineering |
| 资本分配、公司战略或并购 | strategy-frameworks |
| 组织结构和人才设计 | org-design |
| 独立保证或问题项目干预 | 保证与干预 |
| 交付后的采用证据或收益学习 | product-adoption 和 product-lifecycle-learning |
输出约定与完成标准
产出最精简且实用的成果:项目简报、集成依赖/控制记录、收益图谱、治理决策、升级简报、利益相关者更新、恢复方案,或交接/收尾记录。区分证据、推断、假设、承诺、选项和未知事项。链接到组成部分的来源并注明负责人,不要虚构共识。
满足以下条件即视为完成:交付所请求的项目决策或成果,明确共同成果和组成部分的边界,为重要依赖关系和收益指定负责人及审查触发条件,升级尚未解决的决策权问题,并且所有声明均不超出证据所支持的范围。没有经授权的机制时,不要暗示会持续监控。
研究依据与局限
本综合内容参考了一份深入且以来源为依据的研究成果,该成果保留在开发记录中,其中包括 PMI 的 The Standard for Program Management, Fifth Edition(2024 年)、英国政府项目交付指南、地方政府协会的依赖关系指南,以及 NASA 风险管理指南。深入研究确认了收益依赖关系映射、分阶段投入、负面收益、企业风险类别和独立保证的价值。研究直接查阅了三个来源;NASA 手册 PDF 和部分英国网页无法通过抓取工具访问,因此本文未将需要这些确切文档支持的说法列为已核实内容。这些来源提供的是原则和特定司法辖区的要求,并非通用的运营模式,也不能证明任何方法都能保证成功。若实际项目受正式组织标准或法规约束,请遵循这些标准或法规。