archivo

Archivo de la etiqueta: adaptación al cambio

Lo he dicho en numerosas ocasiones y sigo pensando lo mismo: pensar que se puede controlar un proyecto es una forma de engañarnos. Pero una cosa es eso y otra es dejar que sea el proyecto el que te controle a ti. Entre ambos extremos hay muchos matices.

Para poder tener algo controlado implica que se pueden dominar los factores externos y prever las reacciones de las personas. Eso no lo vas a conseguir casi nunca. Lo que sí puedes hacer es analizar el enfoque que más le conviene, realizar ajustes o cambiar si es necesario, evaluar riesgos, analizar la situación y los resultados con los usuarios o con el cliente para obtener feedback, adaptar la carga de trabajo a lo que el equipo y el área usuaria pueden asumir y reajustar posibles plazos, costes y alcance.

¿Te asegura eso el control? No, pero sí es una lanzadera para adaptarte al cambio y a las necesidades del proyecto, pero, ¿solo con eso?, es más efectivo (mucho más) si todas las partes aceptan este esquema de trabajo y si las resistencias al cambio: rigidez de los procesos y deuda técnica, no suponen un porcentaje significativo del esfuerzo.

El camino no es la microgestión porque lo único que se obtiene a través de ella es el rastro de miguitas de pan o la traza del proyecto pero no aporta soluciones.

La transformación, al adaptación al cambio, la aplicación de un nuevo enfoque, implica el abandono de un modelo, de una serie de prácticas, de una cierta manera de hacer las cosas.

No se trata de abandonarlo todo, no se trata de empezar de nuevo, sino de saber que el cambio solo viene a través del cambio y que, por tanto, no es posible alcanzarlo si en lugar de mirar adelante, no dejas de mirar atrás. Llévate en tu mochila todo tu conocimiento y experiencias y todo aquello que pienses que te puede resultar de utilidad en el viaje, pero ten en cuenta que su capacidad es limitada y que tendrás que renunciar o prescindir de prácticas o conductas antiguas para dar espacio a lo que viene a sustituirlas.

La agilidad requiere tener esa capacidad. En el proceso de adaptación al cambio tendrás que mirar dentro de ti, dentro de los proyectos en los que has participado y verás cosas que no te gustarán, de errores que cometiste y que te hacen ponerte las manos sobre la cara, debes entender que es parte del proceso y que nadie es infalible y debes comprender que han sido parte del camino que te ha llevado hasta aquí y que te han dado el suficiente conocimiento y madurez para ser mejor.

Decía Aristóteles que: “El cambio en todas las cosas es dulce”.

Es dulce si se asimila el cambio, si se entiende que es inevitable porque cada día el mundo sigue girando.

Si no se asimila y se entiende que la situación actual es la adecuada y no va a cambiar es cuando llegan los problemas. Tal vez la situación sea adecuada, confortable, positiva, dulce incluso, y es bueno disfrutarla y sacarle todo el provecho posible, pero se debe estar dispuesto y, sobre todo, preparado, para el cambio.

La tecnología está en continua evolución, las personas también. Las organizaciones deben ser conscientes de eso, quien antes era un competidor insignificante tal vez sea hoy quien te esté quitando el mercado y lo peor no es eso, cada día surge nueva competencia más adaptada al contexto actual.

Los sistemas de información no son ajenos a los cambios, teniendo en cuenta que soportan procesos organizativos y que estos se van a ir modificando. El software tiene sentido si existe un usuario, si el usuario y/o su contexto, cambia, evoluciona y sabemos que es una característica inherente, podemos decir que la necesidad de cambio es también inherente al software.

Su enunciado es el siguiente: “Los sistemas deben ser continuamente adaptados o se convierten progresivamente en menos satisfactorios”.

No todos los sistemas requieren el mismo nivel de evolución pero sí que es cierto que el contexto cambia y que tarde o temprano (en algunos casos más pronto que tarde) será necesaria una adaptación al cambio.

Es importante tener en cuenta que la adaptación no implica necesariamente un crecimiento del sistema (si bien en la mayoría de los casos pueden estar ligados), ya que un proceso de adaptación puede estar basado en una nueva forma de enfocar las funcionalidades ya implementadas en el sistema o en una reingeniería del proceso que se ha informatizado.

Es cierto que hay sistemas que no se han tocado en años pero, ¿es realmente porque no es necesario o por el coste que tendría asociado?. El motivo principal de que estas aplicaciones no se toquen es económico a lo que hay que sumar el factor de incertidumbre (o miedo) de retocar un sistema que está funcionando (con más o menos satisfacción para la organización y para los usuarios) y que por dentro se sospecha que está todo cogido con alfileres.

Lo que viene a decir esta ley es que no podemos pensar es que nuestra inversión no termina con la adquisición del producto software o con su desarrollo a medida, sino que tendremos que seguir realizando nuevas inversiones para adaptar el mismo a los cambios en las necesidades de la organización, del mercado, etc…

O lo que es lo mismo, el mantenimiento es inevitable.

Otro aporte de Lehman consistió en el hecho de que conforme se evoluciona un producto crece su complejidad y su tamaño, lo que hace que cada vez sean más costosas esas actividades.

Por tanto, el mantenimiento de un producto es inevitable y su coste (como consecuencia de una mayor complejidad) irá creciendo a lo largo del tiempo. De ahí que se considere que el software no se desgasta, pero sí que se deteriora.

Recordemos una conocida cita de Fred Brooks: “La complejidad del software es una propiedad esencial, no accidental”.

