Skill oficial · Operaciones y administración

Brief de arranque de proyecto

v1.0.0 · Actualizada el 4 de noviembre de 2026

Redacta un brief de arranque de una página: objetivo, una medida de éxito, alcance, hitos, una tabla RACI simplificada, riesgos con responsable y cómo se comunica el equipo.

Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.

Cuándo usarla

• Arranca un proyecto, un lanzamiento o un trabajo con un cliente y hace falta una sola página compartida
• En un proyecto en marcha hay desacuerdo sobre el alcance o sobre quién decide

Qué le das

• Objetivo y por qué importa ahora
• Fecha objetivo
• Personas y roles
• Restricciones y decisiones conocidas (opcional)

Qué obtienes

Un brief de una página en Markdown con objetivo, medida de éxito, tabla de alcance, hitos, roles RACI simplificados, riesgos y plan de comunicación.

Cómo funciona

1. Escribe el objetivo en 1 o 2 frases Di qué será distinto y por qué importa ahora. La guía de kickoff de Asana dice que alinearse en “hacia qué trabajan y por qué importa este trabajo” es la parte más importante de un arranque.
2. Elige una medida de éxito Un número y una fecha (“40 clientes pasados al plan nuevo antes del 30 de junio”) o una prueba de sí o no que cualquiera pueda comprobar. La guía de arranque de Atlassian llama a estas pruebas “una definición compartida de «terminado»”. Criterio por defecto de esta skill: una medida principal y como máximo 2 límites de control (cosas que no deben empeorar).
3. Divide el alcance en lo que entra y lo que no Lista de 3 a 6 elementos dentro del alcance y al menos 3 fuera. Los que quedan fuera son los que alguien pedirá a mitad de camino; nombrarlos pronto es como se evita que el alcance crezca sin control. Si un elemento no está claro, ponlo en preguntas abiertas, no en el alcance.
4. Fija de 3 a 6 hitos Cada uno es algo terminado y comprobable, con fecha y responsable (“página de precios publicada en staging”), no una actividad (“trabajar en precios”). El último hito es la fecha de la medida de éxito.
5. Completa la tabla RACI simplificada Una fila por línea de trabajo. R (Responsible) hace el trabajo; A (Accountable) aprueba y responde del resultado; C (Consulted) revisa antes de avanzar; I (Informed) recibe noticias del avance. La guía de RACI de Asana: “Solo debe haber un rol Accountable por tarea”. Criterio por defecto de esta skill: también un solo Accountable para todo el proyecto, nombrado arriba.
6. Lista los 3 a 5 riesgos principales Para cada uno: qué puede salir mal, qué probabilidad tiene (alta/media/baja), qué haces ya y un responsable. Una forma rápida de encontrarlos es el pre-mortem de Atlassian: el equipo escribe en silencio qué podría salir mal, luego vota las mayores amenazas y da a cada riesgo principal una acción con responsable. Un riesgo sin responsable es una preocupación, no un plan.
7. Di cómo se comunica el equipo Dónde se habla a diario (canal), cómo se comparte el avance (una actualización semanal por escrito, su día y su autor), cuándo se reúne el grupo y dónde se anotan las decisiones. La guía de kickoff de Asana lo incluye como parte habitual del arranque.
8. Lista las preguntas abiertas y lo ya decidido Las preguntas abiertas llevan responsable y fecha. Lo ya decidido va en una línea cada cosa, para que el arranque no lo vuelva a abrir.

El SKILL.md

El archivo completo, tal como lo lee tu IA. Descargarlo

---
name: project-kickoff-brief
description: Redacta un brief de arranque de proyecto de una página a partir de un objetivo y notas sueltas - el objetivo y por qué importa, una medida de éxito, qué entra y qué no en el alcance, hitos con fecha, roles en una tabla RACI simplificada con un solo responsable final, los riesgos principales con un responsable cada uno y cómo se comunica el equipo. Úsala cuando arranca un proyecto, alguien pide un documento de kickoff, un acta de constitución (project charter) o un brief del proyecto, o un equipo necesita acordar quién hace qué antes de empezar.
---

