Cuando las fechas se imponen al producto

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

También en

Raúl Hernández González

Soy Raúl, el autor desde 2004 de este blog sobre desarrollo personal y profesional. ¿Te ha resultado interesante el artículo? Explora una selección con lo mejor que he publicado en estos años.

¡Y si te suscribes podrás seguir recibiendo más reflexiones y herramientas útiles para ti!

También en

Latest posts by Raúl Hernández González (see all)

10 comentarios en “Cuando las fechas se imponen al producto

  1. 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).

    Ains, cuánta razón, amigo mío… me temo que la fecha de entrega irreal es un mal que sufrimos mucho los consultores, ya que el cliente no suele tener mucha idea de lo que hay que hacer y se piensa que se puede hacer en 2 días… a veces el interlocutor es del área técnica y sí te entiende, pero la orden viene de arriba, y la fecha (sobre todo cuando se trata de proyectos en la Administración Pública y vienen elecciones) es lo más importante.

    Lo peor es que a veces el propio “jefe” es usuario de lo que se lanza (en mi caso, llevamos muchas implantaciones de telefonía IP, y el jefe también se encuentra con un nuevo teléfono y tiene que usarlo!), y si no se planifica correctamente, te llevas la bronca igualmente (porque no sabe como transferir una llamada, porque no se ha configurado un botón con lo que él quería…).

    salu2

  2. ¿El cliente? ¿Eso qué es?

    A mi me toca pelearme con los clientes de una empresa más bien conocida en el mundillo*, y con el tiempo uno se da cuenta de que lo que menos importa es muchas veces el cliente.

    * ¿En qué mundillo? eso es otra cuestión :-P

  3. Y sin embargo, cuando hay perspectiva, no se recuerda lo que se ha corrido, el esfuerzo que se ha hecho para llegar a la fecha límite, ni que el proyecto se cerró con carencias porque su responsable en el cliente quiso ponerse la medalla de que estaba terminado para la fecha tal…

    No, al final, lo que se recuerda es: el proyecto lo hizo TAL y es una chapuza: no los vuelvas a contratar…

    Como consejo, es mejor atarse los machos y aguantar las broncas iniciales que te da un cliente por llegar fuera de plazo, que entregar un proyecto de calidad deficiente.

  4. Estoy completamente de acuerdo, de hecho esta misma conversación la tuve con un amigo de toda la vida que es consultor de temas de GIS y, a pesar de que es novato, él me decía que se planifica bien, yo por otro lado le decía que se planifica mal, pero, ¿por qué? Muchas veces los jefes no son especialistas en las herramientas a utilizar y por tanto, cuando se ponen a planificar estiman los tiempos como ellos consideran sin preguntar a los consultores que harán el trabajo.

    Evidentemente un consultor junior no debería planificar un proyecto, pero, por otro lado, ya que va a hacer el trabajo, debería al menos ser consultado porque puede ser que el proyecto tenga algún requerimiento que el consultor no conozca y para el cual tenga que auto-formarse con la pérdida de tiempo consiguiente.

    Lo mismo pasa con los clientes, cuando un cliente contrata a un consultor normalmente es porque no sabe llevar a cabo el proyecto y, por tanto, tampoco debería hacer la planificación. Aunque, benditas sean las versiones Beta.

  5. Hay que saber decirle al cliente que no, que un trabajo es un compromiso mutuo no un encargo unidireccional y que la “chapuza” no es válida si no es aceptada por ambas partes (lo que también puede pasar ; ).

  6. En las grandes corporaciones priva el hecho de quedar bien con los jefes antes que con los clientes y viene dado por el hecho mal entendido de que lso jefes son los que pagan nuestro sueldo y no los clientes, pero esto no es nada nuevo y es sólo harina del mismo costal, a ver quien en la actualidad hace lo contrario.
    SM

  7. Me suena eso que dice Senior Manager… Mal planteamiento, que a la larga no trae buenos resultados y lleva a la chapuza continua. Pero bueno, cada uno que haga lo que quiera.

Deja un comentario