Carl von Clausewitz. La esencia de la gestión de riesgos

Carl Philipp Gottfried von Clausewitz fue un militar prusiano de finales del S.XVIII y primeras décadas del S.XIX, es considerado como uno de los teóricos e historiadores más influyentes de la ciencia militar moderna.

Cuando leí esta reflexión suya, la asocié rápidamente a la gestión de riesgos: «¿Cuál es la idea fundamental de la defensa? Es la de parar un golpe. ¿Por qué señal se distingue? Se distingue porque en ella se espera el golpe que se debe parar».

Viene a decir que para que la defensa sea efectiva es fundamental tener conciencia de que el golpe se puede producir, conocer sus características y establecer las medidas necesarias bien para evitarlo, bien para que su impacto sea el menor posible.

La defensa es menos efectiva desde la improvisación porque lo mismo cuando intentas reaccionar ya es demasiado tarde.

Todos los riesgos no producen el mismo impacto, ni tienen la misma probabilidad de materializarse y el coste de prevenirlos será diferente. Todos esos factores son variables conforme avanza el proyecto, de ahí la importancia de tener en cuenta el riesgo como un factor más dentro del proceso de desarrollo, gestionándose bien mediante un listado de impedimentos y/o riesgos, que se puede enriquecer en el trabajo diario y en las sesiones de retrospectiva.

La gestión, no es enumeración, sino acciones que tienen como objetivo minimizar (o eliminar) el riesgo o reducir su impacto en el caso de que no se puedan evitar (por coste o porque no hayan funcionado adecuadamente las contramedidas).

Desarrollo de software. Milt Bryce. Gestión proactiva y gestión reactiva

La gestión proactiva pretende adelantarse a los posibles problemas que se pueden producir en un proyecto de desarrollo de software o en el ciclo de vida de un sistema de información lo que implica evaluar riesgos y decidir qué estrategia aplicar a cada uno de ellos en función de la probabilidad de que ocurra, de su impacto, del coste de la contramedida, etc…

Pero no se trata solo de de riesgos, se trata también de actuar contra problemas reales que ya tiene el sistema de información: incidencias recurrentes, mala experiencia de usuario, falta de productividad en el uso de la herramienta, problemas de rendimiento, problemas de seguridad, etc…

Actuar de forma proactiva permite actuar con mayor perspectiva haciendo un mejor aprovechamiento de los recursos disponibles, ya que independientemente de los ajustes que sean necesarios realizar, se trabaja sobre un plan.

La gestión reactiva se basa en dar respuesta a las incidencias, problemas y riesgos conforme van apareciendo y materializando. A nivel de gestión es mucho más simple, se trata de evaluar cuáles son los fuegos que tenemos en cada momento y dirigir los equipos a los focos más problemáticos.

Este modelo de gestión hace que el sistema se encuentre en una permanente crisis, que será más o menos acusada en función de la calidad (o no calidad) del mismo, la importancia del proceso o de los procesos que informatiza y el número de usuarios del sistema.

Si un sistema se encuentra en permanente crisis y no se actúa conforme a un plan que priorice las actuaciones sobre las deficiencias ya existentes, así como otras que pueden ocurrir o que están latentes, la evolución del sistema será muy lenta, con alto coste y con mucho desgaste, a lo que hay que sumar el riesgo de que cuando se actúa de manera desordenada y rápida sobre las incidencias y problemas, puede dar lugar a nuevas incidencias y problemas (efectos colaterales) sobre todo en sistemas con una alta deuda técnica.

Hay una cita de Milt Bryce que alerta sobre el riesgo de los gestores que presentan una orientación reactiva: «Ten cuidado con los ‘bomberos’, son probablemente los principales pirómanos».

Desarrollo de software. Antipatrón. Solicitud dirigida

Este antipatrón puede tener tres orígenes:

– El equipo de desarrollo opta por la opción más sencilla (en cuanto a asumir responsabilidades) de acatar la petición de desarrollo que se le ha descrito (con un cierto nivel de detalle que de alguna manera dirigiría la solución hacia un enfoque concreto de implementación), sin entrar en ningún análisis de alternativas de solución. «Me han dicho que haga X y yo hago X». Típico en entornos en donde los gestores caen en el antipatrón «yes man«.

