Archivos de Categoría: Blog

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:

1. ¿Funciona la página web desde el ordenador del técnico?
2. ¿El usuario puede acceder a Google.com?
3. ¿El usuario puede acceder a otras aplicaciones internas?
4. ¿El usuario ha escrito bien la dirección de la página?
5. ¿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.

Cuando hablamos de gestión solemos hablar de «Gestión de proyectos» o de jefes de proyectos, pero cuando estamos gestionando un proyecto no prestamos atención solo a su presupuesto, al tiempo y el alcance del mismo. Lo que realmente queremos conseguir con ese proyecto, dentro de su presupuesto y tiempo establecidos, esproducir un producto que se venda bien y al que le respalde una imagen de buena calidad (después de vender este producto idearemos otro para el que no querremos que le arrastre la mala imagen del anterior).

Idealmente también nos gustaría disfrutar del tiempo en el que lo estamos desarrollando. Ni a nosotros, ni a los miembros del equipo que tengan la suerte de trabajar con nosotros les complacería tener que trabajar en un lugar donde las situaciones de estrés, el mal ambiente o las horas extra nos devoran desde dentro.

El proyecto con el que la empresa de Steve Jobs ideó el iPhone fue un auténtico fracaso, si solo al presupuesto nos referimos. Se terminó gastando en la investigación y desarrollo del nuevo iPhone alrededor de 150 millones de dólares, mucho más de lo presupuestado para ese fin. De hecho, durante el tiempo en el que se estaba concibiendo, se produjo mucha fricción en Apple. Los mejores ingenieros fueron destinados a ese proyecto dejando huérfanos los planes de muchos jefes de proyectos en la casa. Sin embargo, el proyecto terminó generando unos ingresos de 500 mil millones para la compañía de Steve Jobs. Todo un éxito como producto a pesar de que el proyecto fuese un fracaso.

Yo mismo he participado en proyectos que se terminaron a tiempo y dentro del presupuesto, pero que el cliente nunca llegó a utilizar. Se utilizaron tecnologías sencillas y seguras para las que había un amplio margen para hacerlo bien y rápido, pero para cuando vio la luz ya habían sido ampliamente mejoradas por otras. El director del proyecto en el cliente decidió iniciar un nuevo proyecto (con otro proveedor) al poco de que finalizáramos con el anterior.

También he participado en proyectos en los que nos comimos rápidamente el presupuesto y sobrepasamos el tiempo fijado para que comenzase a ser usado por los usuarios. Las buenas ideas usadas en él y lo contentos que estaban los clientes con el resultado final y cómo se había desarrollado todo, hicieron que nos contratasen siempre a nosotros de modo preferente. Perdimos dinero en ese primer proyecto, pero nos hizo ganar buena fama en el resto de la industria donde se ofertaba nuestro producto.

En este libro intento prestar atención no solo al proyecto, sino al producto que se está construyendo en ese proyecto, al equipo que lo está haciendo y, por qué no, a tu propia tranquilidad mientras lo haces. De seguro no querrás un proyecto que te quite el sueño a ti ni a tus compañeros de trabajo.

No está de moda usar la palabra proyectos cuando en realidad lo que queremos es un producto de éxito. Tampoco está en boga emplear a equipos de usar y tirar, configurados explícitamente para los seis meses de un proyecto, cuándo queremos equipos muy cohesionados y de alta productividad ¿Debería decir, por tanto, gestión de productos o gestión de equipos en lugar de gestión de proyectos?

Bueno, un nombre había que darle a esto que hacemos. A pesar de llamarlo proyecto, no se olvide de todos los aspectos que intervienen en un proyecto de éxito: el producto y el equipo.

En inglés existe una frase hecha que dice «Good, fast or cheap, choose two». Nos viene a decir que no podemos tener los tres atributos en un producto o servicio. Si es bueno y rápido no será barato. Si es barato y rápido no será bueno. Si es bueno y barato será un servicio lento o tendremos el producto dentro de mucho tiempo.

