Qué decide el go/no-go
Un go/no-go es el momento en que el negocio dice: esta versión del CRM puede pasar a producción, en esta fecha. O dice: todavía no. No es una formalidad al final de la prueba. Es la razón por la que se hizo la prueba.
Un buen go/no-go tiene tres partes:
- Hechos. Qué se probó, qué pasó y qué sigue abierto. Sacados de los resultados de las pruebas, no de la memoria.
- Una valoración. Los responsables de los procesos dicen si pueden hacer su trabajo con esta versión, y con qué condiciones.
- Una decisión. El comité de dirección sopesa los hechos y las valoraciones frente a la fecha de puesta en producción, y decide.
A la mayoría de las reuniones de go/no-go que salen mal les falta la primera parte. La gente discute sobre la gravedad de una incidencia, o sobre si un proceso se probó siquiera, porque nadie tiene las cifras. El resto de esta guía trata de asegurarse de que los hechos están ahí antes de que empiece la reunión.
Criterios de salida: acuérdalos antes del primer día de pruebas
Los criterios de salida dicen cuándo la prueba es lo bastante buena para pasar a producción. Acuérdalos con el comité de dirección antes del primer día de pruebas. Al final, los ánimos están caldeados y las fechas están cerca. Ese es el peor momento para decidir qué cuenta.
Criterios que funcionan en la mayoría de las puestas en producción de CRM:
- No hay ninguna incidencia Critical abierta.
- Todos los casos de prueba Must han pasado.
- Cada incidencia High abierta tiene una solución provisional o una fecha de corrección que el negocio acepta.
- Cada caso de prueba del alcance tiene un resultado.
- El responsable de cada proceso ha dado su sign-off.
Acuerda qué significan las palabras
Los criterios solo funcionan cuando todos usan la misma escala. Anota qué significa cada nivel de gravedad y compártelo por igual con los testers y con el comité de dirección:
| Gravedad | Qué significa |
|---|---|
| Critical | Un proceso clave no funciona y no hay forma de sortearlo, o se pierden datos o son incorrectos. Bloquea la puesta en producción. |
| High | Un proceso clave solo funciona con una solución provisional, o falla una función importante. |
| Medium | Una función no se comporta como debería, pero hay una forma razonable de sortearlo. |
| Low | Estético: un texto, la disposición, una pequeña molestia. |
Haz lo mismo con la prioridad. Un caso de prueba marcado como Must cubre lo que tiene que funcionar el primer día, como crear una oferta o enrutar un caso. Si falla un caso de prueba Must, la puesta en producción está en riesgo. Consulta Casos de prueba que entienden los testers de negocio para saber cómo fijar las prioridades.
Anota lo que no se prueba
Toda UAT deja algo fuera: un país que pasa a producción más tarde, un informe que no está listo, una integración probada solo en la prueba de sistema. Ponlo por escrito antes de la prueba. Así nadie podrá decir en el go/no-go que daba por hecho que estaba cubierto.
Quién decide
Participan dos grupos de personas, con roles distintos.
Los responsables de los procesos dan el sign-off
Para cada proceso o grupo de la prueba, una persona del negocio da el sign-off: el director de ventas para lead to cash, el responsable de atención al cliente para la gestión de casos, el responsable de finanzas para la facturación. Saben lo que necesitan sus equipos y vivirán con el resultado. Su sign-off dice: mi gente puede hacer su trabajo con esta versión.
Nómbralos al inicio del proyecto, no en la última semana. Un responsable de proceso que ve la prueba por primera vez en la reunión de go/no-go firmará sin leer o pedirá otra semana.
El comité de dirección decide
El comité de dirección toma la decisión para toda la puesta en producción. Suele incluir al patrocinador del negocio, al jefe de proyecto, a un responsable de TI y, si hay un partner de implantación, a alguien del partner. Sopesa cosas que un responsable de proceso por sí solo no ve: un contrato con el CRM antiguo que vence, un plan de formación, un fin de semana de migración, otros proyectos en la misma fecha.
El líder de pruebas prepara, pero no decide
El líder de pruebas aporta los hechos y un consejo. El líder de pruebas no da el sign-off en nombre del negocio ni toma la decisión. Mantener separados estos roles es lo que hace que la decisión se sostenga cuando algo sale mal después de la puesta en producción.
El informe: qué incluye
El informe de go/no-go es para personas que no estuvieron en la prueba. Que sea breve: una página, con los detalles detrás para quien los quiera.
- Un consejo. Go, go con condiciones o no-go, con los motivos en una o dos líneas.
- Alcance. Qué procesos e historias de usuario estaban en la prueba, y qué no se probó.
- Qué se probó. El entorno, la versión y la build. Un resultado pertenece a una versión concreta del sistema.
- Las cifras. Casos de prueba pasados, fallidos, bloqueados y sin terminar.
- Por grupo o proceso. Las mismas cifras, con el sign-off de cada grupo.
- Por prioridad. Cuántos casos de prueba Must, Should y Could pasaron, y qué casos de prueba Must no.
- Incidencias por gravedad. Cuántas están abiertas, listas para volver a probar y cerradas, con las incidencias Critical y High abiertas por su nombre.
- Los sign-offs. Quién firmó, cuándo, con qué decisión y qué condiciones.
- Riesgos conocidos. Las soluciones provisionales que usará el negocio en las primeras semanas, y quién les da soporte.
Envía el informe un día antes de la reunión. Quien lo lee en casa hace mejores preguntas.
En UAT StudioEl Go/no-go report del dashboard contiene la indicación (GO, GO with conditions o NO-GO, con los motivos), las cifras, el avance por día, los resultados por grupo, por epic y por prioridad, las incidencias por gravedad, las incidencias Critical y High abiertas por su nombre y cada sign-off de la ronda. La indicación sigue reglas fijas y es un consejo: decide el comité de dirección. Compártelo en PDF o descárgalo como diapositivas para la presentación del comité de dirección.
Qué hacer con las incidencias abiertas
Al final de una UAT siempre hay incidencias abiertas. La pregunta no es si las hay, sino si cada una tiene una decisión. Repásalas antes de la reunión, con el negocio y el equipo de desarrollo, como en el triaje diario.
| Gravedad | Qué necesita el negocio antes de la puesta en producción |
|---|---|
| Critical | Corregida y vuelta a probar. Si no se puede corregir a tiempo, la respuesta es no-go, o el proceso sale de la puesta en producción. |
| High | Corregida, o una solución provisional que el responsable del proceso acepta, con una fecha para la corrección. |
| Medium | Una fecha para la corrección, o la decisión de convivir con ella de momento. |
| Low | En el backlog. No es motivo para esperar. |
Reclasifica con cuidado
En los últimos días hay presión para pasar una incidencia Critical a High. A veces es lo correcto: aparece una solución provisional, o resulta que el proceso es poco frecuente. Hazlo abiertamente, en el triaje, con el responsable del proceso, y anota por qué. Nunca lo hagas a escondidas para que las cifras parezcan mejores. Así es como fracasa una puesta en producción en su primera semana.
Los deseos no son defectos
Los testers encuentran cosas que les gustaría que fueran distintas. Si el sistema funciona tal como se diseñó, es una solicitud de cambio: va al backlog, no a esta versión, y no cuenta en contra de la puesta en producción.
En UAT StudioEl triaje da a cada incidencia una gravedad, una prioridad, un responsable y una decisión: Fix, Reject o Change request. Con el módulo AI test design, Summarize with AI en la pestaña Issues escribe un breve resumen de las incidencias abiertas para la reunión de go/no-go: agrupadas por tema, con lo que bloquea la puesta en producción. Sin el módulo, Summarize with your own AI te da un prompt para pegar en la IA de tu empresa.
Un go con condiciones
Muchas puestas en producción de CRM reciben un go con condiciones. El sistema es lo bastante bueno, siempre que se haga algo antes o justo después de la puesta en producción. Es una decisión justa, siempre que las condiciones sean reales.
Una buena condición es:
- Concreta. La aprobación de descuentos para pedidos de más de 50.000 está corregida y vuelta a probar, no las aprobaciones funcionan.
- Con responsable. Una persona se encarga de ella, con nombre.
- Con fecha. Antes de la puesta en producción, o una fecha en las primeras semanas después.
- Comprobada. Alguien confirma que se hizo, y el comité de dirección lo sabe.
Vigila el número de condiciones. Dos o tres es normal. Quince significan que la prueba no ha terminado. Un go con condiciones no es una forma de evitar un no-go.
Puesta en producción por partes
A veces un proceso no está listo y el resto sí. Entonces puedes pasar a producción sin ese proceso, o con un país o un equipo más tarde. Decídelo de forma explícita, anota la nueva fecha de la parte que espera y planifica su propia ronda de UAT y su propio sign-off.
Sign-off por grupo
Pide un sign-off por proceso o grupo, no una sola firma para todo. Un director de ventas no puede juzgar la gestión de casos, ni debería tener que hacerlo. Cada responsable elige una de tres respuestas:
- Aceptado: mi gente puede hacer su trabajo con esta versión.
- Aceptado con condiciones: siempre que se cumplan las condiciones. Anota cada una, con quién la hace y para cuándo.
- Rechazado: no es lo bastante bueno para pasar a producción. Pregunta qué cambiaría la respuesta.
Reúne los sign-offs antes de la reunión, para que el comité de dirección decida con la imagen completa. Un sign-off pertenece a una versión concreta: cuando llega una nueva build o una nueva ronda de pruebas, vuelve a dar el sign-off.
En UAT StudioLa tarjeta Sign-off del dashboard tiene una fila para todo el proyecto y otra para cada grupo, con Accepted, Accepted with conditions o Rejected. Se registran la fecha, la hora y el número de incidencias Critical abiertas. Por defecto, nadie puede aceptar mientras haya una incidencia Critical abierta; con No sign-off while Must test cases have not passed marcado, aceptar también espera hasta que todos los casos de prueba Must hayan pasado. Rechazar siempre es posible. Un sign-off pertenece a la ronda actual.
Cómo llevar la reunión de go/no-go
Planifica la reunión cuando planifiques los días de prueba, con la fecha en el calendario del comité de dirección. Reserva una hora. Un orden habitual:
- El líder de pruebas muestra el informe: alcance, cifras, incidencias abiertas, sign-offs. Diez minutos, con las cifras en pantalla.
- Cada responsable de proceso explica en una o dos frases por qué firmó como lo hizo, y cuáles son sus condiciones.
- Preguntas sobre las incidencias Critical y High abiertas: ¿hay una corrección, una solución provisional, una fecha?
- Preguntas fuera de la prueba: formación, migración de datos, soporte en las primeras semanas, el plan de vuelta atrás.
- La decisión: go, go con condiciones o no-go. Léela en voz alta, con las condiciones, los responsables y las fechas.
Si la decisión es no-go, termina con un plan: qué tiene que cambiar, una nueva ronda de pruebas y una fecha para el próximo go/no-go. Un no-go con un plan es una decisión normal de proyecto. Un no-go sin plan se vive como un fracaso.
El registro de decisiones
Anota la decisión el mismo día. Meses después, tras un incidente o durante una auditoría, alguien preguntará quién decidió pasar a producción con esa incidencia abierta. La respuesta debería encontrarse en un minuto.
Un registro de decisiones contiene, para cada go/no-go:
- La fecha, y quién estuvo en la reunión.
- La decisión: go, go con condiciones o no-go.
- Cada condición, con su responsable, su fecha y, más tarde, cuándo se cumplió.
- Las incidencias abiertas que el negocio aceptó, con el motivo.
- El informe en el que se basó la decisión, tal como era en ese momento.
Guárdalo con los documentos del proyecto y haz el seguimiento de las condiciones en las primeras semanas después de la puesta en producción, hasta que se cumpla cada una.
En UAT StudioSave snapshot en el informe de go/no-go guarda el informe tal como era cuando se tomó la decisión; ya no cambia, y Show lo vuelve a abrir más tarde. Cada sign-off queda en el historial, también los que se sustituyeron o retiraron. Para un auditor, los administradores descargan el Evidence pack: el informe, los casos de prueba, los resultados y las incidencias, el historial de cada incidencia, cada sign-off y el registro de auditoría, con una suma de comprobación de cada archivo.
De uso libre
Los criterios de salida, el sign-off y el informe también están en la checklist de UAT para la puesta en producción de un CRM, como archivo Excel gratuito. Para toda la prueba, consulta las guías de Salesforce UAT y de Dynamics 365 UAT.