draft-project-charter
정보
이 Claude Skill은 포괄적인 프로젝트 헌장을 작성하며, 범위, 이해관계자, 성공 기준 및 초기 위험 등록부를 정의합니다. 문제 진술, RACI 매트릭스, 마일스톤 계획, 애자일 및 고전적 방법론 모두에 대한 범위 경계를 포함합니다. 프로젝트를 공식적으로 시작하거나, 이해관계자를 조정하거나, 발견 단계에서 실제 작업 단계로 전환할 때 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/draft-project-charterClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
name: draft-project-charter description: > Redactar un acta de constitución de proyecto que defina el alcance, los interesados, los criterios de éxito y el registro inicial de riesgos. Cubre el enunciado del problema, la matriz RACI, la planificación de hitos y los límites del alcance para metodologías ágiles y clásicas. Usar al iniciar un nuevo proyecto o iniciativa, al formalizar el alcance después de un inicio informal, al alinear a los interesados antes de que comience la planificación detallada, o al pasar del descubrimiento al trabajo activo del proyecto. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: basic language: multi tags: project-management, charter, scope, stakeholders, raci, risk-register locale: es source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16
Redactar un Acta de Constitución de Proyecto
Crea un acta de constitución estructurada que establece los límites del proyecto, los acuerdos con los interesados y los criterios de éxito antes de que comience la planificación detallada. Produce un documento completo que cubre el alcance, las asignaciones RACI, la planificación de hitos y un registro inicial de riesgos, adecuado para metodologías de proyecto ágiles, clásicas o híbridas.
Cuándo Usar
- Al iniciar un nuevo proyecto o iniciativa
- Al formalizar el alcance después de un inicio informal del proyecto
- Al alinear a los interesados antes de que comience la planificación detallada
- Al crear un documento de referencia para las decisiones de alcance durante la ejecución
- Al pasar del descubrimiento/ideación al trabajo activo del proyecto
Entradas
- Requerido: Nombre del proyecto y descripción breve
- Requerido: Interesado principal o patrocinador
- Opcional: Documentación existente (propuestas, resúmenes, correos electrónicos)
- Opcional: Restricciones conocidas (presupuesto, plazo, tamaño del equipo)
- Opcional: Preferencia de metodología (ágil, clásica, híbrida)
Procedimiento
Paso 1: Recopilar el Contexto del Proyecto y Crear la Plantilla del Acta
Leer cualquier documentación existente (propuestas, correos, resúmenes) para entender el contexto del proyecto. Identificar el problema u oportunidad central que aborda el proyecto. Crear el archivo del acta con una plantilla estructurada que se completará en los pasos siguientes.
Crear un archivo llamado PROJECT-CHARTER-[PROJECT-NAME].md con esta plantilla:
# 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 | | |
Completar el ID del documento con el formato PC-[PROJECT]-[YYYY]-[NNN] (por ejemplo, PC-WEBSITE-2026-001). Escribir un enunciado del problema (2-3 oraciones) que describa la situación actual, la brecha y el impacto. Escribir un enunciado del propósito del proyecto (1 párrafo) explicando lo que se logrará.
Esperado: Archivo del acta creado con el ID del documento, el enunciado del problema y el propósito completados. El enunciado del problema es específico y describe una brecha medible.
En caso de fallo: Si el contexto del proyecto no está claro, documentar preguntas específicas para el patrocinador en una sección QUESTIONS al principio del acta. Si los documentos existentes presentan contradicciones, anotarlas en una sección OPEN ISSUES y señalarlas para resolución por parte de los interesados.
Paso 2: Definir los Límites del Alcance
Crear listas explícitas de lo que está y no está incluido en el alcance del proyecto. Escribir 3-5 entregables dentro del alcance con criterios de aceptación específicos para cada uno. Escribir 3-5 elementos fuera del alcance para prevenir la expansión del alcance. Completar la tabla de Entregables con cada entregable, sus criterios de aceptación y una fecha objetivo.
Esperado: La sección de alcance tiene listas equilibradas de elementos dentro y fuera del alcance. La tabla de Entregables contiene 3-5 entradas con criterios de aceptación específicos y verificables. Las fechas objetivo son realistas y están ordenadas lógicamente.
En caso de fallo: Si los entregables son vagos, desglosar cada uno en sub-entregables con salidas concretas. Si faltan criterios de aceptación, preguntar: "¿Cómo demostraríamos que este entregable está completo?" Si las fechas objetivo no están disponibles, marcarlas como TBD y señalarlas para la sesión de planificación de hitos.
Paso 3: Identificar Interesados y Asignar la RACI
Listar todas las personas o grupos que se verán afectados por el proyecto, que contribuirán a él o que tendrán autoridad de decisión sobre el mismo. Incluir su rol organizacional. Crear una matriz RACI que asigne cada interesado a cada entregable usando:
- R (Responsible / Responsable): Realiza el trabajo
- A (Accountable / Rendición de cuentas): Autoridad final de decisión (solo una A por entregable)
- C (Consulted / Consultado): Proporciona información antes de las decisiones
- I (Informed / Informado): Se mantiene actualizado sobre el progreso
Asegurarse de que cada entregable tenga exactamente una A y al menos una R.
Esperado: La tabla de interesados lista 5-10 personas con sus roles. La matriz RACI tiene una A por columna de entregable. Ningún entregable carece de una R ni tiene múltiples A. El patrocinador es A para la aprobación final.
En caso de fallo: Si la lista de interesados está incompleta, cruzar referencias con el organigrama y los asistentes a las reuniones de la fase de descubrimiento. Si se identifican múltiples A, escalar el conflicto al patrocinador para aclarar la autoridad de decisión. Si no existe ninguna R, marcar el entregable como no asignado y que requiere asignación de recursos.
Paso 4: Definir Criterios de Éxito e Hitos
Escribir 3-5 criterios de éxito medibles usando el formato SMART (Específico, Medible, Alcanzable, Relevante, Con límite de tiempo). Cada criterio debe vincularse a una medida cuantificable y un valor objetivo. Definir 4-6 hitos clave que representen las principales etapas del proyecto o la finalización de entregables, con fechas objetivo y dependencias de hitos anteriores.
Esperado: La tabla de Criterios de Éxito tiene 3-5 entradas con medidas específicas (por ejemplo, "Tiempo de actividad del sistema" medido como "% de disponibilidad" con objetivo "99,5%"). La tabla de Hitos muestra fases lógicas del proyecto con fechas objetivo realistas. Las dependencias están claramente indicadas.
En caso de fallo: Si los criterios de éxito son vagos (por ejemplo, "mejorar la calidad"), reescribirlos como resultados medibles con valores de referencia y objetivo. Si las fechas de los hitos son poco realistas, trabajar hacia atrás desde la fecha límite final usando duraciones estimadas y márgenes. Si las dependencias crean una lógica circular, reestructurar la secuencia de hitos o dividir los hitos conflictivos.
Paso 5: Crear el Registro Inicial de Riesgos
Identificar 5-10 riesgos que podrían afectar el éxito del proyecto. Para cada riesgo, evaluar la probabilidad (Baja/Media/Alta) y el impacto (Bajo/Medio/Alto), luego calcular la gravedad. Definir una estrategia de mitigación específica para cada riesgo y asignar un responsable del riesgo encargado del seguimiento y la respuesta. Incluir al menos un riesgo en cada categoría: alcance, cronograma, recursos, técnico y externo.
Esperado: El Registro de Riesgos tiene 5-10 entradas que cubren riesgos de alcance, cronograma, recursos, técnicos y externos. Cada riesgo tiene evaluados la probabilidad, el impacto y la gravedad. Las estrategias de mitigación son específicas y accionables. Cada riesgo tiene un responsable asignado.
En caso de fallo: Si la lista de riesgos está incompleta, revisar los límites del alcance, las dependencias, la lista de interesados y los supuestos en busca de puntos de fallo potenciales. Si las estrategias de mitigación son genéricas ("monitorear de cerca"), especificar: ¿Qué se monitoreará? ¿Con qué frecuencia? ¿Qué desencadena la acción? Si nadie acepta la responsabilidad de un riesgo, asignarla temporalmente al líder del proyecto y escalar al patrocinador.
Validación
- Archivo del acta creado con ID del documento
- El enunciado del problema es específico y medible
- El alcance tiene tanto elementos dentro como fuera del mismo
- La matriz RACI cubre todos los entregables
- Los criterios de éxito son medibles (SMART)
- Al menos 5 riesgos identificados con estrategias de mitigación
- Los hitos tienen fechas objetivo
- Sección de aprobación incluida
Errores Comunes
- Alcance sin límites: Listar elementos dentro del alcance sin elementos explícitos fuera del mismo lleva a la expansión del alcance. Siempre definir qué no se hará.
- Criterios de éxito vagos: "Mejorar el rendimiento" no es medible. Vincular cada criterio a un número con una línea base y un objetivo.
- Interesados faltantes: Los interesados que se pasan por alto aparecen tarde y desvían el proyecto. Cruzar referencias con organigramas y comunicaciones de proyectos anteriores.
- El registro de riesgos como lista de verificación: Enumerar riesgos sin planes de mitigación accionables proporciona una falsa confianza. Cada riesgo necesita una estrategia de respuesta específica.
- Acta demasiado detallada: El acta es una brújula, no un mapa. Mantenerla en 2-4 páginas. La planificación detallada ocurre después.
Habilidades Relacionadas
create-work-breakdown-structure— descomponer los entregables del acta en paquetes de trabajomanage-backlog— traducir el alcance del acta en una lista de pendientes priorizadaplan-sprint— planificar el primer sprint a partir de los entregables del actagenerate-status-report— informar el progreso en relación con los hitos del actaconduct-retrospective— revisar los supuestos del acta después de la ejecución
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
