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:
- Que el cliente esperaba más de lo que el sistema hace.
- 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. ....