Es una frase equivalente a nuestro «Bueno, bonito y barato» que nos venden en los mercados y que siempre damos como imposible. Pensamos que nos están timando, que un producto así no existe.

Esto pensamos también cuando somos nosotros los manufacturadores de ese servicio que queremos vender. Si invertimos en calidad y hacemos un producto bueno, será caro en el mercado y nos costará venderlo. Si lo hacemos rápido y económico no será gran cosa y se convertirá en un producto mediocre más en las estanterías de los minoristas o en el catálogo de nuestros comerciales.

Sin embargo, Tom DeMarco y Tim Lister nos cuentan en su libro Peopleware que esa frase no es verdad. Cuando midieron la productividad de los programadores de cientos de empresas de Estados Unidos, la calidad era recompensada con creces.

Según su estudio, los técnicos que realizaban los proyectos en una décima parte del tiempo que los demás también cometían diez veces menos errores que los más errores cometían. Es decir, que no necesitaban invertir más tiempo para cometer menos errores. Simplemente lo hacían bien a la primera. Tenían en sus empresas una cultura de la calidad que les hacía prestar atención a lo que hacían, intentando entregarlo bien al primer o segundo intento.

Hacer el trabajo para después corregir errores hace que todo sea mucho más lento. Cuando semanas después de terminar el producto aparece el primer problema tienen que desmontarlo todo, revisar e intentar hacer memoria de por qué estaba hecho así.

Jeff Sutherland en su libro Scrum cuenta que miembros del equipo de desarrollo de Palm, los contructores de las primeras PDAs, le contaron que decidieron medir cuando costaba corregir cada error que encontraban. Revisando estas mediciones se dieron cuenta de que, si un error se corregía el mismo día que se produjo, se solucionaba en una media de una hora. En cambio, si el problema era archivado y se corregía tres semanas después, el tiempo medio empleado para arreglar el error era de 24 horas ¡24 veces más!

No entreguemos nuestro trabajo a las primeras de cambio. No nos dejemos llevar por la presión y entreguemos lo primero que nos pareció bien. Tardaremos mucho menos si revisamos concienzudamente nuestro trabajo, empleando el tiempo y la paciencia suficiente que da el saber que, adelantar un minuto ahora, hará que nos retrasemos mucho más después.

Deming lo explica así con su ciclo de Reacción en Cadena de la Calidad:

1. Aumentamos la calidad.
2. Se reducen los costes porque hay menos errores, menos tiempo en corregirlos y rehaciendo el trabajo, menos tiempo resolviendo quejas y pagando reclamaciones, etc.
3. Aumenta la productividad (empleamos menos recursos para hacer los mismo).
4. Ganamos más mercado por tener mejor calidad y costes más bajos.
5. Seguimos en el negocio.
6. Creamos más empleo.

Y ahora que ha terminado con los seis puntos, vuelva al punto número uno y continúe mejorando (recuerde la mejora continua). Merecerá la pena porque podrá elegir los tres atributos: Bueno, rápido y barato.

Para estas fechas estaba prevista la salida a la venta de mi tercer libro, pero he decidido posponerlo a la espera de que se confirmen algunas novedades en su publicación. Les mantendré informados mediante este blog, LinkedIn o Twitter.

Mientras tanto les dejo con el índice provisional que tendría:

NO HAY PRÁCTICA SIN TEORÍA

1. A qué llamamos Agilidad
2. Scrum
3. Lean
4. Extreme Programming

NI TEORÍA SIN PRÁCTICA

1. Hablando con el cliente
2. Leyendo el futuro
3. Cómo ser ágiles en todo tipo de proyectos

GESTIÓN DE EQUIPOS DE TRABAJO

