Desarrollo de software. Presupuestos holgados y presupuestos excesivos

Siempre estaré en contra de proyectos de desarrollo de software donde el presupuesto para realizarlo sea claramente inferior al necesario. Esto ha hecho mucho daño a nuestra profesión como también lo ha hecho proponer sistemáticamente ofertas muy por debajo del precio de mercado.

Mientras exista mayoritariamente crisis del software, con el máximo exponente en los Death March Project, nos costará darle a nuestro trabajo el valor que realmente tiene.

Los presupuestos en los proyectos deben ser holgados y esa holgura depende de la propia naturaleza de las tareas a realizar y del contexto en el que se desarrollen las mismas.

Al fin y al cabo los proyectos tienen siempre un coste de mantenimiento, la holgura es simplemente deslizar parte de ese presupuesto de mantenimiento al propio de desarrollo de manera que se pueda evolucionar el producto de manera adecuada, adaptándolo paulatinamente a las necesidades del usuario.

Pero, ¿cuándo un presupuesto es excesivo? Cuando la cantidad de trabajo que se realiza con él es inferior al acabado y calidad que debería tener el proyecto software en el contexto en que se ha realizado. Esto implica que podemos tener presupuestos excesivos incluso en proyectos donde el mismo es muy ajustado o incluso por debajo de lo necesario.

Más dinero no implica hacer las cosas mejor, la Ley de Parkinson es una muestra reveladora de lo que pasa cuando existe mucho presupuesto y no se enfoca adecuadamente el trabajo a realizar.

2 comentarios
  1. aaloy dijo:

    La ley de Parkinson muchas veces ha servido de justificación para que los responsables del proyecto reduzcan el tiempo del mismo a niveles imposibles (un deathmarch) con la excusa de que si se da más tiempo se acaba desaprovechando. Es una mala excusa para que no tener que llevar una gestión del tiempo y de las tareas.

    En el desarrollo de software sabes realmente sabes si era un presupuesto ajustado o no una vez realizado el proyecto. En las primeras etapas de desarrollo la variabilidad es tan grande que esperas siempre que en termino medio el presupuesto sea correcto, sólo cuando el proyecto está avanzando y va definiéndose puedes ir ajustando el presupuesto a la realidad.

    El problema que tenemos muchas veces es la obligatoriedad de hacer presupuestos “cerrados” en etapas en las que el proyecto todavía no está definido. Personalmente soy partidario de que el cliente tome el presupuesto como una declaración de intenciones “miraremos de no pasarnos de ahí”, pero que el proyecto pueda ir variando, añadiendo y quitando funcionalidades según vaya avanzando el proyecto. Cuando el cliente tiene experiencia en el desarrollo de proyectos es un método que funciona muy bien, si no la tiene y está acostumbrado a proyectos tipo constructora de edificios es difícil hacérselo entender, ya que la metáfora tantas veces usada de que un proyecto de software es como la construcción de edificio no es adecuada. Creo que es una de las más perniciosas que hay.

    Para luchar contra la ley de Parkinson hay que gestionar los proyectos por hitos, hacer visibles las tareas realizadas al cliente y medir las velocidad de desarrollo. Pero sobre todo hay que conocer a nuestro equipo. He tenido la suerte de tratar con desarrolladores que itentan siempre es terminar el proyecto en el mínimo tiempo posible.

    • jummp dijo:

      Creo totalmente en la forma de enfocar de proyectos que comentas. Los que nos dedicamos a este negocio no tenemos bolas de cristal y cualquier enfoque de proyecto de naturaleza predictiva tiene todas las papeletas para dar problemas y para no conseguir los resultados esperados.

      El desarrollo de software es adaptativo y presupuestos cerrados de inicio no facilitan esa tarea, si bien lo importante es saber aprovechar de manera adecuada lo que tienes y que el cliente sea consciente de que un producto software de calidad tiene su coste y que este dependerá de muchos factores, entre otras, la participación de manera adecuada del personal que ponga a disposición del proyecto.

      Los Death March Project han hecho y están haciendo mucho daño a nuestro negocio y a los profesionales, que se frustran en proyectos donde se sabe, en muchos casos, que van a ir mal desde el principio y en donde tienen que trabajar con overtime durante largos períodos de tiempo para obtener productos (si es que finalmente se llega a algo) con una calidad discutible.

      Conozco a desarrolladores de software del tipo que planteas, donde su motivación, una vez cubiertas unas necesidades económicas y profesionales (incluso algunos sin eso) es hacer el trabajo de manera adecuada, con calidad, consiguiendo la satisfacción del usuario, permitiendo que el desgaste cliente/proveedor en el proyecto sea el menor posible.

      Pero también conozco el lado opuesto, desarrolladores no productivos y que viven más tranquilos en proyectos donde haya poco movimiento.

      En el desarrollo de software lo más importante son las personas, todo empieza y termina en nosotros: equipo de proyecto, usuarios, responsables del proveedor, responsables del cliente, todos son importantes dentro del rol que desempeñan. Cuando más elementos fallen más inestable será la maquinaria y más complicado será conseguir los objetivos del proyecto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: