archivo

Archivo de la etiqueta: ciclo de vida

En ocasiones nos empeñamos en estirar el ciclo de vida de un determinado producto software hasta límites donde el mantenimiento del sistema supone unos costes superiores al que tendría la amortización del desarrollo o adquisición de una nueva solución, que lo mismo, además supone una mejora en cuento a rendimiento y eficiencia en el uso de la solución anterior.

¿Qué circunstancias nos pueden llevar a este antipatrón? Algunos ejemplos pueden ser los siguientes:

– Se considera no amortizada la inversión en el anterior sistema y no se quiere afrontar un nuevo desarrollo hasta que dicha amortización se haya producido.

– (Tiene una relación directa con el anterior) Se ha desarrollado un sistema, no cumple con las expectativas del usuario y/o del entorno tecnológico y en lugar de asumirse que se ha producido un error, se decide seguir hacia adelante aunque el coste sea superior que el de enmendar lo que se ha hecho mal.

– El producto software tiene éxito, cubre perfectamente las expectativas del usuario y del negocio y se tiene miedo a realizar una nueva solución que no iguale, al menos, los solución desarrollada, teniendo en cuenta, además, de que como en toda migración de sistema de información, se encontrará de partida con el rechazo de buena parte de la comunidad usuaria, que está acostumbrada a la solución antigua (a lo que habrá que sumar el tiempo necesario para dejar el sistema totalmente ajustado).

– Se entiende que no hay dinero para una solución nueva, sin pensar en que la solución actual cuesta al fin y al cabo, más que el nuevo desarrollo.

En el ciclo de vida en cascada, por su naturaleza, por el hecho de que el usuario empieza a ver las funcionalidades implementadas muy tarde (poco antes de la entrega) existe la tendencia a querer abrir puertas que ya se consideraban cerradas, es decir, a retocar especificaciones, en algunos casos serán cosas menores e incluso asumibles y en otros casos, se requerirá un trabajo muy importante realizar su implementación.

Y eso sucederá por muchos prototipos con los que hayas trabajado con el usuario. Es cierto, que el uso de prototipos disminuye el riesgo de posibles discrepancias entre el producto final y las expectativas del usuario, pero también lo es que durante el proceso de desarrollo pueden pasar muchas cosas que hagan que algunas (siendo generoso) especificaciones iniciales ya no valgan, que el usuario que te las haya definido se haya ido de la organización o se haya cambiado de departamento y sobre todo que hasta que no se trabaja con el producto el usuario no termina de ver claro lo que necesita (e incluso requerirá varias iteraciones hasta alcanzar con una solución que empiece a satisfacerle).

¿Qué hacemos entonces?, ¿dejamos las puertas abiertas o cerradas?. Probablemente si se dejan cerradas el producto desarrollado fracase porque por muy bien que se haya hecho, no hará o funcionará como el usuario quiere que lo haga.

Ahora bien, lo que no puede ser es que el proveedor asuma con la carga. ¿Se han desarrollado todas las funcionalidades pactadas de la manera en que está recogida en los diferentes items documentales del proyecto que a su vez ya han sido aprobados por sus responsables? Sí, pues entonces el proveedor no puede, ni debe asumir esa carga.

Debe asumir lo que no haya hecho y los errores de lo que haya hecho, pero no debe asumir errores de terceros.

El problema de todo esto es que cuando esto ocurre, en lugar de asumir lo que hay, de responsabilizarse de lo hecho y de aplicar un mayor presupuesto al proyecto, se recurre al desgaste cliente (área técnica)/proveedor para intentar que esas funcionalidades se hagan, mientras que el área usuaria, suele salir impune, actuando como un espectador que ve una película en la mejor localidad, con palomitas y refresco gratis y que actúa como un crítico implacable.

Estas situaciones son demasiado frecuentes y dan lugar a proyectos que no dejan satisfechos a nadie, que no producen buenos resultados económicos y que han originado un gran desgaste entre las partes. Por motivos como este, es necesario huir de las cascadas como metodología y por otro hace necesario un proceso de educación importante en el área usuaria antes de iniciar el proyecto para que entiendan cuál es su papel en el mismo y la responsabilidad de las decisiones que toman.