1. Las dos teorías de la gestión
2. Coding wars
3. El portfolio
4. Permítase trabajar con gente que dude
5. El efecto Pigmalión
6. No deshaga los buenos equipos
7. Todo el mundo tiene derecho a equivocarse
8. Trabajando con incompetentes
9. Trabajando con genios
10. Principio de Hanlon
11. La increíble historia del robo de un banco y los equipos de trabajo

SUELO FÉRTIL

1. Ley de Parkinson
2. Ley de Carlson
3. Nada peor que la multitarea
4. Y si de interrupciones hablamos
5. Ofrezca un trato justo

LA “LÓGICA” DEL COMPORTAMIENTO HUMANO

1. Síndrome del estudiante
2. Añadir gente a un proyecto retrasado hace que se retrase aún más
3. Principio de Hawthorne
4. Psicología de la persuasión
5. La firma de abogados y las máquinas de escribir
6. Deje que le atrape el efecto Zeigarnik

QUIÉN ES EL DUEÑO DE TODO ESTO

1. Agilidad para el dueño
2. Deje madurar las peticiones
3. Pero ¡Qué estamos haciendo!
4. Parálisis por análisis
5. Agilidad o contorsionismo
6. Efecto IKEA

LOS ERRORES MÁS HABITUALES

1. Pasarnos de ágiles
2. Dejar que el miedo campe a sus anchas
3. Pruebas insuficientes
4. Lo que hay que entregar está grabado a fuego hasta el día del juicio final
5. ¿Está enseñando su trabajo?
6. Diseñar todo el proyecto desde el inicio
7. Nos pasamos el día reunidos
8. El jefe de proyecto reparte las tareas
9. Apretar demasiado en el objetivo del sprint
10. Dependemos demasiado de héroes
11. Interrupciones urgentes que no nos dejan avanzar
12. Asumir que ya lo sabemos todo
13. Demos que no están listas
14. La Pila del Producto no está lista
15. Hacemos demos huecas
16. Temor a las demos

VENTAJAS DE SER ÁGIL

1. Divide y vencerás
2. Saber cada dos semanas lo que piensa el cliente
3. Que comience ya a usar su producto
4. Medir la productividad individual
5. Llegar tan lejos y tan rápido como un ciclista
6. ¿A quién le gustan las sorpresas?

ES LA CALIDAD, ESTÚPIDO

1. El verdadero precio de la calidad
2. El coste de hacer las cosas mal

HABILIDADES ÁGILES

1. Vísteme despacio que tengo prisa
2. Levante la cabeza y mire alrededor
3. Empiece por lo más fácil
4. Todo el mundo comete errores (excepto yo, claro)

Este es un extracto de mi nuevo libro «Dibujando la revolución ágil» en el capítulo sobre gestión de equipos de trabajo. Espero que le guste:

Alguien contó a McArthur Wheeler[1], un pequeño delincuente de la zona de Pittsburgh (USA) que, si se ponía zumo de limón sobre la cara, este actuaría como tinta invisible y no podría ser grabado por las cámaras de seguridad de los bancos.

McArthur, que a pesar de todo no era tan confiado, quiso probar esto por su cuenta y se intentó hacer una foto a sí mismo con una Polaroid para probar este efecto. Se cree que, con los ojos terriblemente irritados por el zumo de limón, no pudo hacer bien la foto y el encuadre salió desviado. Probablemente fotografió el techo de su salón.

Animado por un descubrimiento que le permitiría dirigirse tranquilamente a un banco sin despertar sospechas y atracarlo sin que nadie le grabase, entró a plena luz del día y untado en limón en dos bancos de Pittsburgh. Allí todas las cámaras lo grabaron nítidamente apuntando con su arma al cajero.

Con lo que no contaba el señor Wheeler es que su imagen saldría esa misma noche en los noticieros de las 11. Tan solo una hora después, sobre las 12:10, Wheeler fue detenido por la policía. Además, su casi metro setenta de altura y más de 120 kilos de peso lo hicieron fácilmente reconocible por los vecinos de Pittsburgh que indicaron a los detectives por dónde solía andar.

