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

Para Peter Drucker: “El emprendedor siempre busca el cambio, responde a él y lo explota como una oportunidad”, es curioso, porque precisamente es ese cambio el que asusta a la mayor parte de los gestores.

Asusta porque en la situación actual se sientes cómodos, se encuentran en su zona de seguridad, y eso es así, por mucho que los números empiecen a indicar que si se sigue actuando de la misma manera, la organización se va a ver más y más perjudicada.

La solución no es esperar a que amaine el temporal porque con independencia del contexto económico en el que nos encontremos, las condiciones, las reglas del juego varían: aparecen nuevas necesidades por parte de los consumidores, surge nueva competencia perfectamente adaptada al contexto actual (y con capacidad de poder adaptarse a cambio) a la que hay que sumar a la competencia tradicional que ha sabido reaccionar y ajustarse a la nueva situación.

Porque como también decía Peter Drucker: “La única cosa que sabemos sobre el futuro es que será diferente”.

Ante esa situación, no resulta recomendable centrarse en un negocio, cliente o producto exitoso, es decir, sí, sácale todo el partido que puedas pero no te olvides que si no sigues trabajando en innovación, en entender qué quiere el mercado y si tu organización no está estructurada para adaptarse al cambio que, sin duda, aparecerá, todo lo que hoy es ventaja, mañana no te servirá para nada.

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un “martillo de oro” que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.