Una checklist de go / no-go convierte "parece listo" en una decisión que puedes explicar. Cada criterio tiene un responsable, un umbral y una evidencia. Si eres desarrollador en solitario, eres todos los responsables, y escribirlo igual te impide saltarte los incómodos.
Plantilla para copiar y pegar
DECISIÓN DE LANZAMIENTO: [App], versión [x.y.z] (build [n]), fecha [fecha]
Quien decide: [nombre]
| # | Criterio | Responsable | Evidencia (enlace / nota) | ¿Go? |
|---|------------------------------------------------------------|-------------|-------------------------------|------|
| 1 | Sin bugs de cierre o pérdida de datos abiertos en la build | [nombre] | [lista de issues, log de cierres] | S/N |
| 2 | Los flujos principales pasan en la build de lanzamiento | [nombre] | [notas de prueba, fecha] | S/N |
| 3 | Instalación y actualización desde la versión anterior | [nombre] | [dispositivo, versiones] | S/N |
| 4 | Problemas conocidos documentados y aceptados | [nombre] | [lista de problemas conocidos] | S/N |
| 5 | Inicio de sesión, pagos y permisos funcionan | [nombre] | [notas de prueba] | S/N |
| 6 | La ficha de la tienda, las notas y las capturas coinciden | [nombre] | [enlace al borrador] | S/N |
| 7 | Existe un plan de rollback o de parada | [nombre] | [enlace al plan] | S/N |
| 8 | Alguien vigila los cierres tras el lanzamiento | [nombre] | [quién, hasta cuándo] | S/N |
Cualquier "N" en 1-3 o 5 = NO-GO, salvo que quien decide escriba por qué.
Decisión: GO / NO-GO / GO con condiciones: [condiciones]
Ejemplo (inventado)
DECISIÓN DE LANZAMIENTO: Pocket Budget, 1.2.0 (build 57), 2026-10-17
Quien decide: Sam
1 Cierres/pérdida de datos: ninguno abierto - lista de issues revisada a las 10:15 - S
2 Flujos principales: añadir, editar y borrar una entrada pasan en la build de lanzamiento - S
3 Actualización desde 1.1.4: probada en dos dispositivos - S
4 Problemas conocidos: exportación CSV lenta, aceptada - S
5 Inicio de sesión/permisos: no se probó el camino de permiso de notificaciones denegado - N
...
Decisión: GO con condiciones: probar el camino de permiso denegado antes de enviar.
Cómo adaptarla
- Cambia los criterios a tu app. Una app offline-first necesita una fila sobre el modo sin conexión; una app con compras dentro de la app necesita una fila de compras.
- Escribe los umbrales como sí/no. "Parece estable" no es un criterio. "Sin bugs de cierre abiertos en la build de lanzamiento" sí lo es.
- Prueba la build de lanzamiento, no la de depuración. El comportamiento puede cambiar, así que la evidencia de otro artefacto no cuenta.
- Nombra a una sola persona que decida. Los grupos que votan se dispersan. Una persona decide tras escuchar a los responsables.
- Guarda la copia rellenada. En la siguiente versión verás qué aceptaste la última vez.
Relacionados: checklist de hotfix, plan de rollback y de parada y el hub checklists de pruebas de apps móviles.
¿Necesitas testers en la build de lanzamiento antes de decidir? Empieza gratis.