archivo

Archivo de la etiqueta: gestión del cambio.

La inclusión de pruebas unitarias, la automatización del testing, la inclusión de software para trazar comportamientos irregulares de una aplicación en un servidor de aplicaciones o de base de datos, etc…, son en algunos casos buenas prácticas y en otros buenas soluciones, siempre que se apliquen adecuadamente, y que pueden ayudar no solo a prevenir problemas sino a detectar la causa de otros que ya se han materializado.

Pero no solo eso, el cambio de versión de un determinado backend con el objetivo, por ejemplo, de mejorar el rendimiento de la aplicación ante una previsión de una mayor carga del sistema puede ser origen de nuevas anomalías, por más que pensemos que resulta improbable que se produzcan esos efectos.

Es importante que tengamos en cuenta que son elementos que se añaden ya sea al código o a la infraestructura y que pueden provocar a la vez nuevos problemas, en la misma aplicación o en otras. Esos problemas pueden ser el resultado de la incompatibilidad con otros artefactos o por errores humanos a la hora de desarrollarlos, configurarlos o instalarlos.

Es cierto que un sistema robusto, con una deuda técnica bajo control y la existencia dentro del departamento de TIC de mecanismos que permitan gestionar adecuadamente el cambio (en la inclusión o sustitución de elementos de infraestructura físicos y lógicos) reducirán la probabilidad de que estos problemas se produzcan, y mayor será la reducción cuanto más se invierta en ello (si la inversión se realiza de manera efectiva), hay que medir siempre la criticidad de los sistemas que estamos manejando y las consecuencias de su falta de disponibilidad o de tener un comportamiento anómalo.

Esta situación es la base de la paradoja del pesticida de Bruce Beizer: “Cada método que utilices para prevenir o encontrar errores deja un residuo de errores sutiles contra los que esos métodos resultan ineficaces”.

Esto nos lleva a la necesidad de ser prudentes, a la necesidad de medir el riesgo a la hora de realizar determinadas actuaciones, a la necesidad de no dar nada por sentado y a ampliar nuestro rango de visión cuando empecemos a detectar anomalías en un sistema y nos resulte complicado detectar su origen.

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

No es un hecho puntual, he podido comprobarlo en primera persona y como espectador en numerosas ocasiones.

He escuchado a usuarios decir auténticas barbaridades sobre el sistema de información que están utilizando, repasando el árbol genealógico del mismo y de los que lo desarrollaron, presionando hasta el límite para dejar de usarlo y que cuando se les brinda una nueva solución que mejora sustancialmente a la anterior, vuelven a repetir ese mismo ciclo, ensalzando todas las virtudes del sistema antiguo y minimizando sus defectos.

Es cierto que hay veces que se les ha sustituido basura por una basura tecnológicamente más avanzada pero en otras no ha sido así y sin embargo su rechazo sigue siendo frontal.

Por este motivo, es tan importante realizar una gestión del cambio adecuada, ya que no todos los usuarios han podido participar activamente en la concepción y desarrollo del producto y también lo es que determinados usuarios referencia, hayan tenido una implicación importante en la solución construida y en la toma de decisiones.

Cualquier cambios que se le haga a un usuario respecto a su forma de trabajar no suele ser acogido de buena gana, es más, cuando mayor sea la diferencia, mayor será su resistencia al cambio. En general, cualquier ruptura de hábitos y/o automatismos provoca estas sensaciones, a todos nos pasa, por lo que es inteligible que ese tipo de circunstancias tenga esas consecuencias.

Cuando se desarrolla un sistema de información, hay que tener en cuenta ese salto entre la situación actual y la situación objetivo, teniendo en cuenta también las características de los usuarios que va a tener la aplicación. Es importante, por tanto, que el usuario sienta la menor hostilidad con respecto al entorno, para ello es esencial la gestión del cambio, la cual puede empezar (y debe empezar) desde el mismo proceso de desarrollo y no esperar hasta que se ha realizado la implantación, como suele suceder casi siempre.

Si se quiere implantar una política en una determinada organización se considerará que ha tenido éxito cuando se convierta su cumplimiento en un hábito por parte de los integrantes de la misma, ya que de esta forma se tiene la seguridad de que se llevará a cabo y se verá como una tarea mecánica más y no como ese incordio que ha sido impuesto, del que me tengo que acordar para hacerlo y que me supone una pérdida de tiempo.

La implantación de una política no es tarea sencilla y menos en el mundo del desarrollo de software, donde todos somos (me incluyo) un tanto anárquicos.

Para que una política termine por implantarse es necesario que cuente con el apoyo de los niveles más altos del departamento afectado o incluso de la organización si se trata de una política de carácter horizontal, ese apoyo no debe ser sólo testimonial, sino que necesariamente se tienen que involucrar (el que algo quiere, algo le cuesta), realizar un seguimiento del proceso de implantación y pedir responsabilidades en el caso de que no progrese la implantación de la politica.

