archivo

Archivo de la etiqueta: riesgo

Un error muy frecuente que podemos encontrarnos tanto en el equipo de desarrollo como en los responsables funcionales del cliente consiste en dar continuidad a una determinada línea o estrategia de desarrollo a sabiendas que el camino o solución elegida no es correcta y/o que arrastra un buen número de defectos y/o deuda técnica.

A este error se llega por el deseo de acabar el proyecto cuanto antes. Pero no debemos olvidar que una cosa es hacer una entrega que se podría considerar como teóricamente final y otra cerrar el proyecto que es cuando todas las partes llegan al acuerdo de que efectivamente los trabajos han terminado.

Esta huída hacia adelante tiene sus consecuencias, sobre todo si cuando se ha optado por un determinado camino no hay un acuerdo explícito que más adelante se pueda hacer valer cuando aparezcan problemas porque, llegado el momento, cuando personas ajenas al proyecto intervengan para pedir explicaciones, no van a recurrir a si en tal momento se ha llegado a tal o cual decisión sino a solicitar pruebas por escrito y a ceñirse a la literalidad del contrato.

No se trata de trabajar con un escudo, de hecho, no es la estrategia más recomendable para desarrollar software, sino de analizar en qué condiciones es necesario sacarlo porque si se sabe que el camino elegido va a dar problemas es necesario tomar ciertas precauciones, sobre todo si no se llegan a acuerdos en donde la otra parte asuma el riesgo de continuar con la estrategia elegida pese a que se ha advertido de las posibles consecuencias.

Decía Confucio que: “Cometer un error y no corregirlo es otro error” y en circunstancias en las que existe un alto grado de posibilidad de que la solución elegida dé problemas es necesario plantearnos todas las partes de si se debe seguir de esa manera porque después el coste de volver a atrás será mayor, a lo que hay que sumar el desgaste añadido en las relaciones entre las partes que impactará negativamente en lo que reste de proyecto.

Buena parte de la contratación del software está basada en acuerdo llave en mano en la que se pacta un precio cerrado para desarrollar un producto en base a unas especificaciones, por regla general, no muy detalladas de lo que se pretende hacer.

En muchos casos, el proyecto parte de una situación de Death March Project que dará lugar, si es que se consigue llegar, al menos, a ese punto, a un producto que no satisfará las necesidades y expectativas del usuario y en medio de todo eso se habrá producido un desgaste importante entre los diferentes implicados en el proyecto.

Los defensores de esta estrategia de contratación se centran en que el riesgo se traspasa al proveedor que es quien asume unas condiciones y como tal, debe cumplir lo pactado. Sin embargo es algo que termina volviéndose en contra también del cliente, que se debería conformar, con las especificaciones que dé en la fase de captura de requisitos, sin posibilidad de modificarlas posteriormente (la llave en mano y el desarrollo en cascada son compañeros de viaje).

¿Qué pasa? Pues que acertar a la primera es muy complicado y conforme vaya avanzando el desarrollo y los responsables funcionales vayan viendo partes del producto funcionando, surgirá la necesidad de realizar cambios sobre las especificaciones o incluso la necesidad de incrementar el alcance inicialmente previsto.

En ese momento entran en juego las negociaciones y dependerá de la voluntad de las partes que las mismas lleguen a un punto donde sea posible todavía entregar un producto que cumpla unas condiciones mínimas.

Desde mi punto de vista creo que, a pesar de ser legítima, una situación de partida en la que una de las partes trata de echar sobre la otra todo el riesgo no es positiva para un proyecto por sus propias características inherentes: incertidumbre, carácter evolutivo del desarrollo y las diferentes contingencias, casuísticas y problemas que suele haber en los mismos.

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

Todo lo que sea mejorar y agilizar el funcionamiento y los procesos de un departamento o de una organización supone inherentemente una oportunidad y el desarrollo de software es una herramienta para conseguirlo.

¿Por qué hay quiénes no lo ven así? En muchos casos su experiencia en la adquisición de aplicaciones o en el desarrollo de soluciones a medida no ha sido buena en términos de coste/beneficio y en otros casos catastrófica.