El ciclo de vida en cascada tiene como consecuencia que las primeras versiones utilizables del producto software se dilaten en exceso en el tiempo. El mismo problema lo podemos tener en enfoques iterativos e incrementales si se tarda en tener una primera versión operativa de algún módulo o componente del sistema (más allá de los esqueletos andantes).

Cuanto menos tiempo pase en que el usuario (o el cliente) empiecen a ver el resultado de los trabajos, mejor, ya que no pierden el enfoque en el proyecto. Cuanto menos tiempo pase en obtener su feedback, más pronto se podrá tener un producto acorde a sus expectativas.

Sun Tzu, pensaba algo parecido: “Una victoria rápida es el principal objetivo de la guerra. Si la victoria tarda en llegar, las armas pierden el filo y la moral decae. Si las tropas atacan ciudades, su fuerza se desgasta. Cuando un ejército se implica en una campaña prolongada, los recursos del estado disminuyen rápidamente”.

Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en cascada, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.

¿Contingencias? Pues de todo.

Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos.

Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis.

¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar.

Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él.

No se trata de hacer tábula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta.

Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.

Han pasado casi tres años desde que escribí una serie de artículos dedicados a la definición de un plan de sistemas de información:

Plan de sistemas de información I
Plan de sistemas de información II
Plan de sistemas de información III
Plan de sistemas de información IV
Plan de sistemas de información V
Plan de sistemas de información VI
Plan de sistemas de información VII
Plan de sistemas de información VIII
Plan de sistemas de información IX

Llevaba pensando un tiempo pensando en escribir un nuevo artículo sobre los planes de sistemas, haciendo hincapié en uno de sus principales problemas: su carácter eminentemente predictivo, basado en un fotografía de la organización en un momento dado, algo que no se ajusta a la realidad de las entidades.

En resumidas cuentas, presenta el mismo problema que las metodologías software basadas en métodos predictivos como el ciclo de vida en cascada, lo que hoy puede ser válido (si es que la especificación realizada es buena, algo que no es sencillo), mañana puede dejar de serlo porque las condiciones de partida han variado sensiblemente.

Finalmente, unas series de tweets que leí ayer a Jon Kern (uno de los padres del manifiesto ágil) sobre gobierno ágil, me animaron a escribir sobre este asunto.

Básicamente Kern expresaba la dificultad de establecer planes de gobierno a largo plazo ante una situación basada en la incertidumbre.

Un plan de sistemas no es más que un plan de gobierno de los sistemas de información de una organización, en la que se estudia una situación inicial, se determina un modelo objetivo al que se quiere llegar y un plan de acción que nos permita llegar desde esa situación inicial al modelo objetivo. Se suelen definir con un período de vigencia de tres o cuatro años.

Como ya recomendaba cuando escribí esos artículos, el tránsito desde la situación actual a una situación que se aproxime a lo que consideramos como ideal (dadas las características de nuestra organización y su contexto), probablemente si la organización no se encuentra lo suficientemente madura a nivel de procesos relacionados con el desarrollo de software y el gobierno TIC, requiera de la realización de varios planes de sistemas de información.

Este enfoque iterativo incremental tiene en esencia fundamentos ágiles, sin embargo, el tiempo que hay entre planes de sistemas, difumina casi todos los atisbos de agilidad que pudieran existir.

Mi recomendación sería en primer lugar, disminuir el período de vigencia de un plan de sistemas, situándolo a lo sumo en dos años y existiendo la posibilidad de que tenga una vigencia anual si existen riesgos ciertos de cambios de contexto o se han producidos cambios no previstos en la organización, procesos, de la organización hacia el exterior, etc… En cualquier caso, tanto si se decide que la vigencia sea de dos años, como de uno, hay que estar abiertos a reorganizar las prioridades si fuera preciso, para poder adaptarnos a cualquier variación de las condiciones iniciales o para ayudar a la organización a conseguir algún objetivo operativo o táctico de mayor trascendencia.

