Cómo prepararse para, y sobrevivir a, decisiones de Lanzar/No Lanzar

De eso trata este artículo. No ofrece nada nuevo ni "revolucionario", solo reflexiones y consejos muy prácticos basados en mis propias experiencias llenas de tensión como líder de QA durante varias décadas, y las lecciones que he extraído de ellas. Mi propia autenticidad ejecutiva de QA, por así decirlo. Lecciones que, por supuesto, eres libre de ignorar, contradecir o ridiculizar como gustes.

Está claro para cualquiera que haya estado en un puesto de liderazgo en QA durante cierto tiempo que el trauma central de esa experiencia es negociar la notoria reunión de "se lanza o no se lanza". Y sobrevivir a ella. 

Porque aquí es donde todo llega a un punto crítico, y QA es interrogado como si fuera sospechoso de un crimen, y los detectives son todos los demás “interesados” (un eufemismo si alguna vez hubo uno). Y, como todo detective, todo lo que quieren de ti es que firmes la confesión.

Pero no tiene por qué ser así. Todo lo que necesitas es una coartada irrefutable. Escribo este artículo para proporcionarte una.

Hora de la historia

El mayor error que cometen los líderes de QA al entrar a una reunión de lanzamiento o no lanzamiento es la falta de preparación. O mejor dicho, la falta de preparación efectiva. 

La mayoría de los líderes o responsables de QA llegan a esta reunión "preparados" principalmente, y a menudo exclusivamente, con métricas de errores. Número de incidencias abiertas, número de incidencias abiertas de Categoría A, de Categoría B, bla bla bla. A veces, si el resto del equipo tiene suerte, el líder de QA podrá dar una visión vaga e impresionista de la cobertura de pruebas alcanzada hasta ese momento. Aunque, normalmente, los datos que usan para esto son simplemente un inventario de las pruebas y scripts de prueba que han ejecutado. Lo cual no es en absoluto una medición de la cobertura de pruebas real. Estas son métricas de esfuerzo, no verdaderas métricas de calidad.

La falacia tras esta estrategia va más allá del uso de métricas ambiguas o vacías de significado para defender (¿algún tipo de?) argumento sobre lanzar o no lanzar. El error que se comete aquí es mucho más fundamental.

Porque la estrategia de decisión de QA descrita arriba se basa en un claro error de categoría. El liderazgo de QA en este escenario supone que el propósito de la reunión de lanzar o no lanzar es presentar datos para que otros los consuman y tomen la decisión por sí mismos. Nada más lejos de la realidad, ni más perjudicial para la autoridad del área de QA.

Lo que el resto del equipo espera del liderazgo de QA en esa reunión no son más datos. Esperan un veredicto claro y con autoridad sobre si lanzar el producto o no. Ahora. Hoy. 

Por supuesto, los datos de pruebas y defectos serán necesarios para defender y lograr aceptación sobre el veredicto experto que emita QA. Pero lo que debe aportar QA es un veredicto con autoridad. 

De lo contrario, QA está abandonando su responsabilidad única y su autoridad dentro de la organización de entrega de producto. Es una actitud inherentemente evasiva y pasivo-agresiva. Lo cual no hace nada para mejorar la posición de QA dentro de esa misma organización. 

Con el tiempo, esto supone una espiral descendente para las posibilidades de QA de convertirse en una voz igualitaria dentro del desarrollo. Una situación sobre la que el área de QA se queja interminablemente, pero que, a menudo, ella misma es responsable de su propia irrelevancia por esta misma razón.

Esto significa que el liderazgo de QA debe entrar a la reunión de lanzamiento o no lanzamiento con una historia clara y persuasiva que conduzca a una recomendación inequívoca. Es decir, hay que llegar a esa reunión listo y dispuesto a firmar con sangre digital, lo que sea que estés recomendando. Sin apostar a dos bandas. Sin esconderte bajo la falda de la negación plausible. 

Porque si no lo haces, tú y tu equipo perderán toda credibilidad dentro de la organización. Y, lo que es peor, quedaréis posicionados para recibir toda la culpa si otros tienen que tomar esa decisión por ti y el resultado es un desastre de calidad en el campo. Lo cual es, seamos sinceros, exactamente lo que las otras áreas desean que pase. Quieren culparte de todo y usar tu propia indecisión sobre la calidad del producto como prueba en tu contra.

