El método simplificado de resolución de problemas

Hoy esto me viene como anillo al dedo!

En han traducido el artículo de Henrik Kniberg sobre una plantilla rápida para resolución de problemas que ayuda a identificar todos los factores a tener en cuenta cuando se pretende solucionar un problema, de modo que podamos seguir un sistema.

Los 17 pasos que plantea son:

1. Darle un nombre al problema. Por ejemplo, "Bugs en producción". Más tarde lo podremos reformular. Mantenerlo neutral, sin hacer acusaciones.

2. Identificar las distintas perspectivas del problema. Por ejemplo: desarrolladores, testers, operaciones.

3. Reunir a las personas clave de estas perspectivas (personas que están afectadas por el problema y les importa), y armar una discusión informal delante de una pizarra. Por ejemplo: un desarrollador, un tester, una persona de operaciones, y el Dueño del Producto. Queremos que haya pocas personas, y que cubran una perspectiva amplia.

4. Describir el problema, y verificar que todos estén de acuerdo de que es un problema. Quizás pueda reformularse el nombre del problema.

5. Si hay una solución simple y obvia, implementarla. A veces, el sólo hecho de reunir a las personas indicadas en una misma sala es la mitad de la solución. Si el problema es complejo, recurrente, o no tiene una solución obvia, continuar:

6. Discutir si realmente vale la pena resolver el problema. No podemos resolver todos los problemas a la vez, por lo cual es importante asegurar la necesidad de dedicarle esfuerzo ahora. Si vale el esfuerzo, continuar:

7. Hacer un análisis de causa-raíz usando los "5 porqué" o un diagrama de causa-efecto o similar, para comprender la naturaleza del problema y reducir el riesgo de resolver un síntoma en vez del problema real.

8. Discutir cómo sería la situación "perfecta" (Definición de Increíble). Si no tuviéramos este problema, ¿cómo serían las cosas? Por ejemplo: "cero bugs en producción". No es necesario ser realistas – la perfección es una dirección, no un lugar.

9. Discutir cuál sería un paso importante hacia la perfección. Por ejemplo, "50% de reducción en los bugs en producción, y cuando se encuentra un bug se soluciona en 1 hora". Debe ser desafiante pero no imposible.

10. Hacer una lluvia de ideas sobre cambios a realizar, cosas que harían para lograr este primer paso. Ser creativos, incluir ideas sin filtrar, ideas locas o imposibles.

11. Para cada idea, listar las ventajas y desventajas más obvias.

12. Decidir en la ejecución de un cambio. Recordar que es un experimento. Si resulta difícil decidirse por uno, votar con palitos o por consenso (todos escriben un número de 1-5 al lado de cada idea, para mostrar cuánto les gusta). No gastar mucho tiempo decidiendo, no sabemos por adelantado cómo va a funcionar. Sólo elijamos una idea que no parezca ser una porquería.

13. Descubrir quienes se verán afectados por el cambio, y conseguir su apoyo. Si no logramos su apoyo, averiguar qué haría falta para lograrlo. O volver a elegir una de las otras ideas que tienen mejores posiblidades de apoyo. El cambio organizacional no va a ocurrir sin apoyo clave.

14. ¡Ejecutar el experimento! Y agendar tiempo para hacer un seguimiento.

15. … (experimentando) …

16. En la reunión de seguimiento: llevar datos y evaluar lo ocurrido. Por ejemplo: ¿cuántos bugs en producción ocurrieron? ¿cuánto nos llevó arreglarlos?

17. Compartir las lecciones aprendidas, y decidir si el problema sigue siendo un problema. Si sigue siendo un problema, volver al paso 10 u 11 y realizar otra iteración.