Por ese motivo hay quienes creen que más que una oportunidad supone un riesgo y se piensan mucho volver a realizar inversiones porque probablemente ni habrán amortizado las anteriores.

Es cierto que la economía está como está y que en todos sitios se cuida mucho donde se gasta el dinero pero tal vez, si somos autocríticos y creo que no viene mal serlo en este caso, si hubiésemos hecho las cosas mejor en nuestra profesión, encontraríamos menos resistencias a la inversión en desarrollo de software.

Cada vez más muchas organizaciones están dirigiendo sus miradas a la adquisición de productos software o a la adaptación de los mismos a sus necesidades, dejando de lado el desarrollo a medida.

Motivos:

– Coste. Será más barato hacerse con la licencia de un producto (o todavía más si es gratuito) o contratar servicios para adaptarlo a tus necesidades (es un desarrollo a medida pero partiendo de un producto, es decir, de una base sólida a partir de la cual realizar las adaptaciones y evoluciones que se necesiten) que desarrollar desde cero una solución que hace lo mismo o prácticamente lo mismo.

Existen muchas empresas que han ganado mucho dinero con el desarrollo a medida, en unos casos aplicando internamente políticas orientadas a productos (esto que hemos hecho allí, lo aplicamos aquí haciendo un par de retoques y lo vendemos como si lo hubiéramos desarrollado desde cero), en otros sobredimensionando costes (que después no se correspondían a la calidad de los resultados) y en otros rehaciendo lo que deberían haber hecho bien antes (mantenimientos perpetuos).

Sin embargo, la crisis del software pasa factura y los clientes de estos servicios están cansados de no obtener unos resultados acordes con el dinero que pagan. Si a esto le sumamos la crisis económica actual donde no se pueden (o no se deben) cometer los dispendios de antaño, el impacto sobre el desarrollo a medida resulta evidente.

– Riesgo. Embarcarse en un proyecto de desarrollo de software presenta riesgos, porque desde que se contratan los servicios hasta que se obtiene la versión definitiva del producto, pueden pasar muchas contingencias que supongan un incremento de los costes, un retraso en la planificación o incluso que finalmente el proyecto termine en un cajón.

Con la que está cayendo, tener certeza de que lo que necesito lo voy a tener prácticamente de inmediato y con un presupuesto controlado, es un argumento de mucho peso a la hora de elegir entre un producto o un desarrollo a medida.

Los desarrollos a medida seguirán existiendo, tanto en la vertiente de adaptación de productos como en la de desarrollos de soluciones desde cero, ya que existirán necesidades no cubiertas por soluciones ya existentes o se quiera tener un control total sobre el proceso de desarrollo del producto.

En el artículo anterior vimos que Tim Lister, en función de diversos criterios: probabilidad, impacto, esfuerzo/coste necesario para evitar su ocurrencia, etc…, recomendaba que el tratamiento de los riesgos en función de dicho análisis se realizara antes/proactivo (evitar su materialización), después/reactivo (reaccionar ante las consecuencias del impacto) o una combinación de ambas posibilidades.

En la gestión del riesgo hay que entender que siempre estamos en un presente, en el durante y que por tanto, de la misma manera que las condiciones de un proyecto pueden cambiar, ya que no olvidemos que el proceso de desarrollo se encuentra siempre bajo un prisma de incertidumbre. Variarán los riesgos, aparecerán algunos nuevos y los ya identificados también se podrán ver afectados (reduciéndose o incrementándose la probabilidad de su ocurrencia, su impacto o incluso pueden desaparecer).

Por tanto, le gestión del riesgo, es una actividad que nos acompañará de manera horizontal a lo largo de todo el ciclo de vida y en donde es necesaria la participación de todos los stakeholders, tanto en el proceso de identificación y evaluación continua, como en la realización de tareas proactivas o reactivas ante los mismos.

Sobre esto Tim Lister comenta lo siguiente (traducción libre): “No hay forma de identificar todos los riesgos al inicio de un proyecto y establecer una gestión de los mismos que abarque desde ese momento hasta el final. Un buen gestor de riesgos es aquel que no solo vigila los riesgos identificados sino aquel que busca en colaboración con los demás la existencia de nuevos riesgos”.

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.