Un factor clave que permite este enfoque pasivo-agresivo para la decisión de lanzar o no lanzar es la convicción — a menudo utilizada de manera oportunista — de que “No importa lo que diga, van a lanzar igual”. Esta mentalidad, esta adopción estratégica de la falta de poder, es precisamente lo que perpetúa la impotencia organizacional de QA. ¡Hablamos de una profecía autocumplida! 

Al margen de la política y la psicología autoderrotista, esta estrategia parte de una incomprensión fundamental de lo que se espera de QA en esa reunión. Porque, en realidad, no se le pide emitir una decisión irrevocable de lanzar o no lanzar, incluso si la decisión que se te pide tomar públicamente tome esa forma. 

Y, sí, aún debes presentar un veredicto con autoridad. Pero para hacerlo, debes entender la pregunta que realmente tienes que responder con autoridad.

La verdadera pregunta que se le pide responder al liderazgo de QA es esta: ¿Cuáles son los riesgos —su probabilidad y severidad en el campo— de lanzar hoy? ¿En vez de, digamos, el próximo mes? En otras palabras, le están pidiendo que brinde una evaluación de riesgos para habilitar la toma de decisiones racional en ese momento por parte de la alta dirección. 

Esto significa que su respuesta definitiva en la reunión de decisión final es, en última instancia, una respuesta definitiva sobre el riesgo. No sobre si debe o no presionar el botón que lanza el cohete al espacio exterior.

Lo que implica a su vez que, al final, la historia de la calidad que cuente en esa reunión debe estar basada en escenarios. Es decir, no será una respuesta simple de sí o no, por mucho que los demás lo deseen para lavarse las manos de toda responsabilidad sobre la decisión (lo cual nunca es el caso, ¿verdad?). Para esquematizar un poco, su presentación debe tener dos partes:

• Primero, una declaración autoritativa y relevante basada en datos, del estado actual de la calidad del producto. Con métricas que respalden eso. Atención: necesitará más que métricas de bugs para lograrlo.
• Segundo, una valoración autoritativa de la calidad latente que quedaría sin explotar si se decide lanzar el producto ahora. ¿Es tan relevante que merece la pena añadir tiempo al calendario de lanzamiento para liquidar esa deuda de calidad? Si es así, ¿cuáles son los compromisos tiempo/calidad que recomienda QA? ¿Y qué áreas específicas de la funcionalidad del producto deberían ser el objetivo de esta extensión, y cómo sabríamos que se ha realizado esa calidad latente?

Esto no es una manera de esquivar la pregunta. Es una forma de responderla considerando todos los parámetros, variables y costes asociados a esa decisión —hoy, la próxima semana o el mes siguiente. 

Porque, y esta es una verdad que debe grabarse en su conciencia de QA, su verdadero público en esa reunión no son los otros responsables funcionales. Es la alta dirección. Estén presentes físicamente en la reunión o no. Lo que usted diga se les transmitirá de inmediato. Créame.

Y esto solo juega a su favor. Porque lo que más les gusta a los CEOs y COOs es que se les presenten opciones significativas, respaldadas por datos y hechos concretos. Lo que más odian es que solo se les diga: “Eh, no estamos listos para lanzar. Y no podemos decirles exactamente por qué. Pero quizá lo sepamos en cuatro meses”. Por esto es que los CEOs salen a buscar nuevas adquisiciones —para conseguir un equipo completo de entrega de productos. 

La queja habitual de los equipos de entrega de producto es que la alta dirección dicta, por decreto, una fecha de lanzamiento inflexible, y que se niega a hacer concesiones. Quizá debería preguntarse por qué actúan de forma tan reiterada. 

Es porque nunca logran obtener una respuesta definitiva sobre el estado de la calidad del producto, y si no puede cumplirse su fecha favorita de lanzamiento, en qué fecha sí se podrá. Así que imponen la suya. Porque el equipo de producto no les ha dado alternativas significativas.

Por eso, debe presentarse en la reunión de decisión final con una exposición impactante, 3D, basada en hechos y escenarios, que conduzca a un conjunto autoritativo de recomendaciones, las cuales pueden incluir opciones de coste/beneficio de calidad significativas en torno a la decisión de lanzar —o no. Balbucear unos minutos sobre métricas de bugs, y luego dejar la decisión a los demás, no es la historia adecuada.