Pero no es suficiente con eso (aunque sí necesario) para que la implantación de una política se lleve a cabo con éxito, también es necesario que se realice un correcto proceso de gestión del cambio en el que resulta fundamental la explicación al personal implicado de por qué se ha decidido adoptar la política y que repercusiones negativas tendría para el departamento u organización la no aplicación de la misma y que beneficios se obtiene por ello. Seguro que si el personal entiende mejor por qué se aplica una política tenderá a asumirla antes.

Y como en todos los casos, se requiere tiempo para que sea asimilada (unos la asimilan antes, otros después) y más para que se convierta en un hábito, en el momento en que se consiga esto último se podrá considerar que la implantación de la política ha sido un éxito.

Como ya he comentado en otros artículos estoy totalmente a favor del uso de software libre en entornos corporativos y particulares y que tanto las administraciones públicas como las empresas privadas deberían tener entre sus estrategias la progresiva utilización de este tipo software mediante la sustitución de su equivalente propietario en todos aquellos casos en los que el nuevo software proporcione unas funcionalidades iguales o mejores que el anterior.

Digo progresiva, porque la sustitución de unos productos por otros (y esto es extensible a cualquier sustitución de un software por otro, por tanto es un caso general y que no depende que el nuevo software sea libre) requiere de una planificación y de un proceso de gestión del cambio (e incluso en muchas ocasiones de soporte) que en muchos casos es costoso, sobre todo si el cambio afecta a un buen número de empleados, es decir, no se puede de la noche a la mañana pasar de utilizar un producto a utilizar otro, ya que puede afectar entre otras cosas a la productividad de los empleados. También digo progresiva porque si se van a sustituir varios componentes software por otros y hay que hacer para cada uno de ellos el proceso que acabo de indicar, en muchos casos será conveniente realizar la sustitución de forma escalonada. También es necesario tener en cuenta que existirán organizaciones que por sus características particulares sea bastante complicado el cambio de un software por otro y que provoque que el mismo se realice de forma muy pausada o bien que se descarte.

Pero una cosa es eso y otra olvidar que los Departamentos de Informática deben dar un servicio al resto de la organización y que ese servicio debe ser lo más óptimo posible, es decir, hay que evitar la experimentación en circunstancias que afecten a la productividad y por tanto si se va a sustituir un producto por otro, y centrándonos en concreto en la sustitución de un software propietario por uno libre, se debe tener claro (además de que es necesario un proceso de transición como el que se indicó en el párrafo anterior) que el nuevo producto permite proporcionar un servicio igual (o casi igual) o mejor que el anterior. Si no es así, salvo circunstancias que habría que estudiar caso por caso (por ejemplo, el coste de licencia de un producto propietario es muy grande y su sustitución por un producto de software libre, provoca una pérdida de algunas funcionalidades importantes que afectan, por ejemplo a alguna de las siguientes variables: disponibilidad, seguridad, productividad, etc…, pero el impacto de las mismas traducido en términos económicos es menor que el pago de las licencias del producto propietario), lo mejor es quedarse con el software propietario que se esté utilizando del cual sabemos que está dando un servicio y lo está haciendo haciendo bien.

Una solución ideal puede chocar con la realidad de un entorno. Esta circunstancia provoca en muchas ocasiones el fracaso de un proyecto de desarrollo de software o una consultoría. Es importante que el resultado final se adapte a las circunstancias de la organización y de los usuarios, esperar lo contrario no es una visión real del problema. Con esto no quiero decir que no se pueda intentar mejorar el funcionamiento de un determinado proceso de negocio, pero una cosa es intentar optimizar y otra es que esa mejora tenga que ser consecuencia de un proceso previo de cambio brusco para la adaptación al resultado del proyecto.

Si hay que cambiar y este cambio debe hacerse en profundidad, lo mejor es intentar hacerlo poco a poco, con una visión a largo plazo, pero estableciendo metas a corto. Intentar ir más rápido puede provocar un rechazo del proyecto que lo avoque al fracaso o bien que provoque circunstancias que den lugar a una pérdida de la eficiencia y de la productividad, por la necesidad del período de adaptación, pérdidas esta que si se sostienen en el tiempo, también provocarán el fracaso del proyecto, ya que por encima de cualquier este se encuentra que la organización o el departamento puedan realizar su trabajo con normalidad.

Marcar soluciones realistas no es pecar de falta de ambición, ya que al fin y al cabo la ambición persigue el éxito, tal vez éste tarde tiempo en salir a la luz, pero más vale tarde que nunca.