Agent-almanac draft-project-charter
git clone https://github.com/pjt222/agent-almanac
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/zh-CN/skills/draft-project-charter" ~/.claude/skills/pjt222-agent-almanac-draft-project-charter-84679c && rm -rf "$T"
i18n/zh-CN/skills/draft-project-charter/SKILL.md起草项目章程
创建结构化的项目章程,在详细规划开始前确立项目边界、干系人协议和成功标准。生成涵盖范围、RACI 分配、里程碑规划和初始风险登记册的综合文档,适用于敏捷、传统或混合项目管理方法。
适用场景
- 启动新项目或计划
- 在非正式项目启动后正式确定范围
- 在详细规划开始前对齐干系人
- 创建执行过程中范围决策的参考文档
- 从探索/构思阶段过渡到主动项目工作
输入
- 必填:项目名称和简要描述
- 必填:主要干系人或发起人
- 可选:现有文档(提案、简报、邮件)
- 可选:已知约束(预算、截止日期、团队规模)
- 可选:方法论偏好(敏捷、传统、混合)
步骤
第 1 步:收集项目背景并创建章程模板
阅读所有现有文档(提案、邮件、简报)以了解项目背景。识别项目所解决的核心问题或机会。创建章程文件并填入结构化模板,后续步骤将逐步完善内容。
创建名为
PROJECT-CHARTER-[PROJECT-NAME].md 的文件,使用以下模板:
# Project Charter: [Project Name] ## Document ID: PC-[PROJECT]-[YYYY]-[NNN] ### 1. Problem Statement [2-3 sentences describing the problem or opportunity this project addresses] ### 2. Project Purpose [What the project will achieve and why it matters] ### 3. Scope #### In Scope - [Deliverable 1] - [Deliverable 2] #### Out of Scope - [Exclusion 1] - [Exclusion 2] ### 4. Deliverables | # | Deliverable | Acceptance Criteria | Target Date | |---|------------|---------------------|-------------| | 1 | | | | ### 5. Stakeholders & RACI | Stakeholder | Role | D1 | D2 | D3 | |-------------|------|----|----|-----| | | | | | | *R=Responsible, A=Accountable, C=Consulted, I=Informed* ### 6. Success Criteria | # | Criterion | Measure | Target | |---|-----------|---------|--------| | 1 | | | | ### 7. Milestones | Milestone | Target Date | Dependencies | |-----------|-------------|--------------| | | | | ### 8. Risk Register | ID | Risk | Likelihood | Impact | Severity | Mitigation | Owner | |----|------|------------|--------|----------|------------|-------| | R1 | | | | | | | *Likelihood/Impact: Low, Medium, High* *Severity = Likelihood × Impact* ### 9. Assumptions and Constraints #### Assumptions - [Key assumption 1] #### Constraints - [Key constraint 1] ### 10. Approval | Role | Name | Date | |------|------|------| | Sponsor | | | | Project Lead | | |
使用格式 PC-[PROJECT]-[YYYY]-[NNN] 填写文档 ID(例如 PC-WEBSITE-2026-001)。撰写问题陈述(2-3 句话),描述当前状况、差距和影响。撰写项目目的陈述(1 段话)说明将要实现的内容。
预期结果: 章程文件已创建,文档 ID、问题陈述和目的均已填写。问题陈述具体且描述了可衡量的差距。
失败处理: 如果项目背景不清晰,在章程顶部的 QUESTIONS 部分记录向发起人提出的具体问题。如果现有文档存在冲突,在 OPEN ISSUES 部分注明矛盾之处,并标记以供干系人解决。
第 2 步:定义范围边界
明确列出项目范围内和范围外的内容。写出 3-5 个范围内的可交付成果,并为每项制定具体的验收标准。写出 3-5 个范围外的条目以防止范围蔓延。在可交付成果表格中填入每项可交付成果、其验收标准和目标日期。
预期结果: 范围部分包含均衡的范围内和范围外列表。可交付成果表格包含 3-5 个条目,具有具体、可测试的验收标准。目标日期切实可行且逻辑有序。
失败处理: 如果可交付成果模糊,将每项分解为具有具体输出的子可交付成果。如果缺少验收标准,请问:"我们如何证明此可交付成果已完成?"如果目标日期不可用,标记为 TBD 并标记以供里程碑规划会议跟进。
第 3 步:识别干系人并分配 RACI
列出所有将受项目影响、参与项目或对项目拥有决策权的个人或群体。包含其组织角色。创建 RACI 矩阵,使用以下方式将每位干系人映射到每项可交付成果:
- R(负责人):执行工作
- A(问责人):最终决策权(每项可交付成果只有一个 A)
- C(咨询人):在决策前提供意见
- I(知情人):及时了解进展
确保每项可交付成果只有一个 A,并且至少有一个 R。
预期结果: 干系人表格列出 5-10 人及其角色。RACI 矩阵每列可交付成果只有一个 A。没有可交付成果缺少 R 或有多个 A。发起人是最终审批的问责人 (A)。
失败处理: 如果干系人列表不完整,参照组织结构图和探索阶段的会议参与者进行交叉核对。如果识别出多个问责人 (A),将冲突上报给发起人进行决策权限澄清。如果没有负责人 (R),将可交付成果标记为未分配,并需要资源调配。
第 4 步:定义成功标准和里程碑
使用 SMART 格式(具体、可衡量、可实现、相关、有时限)写出 3-5 个可衡量的成功标准。每项标准应与可量化的衡量指标和目标值相关联。定义 4-6 个代表主要项目阶段或可交付成果完成节点的关键里程碑,包含目标日期和对先前里程碑的依赖关系。
预期结果: 成功标准表格包含 3-5 个条目,具有具体的衡量指标(例如,"系统可用性"衡量为"可用率百分比",目标为"99.5%")。里程碑表格显示合理的项目阶段,目标日期切实可行。依赖关系清晰标注。
失败处理: 如果成功标准模糊(例如"提升质量"),重写为具有基线和目标值的可衡量结果。如果里程碑日期不切实际,从最终截止日期逆向推算,使用预估工期和缓冲时间。如果依赖关系形成循环逻辑,重新组织里程碑顺序或拆分冲突的里程碑。
第 5 步:创建初始风险登记册
识别 5-10 个可能影响项目成功的风险。对每个风险评估可能性(低/中/高)和影响(低/中/高),然后计算严重程度。为每个风险定义具体的缓解策略,并指定负责监控和响应的风险负责人。至少在以下每个类别中包含一个风险:范围、进度、资源、技术和外部。
预期结果: 风险登记册包含 5-10 个条目,涵盖范围、进度、资源、技术和外部风险。每个风险已评估可能性、影响和严重程度。缓解策略具有可操作性和针对性。每个风险已指定负责人。
失败处理: 如果风险列表不完整,审查范围边界、依赖关系、干系人列表和假设条件中的潜在失败点。如果缓解策略过于笼统("密切监控"),请具体说明:监控什么?多久一次?什么情况触发行动?如果没有人接受风险负责人角色,暂时分配给项目负责人并上报给发起人。
验证清单
- 章程文件已创建并包含文档 ID
- 问题陈述具体且可衡量
- 范围包含范围内和范围外条目
- RACI 矩阵涵盖所有可交付成果
- 成功标准可衡量(SMART 格式)
- 至少识别 5 个风险并制定缓解策略
- 里程碑包含目标日期
- 审批部分已包含
常见问题
- 范围无边界:列出范围内条目而不明确范围外条目会导致范围蔓延。始终定义不包含的内容。
- 模糊的成功标准:"提升性能"无法衡量。将每个标准与具有基线和目标的数字绑定。
- 遗漏干系人:被忽略的干系人会在后期出现并扰乱项目。交叉核对组织结构图和先前的项目沟通记录。
- 风险登记册流于形式:列出风险而没有可操作的缓解计划会产生虚假的安全感。每个风险需要具体的应对策略。
- 章程过于详细:章程是指南针,而非地图。保持在 2-4 页以内。详细规划在之后进行。
相关技能
— 将章程可交付成果分解为工作包create-work-breakdown-structure
— 将章程范围转化为优先级排列的待办事项列表manage-backlog
— 根据章程可交付成果规划第一个冲刺plan-sprint
— 报告针对章程里程碑的进展generate-status-report
— 执行后回顾章程假设条件conduct-retrospective