Por supuesto, para hacerlo debe tener su propia metodología, formación y métricas de QA en perfecto estado. He escrito artículos detallados sobre estos temas en otros lugares (por ejemplo, en LI), pero, al ser teóricos sobre el proceso, quedan fuera del enfoque pragmático de este artículo.

Un final feliz

Lo que he escrito arriba puede parecer intimidante, e incluso algo contradictorio —en apariencia. Así que permítame terminar este artículo con mi experiencia en una reunión de decisión final muy exitosa. Una que se desarrolló un poco diferente de lo descrito arriba, e incluso diferente de cómo yo esperaba que fuera.

Mi equipo había estado probando un producto completamente nuevo. No solo un producto nuevo, sino uno que abordaba un nicho en el que la empresa no tenía ninguna experiencia previa. Así que fue una maratón de peligros ocultos, desconocidos desconocidos y sorpresas desagradables desde el principio.

Llegó el momento de la reunión de decisión final. Al inicio de mi gestión como Director de QA, había implementado un régimen estricto sobre cómo definiríamos las métricas de calidad, incluidas las métricas de cobertura de pruebas basadas en requisitos, y no por módulo o scripts de prueba. También teníamos no solo métricas de bugs, sino métricas de tendencia de bugs y métricas de velocidad de cambios de código para reforzar nuestra exposición. 

Y todas esas métricas eran indiscutiblemente positivas. Todo estaba a punto. No eran necesarios escenarios de if/then/else. Por una vez, no vi razón para no decir alto y claro: “¡Láncenlo!”, sin reservas. 

Sin embargo, técnicamente, no era mi papel hacerlo. Porque el proyecto lo había liderado uno de mis gerentes de QA, y le correspondía a esa persona dar el veredicto autoritativo. Esta persona resumió acertadamente todas las métricas y reconoció que todas eran positivas. 

Luego, para mi sorpresa, dudó sobre si estaba o no listo para lanzar. Me sorprendió porque, por supuesto, habíamos hablado sobre cuál sería la postura de QA antes de entrar a esa reunión. (Nota importante: No sorprenda nunca a su jefe en una reunión. Jamás.)

Le pregunté al gerente: “¿Qué haría falta para que se sintiera cómodo recomendando la decisión de lanzar? Si no es hoy, ¿cuándo en el futuro?”

Una vez más, para mi sorpresa, el gerente no pudo — o no quiso — responder a mi pregunta. Se hizo evidente para mí que este gerente simplemente no quería asumir la responsabilidad de tomar esa decisión, de firmar en la línea punteada. Lo cual me resultó más que decepcionante. 

También fue un insulto para el responsable de ingeniería del proyecto, quien había apoyado incansablemente el esfuerzo de QA y había desarrollado un producto de primera clase. No merecía ser tomado por sorpresa de esta manera. Y yo tampoco.

Así que intervine y dije: “No he visto, ni escuchado, ningún motivo válido para no lanzar este producto HOY. Ese es el veredicto de QA, y yo, como Director de QA, asumo toda la responsabilidad por tomar esta decisión”.

Pensé que el responsable de ingeniería estaba a punto de besarme. Pero después de esa reunión, QA recibió un gran reconocimiento y respeto de parte de ingeniería, gestión de proyectos y gestión de producto. 

Porque la clave para que te tomen en serio en nuestro mundo es asumir públicamente la responsabilidad. Lo cual sentí totalmente seguro de hacer en ese momento porque nuestra historia se había preparado desde el principio. Y se había escrito pensando en un final feliz.

El producto, una vez lanzado, mostró una gran calidad en el campo, y fue un gran éxito. Retrasar su lanzamiento solo para evitar la responsabilidad de tomar la decisión de lanzar o no lanzar solo habría supuesto un aumento minúsculo en la calidad del producto a un coste injustificable en dinero y tiempo de salida al mercado. 

Cómo conseguimos eso es otra historia para otro día.

Como siempre, os deseo mucha suerte en vuestros esfuerzos de QA.

Podcast relacionado: TRABAJO EN EQUIPO, IA, Y CONTENERIZACIÓN (CON MICHAEL RITCHSON DE LA NASA)