En su blog Henry Kniberg comparte su propia adaptación del método A3 para la resolución de problemas, que busca ser una metodología para consencuar, entender y resolver cualquier problema que pueda surgirnos. Es un enfoque interesante y sistemático, muy interesante para tener a mano.

A continuación les dejo una traducción con los 17 pasos sobre esta técnica para resolver problemas.

El método simplificado de resolución de problemas

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 un pizarrón. 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 Inreíble). Si no tuvieramos este problema, ¿cómo serían las cosas? Por ejemplo: "cero bugs en producción". No es necesario ser realistas - la perfeccións 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 dificil 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.

Traducido de Light-weight problem solving template, por Henry Kniberg