Y lo que antes en negocios era ubicación, ubicación, ubicación es nuestro talón de Aquiles en Software: Requisitos, requisitos, requisitos.

En realidad abstrayéndonos de la implementación y pensando en términos de reglas de negocio es el mayor riesgo y el responsable del fracaso de la mayoría de los proyectos.

¿Que pasa con los requisitos?, pues que son un contrato y si el sistema hace lo que los requistos dicen pues estamos bien (no iremos presos), siempre y cuando que los requisitos y sus especificaciones documentadas sean aprobadas por el cliente.

De esto surgen dos escenarios negativos:

1. Que el cliente esperaba más de lo que el sistema hace.
2. Que el sistema no implementa los requisitos.

¿Que errores de dirección permiten que ocurra esto? pues en lo que siempre fallan quienes se centran en la tecnología y no en las reglas de negocio de lo que estamos desarrollando - cosa que alguna vez me ocurre:

• No existe gestión de espectativas: El cliente normalmente no entiende hasta donde llega el proyecto, se debe definir un alcance: ¿Qué es el proyecto? ¿Que no es el proyecto?
  

• No existe un listado de características y de funcionalidades formal del sistema: Si no hay documentos no hay nada que hacer.
  

• Que los documentos de requisitos están en lenguaje técnico que el cliente no entiende.
  

• Que no se da la importancia a la gestión de la configuración: Un gestor de configuración es casi un médico heroe, se encarga de controlar los artefactos producidos,sus cambios, versiones, su archivo, su coherencia, etc; no tener un gestor de configuración - o no hacer las actividades de gestión de configuración - es conducir un automovil con los ojos cerrados.

Y yo que creía que el gestor de configuración era quien configuraba las máquinas. ....