Al parecer, en el momento de la detención, Wheeler no salía de su asombro por haber sido detenido tan pronto y solo atinó a decir “¡Pero si me había puesto el zumo!” ¿Qué había llevado a este buen señor a creerse más listo que nadie y descubrir el secreto de la invisibilidad y el atraco perfecto? David Dunning, un profesor de psicología en la Universidad de Cornell, leyó esta noticia en el Almanaque Mundial de 1996 y se hizo preguntas similares.

Dunning pensó que, si Wheeler era tan tonto como para atracar bancos con zumo de limón, quizás ni el mismo se diera cuenta de su propia incompetencia, lo que le habría llevado a atreverse a hacer algo así.

Junto a uno de sus estudiantes, Justin Kruger, Dunning quiso saber si era posible medir si somos conscientes o no de nuestros propios límites y se animaron a hacer un estudio para intentar averiguarlo. Si fuéramos conscientes de hasta dónde llega nuestro conocimiento podríamos pensar “¡Eh! Espera un minuto, la decisión que acabo de tomar no tiene mucho sentido, mejor busco a alguien que me aconseje”. Pero ¿Y si no lo somos y nuestro propio desconocimiento nos hace pensar que lo sabemos todo?

Dunning y Kruger[2] tomaron como sujetos del estudio a diversas clases de psicología en su universidad a cuyos estudiantes les pasaron unos tests de lógica, gramática o sentido del humor. Una vez hechos estos tests, se le preguntó a cada estudiante en qué posición creían que habían quedado con respecto a sus compañeros.

Lo que pudieron comprobar en esos tests no le sorprenderá mucho después de lo aquí comentado: Los estudiantes que peor nota sacaron en los tests, creían estar entre los que mejores resultados habían obtenido. Sin embargo, aquellos para los que se probó que eran más competentes, creían estar engrosando las filas de los de peor resultado.

Esto dio lugar a lo que se conoce como el Efecto Dunning-Kruger: Las personas más incompetentes sobrevaloran su propia capacidad, pero además tampoco son capaces de reconocer la capacidad de los otros.

Tenga en cuenta este efecto cuando observe la dinámica con la que se desenvuelve cada día el equipo con el que trabaja. No permita que el desconocimiento de algunos miembros del equipo de trabajo les haga aventurarse demasiado a decisiones arriesgadas que no están bien valoradas. Escuche a aquellos más reflexivos y que admiten dudas, seguramente son capaces de intuir delante de ellos un abismo que no pueden rellenar ahora por esa inexperiencia o impericia. Procure evitar que la arrogancia que provoca el desconocimiento, y que convierte a algunos en líderes de equipo, lleve a todos por mal camino.

Téngalo presente también para sí mismo. Aunque hubiese sido usted uno de aquellos estudiantes que mejor puntuación sacaron en los tests de este estudio, siempre habrá un área de conocimiento, tecnología o campo para el que sea solo un novato. No permita que desconocer todos los factores y parámetros que deban influir en la toma de una decisión le lleve a equivocarse. Coméntela con todo el equipo y aquellas personas que considere que tienen buen criterio. Puede que le sorprenda (o incluso le alarme) la cantidad de cosas que usted no tuvo en cuenta.

Si quiere saber más sobre cómo la Agilidad puede ayudarle a su productividad y la de su equipo, no dude en comprar Dibujando la revolución ágil: Ahora a un precio especial.

Dibujando la revolución ágil en Amazon España

Dibujando la revolución ágil en Amazon.com

Dibujando la revolución ágil en Amazon México

Referencias:

[1] The Anosognosic’s Dilemma: Something’s Wrong but You’ll Never Know What It Is por Errol Morris en el New York Times

[2] Dunning-Kruger effect en la Wikipedia