Lo hacíamos desde nuestra época de estudiantes. Teníamos un montón de cosas por repasar y deberes por hacer. Desde Dibujo a Matemáticas, pasando por Lengua o Sociales. Desde luego no empezábamos por los complejos ejercicios de Química que siempre nos resultaban tan difíciles. Cogíamos primero los sencillos problemas de la clase de Ética que siempre aprobábamos con nota.

Esto tenía un claro inconveniente: las horas pasaban muy rápido y con alegría dedicadas a hacer muy bien lo que nos gustaba y resultaba fácil, pero pronto se nos hacían las 9 de la noche. Ese era el momento de comenzar, ya sin fuerzas ni capacidad de concentración, con las páginas de la 298 a la 315 del libro de ejercicios de Matemáticas.

Procrastinábamos como hacemos ahora en el trabajo. Nos engañamos manteniéndonos ocupados haciendo las tareas más sencillas y de recompensa fácil. Pensamos que, de esa manera, nadie puede decirnos nada, estamos trabajando mucho.

Vamos postergando las tareas ingratas y con alta incertidumbre. Las sencillas las tenemos resueltas muy pronto. Que hay 10 pequeños errores que corregir, no hay problema, para mañana estarán resueltos todos. Que hay que lidiar con ese complejo problema que ya nos tuvo 3 días atascados con poco avance, quizás mejor la semana o el mes que viene, cuando tenga tiempo suficiente. El caso es que ese momento nunca llega y el cliente comienza a desesperar sin una resolución a su caso.

Si se trata de un proyecto en el que estamos trabajando, tardamos en abrir el melón de los asuntos serios, los que necesitan de análisis y revisión cuidadosos. Para el resto no hay problemas, comenzamos rápidos con ellos. Así entrenemos nuestro tiempo y nuestra conciencia. Después de todo estamos trabajando duro en el proyecto y sin tiempo que perder.

Para cuando ya no haya más remedio que atajar los problemas graves o las tareas complejas, ya se habrá consumido casi todo el tiempo del proyecto. Le habremos dicho además al manager que está finalizado al 90%. Al fin y al cabo, todas las tareas están resueltas (excepto esas dos o tres que estamos siempre evitando)

¿Y si vemos que en esas labores con alta incertidumbre había problemas escondidos? ¿Y si no podemos resolverlos? ¿Qué hacemos ahora con el presupuesto y el tiempo del proyecto consumidos?

Ataca los problemas desde el inicio. Nos producirá rechazo y nuestra mente tenderá a evitarlos. Tendremos que dar malas noticias y comunicar que nos enfrentamos a problemas. Tendremos que decir que solo llevamos un 10% del proyecto completado, cuando ya hace meses que comenzamos. Siempre será mejor esto que autoengañarnos, con avances irreales, comunicar un optimismo infundado, o lo que es peor, fracasar del todo.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• Quality Software Management: Systems Thinking de Gerald Weinberg.

Evita las situaciones en las que te has quedado sin objetivos claros y no sabes qué hacer en el próximo sprint. Buscarás algo que darle al equipo para que no se quede parado, pero no se encuentra nada que hacer. Se ha terminado lo que han pedido y, por entretenerlos con algo, se deciden desarrollar funcionalidades que no se ha estudiado su viabilidad o su valor.

El resultado será código y funcionalidades que habrá que mantener, y mantenerlas tiene un coste, muchas veces oculto, pero un coste. Es el equivalente a los almacenes o estanterias llenas de stock de artículos que a nadie le interesan, ni secompran (son un desperdicio). Nos engañamos a nosotros mismos pensando que el trabajo que le damos tiene algún valor.

Podemos estar meses así, añadiendo funcionalidades al producto que no son más que un lastre o un coste adicional. Si a un producto le añadimos 40 000€ de coste, pero las ventas solo aumentan en 4 000€, solo habremos conseguido gastar diez euros por cada euro ganado.

