Ya he mencionado alguna vez en este blog al estadístico norteamericano Edwards Deming cuyo nombre está asociado al espectacular desarrollo de Japón después de la Segunda Guerra Mundial. A él se asocian también conceptos como el de Calidad Total o el que luego dio lugar a la palabra japonesa Kaizen o mejora continua. Por algo los japoneses llaman a Deming «el padre de la tercera revolución industrial».
También se ha hablado varias veces en este libro sobre lo importante que es la calidad cuando ofrecemos un servicio o creamos un producto. Pero de acuerdo con Deming, la calidad no es una meta fija que alcanzamos y en la que nos podemos dormir en los laureles. La calidad total siempre está un poco más lejos de lo que podemos llegar esta semana.
Pero ¿Cómo podemos establecer un plan sistemático para mejorar la calidad? Deming nos habla del ciclo PDCA (Plan, Do, Check, Act o Planificar, Hacer, Comprobar y Actuar) para conseguirlo:
- Plan: Detectar una oportunidad de mejora y crear un plan para conseguirla.
- Do: Probar ese plan con un test a pequeña escala cuyos resultados podamos medir con fiabilidad.
- Check: Comprobar esos resultados y aprender de ellos.
- Act: A la vista de los resultados, si el test funcionó implementar el plan a una escala mayor. Tanto si funcionó como si no lo hizo, volver al paso 1: Planificar.
Imagina que eres el responsable de un servicio de HelpDesk de IT. Desde todos los departamentos de la empresa te llegan, a través de una página web, solicitudes de todo tipo: No me funciona el ratón, no puedo cambiar mi clave, necesito un portátil nuevo o la página web para reservar salas de reuniones está caída.
La principal queja que usted recibe de los usuarios es que los técnicos cierran los tickets con las solicitudes demasiado pronto. Si una página no funciona, el técnico la comprueba, ve que a él si le conecta y decide cerrar el ticket como solucionado. Ha pensado que el usuario no ha sabido escribir bien la dirección de la página o que fue un problema puntual y que ya está resuelto. No se ha parado a pensar si el usuario se está intentando conectar desde otra red o la clave de la Wi-Fi de su edificio ha sido cambiada y por tanto sigue sin poder conectarse.
Decides poner un plan en marcha para mejorar esto. Crearás una checklist como la mostrada a continuación para que cada técnico la complete antes de marcar un ticket como resuelto. Será una checklist a usar solo por los técnicos que dan soporte a las incidencias en las aplicaciones web. Los que dan mantenimiento al hardware o instalan software estarán fuera de momento. La checklist propuesta sería una como la que sigue:
- ¿Funciona la página web desde el ordenador del técnico?
- ¿El usuario puede acceder a Google.com?
- ¿El usuario puede acceder a otras aplicaciones internas?
- ¿El usuario ha escrito bien la dirección de la página?
- ¿Está accediendo el usuario desde la Wi-Fi del edificio o lo hace desde su casa?
Como verás es una lista breve, no queremos que los técnicos pasen mucho tiempo contestando preguntas.
Pasarás ahora a crear un test para comprobar si usar esta checklist da resultados. Si la valoración de los usuarios a los tickets resueltos mejora en un 20% definitivamente vas a dejar esta checklist implantada para siempre.
Dejarás pasar un mes para luego examinar las estadísticas de los técnicos que resuelven incidencias en las páginas web. Compruebas que en ese tiempo la puntuación dada a los tickets resueltos ha mejorado ampliamente esa cifra. No solo eso, el número de tickets reabiertos por los usuarios ha bajado también en un porcentaje significativo.
Es momento de actuar. Decides mejorar un poco esta checklist con una comprobación más e idear otro test para la sección que resuelve incidencias de hardware. Esta checklist no es tan sencilla y tendrás que planearla bien. Es momento de volver a planificar e iterar en este ciclo PDCA.
No intentes volver del revés todo el servicio ni cambiar de la noche a la mañana todo tu producto para mejorar. Como dicen los ingleses «Don’t boil the ocean» (no hiervas todo el océano si solo necesitas hacerte un té). Puede volver loco a todo el equipo o a los usuarios que usan tu producto. Las mejoras tienen un coste de implementación y puede que sus beneficios no superen ese coste (o que perjudiquen más que beneficiar).
A veces nos equivocamos y decidimos atacar un problema que no existe mediante un recurso que impresionará a los demás. Quizás decidimos aplicar la norma de cero defectos o calidad 100 %, cuando en el equipo no se están haciendo copias de seguridad con la suficiente fiabilidad o cada vez que una nueva versión sale al mercado se sufre demasiado. Resuelve los asuntos básicos e importantes primero. Le permitirán coger velocidad después. Cuando haya conseguido atajar los asuntos más relevantes y el equipo haya cogido resuello, es tiempo de pasar al siguiente nivel y avanzar un poco más.
Presta también atención en las mejoras en la prevención del fuego y no en la lucha contra el fuego. Analiza la causa de los principales problemas que estás teniendo, aquellos que están causando el mayor número de incidencias o que están impidiendo que el servicio funcione de forma suave y tranquila.
«Pre-ocupándote» antes de ocuparte en la extinción, conseguirás reducir el número de fuegos abiertos en el futuro. Si procuras ser constante en estos planes de mejora continua y trata de poner en marcha un plan sencillo en cada sprint o cada mes, en poco tiempo habrás atajado la fuente de numerosos problemas. Ante los problemas habrás sido proactivo en lugar de reactivo.
