Desarrollo de software. Adaptación al cambio. Hasta donde debería llegar la anticipación

¿En qué consiste anticiparse?, ¿es tener preparado todo lo necesario para cuando se produzca el cambio?. No hay respuesta general a eso pero sí diferentes reflexiones:

– No puedes prever todos los cambios que pueden producirse por lo que no puedes tener preparado todo lo necesario para todas las situaciones. Ten en cuenta que esos preparativos: planes de contingencia y de trabajo, ahorro de recursos, adaptación de la aplicación para lo que pueda venir, etc… son como tener carga en una mochila, a más peso más esfuerzo se necesita para continuar con el desarrollo hasta que se llega a un punto donde será necesario quitar carga de la misma para poder seguir.

– Hay cambios que sí son muy previsibles o muy probables y en esos casos sí que es posible o incluso recomendable que los trabajos que estemos realizando y los diferentes preparativos estén orientados a eso (si hay nubes negras y además los informes meteorológicos indican una alta probabilidad de lluvia no resulta razonable que salgas de casa sin paraguas y/o el chubasquero).

– Una gestión del riesgo eficaz deberá gestionar no solo los posibles problemas del proyecto, además deberá tener en cuenta las diferentes circunstancias conocidas que pueden provocar un cambio de contexto teniendo en cuenta que una cosa es inventariarlas y asignarle un perfil de riesgo y otra implementar las contramedidas algo que se deberá hacer en aquellos casos donde exista una alta probabilidad de ocurrencia (ya sea para adaptarnos cuando suceda o para evitarlo) y en donde exista un riesgo crítico para el proyecto (en este caso la definición y puesta en práctica de contramedidas deberá valorarse en función de diferentes factores: coste de las mismas, impacto real y probabilidad de que se produzca, etc…

– Hay prácticas que facilitan la adaptación al cambio (y que pueden ser suficientes en muchos casos) y que se amortizan desde el mismo momento en que se ponen en marcha: desarrollar software con una deuda técnica adecuada a las características del proyecto e intentar conseguir una cohesión entre los equipos de trabajo y dentro del equipo de desarrollo en los que además se fomente el hecho de que los proyectos no son necesariamente lineales ya que las condiciones iniciales pueden ser distinta de las finales.

Deja un comentario