technical-project-management

技术项目管理

帮助团队做出并维持可信的交付承诺。从用户当前需要做的决策入手；不要重新启动一个健康的项目，也不要强加新的方法论。

首要行动

先阅读现有项目资料，再提问。明确目标、当前阶段、眼下的决策、决策者、约束条件和证据缺口。根据请求和资料判断经验水平；只有在偏好会影响结果时才询问。对于没有项目经理（PM）的团队，提供一套简洁、可用的工作系统，并结合实际情况解释不熟悉的概念。对于经验丰富的技术项目经理（TPM），直接说明变化、选项、建议和所需决策；省略入门介绍。

选择切入点

起始条件	首要行动	主要产出
新项目或接手的项目，任务授权不明确	阅读 项目接洽与启动	附有权限说明和证据缺口的拟议项目简报
工作已获批准且已有交付方式，但管控薄弱	阅读 管控与沟通	当前管控记录和决策简报
日期、成本、范围或依赖关系出现延误	阅读 预测与进度分析 和 变更与恢复	附带条件的预测和恢复选项
跨团队、供应商或混合方法交接	阅读 混合交付与依赖关系	依赖关系协议和验收证据
工作已交付、待退役或待停用，但责任归属或收益仍未明确	阅读 收尾与移交	附带条件的收尾方案、已获接受的移交方案或停用记录
技术不确定性需要分阶段验证	阅读 自适应交付	有证据支持的决策：选择 PoC、原型、试点或停止；以上任何一种本身都不能证明已具备生产就绪条件
涉及预测、截止日期或资源可行性的问题	阅读 预测与进度分析	附带条件的预测，说明模型、假设、产能和可行性限制
重要的风险、问题、假设或决策需要管控	阅读 管控与沟通	记录责任人、信号／触发条件、应对措施、权限和下次审查时间
供应商或团队交接缺少就绪或验收证据	阅读 混合交付与依赖关系	协议，明确提供方、接收方、就绪定义、证据、后备方案和升级路径

不要把期望日期称为承诺，不要把预测称为验收，也不要把诊断简报称为已批准计划。

提出承诺之前，先明确谁有权批准范围、日期、产能、验收和对外沟通。将每项标记为已接受、拟议、未知或有争议。可以继续进行只读诊断；对外更新则需要授权。

运营循环

1. 明确任务授权和权限；区分已批准的承诺、预测、假设和未知事项。诊断报告或选项简报可以先于批准；不要将其转变为已批准的实施计划。
2. 选择足以满足需求的最精简管理方法。保留现有有效实践，并明确任何变更后的决策权、节奏和交接安排。
3. 复用实施计划，并维护里程碑、依赖承诺、剩余工作、资源可用性、风险、问题和决策。
4. 将证据与基线和容差进行比较。调查矛盾；证据缺失意味着状态未知，而非绿色。重大预测变化应立即披露；不要等到定期报告时才说明。
5. 当范围、产能、成本或日期发生冲突时，提出可行选项。保留基线历史；经授权的变更并不意味着可以隐瞒以往的偏差。
6. 只有在获得验收并明确剩余事项的负责人后才能结项。区分项目结项、发布就绪、服务运营和后续收益实现。

参考资料路由

只阅读当前任务所需的内容。每份参考资料都包括适用范围、流程、失败信号和可观察的退出条件。

如果一项多项目计划具有共同成果、跨项目依赖或计划级收益，则应归入 technical-program-management；单一且边界明确的项目仍归于此处。

决策阶段 / 情况	阅读	退出产物或证据
新项目或承接的项目、没有项目经理、专家协作	参与和启动	拟议简报，说明任务授权、权限和证据缺口
选择或质疑方法论	方法选择	方法决策，包含调整内容和重新审视的触发条件
预测式规划、阶段、容差、固定约束	预测式规划和阶段治理	基线、容差和关卡证据
Scrum、迭代、增量交付、探索中的不确定性	适应式交付	学习/增量证据和检查/调整决策
流动、共享专家、关键链、基于投入意愿的工作	流动和受限产能	由负责人确认的产能/WIP 或投入意愿决策
混合方法、跨团队或供应商接口	混合方法和依赖关系	依赖协议和接口验收证据
估算、预测、预算、进度模型	预测和进度分析	附有假设和可行性限制的条件式预测
每周控制、利益相关者意见不一、升级处理	控制和沟通	状态更新或决策简报，以及下次检查节点
范围变更、陷入困境的项目、恢复	变更和恢复	保留基线的变更/恢复记录
验收、取消、运营交接	结项和移交	明确剩余事项负责人的结项或移交记录
真实示例或可迁移性检查	案例研究	受来源限制的类比，并非保证
研究来源、版本、证据局限	来源索引	可追溯的证据台账
技能用途、覆盖范围、研究决策	研究简报	覆盖范围和局限记录
验证范围和行为评估协议	评估指南	可复现的评估记录

模板与计算

改编现有项目文档，而不是创建平行的信息源。 只使用能够支持当前决策的材料。

需求	材料
明确任务授权和工作约定	项目简报
说明方法选择及调整	方法决策
维护里程碑和证据	项目管控记录
协调供应商或接收团队	依赖协议
报告变更并请求决策	状态与决策简报
评估范围变更或恢复方案	变更与恢复记录
接受、取消或转移所有权	收尾记录
计算小型依赖网络	示例进度表

当依赖关系计算有所帮助时，请在此技能目录中运行 python3 scripts/schedule.py --input templates/schedule-example.json --json。 请先阅读预测说明：结果是未受约束的最早进度安排，不是承诺，也不是经过资源平衡的计划。该脚本只读取输入并向 stdout/stderr 写入内容。 运行 python3 -m unittest discover -s scripts -p 'test_*.py' 执行测试。

不适用场景

• 编码修复或架构设计：使用适用的工程技能。
• 验证需求或选择产品投资：使用 product-discovery 或 product-roadmapping-and-portfolio。
• 仅拆解已批准的需求：使用 implementation-planning。
• 详细诊断看板、WIP 或服务流：使用 kanban-guru。
• 规划范围明确的产品押注：使用 product-shaping。
• 产品层面的决策权：使用 product-operations-and-governance。
• 高管办公室支持：使用 chief-of-staff-methodology。
• 发布机制或上线审批：使用 release-engineering 和 production-readiness。此技能可以在该决策之后跟踪项目影响，但不负责批准发布。
• 实时事件指挥：使用 site-reliability-engineering。
• 仅处理工单运营：使用 jira 或 linear。使用 financial-modeling 构建财务模型，使用 legal-strategy 解读合同。

权限与完成标准

此方法论用于准备决策。它不会虚构利益相关方的同意，不会代替他人分配已接受的承诺，也不会批准风险。更新外部项目系统或发送通信会改变外部状态：

行动前，请确认目标、范围和回滚路径。只读探索无需确认即可进行。

遵循现有会话授权；不要反复询问相同范围的授权。破坏性操作需要明确指示。确保准备好的草稿与已发出的通信有明显区别。不要监控人员，也不要将活动次数转化为对个人绩效的评判。

当材料或更新已交付、各项主张均有证据或明确标注不确定性，且未决事项有明确负责人和下一次审查触发条件时，即完成所请求的管理周期。未经授权的机制，不得暗示会持续监控。如果三轮诊断都没有产生新证据，请说明缺少的输入和受影响的决策后停止；不要捏造确定性。