archivo

Archivo de la etiqueta: análisis de riesgos

Para Tom DeMarco en su libro “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” (traducción libre): “Si identificas cualquier proyecto como libre de riesgos, o incluso relativamente libre de riesgo, cancélalo. Vas a necesitar los recursos y el plazo para hacer algo transformacional”.

Desde mi punto de vista, DeMarco trata de poner sobre la mesa la importancia de tener en cuenta los riesgos que se presentan en un proyecto de desarrollo de software y que van más allá de un análisis superficial del mismo.

Claro que hay proyectos con menos riesgos y donde se prevé una cierta estabilidad que facilite la gestión del proyecto, el trabajo de las personas y las relaciones entre los diferentes implicados, pero también lo es que la incertidumbre es una variable inherente en los proyectos de desarrollo de software y que se pueden producir situaciones que en un plazo corto de tiempo requieran hacer adaptaciones y ajustes sobre el proyecto y ahí es donde pueden aparecer problemas que afecten de manera sensible al mismo, entre otras cosas porque no se suele ir muy sobrado ni de presupuesto ni de tiempo y si el producto además se encuentra en producción, la presión que se recibe se incrementa considerablemente.

Es cierto que hay incertidumbre y circunstancias que no son sencillas de ser previstas pero también lo es que sí hay otras que pueden ser previsibles a corto, medio y largo plazo y ahí es donde entra la gestión de riesgos en los proyectos de desarrollo de software, en la capacidad de identificarlos y de tomar medidas o no en función del impacto del riesgo, del coste de las medidas, de la probabilidad de su ocurrencia, etc…

La identificación de riesgos debería comenzar desde incluso la etapa de conceptualización o definición del proyecto porque lo mismo, tras un análisis de los mismos se decide que lo mejor es no realizar el proyecto, buscar otras alternativas, plantearse alcances, presupuestos y plazos más realistas, etc…

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).

¿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.

La fuerza de rozamiento o fricción son todas aquellas contingencias que se producen en el proyecto de desarrollo de software que se suma a un valor inicial resultado de la negociación previa a la contratación del mismo (o al decisión de su realización mediante recursos internos).

Ese valor inicial puede ser tan alto que el condicione de manera absoluta el resultado del proyecto pudiéndose llegar al punto de que en la práctica sea casi imposible llegar a buen fin sin que alguna de las variables (calidad del producto, desgaste entre stakeholders, sobrecoste, etc….) se vean afectadas (Death March Project).

Pensar que el valor inicial se va a mantener durante todo el proyecto es suponer que en el desarrollo de software no se van a producir ninguno de los factores que definen su incertidumbre inherente (cambio de prioridades, cambios en los procesos, cambio en los stakeholder, variación de la implicación de los mismos, contingencias en el equipo de proyecto, etc…) y eso es peligroso porque no te hace pensar en los posibles riesgos y gestionarlos.

Conseguir un producto que satisfaga las expectativas del usuario será el resultado de vencer esa resistencia, esa fuerza de rozamiento, esa fricción.

No es sencillo porque el desarrollo de software no lo es, pero será cuestión de asumir que esas dificultades existen y que conformen vayan llegando será necesario superarlas, venciendo la resistencia con más empuje teniendo en cuenta que el mismo no solo es resultado de un mayor esfuerzo, sino también de una buena práctica en el proyecto resultado de la cualificación del equipo que participa en él.

Yo he pecado en muchas ocasiones con este antipatrón. Lo reconozco.

Es el resultado de la presión que terceros te meten en el proyecto y/o la misma presión que se mete uno por intentar alcanzar los objetivos temporales marcados, aunque estos sean difíciles de conseguir.

A veces también son el resultado de la falta de confianza en el equipo de proyecto.

Este antipatrón consiste en solicitar estimaciones de avance del proyecto sin dar tiempo a que quien tiene que ofrecer la estimación realice un análisis medianamente objetivo de lo que se lleva realizado y de lo que se piensa que falta, todo ello teniendo en cuenta el contexto en el que hasta ahora se ha desarrollado el proyecto y el análisis de los riesgos actuales.

Muy interesante la siguiente cita del libro “El arte de la guerra” de Sun Tzu: “En la guerra el estratega victorioso solo busca batalla después de que la victoria ha sido ganada, mientras que el que está destinado a la derrota primero pelea y después busca la victoria”.

En los proyectos de desarrollo de software sucede lo mismo, antes de pelear por intentar sacar un proyecto adelante lo mejor es sentar las bases para que el mismo pueda ejecutarse con éxito: stakeholders implicados, presupuesto y plazos acordes a las expectativas, análisis de riesgos, selección de la metodología y tecnología adecuada, etc…

Después pueden pasar muchas cosas, ya que los proyectos son así, llenos de incertidumbre, en los que el escenario inicial probablemente cambiará y en donde la capacidad de adaptación al cambio determinará la suerte final del mismo, pero desde luego, si no trabajamos por conseguir unas condiciones de partida adecuadas y lo dejamos todo a nuestra destreza, probablemente se tendrá mucho perdido antes de ni siquiera haber empezado.

Se quiere desarrollar un sistema de información en el que existe un riesgo muy alto de que alguna de estas variables se produzca (seguro que se os ocurren unas cuantas más):

– El área usuaria no va a colaborar o su colaboración va a ser residual.

– No existe una dirección usuaria que asuma la dirección o gobierno funcional del proyecto.

– El presupuesto disponible para realizarlo se encuentra sensiblemente por debajo del necesario y no existe voluntad de reducir el alcance del proyecto o la reducción del alcance no permite solventar la diferencia entre lo necesario y lo disponible o garantizar que se superan unos umbrales de calidad aceptables.

– Las áreas de proceso que se van a informatizar se modifiquen de manera sensible.

– El plazo impuesto para tener una versión del producto con un nivel de funcionalidades adecuado no se puede conseguir.

Lo mejor será que se invierta el dinero y el esfuerzo en algo más provechoso.