En el Foro de Arquitectos .NET hicimos una encuesta sobre los principales problemas que suelen aparecer en la definición inicial de los proyectos y posteriormente en la fase de construcción / mantenimiento.
https://lnkd.in/dFNWuvr
(Podéis ver las respuestas aquí:
https://docs.google.com/forms/d/1KB5qDrHpbjPDqAC-gcanWSM7NHuPexkhBBuV2NyZzkU/viewanalytics)
Sea cuál sea la metodología de ingenería de software aplicada este tipo de problemas está contemplado y definido.. simplemente en la mayoría de casos no se aplica aunque las áreas técnicas lo reclamen.
Es muy común que en la fase inicial del proyecto la prioridad sea modelizar la lógica de negocio, durante la construcción sea el time-to-market, durante la puesta en marcha la integración con el resto de sistemas y explotación de datos (reporting, etc).. y a medida que el sistema está en producción es cuando se detectan los problemas de rendimiento y la flexibilidad(o no) del sistema para incorporar cambios funcionales o de operación del sistema (monitorización, trazabilidad, etc).
Dentro del ciclo de vida de la aplicación, pongamos que está destinada a tener una vigencia de 5 años, el impacto en recursos económicos y humanos de hacer un diseño incompleto, selección equivocada de la tecnología o una implementación de mala calidad es sustancial.
Se suele decir que estamos pagando la "deuda técnica" de lo que en su momento no hicimos y depende del caso, los intereses acaban suponiendo el coste del desarrollo varias veces.
Una de las argumentaciones para hacer este tipo de proyectos "a crédito" es que la inversión inicial de arrancar el proyecto (CAPEX) es menor y los sobrecostes se pueden ir repercutiendo en el presupuesto de mantenimiento general (OPEX).
Esto puede ser asumible en el caso de que la aplicación no sea crítica o que como en caso de campañas de marketing etc, lo fundamental sea asegurar el time-to-market como sea.
Siendo como fuere, el nivel de calidad asumido y los compromisos "ad hoc" que se van adquiriendo a lo largo del ciclo de vida debería ser explícito y consciente.
Una propuesta sería incorporar a la gestión del proyecto una matriz del estilo GE-McKinsey asignando prioridades y pesos a los factores intangibles
Para detectar si el nivel de calidad es insuficiente de partida o se va degradando con el tiempo es necesario implantar un control de calidad, con indicadores fiables y auditar cada nueva entrega.
De esta manera la deuda técnica puede ser evaluada y tenida en cuenta en la priorización de las siguientes modificaciones y balancear la inclusión de nuevas funcionalidades y mejoras técnicas del sistema.
No hay comentarios:
Publicar un comentario