# Brief de arranque de proyecto

Un brief de arranque logra que todos estén de acuerdo en por qué existe el proyecto, cómo se ve “terminado” y quién se encarga de qué, antes de empezar a trabajar. Cabe en una página. Lo que no cambia lo que la gente hace este mes va en un documento enlazado.

## Cuándo usarla

- Arranca un proyecto, un lanzamiento, una migración o un trabajo con un cliente y la gente necesita una sola página compartida.
- Alguien pide un “documento de kickoff”, un “acta de constitución del proyecto”, un “resumen del proyecto en una página” o una “lectura previa para la reunión de arranque”.
- El proyecto ya está en marcha pero hay desacuerdo sobre el alcance o sobre quién decide. Escribe el brief para reordenar.
- No para una especificación de producto ni un documento de requisitos. Usa un PRD para lo que hace el producto; este brief cubre cómo funciona el proyecto.

## Qué necesitas

- El objetivo y por qué importa ahora. Si falta, pregunta una vez: “¿Qué cambia para el negocio o para el cliente cuando esto esté hecho?”.
- La fecha límite o fecha objetivo. Si no la hay, escribe “[sin fecha]” y ponla como la primera pregunta abierta.
- Las personas implicadas y sus roles. Si no se conocen los roles, lista los nombres y marca la tabla RACI con “[borrador, confirmar en el arranque]”.
- Opcional: presupuesto, restricciones conocidas, proyectos relacionados y lo que ya esté decidido.

## Pasos

1. **Escribe el objetivo en 1 o 2 frases.** Di qué será distinto y por qué importa ahora. La guía de kickoff de Asana dice que alinearse en “hacia qué trabajan y por qué importa este trabajo” es la parte más importante de un arranque.
2. **Elige una medida de éxito.** Un número y una fecha (“40 clientes pasados al plan nuevo antes del 30 de junio”) o una prueba de sí o no que cualquiera pueda comprobar. La guía de arranque de Atlassian llama a estas pruebas “una definición compartida de «terminado»”. Criterio por defecto de esta skill: una medida principal y como máximo 2 límites de control (cosas que no deben empeorar).
3. **Divide el alcance en lo que entra y lo que no.** Lista de 3 a 6 elementos dentro del alcance y al menos 3 fuera. Los que quedan fuera son los que alguien pedirá a mitad de camino; nombrarlos pronto es como se evita que el alcance crezca sin control. Si un elemento no está claro, ponlo en preguntas abiertas, no en el alcance.
4. **Fija de 3 a 6 hitos.** Cada uno es algo terminado y comprobable, con fecha y responsable (“página de precios publicada en staging”), no una actividad (“trabajar en precios”). El último hito es la fecha de la medida de éxito.
5. **Completa la tabla RACI simplificada.** Una fila por línea de trabajo. R (Responsible) hace el trabajo; A (Accountable) aprueba y responde del resultado; C (Consulted) revisa antes de avanzar; I (Informed) recibe noticias del avance. La guía de RACI de Asana: “Solo debe haber un rol Accountable por tarea”. Criterio por defecto de esta skill: también un solo Accountable para todo el proyecto, nombrado arriba.
6. **Lista los 3 a 5 riesgos principales.** Para cada uno: qué puede salir mal, qué probabilidad tiene (alta/media/baja), qué haces ya y un responsable. Una forma rápida de encontrarlos es el pre-mortem de Atlassian: el equipo escribe en silencio qué podría salir mal, luego vota las mayores amenazas y da a cada riesgo principal una acción con responsable. Un riesgo sin responsable es una preocupación, no un plan.
7. **Di cómo se comunica el equipo.** Dónde se habla a diario (canal), cómo se comparte el avance (una actualización semanal por escrito, su día y su autor), cuándo se reúne el grupo y dónde se anotan las decisiones. La guía de kickoff de Asana lo incluye como parte habitual del arranque.
8. **Lista las preguntas abiertas y lo ya decidido.** Las preguntas abiertas llevan responsable y fecha. Lo ya decidido va en una línea cada cosa, para que el arranque no lo vuelva a abrir.

## Formato de salida

```markdown
# [Nombre del proyecto] — brief de arranque

**Responsable final:** [un nombre] · **Inicio:** [fecha] · **Fecha objetivo:** [fecha o “sin fecha”]

## Objetivo
[1–2 frases: qué cambia, para quién y por qué ahora.]

## Medida de éxito
- **Principal:** [número + fecha, o prueba de sí o no]
- **Límites de control:** [lo que no debe empeorar, o quitar]

## Alcance
| Dentro del alcance | Fuera del alcance |
|---|---|
| [elemento] | [elemento] |

## Hitos
| Hito (algo terminado) | Responsable | Fecha |
|---|---|---|
| [hito] | [nombre] | [fecha] |

## Roles (RACI simplificada)
| Línea de trabajo | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| [línea de trabajo] | [nombre] | [un nombre] | [nombres] | [nombres o grupo] |

## Riesgos
| Riesgo | Probabilidad | Qué hacemos ya | Responsable |
|---|---|---|---|
| [riesgo] | [alta/media/baja] | [acción] | [nombre] |

## Cómo nos comunicamos
- **Día a día:** [canal]
- **Avance:** [actualización por escrito, día, autor]
- **Reuniones:** [cuáles, cada cuánto]
- **Decisiones anotadas en:** [lugar]

## Ya decidido
- [decisión, una línea]

## Preguntas abiertas
- [pregunta] — [responsable], antes del [fecha]
```

## Ejemplo

**Entrada:** “Vamos a pasar a nuestros 120 clientes activos de la herramienta de facturación antigua (Billwise) a Stripe. El arranque es el 7 de abril; Billwise se cancela el 30 de junio. Lo lleva Daniela, Marco hace la integración, Lucía se ocupa de los correos a clientes, y finanzas (Elena) tiene que aprobar la nueva plantilla de factura antes del 2 de mayo. El CEO, Tomás, lo quiere terminado antes del cambio de precios del 1 de julio. Plan de Marco: 5 cuentas internas de prueba facturando bien en el modo de prueba de Stripe antes del 25 de abril, todos los clientes en producción antes del 13 de junio. Lucía envía el aviso antes del 16 de mayo, luego un recordatorio 1 semana antes de que se pase cada cliente, y llama por teléfono a las 20 cuentas principales. No hacemos: el historial de clientes dados de baja, un portal de facturación de autoservicio, cambios en el sistema contable. Nos preocupa: que las tarjetas guardadas no se traspasen; que a alguien se le cobre dos veces el mes del cambio. Los pagos fallidos no deben subir. Hablamos en #billing-migration, Daniela escribe una actualización los viernes, nos reunimos 20 minutos los martes y las decisiones van en el documento del proyecto. Ya decidimos que no habrá cambios de precio durante la migración. Elena quiere saber si mantenemos Billwise en solo lectura un mes después de cancelarlo”.

**Salida:**

