Desarrollo de software. Triángulo de hierro III

¿Cuál es la conclusión final de todo esto?

1) Para mantener el nivel de calidad es necesario que cuando una variable cambie el resto se ajuste a esta circunstancia si se quiere mantener el nivel de calidad definido. Esto supondrá un ajuste de la agenda, algo que también trato en relación a la segunda consecuencia.

2) La necesidad de un equilibrio porque no se trata exclusivamente de que a lo largo del proceso de desarrollo estas variables varíen su valor sino de establecer de partida un equilibrio entre todas ellas para alcanzar los objetivos de calidad que se esperan.

Eso es muy complicado ya que se trata de hacer una predicción, la cual muy probablemente haremos con un desconocimiento importante del alcance final de los trabajos, ya sea porque el usuario o el cliente no tenga todavía claro lo que quiere (que será lo más probable) o porque todavía no terminamos de captar o entender con el suficiente detalle qué es lo que quieren.

¿Entonces?, ¿qué hacemos? Incluso en ese contexto tratar de hacer una estimación con la mayor calidad posible. Mi recomendación es que se haga un análisis preliminar para llegar a captar la visión del producto. Digo análisis preliminar, no análisis detallado. La duración y alcance del mismo dependerá de la naturaleza del sistema a desarrollar.

De esta manera podremos empezar con un triángulo de hierro que se ha intentado que sea equilibrado. Lo más probable es que nos hayamos equivocado, entre otras cosas porque es muy complicado acertar y porque entre nuestras herramientas de estimación no se encuentran las bolas de cristal. Sin embargo, lo más importante en todo caso es la intención, se ha definido esa agenda exprimiendo al máximo las posibilidades y conocimiento que tenemos en ese momento, de esa forma habremos tratado de minimizar esa desviación.

Después de esto podremos haber acertado más o menos (incluso haber errado sensiblemente) pero no lo hemos dejado a la improvisación, si eso sucede no habrá sido por dejadez, no habrá sido por intentar conseguir una situación de partida justa y apropiada para los trabajos que se tendrán que realizar.

Tras esto, la gestión de la agenda puede ser flexible o rígida.

Sobre esto no os voy a decir nada que no sepáis o hayáis experimentado vosotros: en el desarrollo de software pueden pasar muchas cosas que te revienten la agenda (o al fin y al cabo, ese triángulo de hierro), a lo que hay que sumar que los propios responsables funcionales van a aprendiendo sobre el producto que quieren a medida que se va desarrollando.

Si no es flexible, el principal afectado será el producto final y después tanto el cliente como el proveedor, tanto a nivel institucional (ambos perderán dinero ya sea directamente por el desarrollo o como consecuencia del mismo) como de las personas que han participado en el proyecto, que se habrán esforzado, en muchos casos muy por encima del salario que están percibiendo.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: