Archivos de Autor: Antonio Martel

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.

Hace unos años, en 2018, Jonathan Smart y Morag McCall dieron una charla en la DevOps Enterprise Summit de Londres. Jonathan es el responsable de Ways of Working en Barklays y Morag trabaja en el equipo de gestión de portafolio de productos del mismo banco. Allí defininieron una serie de antipatrones que deberíamos evitar cuando gestionamos las peticiones de desarrollo a un equipo software. Aquí las resumo:

Comprometerse en exceso

O over-commitment. Se trata de cuando le decimos a todo que sí al cliente, pero en realidad no tenemos ni idea de cuanto producimos en cada sprint.

Ante la pregunta de si me puedes hacer esto y aquello para el próximo mes, la respuesta siempre es sí. El caso es que nos comprometemos a 7 u 8 funcionalidades al mes, pero en realidad nuestro equipo solo produce 3 o 4.

El backlog no para de crecer y la desesperanza de nuestro cliente tampoco. Se han creado unas expectativas que no se van a poder cumplir y que crean frustración al que pide, pero también estrés y agobio al que entrega.

No olvidemos tampoco otra problema importante con esto: como la presión aumenta, se intenta que el equipo pueda hacer todo al mismo tiempo y que esté ocupado a un 120%. Ya sabemos los problemas que traen la multitarea y el estar siempre ocupados. Aquí unos tips para solucinarlo: Cómo manejar la presión y Estoy muy ocupado, pregúntame la semana que viene I y II.

Hambruna y sobreproducción

Esto sucede cuando el cliente, o el product owner/product manager que lo representa, no son capaces de entregar cosas con el ritmo suficiente para el equipo de trabajo. Tardan demasiado en analizar lo que necesitan, en prepararlo y detallarlo para que puedan acometerlo o, lo que suele ser más habitual, no se deciden a autorizar el trabajo una vez creado.

Esto crea una situación en la que al equipo de trabajo no llegan las suficientes peticiones, creando una «hambruna». Ante la indecisión y la falta de trabajo, ellos mismo deciden qué hacer. Comienzan entonces a desarrollar features que, posiblemente nadie necesite, y que no van alineadas con la estrategia del producto o de la empresa. Se crea entonces una sobreproducción.

El atracón y la hambruna

Smart y McCall llaman con este nombre al problema que se da cuando al equipo de trabajo le llega un atracón de tareas y se indigesta con ellas. Lo pasa fatal para terminarlas tardando mucho tiempo.

Se da en esas situaciones en las que se tiene un proyecto clave para la empresa al que se le dan muchas vueltas antes de entregarlo al equipo de trabajo. Se analiza y se perfila mucho, ya que grande y muy importante para la empresa. Cuando finalmente se le da el visto bueno se quiere tenerlo ya.

El equipo de trabajo recibe todas esas tareas de golpe y comienza a trabajar urgentemente en ellas. Lo pasa mal y las horas extra y el estrés son habituales.

Cuando por fin lo entrega, queda casi de brazos cruzados: el cliente está preparando otro gran hito que va a tardar unos meses en tener listo. Mientras, está casi sin trabajo. Es otro momento de hambruna.

Cuando llega el nuevo atracón, todo vuelve a comenzar. Nuevos sudores para digerir todo el trabajo pendiente para luego llevar a un valle de inactividad.

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:

• The PMO Is Dead. Long Live The PMO by DevOps Enterprise Summit
• The PMO is Dead, Long Live the PMO – Barclays en Youtube.