```markdown
# Migración de la facturación a Stripe — brief de arranque

**Responsable final:** Daniela · **Inicio:** 7 de abril · **Fecha objetivo:** 30 de junio

## Objetivo
Pasar a todos los clientes de Billwise a Stripe antes del cambio de precios del 1 de julio, para que los precios nuevos entren en vigor en un solo sistema y se pueda cancelar Billwise.

## Medida de éxito
- **Principal:** 120 de 120 clientes activos facturados con Stripe antes del 30 de junio.
- **Límites de control:** A ningún cliente se le cobra dos veces ni se le deja sin cobrar en ningún mes; los pagos fallidos se mantienen en el nivel mensual actual o por debajo.

## Alcance
| Dentro del alcance | Fuera del alcance |
|---|---|
| Traspasar las suscripciones activas y las tarjetas guardadas | Cambios de precio (decidido: ninguno durante la migración) |
| Nueva plantilla de factura aprobada por finanzas | Traspasar el historial de clientes dados de baja |
| Correos a clientes antes y después del cambio | Un nuevo portal de facturación de autoservicio |
| Cancelar Billwise | Cambios en el sistema contable |

## Hitos
| Hito (algo terminado) | Responsable | Fecha |
|---|---|---|
| El modo de prueba de Stripe factura bien 5 cuentas internas | Marco | 25 de abril |
| Plantilla de factura aprobada | Elena | 2 de mayo |
| Correo de aviso a clientes enviado | Lucía | 16 de mayo |
| Los 120 clientes en producción en Stripe | Marco | 13 de junio |
| Billwise cancelado | Daniela | 30 de junio |

## Roles (RACI simplificada)
| Línea de trabajo | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Integración y traspaso de datos | Marco | Daniela | Elena | Tomás |
| Facturas | Marco | Elena | Daniela | Lucía |
| Correos a clientes | Lucía | Daniela | Elena | Tomás |

## Riesgos
| Riesgo | Probabilidad | Qué hacemos ya | Responsable |
|---|---|---|---|
| Las tarjetas guardadas no se traspasan y los clientes tienen que volver a ingresarlas | Media | Preguntar esta semana al soporte de Billwise si permite exportar las tarjetas a Stripe | Marco |
| A un cliente se le cobra en los dos sistemas el mes del cambio | Media | Desactivar cada suscripción de Billwise el mismo día que empieza en Stripe; lista de control diaria | Marco |
| Los clientes ignoran el aviso y no se enteran del cambio | Alta | Enviar el aviso antes del 16 de mayo y un recordatorio 1 semana antes de cada traspaso; Lucía llama a las 20 cuentas principales | Lucía |

## Cómo nos comunicamos
- **Día a día:** #billing-migration
- **Avance:** actualización por escrito cada viernes, de Daniela
- **Reuniones:** seguimiento de 20 minutos los martes
- **Decisiones anotadas en:** la sección “Decisiones” del documento del proyecto

## Ya decidido
- No hay cambios de precio durante la migración.

## Preguntas abiertas
- ¿Mantenemos Billwise en solo lectura un mes después de cancelarlo? — Elena, antes del [fecha a fijar en el arranque]
```

## Comprobaciones antes de enviar

- [ ] El objetivo dice por qué ahora, y la medida de éxito es un número con fecha o una prueba de sí o no.
- [ ] Fuera del alcance hay al menos 3 elementos que alguien podría pedir de forma razonable.
- [ ] Cada hito es algo terminado, con un responsable y una fecha.
- [ ] Cada fila RACI tiene exactamente un Accountable, y el proyecto tiene un responsable final nombrado arriba.
- [ ] Cada riesgo tiene una acción que se toma ya y un responsable.
- [ ] No aparece ningún nombre, fecha ni número que no esté en la entrada; los huecos se marcan con “[sin fecha]” o se listan como preguntas abiertas.
- [ ] Cabe en una página.

## Errores comunes

- Escribir una medida de éxito que nadie puede comprobar (“mejorar la facturación”). Pregunta qué número o prueba lo demostraría.
- Dejar vacío lo que queda fuera del alcance. Ahí empiezan las discusiones en la semana 4.
- Dos Accountable en una fila. Si dos personas tienen que estar de acuerdo, haz a una Accountable y a la otra Consulted.

Compártela con tu equipo

Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo

Agregar al pod de mi equipo

Historial de cambios

• v1.0.0 · 4 de noviembre de 2026 · First release.