Precio fijo

Precio fijoEn el campo de los proyectos IT todas las empresas se han encontrado más de una vez con la problemática de la presupuestación y de la venta de un proyecto “llave en mano”. Una situación en la que teóricamente un cliente tiene unos requisitos, un plazo y un presupuesto, y la empresa desarrolladora se enfrenta a la dificultad de aceptar esas tres variables si quiere vender. Esto es norma común en las Administraciones públicas, por su especial sistema de contratación basado en pliegos de condiciones y concursos públicos, pero también sucede muchísimas veces con clientes del sector privado.

El concepto “llave en mano” es una forma de trabajo muy válida, siempre que se mantenga un nivel de confianza entre cliente y proveedor, y que cada parte entienda bien que está asumiendo unos riesgos.

Sin embargo también es común que los requisitos no estén claros porque el cliente, de forma razonable y no de mala fe, no sabe exactamente lo que quiere o necesita hasta que comienza a ver cosas, y entonces las peticiones de modificaciones son fuente de conflicto.

Adicionalmente las variables de plazo y coste no siempre están basadas en criterios lógicos, sino en condicionantes externos (acontecimientos temporales externos, disponibilidad económica,…), que en muchos casos no tienen nada que ver con el alcance del proyecto.

Todos esto hace que las partes asuman riesgos que  desembocan en tensión y dificultades cuando el proyecto se pone en marcha, y tras varias experiencias similares muchas empresas desarrolladoras, si tienen la ocasión, se cubrirán en los presupuestos con un colchón de seguridad, por si acaso. Sobre todo si además se establecen las temidas penalizaciones.

Una vez más se aplican formas de trabajo de otros sectores, cuando un proyecto tecnológico es más artesanía que ingeniería. ¿No tendría sentido en algunas situaciones, como hacen por ejemplo los arquitectos, establecer una provisión inicial de fondos para construir una primera versión y definir luego, con más conocimiento de requisitos y visibilidad, el resto del proyecto?

Las metodologías ágiles son el camino para esa transformación y entendimiento del desarrollo y programación como un trabajo artesano, pero sólo de puertas adentro. Sin embargo tenemos muchas veces miedo a contarle esto al mercado y a los clientes, y sobre todo a competir y perder frente a los que no lo cuentan.

Puedes seguir cualquier respuesta a esta entrada mediante el canal RSS 2.0. Puedes dejar un comentario o enviar un trackback desde tu propio sitio.

Deja un comentario

XHTML: Puedes usar estas etiquetas: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>