Sunday, 8 December 2013

Contratos a precio cerrado

Hace algunas semanas me preguntaba Antonio, a través de los comentarios de este blog, por el tipo de contrato que tenía en mis proyectos y si estos contratos se realizaban con clientes internos o externos. La negociación sobre el contrato es uno de los asuntos más difíciles con los que nos podemos encontrar en un proyecto y probablemente, dónde puede surgir más fricción entre proveedor y contratante.

Trabajo en el área de administración pública de una empresa de desarrollo de software. Eso significa que, al menos en el 90% de los proyectos en los que trabajo, tengo como cliente a un organismo público. Los contratos vienen normalmente determinados por un pliego de cláusulas administrativas y otro de prescripciones técnicas en los que se detallan los servicios contratados, las características del producto a ser desarrollado y el precio máximo que puede tener la oferta. Se especifican incluso las características técnicas del software y hasta el perfil de los participantes en el proyecto. Todo está muy acotado y delimitado. Es el precio que tiene que pagar la administración pública para evitar arbitrariedades.

Si se ha tenido suerte y se ha podido ganar el concurso público nos enfrentamos luego, tanto cliente como proveedor, con la cruda realidad de los proyectos. Y es que las circunstancias cambian, aparece nueva legislación que afecta al proyecto o lo que se pensó que era correcto unos meses antes se ha podido comprobar que ahora las necesidades son distintas. ¿Qué hacemos? Si adaptamos el producto a todos los cambios que el cliente necesita,  nosotros como proveedores, sufriremos ese coste adicional. Si negamos al cliente cualquier posibilidad de cambio, remitiéndonos siempre al contrato y a los pliegos, corremos el riesgo de entregar al cliente un producto ajustado a un decreto del año anterior o que, por otras causas, ya sabe que no le va a servir a sus necesidades.

La forma de evitar ésto, por lo menos la que mejor me ha funcionado hasta ahora, ha venido dada por la propia forma de trabajar en estos proyectos, usando Scrum. Al inicio del proyecto hago una lista con las funcionalidades que hay desarrollar y le asigno a ellas una puntuación que el cliente conoce desde el principio. Si el cliente quiere incluir dos nuevas funcionalidades le pido que me indique qué otras funcionalidades de similar puntuación sacamos de la lista. Normalmente esta solución le sirve para resolver la situación y no tiene problemas en renunciar a otras funcionalidades que ahora sabe que no son tan importantes. Si todo queda constatado en un acta de reunión y, sobre todo, queda entendido a qué se renuncia y qué se va a obtener a cambio, no suele haber muchos problemas.

Esta es la solución que yo aplico. Como siempre, espero que le pueda servir a alguien.

No comments:

Post a Comment