Es mejor que dediquemos al equipos a investigar, a hacer spikes, a probar o crear MVPs. Con suerte encontraremos algo que aporte valor al cliente y que quiera comprar. Si el resultado de todas las propuestas que probaste no fue bueno, no apuestes tampoco por el MVP menos malo o por la idea que más te gusta a ti o más bonita te suena. La menos mala sigue siendo una mala idea.

Si no hay ideas o se han intentado todas las razonables, quizás sea el momento de abandonar tu producto, de apostar por otro. Si el equipo está unas semanas parado, investigando, o no haciendo nada productivo, probablemente sea mejor que desarrollando stock que vas a arrimar en una esquina de tus almacenes o repositorios virtuales.

No te cases con una idea solo porque es tuya o porque abandonarlo supone darte cuenta de que invertir ahí no fue buena idea. No te ciegues: todas las ideas no son grandes ideas. Busca otra, mejórala, mide y refínala, y quizás esta sí, sea la gran estrella de tu empresa. No dejes que un producto te deslumbre y te lleve a apostar todo por él, a hundirte con él.

No tienes por qué tener una sola bala para acertar en la diana, cuenta con varias opciones, con varios productos o varias funcionalidades. Tendrás más posibilidades de dar con la buena. ¿Prefieres contar con cinco flechas para acertar en la diana o tener un solo intento? Seguramente, a la tercera o cuarta flecha te hayas acercado más al blanco. Habrás aprendido lo que le gusta al cliente, lo que vende, lo que cuesta poco hacer, y tendrás ideas mucho más centradas en el mercado.

Seguro que lo ha vivido alguna vez: le preguntan por cómo va el proyecto que tiene entre manos y usted les indica que está al 90%, pero lleva diciéndoles esto tres meses ya. Mucho se teme que estará otros tres meses más señalando el fatídico 90%.

Los primeros avances fueron rápidos. Se paso del 10 al 30% y luego del 50 al 70% muy rápido. Pronto indicó usted que solo faltaba un 10% para completarlo, pero completar ese 10% le está llevando el 90% del tiempo, ¿por qué pasa esto?

Imagine que tiene diez tareas en el diagrama de Gantt. Una de ellas es la de cadena crítica, la que definirá la duración total del proyecto, el resto se pueden ir haciendo en paralelo y tardarán menos. Cuando tenemos las 9 tareas menores al 100% y la crítica solo al 50%, decimos que el proyecto está al 90%. Después de todo, la mayoría de tareas está terminada. Lamentablemente, la cruda realidad es que está solo al 50%. Solo cuando acabemos la cadena crítica acabaremos el proyecto.

Es esta tarea crítica la que en realidad nos define la duración del proyecto. Las otras son auxiliares y de menor importancia. Por esto nos ha llevado un año para llegar al 90%, que en realidad es solo el 50%, pero tardamos otro año completo cuando solo quedaba, supuestamente, el 10%.

Otro error habitual es el de comenzar las diez tareas al mismo tiempo al inicio del proyecto, aunque no sean especialmente importantes para el avance. Queremos marcar como terminadas cuantas más tareas mejor.

Por desgracias, si intentamos hacer esto, podemos perder el foco gestionando diez cosas a la vez, en lugar de enfocarnos en que la cadena o tarea críticas sean resueltas lo más pronto posible y sin obstáculos. Estas serán las que nos definan la duración del proyecto (y probablemente su coste final).

Existe una teoría, llamada Teoría de la Latencia de las Decisiones (Theory Decision Latency), que nos viene a decir que la duración del intervalo, o tiempo que tardamos en tomar una decisión, es más importante que la calidad de la decisión. Esta teoría presupone que, para el éxito de nuestro proyecto, más vale tomar decisiones de forma rápida aunque algunas puede que no sean las mejores posibles.

El Standish Group en su informe CHAOS Report de 2018 ha querido probar, midiendo en centenares de ejemplos reales, si esta hipótesis está fundamentada o no. Clasificó los proyectos entre los que tardaban 1 hora de media en tomar cada pequeña decisión del proyecto (baja latencia y equipos Highly Skilled), 2, 3, 4 y hasta 5 horas por decisión (alta latencia o equipos Poor Skilled).

Los investigadores del Standish Group pudieron comprobar que simplemente bajando el nivel de latencia, o el tiempo medio que se tarda en tomar decisiones, podía lograrse una mejora del 25% en el rendimiento del proyecto.

Aquí algunas de las cifras del informe:

Ahora ya tenemos datos que avalan esta teoría y confirman lo que ya intuíamos: dejar todo para después, que la decisión la tome otro, y la burocracia o el exceso de jerarquía, perjudican mucho más de lo que ayudan.

Todos conocemos esos proyectos en los que nada se mueve si no lo aprueba el consejero delegado de la empresa o un comité formado al efecto para tomar cada una de las decisiones (como en The Unicorn Project). Hay demasiado miedo a equivocarse y, si algo pasa, nadie quiere ser tomado como el reponsable de haber dicho: «Sí, adelante».

A veces, no es tanto cuestión de miedo o de cubrirse las espaldas, sino una mal entendida forma de «Hacer las cosas bien». Se quiere tomar siempre la mejor entre las mejores opciones disponibles, no importa si para encontrarla hay que invertir decenas de horas o cientos de euros (aunque la diferencia entre una opción y otra no implique sino un par de clics más en una escondida opción de pantalla).

Un Product Owner hábil que conozca bien el mercado y el producto puede ayudar mucho con esto. Si hay dudas, sabe a quién preguntar. En cambio, si lo conoce él, resuelve rápido. Si es una cuestión de diseño o estética, no va a lanzar la pregunta a todos los stakeholders, simplemente toma una decisión y continúa con su trabajo.

Estará accesible al equipo y cuenta con datos que le permitirán tomar decisiones. Si no tiene herramientas suficientes, planeará acciones que le permitan medir y tendrá siempre en cuenta el coste que tenga esa medición, pero también el coste de retrasar la decisión. Decide, prueba y mide ¿salió mal? Siempre será mejor que la parálisis por análisis. Por lo menos no habrá apostado todas sus cartas en este juego.

Referencias:

• Big, Bang, Boom Revisited: Why Large Projects Fail. A case study research of NPAC por Prof. Jim Johnson et al.
• Review Chaos Report 2018 por Henry Portman.
• What your measures reveal about your mindset por Patricia Kong.

Hace unas semanas comentaba en el blog sobre el que llamaba el mayor asesino de la productividad: la multitarea. Si quieres ser efectivo o que lo sea tu equipo, no les pidas que hagas varias cosas al mismo tiempo, que dediquen un 50% a esto, y luego a lo otro. Solo conseguirás que tarden una eternidad en terminarlo todo.

La presión podrá contigo, te reclamarán cosas de aquí y allá y todo será importante, pero contente y tratar de terminar lo que tienes entre manos. No inicies otras 10 cosas para dejarlo todo abierto y a medio terminar.

Los cambios de contexto y de preparación entre una tarea y otra se comerán todo el tiempo disponible. Pero, incluso sin tener estos tiempos en cuenta, hay una forma clara de ver cómo te va a afectar si intentas la multitarea: con una imagen.

Imagina que tienes tres proyectos o tareas por hacer, las que tienes en la parte superior de la gráfica. Cada una dura 10 unidades de tiempo (10 días o semanas, por ejemplo). Si trabajas en ellas de forma secuencial, sin distracciones, comenzando una solo cuando está terminada la otra, terminarás en 30 días.

El cliente de la tarea A, que llegó primero, o al que se le atribuyó como cliente o tarea de máxima prioridad, se le terminará su trabajo en 10 días, igual que todos los demás. El tiempo medio para entregar los trabajos es de 10 días.

Imagina ahora que los intentas hacer todos a la vez. Comienzas con A y luego presiona B. Dejas lo que estás haciendo y comienzas con él. Pero más trabajos llegan y aparece C a la que también le dedicas su slice de tiempo.

