Sensibilidad al cambio de alcance en ingeniería de software.

Gestionar un cambio de alcance en un proyecto suele ser, en algunos casos, más o mucho más complejo de lo que el cliente podría imaginar. 

Si hablamos de ingeniera de software parece que la sensibilidad por parte del cliente respecto al cambio  en el alcance del proyecto suele ser escasa o incluso nula. ¿Por qué? 

Sin embargo, si observamos otros ámbitos de la ingeniería, parece que este tema está superado. Por ejemplo, en una obra civil, si estamos construyendo un puente entre dos montañas y  ya tenemos los cimientos asentados,  es difícil que nos pidan mover el puente  400 metros a la derecha.  Parece existir una conciencia general sobre la dimensión del nuevo trabajo a realizar y del sobrecoste que supondrá.  Será porque se ve el hormigón, el perímetro de la obra delimitado, el despliegue de accesos a la zona de trabajo, las medidas de seguridad implantadas.

Sin llegar a este extremo, en otros proyectos como en la construcción de una casa, si ya estamos levantando los tabiques ¿sería lógico que nos pidieran reorientar la entrada principal? ¿Accedería el propietario a abrir una nueva fachada y a reorganiza la distribución de su casa?

Sin demasiados conocimientos sobre arquitectura el cliente es perfectamente consciente de lo que está pidiendo y de sus consecuencias. Puede “verlo”. 

En ocasiones,  en el desarrollo de software, nos solicitan  cambios que afectan a la arquitectura del proyecto (sus cimientos), hasta el punto de necesitar rediseñar los “from” (fachadas), la seguridad, los accesos, los modelos de datos o incluso la tecnología a utilizar.  

Sin embargo el cliente no siempre percibe la dimensión del cambio. No sólo piensa  que se puede hacer de forma rápida sino que el coste o es bajo o no tiene mayor  impacto. ¿Qué es lo que no ven?

Pasar de una arquitectura centralizada a distribuida, modular la funcionalidad, migrar a otro lenguaje o adaptarse a nuevas normativas bancarias en tiempo récord no parece un problema si se trata de algo “abstracto”, de código, de elementos  que residen  en nuestro “Cloud” tan de actualidad  en estos momentos. 

Al igual que en otras ingenierías es necesario levantar nuevos planos (volver a definir),  someterlos a aprobación, presentar un calendario, desarrollar (construir), realizar pruebas técnicas y funcionales, certificar, buscar nuevos perfiles si procede, etc.  

En definitiva volver a pasar por un procedimiento exigente y exhaustivo que garantiza que se entiende el nuevo alcance y la calidad de la entrega. 

Hace años se hablaba de líneas de código para valorar un cambio. Podíamos medir si el impacto era de veinte o treinta mil líneas, por utilizar un tangible, pero aun así era discutible.

De igual forma  ocurre con las  horas de esfuerzo. ¿Podemos explicar al cliente el impacto de una modificación en un modelo de datos, en una API o una DDL?  Sin cierto nivel de conocimiento previo  sobre la materia es difícil valorar el alcance de la propuesta. 

Es más fácil medir el cambio cuando se ve afectada el área de hardware, la que se puede ver, como ocurre si ampliamos nuestros entornos Host, Clúster, TELCO, etc.

En definitiva,  gestionar un cambio de alcance en una aplicación de software requerirá de un esfuerzo extra por parte de sus responsables que deberán transmitir de forma clara y sencilla, sin tecnicismos, lo que supone los cambios y de un ejercicio de imaginación  por parte del cliente, para entender lo que está  al otro lado de su pantalla.