Es cierto que siempre se podrá utilizar la defensa de «yo he hecho lo que me han dicho», pero eso puede provocar unos costes y un incremento en la complejidad de la aplicación que puede que no sean sostenibles (al cliente, es posible que no le haga mucha gracia saber que te has gastado una buena parte del presupuesto para implementar una funcionalidad, cuando todavía existen otras muchas por hacer).

Hay que tener en cuenta que el que realiza la solicitud probablemente no sepa las implicaciones que tiene lo que ha pedido y lo mismo considera válidas otras alternativas más simples.

No se trata de no hacer lo que nos piden, sino de buscar la solución más eficiente y productiva para todos.

– Se confía tanto en el criterio de alguien del equipo de proyecto, del área usuaria o el cliente que se decide aplicar la solución propuesta sin aplicar prácticamente ningún filtro sobre la misma.

– El director usuario o el cliente no atienden a razones, quieren lo que piden de una determinada manera y no quieren conocer otras alternativas (por más que se les insista).

En esta situación, lo mejor es dejarle muy claro al que lo ha pedido, los costes que tiene y el impacto en el producto (e incluso en el proyecto). Por tanto, todo por escrito, tanto la solicitud, como la previsión de costes e impacto (lo más probable es que en el futuro haya problemas y es necesario que quede delimitada la responsabilidad).

Desarrollo de software. Antipatrón. Factor de improbabilidad

Este antipatrón se produce cuando conociendo la existencia de un error en el sistema no se le presta atención o no se considera prioritaria su corrección al asumirse que la ocurrencia del mismo no ocasiona perjuicio al sistema, los usuarios, el servicio que se ofrece y/o la continuidad del negocio, sin haber realizado previamente un análisis del riesgo objetivo del mismo.

Los desarrolladores podemos considerar una incidencia como intrascendente y sin embargo para los usuarios y/o el negocio ser muy negativa. Hay que tener en cuenta que el producto no es para nosotros sino para un tercero y para unos propósitos concretos, por lo que nuestra opinión no es la única que vale a la hora de analizar el impacto e importancia de un error.

Si para el usuario todas las incidencias son urgentes y además también lo son los evolutivos a realizar, toca hacerlo bajar a la realidad de los recursos disponibles y de la metodología utilizada, no será fácil que lo entienda, pero no tendrá más remedio que priorizar.

Desarrollo de software. Timothy R. Lister. Gestión del riesgo. Antes o después

En la definición de gestión del riesgo que pudimos ver en el artículo anterior, Tim Lister, indica que las actuaciones relacionadas con el riesgo pueden estar orientadas a evitar que se produzca o a tener previstas las actuaciones a realizar en el caso de que aparezca (o una tercera opción, que sería una solución mixta de las anteriores).

Una vez identificado el riesgo y estudiado la probabilidad de que ocurra y su posible impacto se decide, por tanto, si los esfuerzos se centran en evitar que se materialicen y/o a actuar después.

Es importante tener en cuenta que no da igual el tratamiento que se realice de un riesgo, ya que una mala decisión con respecto a los mismos trae consecuencias, por ejemplo, si consideramos que debemos evitar que todo riesgo llegue a producirse, el esfuerzo y en consecuencia, coste económico, que puede tener consigo puede ser excesivo o no asumible, para las características del proyecto en la que se está trabajando. En la cara opuesta tendríamos la opción contrario, actuar de forma reactiva al riesgo, lo cual puede ser igualmente costoso, ya que tocará recoger los pedazos que ha dejado la materialización de los riesgos e intentar encauzar de nuevo el proyecto.

Se han puesto como ejemplo las dos situaciones extremas, con el objeto de que se tenga en cuenta que la gestión del riesgo debe buscar el equilibrio con las características del proyecto que se está desarrollando, la criticidad del sistema de información y el contexto en el que se realizan los trabajos. No se trata, por tanto, de elegir si todos se tratan antes o todos después, sino que cada cual se trate en la forma y momento más adecuado.