No se puede negar: por más que planifiquemos un proyecto, algo que no fue mapeado previamente eventualmente aparecerá. Eso es un hecho. Y cuando estos problemas no se comprenden y resuelven correctamente, pueden generar consecuencias serias, como:

• Retrasos en las entregas
• Retrasos en el lanzamiento de productos o mejoras
• Problemas con stakeholders
• Equipos sintiéndose bajo presión
• Despidos

También recomiendo leer mi artículo “Cómo medir la productividad de tu equipo y cómo mejorarla” para entender mejor la performance del equipo, y el artículo “Cómo usar la matriz de stakeholders para aumentar tu influencia y mejorar la comunicación del proyecto” para mejorar la gestión de los stakeholders involucrados en tu proyecto.

Volviendo a nuestro tema, cuando enfrentamos un problema, podemos usar técnicas específicas para obtener una comprensión más profunda de lo que está sucediendo y buscar soluciones que traten el problema en su origen. En ambientes de proyecto, los datos también pueden apoyar esta investigación. Una plataforma como Saint Jude puede ayudar a los gestores a identificar patrones en retrasos, estimaciones incorrectas, performance del equipo, consumo de costos, calidad de las tasks, desvíos en sprints y riesgos. Esto no sustituye el análisis de causa raíz, pero ofrece mejores evidencias para entender de dónde puede venir el problema.

Vamos a nuestra primera técnica:

Formulación de hipótesis

Para formular buenas hipótesis, primero necesitamos entender el problema, sus características, su contexto, las personas involucradas, las relaciones entre ellas, los procedimientos conectados al problema y los resultados esperados en comparación con los resultados reales.

Usar herramientas como un diagrama de sistema o un diagrama de red puede ser un buen punto de partida para comprender la situación, especialmente cuando queremos enfocarnos en procesos, flujos y resultados. Daré un ejemplo y lo explicaré abajo:

Diagrama de sistema - Diagrama de red

• Los rectángulos representan algo acumulado a lo largo del tiempo, como población
• Las flechas representan flujos, como tasas de nacimiento y muerte
• Los círculos representan variables auxiliares, como densidad poblacional
• Los signos de más y menos representan si el flujo está aumentando o disminuyendo

Análisis de stakeholders

El análisis de stakeholders nos ayuda a entender quiénes son los actores, cómo se relacionan entre sí y, muchas veces, el contexto en el que están insertados. Menciono nuevamente mi artículo sobre este tema: “Cómo usar la matriz de stakeholders para aumentar tu influencia y mejorar la comunicación del proyecto”.

Análisis de escenarios

Esta parte de la formulación de hipótesis se usa para explorar escenarios alternativos sobre cómo el problema puede evolucionar y cómo podemos resolverlo. Basamos este análisis en premisas, variables e incertidumbres. Después, validamos las implicaciones y los riesgos de cada escenario para apoyar la toma de decisiones. Aquí está un proceso paso a paso:

1. Identificar el problema
2. Definir qué está influenciando el problema
3. Establecer cómo el problema puede evolucionar en el futuro
4. Construir diferentes escenarios
5. Comparar los escenarios, considerando ventajas, desventajas, oportunidades, riesgos e implicaciones

Ejemplo:

• Problema: mi tech leader pidió un aumento salarial
• Influencia: sobrecarga de trabajo y exceso de responsabilidad
• Posible evolución: pedido de renuncia y retrasos en las entregas
• Escenarios:
  • El tech leader renuncia y no existe documentación del proyecto
  • El tech leader empieza a transferir responsabilidades a otra persona, pero sin documentación formal
  • Otros miembros del equipo quedan insatisfechos por demandas inesperadas
  • El tech leader renuncia y el gestor no tiene desarrolladores senior disponibles

Disclaimer: ten cuidado al formular hipótesis basadas en procesos poco claros o stakeholders de alto impacto que no fueron correctamente mapeados. La falta de claridad puede llevarnos a cometer errores serios en la creación de nuestras hipótesis.

Aquí, Saint Jude puede apoyar el análisis mostrando si el proyecto ya presenta señales de sobrecarga, como tasks concentradas en una sola persona, retrasos por nivel de seniority, bugs recurrentes, descripciones de tasks poco claras o desequilibrio entre asignación planificada y trabajo real. Estos indicadores pueden ayudar a los gestores a crear mejores hipótesis en vez de basarse solamente en la percepción.