El resultado es que ahora tardas 20 unidades de tiempo, el doble, en terminar cada una de ellas. Eso sin contar los tiempos de latencia, preparación de los trabajos y los cambios de contexto o el estrés del equipo. Merece la pena estar centrado en un solo trabajo a la vez, no?

Más sobre multitarea en mi blog:

• Cómo manejar la presión.
• Estoy muy ocupado. Pregúntame la semana que viene! (I)
• Estoy muy ocupado. Pregúntame la semana que viene! (II)

Referencias:

• Libro Cadena crítica de Eliyahu M. Goldratt.

Todos hemos aplicado alguna vez un margen a nuestras estimaciones. Son los conocidos «colchones» de seguridad. No queremos fallar y llevarnos una bronca, así que cuando nuestra jefa nos pregunta que cuánto podemos tardar en hacer algo, rápidamente le decímos que 5 semanas.

En realidad pensamos que con 2 o 3 semanas estaría resuelta, con suerte quizás solo en una, pero no queremos ver caras largas si fallamos. Después de todo, sabemos que las estimaciones siempre se equivocan.

El otro equipo también indica que tardará 5 semanas. Su jefe de proyecto ha añadido también un 100 o 200% de colchón.

Cuando nuestra responsable recoge ambas estimaciones, la suma le sale 10, pero añade otras 3 porque ella también sabe que las estimaciones se equivocan. Lo ha visto multitud de veces, ha puesto nuestras estimaciones, y siempre hemos tardado un 30% más (cuando menos).

Se ha acostumbrado a añadir también un margen de seguridad, pero a pesar de eso, está comprobando, que aún así, fallamos en cumplir los plazos de entrega ¿Cuánto más tiene que añadir de colchón? Está empezando a dudar. Está segura de que si hubiese añadido un 100% en lugar del 30%, también habríamos incumplido los plazos.

Una de las explicaciones para que esto suceda es el síndrome del estudiante, muy relacionadas con las Leyes de Parkinson. Como tenemos tiempo lo dejamos todo para el final. Nunca juzgamos el tiempo que nos queda como muy corto para comenzar. Como el mal estudiante, se nos queda toda la materia a estudiar para el día antes del examen.

Como cada equipo sabe que tiene margen, empieza tarde a trabajar en el proyecto por el síndrome del estudiante: «Total, tengo tiempo. ¿Para qué apresurarse?», parecemos pensar. Llegaremos al final apurado como siempre.

Nos habremos comido todo el colchón. Si pudimos haber entregado el trabajo en la semana dos, los habremos hecho en la cinco, impidiendo así que el otro equipo comenzase tres semanas antes y las ganase a la fecha de entrega.

Otra cosa que suele pasar, y aquí en donde entra la sabiduría de Cyril Northcote Parkinson, es que si algún equipo termina antes, no avisa, dedica el tiempo a hacer pequeñas mejoras, a pensar que se podía hacer mejor de otra manera. De nuevo pensamos «Qué más da! Tengo tiempo para darle otra vuelta!».

El resultado es que los adelantos no pasan a la siguiente fase, los avances se pierden. Siempre nos comemos todo el colchón. El proyecto irá al ritmo de la tarea que más atrasada vaya, adelantos posteriores o anteriores no adelantarán en nada al proyecto (los retrasos se acumulan, pero los avances no).

Pero siempre habrá una tarea crítica en el proyecto, aquella donde todo margen siempre es poco, donde el equipo está más ocupado o la dificultad y la incertidumbre la hacen más difícil y ajustada a plazos. El equipo encargado de ella es el que recibe todas las peticiones de ese tipo en la empresa. Están siempre trabajando al 120% y no paran de llegarles trabajos. No pueden con todos y terminan siempre saltando entre tarea y tarea.

La prioridad en esos equipos se decide según el jefe de departamento peticionario que más levante la voz en las reuniones con dirección o el que demuestre más mala leche. El namedropping es habitual en esas discusiones. Es aquí cuando entra en juego el mayor asesino de la productividad, la multitarea. Pero eso será tema de otro post.

Referencias:

• Libro Cadena Crítica de Eliyahu M. Goldratt.