¿Es posible poner medios? Claro que sí, tanto en las actividades ordinarias de desarrollo (aplicando buenas prácticas y considerando la refactorización como parte del propio proceso de desarrollo) como con actividades extraordinarias (planes de acción para simplificar la arquitectura del sistema, reducir la deuda técnica, etc…). No obstante, debemos tener en cuenta que con independencia de estas actividades sí que es cierto que la complejidad del sistema crece conforme el mismo evoluciona.

Más controvertidas resultan otras afirmaciones de Lehman, en las cuales considera que determinados atributos relacionados con el desarrollo de software (tamaño, número de defectos, tasa de crecimiento), etc…, se mantienen más o menos constantes o siguen una tendencia (una proporcionalidad) a lo largo del proceso de evolución del software.

Estas afirmaciones, personalmente me parecen más discutibles (no quiero decir que no esté de acuerdo en todas), si bien, pese a que me base en mi propia experiencia, no he analizado datos empíricos para verificar si efectivamente se cumplen o no.

En los próximos días se van a publicar una serie de artículos sobre las 8 leyes de Lehman de evolución de los sistemas.

Lo más significativo de ellas es que trata de establecer una serie de pautas relacionadas con la evolución de los sistemas, tratando de generalizar ese comportamiento al conjunto de los mismos.

No es necesario estar de acuerdo con las mismas, de hecho, hay alguna que os parecerá más que discutible o que aplicando el enfoque adecuado se puede resolver o atenuar el problema que describe.

Me parece especialmente interesante el hecho de que Lehman considere la evolución de los sistemas (su mantenimiento) como algo inevitable, por mucho que te esfuerces en desarrollar una versión del producto que trate de ser definitiva.

Uno de los problemas que nos encontramos los desarrolladores de software es que el área usuaria no entiende que un producto requiera de un mantenimiento posterior, pese a que sean ellos mismos los que sugieran o provoquen esos cambios (pese a que entiendan que deberían haber sido tenidos en cuenta en el proceso de desarrollo). Y eso que tienen todos los ejemplos que quieran en el mundo real, más allá del desarrollo de software, para entender la necesidad de una evolución, una adaptación o un mantenimiento del software.

Es cierto que el software es un elemento lógico y que como tal no se desgasta (de ahí la diferencia con el mantenimiento de un elemento físico) pero también lo es que las necesidades de los usuarios, de la organización o del negocio varían, así como su capacidad de inversión (lo mismo hay funcionalidades que no se abordaron por su coste que ahora sí que interesa llevar a cabo) y no se puede pretender, por irreal, que una primera versión finalista del software tenga en cuenta no solo las necesidades presentes sino las futuras (algo que por otra parte sería temerario salvo que se tuviera muy claro cuál es la línea de evolución del producto, algo que en muchos casos depende de muchos factores y variables externas).

La evolución del sistema no solo va a ser motivada por cambios originados por los usuarios y/o por el contexto (puede ser necesario modificar la aplicación para poder dar una respuesta a un determinado movimiento de un competidor en el mercado o para adelantarse a él), sino por la propia infraestructura que lo sustenta o incluso por los propios componentes, librerías, artefactos o backends que utiliza.

Esos elementos que pueden ser físicos o lógicos también evolucionan y la organización responde a esos cambios actualizando las diferentes versiones que utilizan de los mismos o sustituyéndolos por otros, ya que generalmente resuelven problemas de seguridad, robustez, rendimiento y eficiencia. Además estos cambios de versiones llevan aparejados una pérdida de soporte por parte del fabricante, por lo que por un motivo o por otro no tenemos más remedio que terminar evolucionándolos.

Este cambio, a su vez provoca una evolución de los propios sistemas (tareas en este caso de mantenimiento adaptativo), con el objeto de que puedan seguir funcionando en ese nuevo contexto tecnológico.

Lo mismo sucedería, por ejemplo, con las propias librerías que utiliza la aplicación, ¿no cambiaríamos de versión de determinadas librerías (siempre y cuando tengamos la oportunidad de hacerlo) si las nuevas versiones mejoran, por ejemplo, el rendimiento del sistema?.

Manny Lehman se hizo muy conocido por haber formulado las 8 leyes de evolución del software, las cuales se fundamentaron en el estudio que realizó en IBM junto a Laszlo Belady basado en la evolución de los sistemas operativos OS/360 y OS/370.

Dentro de ese estudio, realizado en 1974, me parece muy interesante la clasificación que realizaron de los sistemas de información:

– S-type (Static type): Son aquellos que pueden especificarse formalmente. Por ejemplo, sistemas que devuelven resultados en base a fórmulas ya definidas (una calculadora).

– P-type (Practical type): Son aquellos que pese a que pueden especificarse formalmente, su solución no es ni aparente, ni inmediata, lo que provoca que sea necesario un proceso iterativo para encontrar una solución válida. Se sabe, por tanto, el resultado que se necesita (o el esperado), pero no se sabe describir cómo llegar a él.

La característica principal de esos dos tipos de sistemas es la estabilidad de sus requisitos o especificaciones (una vez encontrada la solución adecuada en el P-type).

– E-type (Embedded type): Son aquellos que tratan de modelar procesos del mundo real y como consecuencia de su uso forman parte del mundo que tratan de modelar, dando lugar a una situación en la que el sistema y su entorno evolucionan de manera conjunta. Este tipo de sistemas son los más comunes hoy día.

Las leyes de evolución del software están basadas en los sistemas de tipo E, en el sentido de que al ser dependientes del contexto, están siempre en continua evolución.

En 1974, Lehman, considera ya el cambio como algo inherente a determinados tipos de sistemas de información y como algo que resulta necesario para mantener el equilibrio con su contexto (su entorno).