5 Porqués

En mi opinión, la técnica de los 5 Porqués es una de las mejores y más simples formas de descubrir la causa raíz de un problema. Sin embargo, funciona bien solamente cuando se usa con transparencia, incluso cuando estamos lidiando con cuestiones políticas dentro de una empresa. A veces, las personas tienen miedo de decir aquello que es obvio para todos. Cuando eso sucede, la técnica pierde parte de su fuerza.

Ejemplo:

- ¿Por qué no tenemos acceso a las máquinas de producción?

- Porque el área de seguridad no nos proporcionó el acceso.

- ¿Por qué el área de seguridad no nos proporcionó el acceso?

- Porque dijeron que solamente el equipo de seguridad puede acceder a producción.

- ¿Por qué solamente el equipo de seguridad puede acceder a producción?

Todos pensando:

- Porque el CTO lo exigió.

Incluso cuando la respuesta parece obvia, el ejercicio de seguir preguntando “por qué” hasta llegar a la causa raíz puede ser revelador. Ayuda a separar suposiciones de hechos y hace que el verdadero problema sea más visible para todos los involucrados.

¿Cuáles son las ventajas de los 5 Porqués?

Identifico ventajas como:

• Identificar fallas de proceso
• Analizar baja performance
• Investigar conflictos
• Comprender tendencias
• Comprender el éxito de un producto
• Comprender el fracaso de un producto

¿Cómo hacer el ejercicio de los 5 Porqués?

A pesar del nombre, no es obligatorio parar en la quinta pregunta o llegar exactamente a cinco preguntas. El número cinco fue elegido porque suele ser una buena medida para encontrar la causa raíz. El concepto es seguir preguntando hasta encontrar el verdadero motivo detrás del problema. En el ejemplo anterior, podría haber continuado con: “¿Por qué el CTO exigió que solamente el equipo de seguridad accediera a producción?”

Otra práctica útil es siempre empezar la próxima pregunta usando la respuesta anterior. Esto crea trazabilidad y nos ayuda a seguir la lógica del problema. Ejemplo:

- ¿Por qué las tasks están retrasadas?

- Porque los desarrolladores están estimando las tasks de forma incorrecta.

- ¿Por qué los desarrolladores están estimando las tasks de forma incorrecta?

Al final, cuando encontramos la causa raíz, podemos avanzar hacia la solución. Dejo aquí otro artículo que escribí: “Cómo encontrar las soluciones correctas para los problemas de tu producto”

En este ejemplo, Saint Jude puede ayudar a apoyar la investigación comparando duración estimada versus duración real de las tasks, identificando qué tipos de tasks suelen retrasarse, qué profesionales o niveles de seniority son más impactados y si los retrasos están relacionados con bugs, user stories, subtasks, features o tags específicas. Esto hace que el ejercicio de los 5 Porqués esté más basado en hechos y dependa menos de opiniones.

Diagrama de Ishikawa

El diagrama de Ishikawa, frecuentemente llamado diagrama de espina de pescado, es una técnica usada para comprender un problema desde una perspectiva sistémica. En otras palabras, nos ayuda a dar un paso atrás y ver el escenario general, en vez de mirar solamente síntomas aislados.

Para usarlo, podemos empezar con un modelo como el de la imagen de abajo, que explicaré paso a paso.

Cabeza del pescado – problema inicial

Aquí colocamos el problema inicial para el cual necesitamos encontrar la causa raíz. Ejemplo: Todas nuestras tasks están retrasadas.

Espina de pescado y 6Ms

En la espina de pescado, organizamos las posibles causas relacionadas con nuestro problema principal, verificando si pertenecen a una de las 6Ms:

• Máquina: todos los equipos, herramientas y máquinas utilizadas
• Método: procesos e instrucciones adoptadas
• Material: materias primas, componentes e información
• Misión / Medio ambiente: ambiente de la empresa, ambiente físico y propósito de la empresa
• Medición: inspecciones, sistemas de monitoreo y controles
• Mano de obra: personas involucradas

Vamos a nuestro ejemplo. Empezaremos con el problema principal: “Todas nuestras tasks están retrasadas.” A partir de este problema, vamos a posicionar posibles causas en la espina de pescado. Ejemplo:

• Máquina: falta de automatización DevOps para deploys en staging y producción
• Método: los refinamientos no están considerando la experiencia de los desarrolladores
• Material: nuestros componentes no son reutilizables
• Medio ambiente: -
• Medición: -
• Mano de obra: muchos desarrolladores junior en el equipo y falta de un profesional DevOps

Nuestro diagrama:

Observa dos puntos importantes en nuestro ejemplo:

1. No todas las Ms fueron completadas, solamente aquellas relacionadas con el problema principal
2. Una causa puede aparecer en dos o más Ms, como la experiencia del equipo, que aparece en Método y Mano de obra, o DevOps, que aparece en Máquina y Mano de obra

Disclaimer: en mi entendimiento, cuando la misma causa aparece en dos o más puntos, es una fuerte candidata a ser la causa raíz. Normalmente, la priorizo en mi lista de resoluciones.

Disclaimer 2: el diagrama de Ishikawa puede ser usado junto con la técnica de los 5 Porqués. Al hacer esto, conseguimos identificar la causa raíz para cada M y definir subproblemas que necesitan resolverse para eliminar el problema principal.

Este es otro punto en el que Saint Jude puede ayudar. Si el problema es “todas las tasks están retrasadas”, la plataforma puede ayudar a separar el análisis por área, seniority, función, tipo de task, tag, costo, horas asignadas, horas consumidas y performance del sprint. Esto ayuda a los gestores a entender si el problema está relacionado con personas, proceso, estimación, calidad de las tasks, carga de trabajo o flujo de entrega.

Problem statement

Por último, después de aplicar las técnicas para descubrir la causa raíz, necesitamos definir el problem statement. Pero ¿qué es un problem statement?

Un problem statement es una declaración clara del problema que vamos a resolver. Es casi como una declaración de guerra contra el problema. En esta declaración, especificamos el alcance, por qué el problema importa y qué objetivos queremos alcanzar al resolverlo. También necesitamos incluir criterios de aceptación y restricciones. Abajo, explicaré cómo construir este documento y traeré un ejemplo.

Cómo construir un problem statement

Para construirlo, debemos:

• Definir el problema con claridad – describir qué está sucediendo, dónde, cuándo y por qué
• Identificar los stakeholders – definir quién es impactado por el problema, sus expectativas, comportamientos y posición en relación con él
• Definir criterios para evaluar la solución – aquí podemos usar criterios de aceptación y objetivos, como reducción de costos, reducción de tiempo, mejora de calidad, mejora de seguridad, entre otros
• Cuantificar el problema – si es posible, cuantificar cuánto está perjudicando el problema al proyecto. Ejemplo: 1 mes de retraso o US$ 100.000 por semestre en costos adicionales
• Explicar la causa raíz – aquí podemos incluir los resultados encontrados por medio de las técnicas explicadas arriba

Disclaimer: recuerda que el problem statement debe ser SMART:

• Específico (S)
• Medible (M)
• Alcanzable (A)
• Relevante (R)
• Temporal (T)

Vamos a nuestro ejemplo:

“La tasa de retraso en las entregas de user stories del Equipo X es de aproximadamente 20%, lo que genera cerca de 1 mes de retraso cada semestre, US$ 100.000 en costos adicionales por semestre e insatisfacción del cliente final, CTO, CEO y área financiera. Las principales causas de estos retrasos son la falta de experiencia del equipo y estimaciones imprecisas. ¿Cómo podemos reducir estos retrasos al 5% en 3 meses?”

Un problem statement fuerte depende de hechos. Saint Jude puede apoyar esta etapa consolidando datos sobre cronograma, costos, estimaciones de tasks, performance de los profesionales, bugs, tipos de tasks, desvíos de sprint e indicadores de riesgo. Con esta visibilidad, los gestores pueden escribir problem statements basados en evidencias en vez de suposiciones.

A partir de este punto, podemos avanzar hacia la resolución. Aquí comparto otro artículo sobre este tema: “Cómo encontrar las soluciones correctas para los problemas de tu producto.”

Llego aquí al final de este artículo. Aquí, aprendiste las principales técnicas para encontrar la causa raíz de un problema: formulación de hipótesis, análisis de escenarios, 5 Porqués, diagrama de Ishikawa y problem statement.

¿Qué te pareció este artículo? ¿Te gustaría agregar alguna herramienta que consideras importante?

Dale like a este artículo, comenta en LinkedIn o compártelo en tus redes sociales.

¡Hasta pronto!

Erik Scaranello