Por otro lado, también recomiendo, ¿por qué no?, plantear desde el principio hacia dónde queremos llegar, pero no con el presente plan de sistemas, sino a nivel estratégico definiendo cuál es la política de sistemas de información que sería deseable tener y realizando ajustes a ese alcance final en cada plan de sistemas, el cual, a su vez pretenderá recorrer parte de ese camino que nos separa de esa meta.

En muchas ocasiones, considerar algo como una pérdida de tiempo es una cuestión de percepción, es decir, para alguien puede serlo, para otros no (y en medio, toda una escala de grises).

En otros casos, no hay lugar a la interpretación, se trata de pérdidas de tiempo.

Comentan Tom DeMarco y Tim Lister que: “El mayor pecado de la gestión es hacer perder el tiempo a la gente”, esto unido a su reflexión sobre los días de trabajo que se pierden, nos debe hacer pensar sobre algunas decisiones que provocan pérdidas de tiempo (a las que habría que añadir todos los malos hábitos productivos que tengamos a nivel de organización e individual).

Una mala selección de prioridades suponen una pérdida de tiempo, ya que estamos dedicando nuestro esfuerzo y atención (enfoque) a una serie de tareas y funcionalidades que no son críticas, dejando de lado otras que sí lo son. Sobre esto, se podría pensar que al fin y al cabo son cosas que tarde o temprano habría que hacer, sin embargo, la incertidumbre de los proyectos y las limitaciones presupuestarias y de tiempo no aseguran que lo que hemos dejado para después se pueda llegar a hacer, por lo que lo mejor es empezar siempre por lo que realmente es importante y trascendente. A esto, habría que sumar el hecho de lo que se deja de ganar o producir por realizar más tarde las tareas y funcionalidades que realmente tienen un impacto.

Una mala selección de funcionalidades también suponen una pérdida de tiempo. Es importante matizar esto.

El desarrollo de software es de naturaleza evolutiva, donde la aproximación a la solución que satisfaga a las expectativas de los usuarios se llega generalmente (que no siempre) mediante aproximaciones iterativas e incrementales. Bajo esta perspectiva, basada en el feedback del usuario (y de todos los stakeholders en cada iteración), no acertar en la definición de una funcionalidad forma parte en sí de la propia naturaleza del desarrollo y por tanto no se debería considerar una pérdida de tiempo. También es importante matizar esto.

El desarrollo iterativo incremental no es lo mismo que un ensayo y error a ciegas, sino que cada intento debe tener una intención y debe ser resultado de un proceso previo de reflexión. Claro que se puede fallar, claro que pueden ser necesarios ajustes, sin embargo, no se trata de probar por probar porque en este caso sí que estamos perdiendo el tiempo y capacidad para desarrollar otras funcionalidades prioritarias, ya que estamos invirtiendo el esfuerzo en dar vueltas sobre lo mismo.

Es importante también un enfoque minimalista en el desarrollo, evitando funcionalidades que finalmente no se van a utilizar o que van a tener un uso residual. El desarrollo de estas utilidades, también supone una importante pérdida de tiempo (y no solo eso, un lastre para el resto del proceso de desarrollo y el mantenimiento).

Normalmente se considera ciclo de vida del software a todo el tiempo que transcurre desde que comienza su especificación hasta que la aplicación deja de usarse y tener utilidad, dividiéndose el mismo en una serie de etapas que variarán en función de la metodología de desarrollo utilizada.

Sin embargo, desde mi punto de vista, el ciclo de vida del software no comienza con la especificación, sino que comienza mucho antes, en el momento de que una persona, un departamento o una organización tiene una necesidad que requiere ser resuelta con una solución informática.

Desde la necesidad, hasta que comienza la especificación en el proceso de desarrollo (o incluso el mismo proyecto), pasan muchas cosas como para ser pasadas por alto y que condicionan mucho todo lo que va a pasar después (es en este punto donde la batalla puede comenzar perdida, totalmente perdida o con una buena base para la realización de las tareas necesarias para el desarrollo): delimitación del alcance, definición del presupuesto inicial, determinación de expectativas iniciales, selección del proveedor o equipo de desarrollo, ajuste del alcance tras la contratación de los trabajos o selección del equipo, etc…