Desarrollo de software. Anticipación al cambio
Es necesario adaptarse al cambio cuando surge un nuevo contexto. Cambiar es casi siempre posible pero el tiempo y esfuerzo que se invierte en ello puede provocar que lleguemos demasiado tarde y/o que hayamos gastado gran parte o casi todo el esfuerzo disponible en ese cambio dejándonos sin posibilidades ante futuros cambios o ante la propia evolución del sistema.
No todos los cambios son iguales ya que hay contextos tan radicalmente diferentes al anterior que no hay proyecto que lo pueda sostener salvo que se redefinan las restricciones del mismo (principalmente el presupuesto).
Sin embargo cuando el cambio sea «más suave» sí que resulta necesario estar preparado para ello y no supone realmente una inversión adicional al proyecto sino que el esfuerzo destinado a ello empieza a amortizarse prácticamente desde el principio.
Sí, hablo de una arquitectura y un código que favorezcan la mantenibilidad del producto a través de una deuda técnica acorde a las características del proyecto y los recursos disponibles pero no solo se tratan de aspectos técnicos ya que un equipo (y no hablo solo del equipo de desarrollo, sino que lo extiendo también a los responsables funciones o al Product Owner y al conjunto de personas que intervienen de manera más o menos directa en la construcción del producto) que se entiende, que se comunica, en el que hay confianza y que es consciente de que puede haber cambios de contextos tomará decisiones más acertadas, de manera más rápida y pensando en el bien general.
También hablo de una adecuada gestión de riesgos. Hay cambios de contexto que suceden y es complicado tener una previsión de los mismos, sin embargo, hay otros cambios de contexto que son el resultado de la materialización de riesgos (en algunos casos pueden ser evitables y en otros caso no).
Jummp 