En el post anterior hablé de las expectativas de los proyectos, y de qué debe y no debe hacer, cuando existe algún conflicto de expectativas entre proveedor y cliente.
El problema con las expectativas creadas es que nacen, crecen, se magnifican, pero jamás mueren. Ya conoce la historia, muchas veces se entusiasma con nuevas tecnologías y las comenta enfrente del cliente sin conocerlas detalladamente, o bien durante la venta se le escapa algún “sí” a algo que debió haber sido “no”, y el costo de esa palabra errónea le puede costar varios cientos de horas de trabajo extra.
Un apropiado inicio para resolver esta problemática es a través de una detallada definición del contrato sobre el servicio que va a proveer. En desarrollo de software se puede ver de todo, desde trabajos realizados por estudiantes, pasando por freelancers y empresas informales (sin procesos definidos), hasta empresas constituidas con procesos claramente definidos. La diferencia más notable entre cada uno de éstos es que, entre más extenso y detallado el contrato, mayores las dudas resueltas antes de empezar, y por lo tanto menores las sobre-expectativas generadas. El sólo ejercicio de definir un buen contrato de desarrollo de software le ayudará inmensamente a definir qué servicio va a proveer, y cómo lo realizará. Ésta es una inversión de tiempo a la que debe obligarse para formalizar la relación con su cliente, y no dejar dudas para más adelante. Tenga en cuenta lo siguiente: una situación ideal es aquella en la cual todo, absolutamente todo es hablado y aclarado antes de empezar el proyecto.
Según el PMBOK, un contrato debiera tener como mínimo las siguientes cláusulas:
- Statement of work or deliverables
- Schedule baseline
- Performance reporting
- Period of performance
- Roles and responsibilities
- Seller’s place of performance
- Pricing
- Payment terms
- Place of delivery
- Inspection and acceptance criteria
- Warranty
- Product support
- Limitation of liability
- Fees and retainage
- Penalties
- Incentives
- Insurance and performance bonds
- Subordinate subcontractor approvals
- Change request handling
- Termination and alternative dispute resolution mechanisms
¿Tomó nota? Se ve simple, ¿no cree? Lamentablemente, en realidad no lo es. ¡Pero no baje los brazos! Es posible que este trabajo le ahorre varios miles de pesos en su próximo proyecto. ¿No cree que amerite algunas horas de inversión?
Diego Nicotra