Di NO a los colchones

0

Una práctica muy común, y muy mala, es la creación de colchones en nuestras estimaciones. Es lo que los ingleses llaman hacer “padding”, y que consiste simplemente en hinchar la estimación de las tareas para no pillarnos los dedos. Es una mala práctica, ya te hago el spoiler. ¿Por qué? Sigue leyendo que te lo explico.

Origen del problema

El programador vive en un mundo hostil. Negocio no le entiende. Le pregunta ¿Cuánto tardarás? El programador dice 4 días. A los 4 dias, sea por el motivo que sea, la tarea no está acabada y las culpas caen en el programador, “Te comprometiste en hacerlo en 4 días y has tardado 6. Esto no se puede volver a repetir”. Cada vez que el programador tarde más de lo que esperaba, negocio le morderá. Y los programadores tienden a ser optimistas en sus estimaciones.

Seguro que alguna vez te has visto en esa situación. Así que la siguiente vez que vienen a preguntarte ¿Cuánto tardarás? aumentas artificialmente la cifra. Ya no estás respondiendo lo que crees que tardarás, sino que ves la soga apretarse alrededor de tu cuello y vas a intentar que sea lo más ancha posible, para que no te ahoge. Así que ya no contestas lo que tardarás, sino el máximo posible que pueda “colar”. Piensas en 4 días, y dices que tardarás 8. Así seguro que llegas. El resultado: que de una estimación optimista pasamos a dar un dato muy pesimista.

Esta práctica, la de aumentar artificalmente las estimaciones, es crear el colchón o hacer padding. Y es malo por muchos motivos, que veremos luego. ¿Pero por que ocurre esto?

El origen del problema está en convertir las estimaciones en compromisos. A la pregunta ¿Cuánto tardas? se responde con una estimación, pero negocio entiende un compromiso. Si negocio preguntase ¿Cuándo es seguro que estará acabado? entonces sí es un compromiso. Pero no es eso lo que se pregunta. El problema está en que negocio no entiende la alta aleatoriedad que hay en el proceso de desarrollo. Hay muchísimos factores que pueden afectar a la fecha de entrega. El primero de ellos es que el alcance cambia a ritmo de vértigo. Y creo que el origen del problema está en intentar entender el proceso de desarrollo de software como si de un proceso de construcción o industrial se tratase. Es algo que tiene que entender negocio: desarrollar software no es construir casas.

Resumiendo: El origen del problema está en que negocio interpreta las estimaciones como compromisos y el programador para defenderse crea colchones.

El problema de los colchones

El problema principal es su ofuscación. Es un engaño, a todos los niveles, y trae problemas. Primero, no controlamos su uso. Un colchón sólo debería consumirse cuando hace falta. Pero como está mezclado con la estimación de la tarea, no podemos controlar cuando se consume y cuando no. Y como no se refleja el programador siente que tiene tiempo de sobra y se relaja. De alguna manera le domina el espíritu de la gacela lenta. Por ejemplo, la tarea se estimó en 4 días, pero se comunicaron 8. Así el programador no siente la necesidad de acabar en 4 días, sino en 8. Así que puede comenzar a consumir el colchón en otras cuestiones. Incluso puede llegar a aplicarse el principio de Parkinson y terminar haciendo gold plating.

De hecho en muchas ocasiones el programador sentirá que tiene que consumir el tiempo que ha dicho o quedará descubierto que se dedica a hacer padding. Tiene que consumir su tiempo, o si no cuando dé nuevas fechas de entrega le dirán que está hinchando, que siempre hincha. Es lo que tienen las mentiras, que hay que ocultarlas. Así todos terminarán afectados. Y el más afectado, la organización, que podía tener esa tarea en 4 días, y al final será en 8.

Resumiendo: Incluir un colchón es mentir. Es ocultar la realidad. Y eso se termina pagando.

Solución al problema

La solución está educar a negocio en que esto de estimar tareas no es una ciencia cierta. Le podemos dar una estimación, pero se puede incumplir por muchos motivos, por lo que tiene que ir con cuidado.

Mi experiencia me dice que negocio puede entender frases como: “Probablemente lo tendré en menos de 4 días, pero puede complicarse y llegar a tardar hasta 6. Sería raro que tardase más de 6, pero ya sabes que esto no es una ciencia exacta. Si quieres un compromiso, te diría, para estar seguros, 8 días. Pero ya te digo que creo que tardaremos menos.”

Estamos hablando de darle horquillas, no fechas concretas. Ya sólo con ese ejercicio nos protegemos del compromiso, y evitamos crear colchones. El programador sentirá que tiene que entregar en 4 días, pero que si salen champiñones por el camino, se puede retrasar sin que le decapiten en público.

Al final una horquilla no es más que una estimación probable, más una reserva. Las famosas reservas de gestión o de contingencia tan manidas de PMBOK. Y hay muchos métodos para calcular la reserva que hay que poner. Quizás el más famoso es el método PERT.

Pero en metodologías ágiles, incluso si estimamos con puntos de historia, las reservas también pueden ser utilizadas. En estos contextos se suele hablar de periodos de aire. Y como dice Alexander Menzinsky en su blog:

La cadencia, que viene a ser marcar un ritmo de tiempo fijo a nuestras tareas, hace que acometamos estas de principio a fin maximizando el ratio de entrega y calidad, como lo hacemos con los sprints de Scrum. La cadencia nos permite poner flujo a tareas que tengan alta variabilidad, como lo son las tareas en el desarrollo TI. Para hacer posible la cadencia necesitamos pequeñas holguras o aire con cada golpe de ritmo, entre cada sprint, no podemos concebir un solo de batería sin silencios.

Alexander Menzinsky

La entrada de Alexander es muy recomendable porque cuenta como pasó por el problema de los colchones en un entorno Scrum y como llegó a la misma conclusión que te planteo aquí.

Al final hablamos de crear holgura, para poder afrontar los imprevistos del camino. Hay veces que la holgura viene por factores externos, o por paralelizaciones fuera de la cadena crítica. Pero en otros casos es necesaria crearla. Y si la creamos, que sea declarada, con conceptos como reservas o aire, pero no oculta en colchones.

Conclusión

Di no a los colchones. Enseña a negocio que una estimación no es un compromiso. Y, si lo necesitas, usa conceptos como las reservas o el aire para ganar la holgura que te hace falta.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios