Te soy sincero, me he pensado varias veces si había que escribir este post, de verdad, aún hoy, año 2016, me cuesta ver y creer que aún tenga que estar explicando cosas como la que ahora te voy a contar.
Y lo peor es que, seguramente, tu, lector de este blog, lo que vas a leer ya lo sabes bien y que aquellos que no lo saben… no van a leer este post. Así que, si conoces a alguno de aquellos, imprímele este post y, aunque sea de manera anónima… déjaselo encima de la mesa (el mundo, tú yo y muchos otros te lo agradecerán).
Aunque el tema para muchos sea evidente, la explicación me ha llevado más del límite que suelo ponerle a los post, por lo que, como es costumbre, lo voy a dividir en dos, el de hoy y el de mañana.
Empecemos…
Evidencia de partida:
Que alguien de negocio, por mucho deseo que tenga, mucho que sepa de su negocio, por mucha pasta que se supone vaya a ganar la empresa con ello, por mucho cargo que tenga, diga que el software “x” con la funcionalidad “y” debe estar en la fecha “z”, solo porque él lo diga, sin más… no implica necesariamente que eso sea posible. Puede que sí, pero puede que no.
Así es, lo siento, la vida es así de dura. Voy a tirar de ejemplos de “edificios”, con lo peligrosos que son (el ejemplo del albañil y la estimación software y la ágil), con lo poco que me gustan, pero a ver si queda claro: Quiero para mañana un rascacielos de 20 plantas. Imposible.
Y dicho lo anterior, que alguien, sin más criterio, evidencia, método o justificación fije una fecha de entrega extremadamente ajustada para tener listo el software “x” con la funcionalidad “y” nos lleva a dos posibilidades:
a) Que la fecha de finalización sea IMPOSIBLE de cumplir, INCLUSO trabajando mal
Esto es lo que se considera zona imposible (aún añadiendo más gente, un clásico entre las malas prácticas, sino lee ¿Cuánto se puede recortar el tiempo de un proyecto añadiéndo más gente?) y, si haces esto, lo único que vas a conseguir es lo que le ha pasado y pasa a innumerables proyectos, una y otra vez, tropezar en la misma piedra, buscar resultados diferentes haciendo centenares de veces lo mismo, vas a conseguir… estrellarte. Todo el mundo saldrá quemado, retraso, tensiones, entregarás cosas a medias, etc.
Y, normalmente, en este caso, al final, tardarás más en terminar que, aun siendo también una mala decisión, tomes la siguiente opción…
b) Que la fecha de finalización sea POSIBLE de cumplir, PERO sólo trabajando mal
¿A qué me refiero por trabajar mal? Pues a que la entrega sólo sea posible quitando del medio todo aquello que “consume” tiempo y que no sea implementar líneas de código.
Ejemplos, quita pruebas, quita evaluar la calidad del código, quita pensar en un buen diseño, quitar montar un servidor de integración continua, quita pensar en control de versiones, quita hacer retrospectivas, etc. Fuera. Todo.
En esta opción b), a duras penas, trabajando mucho y mal… al final se llega a la fecha de entrega (o a una fecha cercana). Se llega a entregar algo, aunque sea “podrido por dentro”, y que tiene la funcionalidad necesaria. La funcionalidad se ve, pero, para ponérnoslo más difícil, todo lo malo que hay dentro no se ve.
Es por ello que, cuando alguien toma una decisión del tipo a «Este proyecto necesitamos entregarlo cuanto antes, por ello en este caso nos vamos a saltar las buenas prácticas (aquí puedes poner, las buenas prácticas ágiles, el proceso de gestión de versiones, el ciclo de vida, integración continua, Testing, etc.) y lo vamos a hacer como siempre», consciente, o inconscientemnte, está diciendo «lo vamos a hacer mal para llegar antes».
Pero ojo, que mal se va a hacer y ello tendrá consecuencias a medio – largo plazo.
Seguimos mañana…
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Yo digo que si las planificaciones se hicieran en condiciones trabajaríamos como los alemanes. El problema viene cuando las tareas se ajustan al tiempo y no el tiempo a las tareas.
Espero que sí lo haya leído alguien de los que desconocen este problema. Yo me he visto tentada de imprimirlo y dejarlo correr libremente por la oficina 😉
Lo que veo bastante a menudo es mucha resignación en los desarrolladores y testers, de manera que cuando alguien de negocio dice «quiero X para el día Y», se baja la cabeza y se hace sin rechistar. Luego en la máquina del café se quejan a más no poder pero muy pocos nos partimos la cara defendiendo estimaciones más realistas con las personas que marcan las fechas de entrega.
Una petición 🙂 En estos post que tienen varias partes ¿podrías enlazar una parte con la siguiente o la anterior según corresponda? He llegado al post 6 meses después de la publicación y ahora para encontrar la parte 2/2 facilitaría mucho el tener el enlace
Un abrazo
Silvia