El otro día estaba en una reunión de planificación de un proyecto. Pensando en el calendario, alguien dijo «tenemos que lanzar antes de X». Y a mí se me hizo un plazo demasiado corto, y así lo dije. «Pero es que esa fecha es importante porque…», me respondieron. «Vale, pues la mantenemos si queréis, pero dudo que lleguemos. Y si llegamos, va a ser haciendo las cosas a medias».
No me entendáis mal. El establecimiento de fechas de entrega o deadlines es un paso clave en la planificación de cualquier proyecto. Según la conocida como ley de Parkinson, cualquier tarea se expande hasta llenar el tiempo disponible para que se termine. O sea, que si no se establecen fechas de entrega, las tareas tienden a extenderse hasta el infinito… Disponer de fechas límite es importante, por lo tanto, para focalizarse en la finalización de las tareas, y también para tener un objetivo compartido.
El problema es cuando estas fechas de entrega se mantienen aun a costa del buen término de un proyecto. Llega la fecha acordada, la tarea no se ha terminado adecuadamente (bien porque la planificación era incorrecta, bien porque se producen errores en la ejecución; da lo mismo), pero alguien insiste en que «da igual, hay que lanzar como sea en la fecha prevista».
¿Resultado? Productos a medio terminar, sin pulir, que no terminan de funcionar bien, errores, insatisfacción… eso sí, se ha «cumplido» con la fecha.
Me parece un gran error de gestión permitir que estas cosas pasen. Si se había hecho una planificación irreal, entonces habrá que asumir el error y corregir dicha planificación para fijar una fecha de entrega más realista. Las cosas tienen un proceso, y un periodo de maduración, y llega un punto más allá del cual no se puede comprimir sin que se resienta el resultado final.
Y si se producen errores en la ejecución, lo que procede es analizar las causas y resolverlas. Cualquiera de estas opciones es mejor que poner en el mercado un producto defectuoso, con todo lo que eso conlleva.
El problema es que muchas veces estas fechas son compromisos adquiridos/impuestos por otros: un jefe, un comité de dirección… gente que valora más un producto regular en fecha que un buen producto un poco más tarde. Es más fácil que caiga una bronca por un retraso que por algo mal hecho (fundamentalmente porque la mayoría de las veces no le dedican ni un minuto a usar el producto/servicio; le echan un vistazo por encima y listo). Mientras tanto los clientes/usuarios, que son quienes deberían importar (al fin y al cabo son ellos los que nos pagan) van a notar mucho más los fallos, mientras que las «fechas de entrega» que nos hayamos fijado a nivel interno les vienen a importar bastante poco…
En definitiva, ¿qué es lo importante? ¿quedar bien con «los jefes» o con los usuarios/clientes? Lamentablemente, una vez más, en el mundo corporativo la respuesta es la que no debería ser.
Foto | Joe Lanman