archivo

Archivo de la etiqueta: adaptación al cambio

Comenta Stephen Hawking que: “La inteligencia es la habilidad de adaptarse a los cambios”. Y es así, si no lo haces, estás abocado a no evolucionar, a esperar sentado a que otros (personas y circunstancias) decidan tu suerte.

Adaptarse al cambio requiere tener mentalidad abierta, no estar atado a prejuicios y contemplar más posibilidades que las que nos pueden parecer, a priori, más válidas.

En los proyectos de desarrollo de software trabajamos en un entorno de incertidumbre, en el que las condiciones cambian, en donde se pasan de situaciones supuestamente bajo control a otras que se nos escapan de las manos, en donde las que eran las mejores decisiones la semana pasada requieren ser revisadas.

Adaptarse al cambio no es improvisación sino entender la propia naturaleza del desarrollo de software. Ahora bien, la línea que la separa ambos conceptos es muy delgada, de ahí que sea una habilidad la adaptación al cambio, primero por la detección de la necesidad (y la inteligencia y el valor para darnos cuenta de que tenemos que actuar en consecuencia) y en segundo lugar porque todo se debe tratar de hacer con intención, no vale cualquier respuesta, la que tomemos, pese a estar equivocada, no debe basarse en un prueba y error, salvo que no seamos capaces de detectar que una de las opciones sea la mejor.

Un proyecto de desarrollo de software no está formado por líneas rectas, de ser así, todos serían proyectos de manual en los que siguiendo la teoría o un determinado proceso se conseguirían los objetivos.

El desarrollo de software es complejo, a lo largo del proyecto habrá contingencias que te obliguen a tomar decisiones y te modifiquen los esquemas y eso probablemente ocurra varias veces. Cada cambio de contexto es difícil pero necesario porque si sabes que por ese camino no hay salida debes buscar otro.

Si intentas mantener la línea recta no estás siendo flexible, no estás dando lugar a otras opciones que resultan más beneficiosas. Es más fácil seguir con el plan establecido aunque no te lleve a ningún sitio.

También es aplicable el antipatrón a la hora de medir el comportamiento o el rendimiento de las diversas personas que participan en el proyecto, formen parte de tu equipo o no. Nadie puede mantener una línea recta, ni tan siquiera quien lo intente, porque somos seres humanos, tenemos fallos, debilidades, la componente emocional está siempre presente y nuestra energía no es ilimitada.

Trabajas en equipo y tienes que tratar de entender este vaivén en las personas (siempre, claro, que se encuentre dentro de unos márgenes razonables).

Este antipatrón trata de dibujar una realidad que no es. La realidad es imperfecta, se ve afectada por el contexto y como tal tenemos que entenderla y adaptarnos a ella.

No ayuda nada obviar el contexto en que se realiza el proyecto bien puede ser por falta de experiencia o por el contrario por pensar que se tiene la solución para derribar todas las puertas (martillo de oro) lo primero se cura con el tiempo (una vez que te recuperas de las caídas que has tenido y si realmente haces retrospección de tus actuaciones y decisiones) de lo segundo también, si bien, resulta algo más complicado ya que supone bajar de las nubes en la que estemos instalados… y es que se está tan bien allí arriba.

Jim McCarthy realizó la siguiente reflexión: “Decir que quieres algo implica que estás dispuesto a cambiar para conseguirlo. De lo contrario, realmente no lo quieres”.

Me parece interesante ya que representa el cambio de actitud necesario cuando con la actual no consigues nada (o incluso empeoras la situación) y por extensión la necesidad de adaptarte al cambio porque no siempre te va a caer todo en las manos (por mucho que pienses que sabes colocarte bien).

Los que van quedando son los supervivientes. Ahora es lo que importante lo que pasó ayer ya es demasiado tarde.

Interesante reflexión de Jerry Weinberg: “Cada uno de nosotros, después de todo, es el descendiente directo de innumerables líneas de supervivientes”.

El negocio del desarrollo de software es así. Supervivencia en un entorno de gran competencia cada vez mejor preparada y que está deseando quedarse con tu trozo del pastel (en situaciones de crisis como la actual, el pastel mengua a la vez que la competencia crece.

En la supervivencia no vale todo porque determinadas victorias son tus derrotas de mañana. Una victoria donde dejas un profundo desgaste y descontento por el camino te da de comer hoy y te lo quita mañana. Es verdad que hay expertos en sobrevivir de esta manera pero no por ellos deben ser ejemplos de nada.

La supervivencia tiene gran parte de aguante y de saber adaptarse a las circunstancias, si no resistes, si no te adaptas lo normal es que termines perdiendo porque otros sí que resistirán y otros sí que conseguirán adaptarse con más o menos esfuerzo al nuevo contexto.

La respuesta es compleja ya que depende del enfoque que tengas por lo que dar una respuesta en términos absolutos hará que los resultados en muchos casos sean erróneos.

En cualquier caso y con respecto a enfoques clásicos de desarrollo sí que supone una fuerte ruptura si bien la tendencia natural de la mayoría de los que han aplicado ese tipo de enfoque ha sido tender hacia enfoques más flexibles aproximándose a lo que sería un enfoque ágil. De hecho se venían aplicando enfoques ágiles, así como estrategias y metodologías mucho antes de que el Manifiesto Ágil fuera publicado.

¿Por qué una ruptura respecto a los enfoques clásicos? Porque sitúa en primer lugar al producto y a las personas mientras que en los enfoques clásicos todo estaba supeditado al proceso (o por lo menos estaba por encima del producto y las personas).

Según el enfoque clásico, estas son las etapas y los hitos a cumplir en cada una de ellas obteniendo análisis y diseños que después se materializarían mucho más tarde en un producto software (planteamiento más rígido). Hasta la entrega del producto el usuario no realizaba un feedback sobre un elemento no abstracto, hasta entonces lo menos abstracto con lo que había trabajado eran prototipos.

Pero no se trata solo de intentar que el feedback del usuario sea de la mayor calidad posible y cuanto antes, sino que se trata sobre todo de entender la singularidad de los proyectos y de su realización en un contexto concreto que probablemente cambie, lo que hace necesario centrar la atención en el producto y en las personas que intervienen en su definición y construcción, se trata de adaptarnos por tanto al producto que se va a desarrollar dentro del contexto en que se realiza el proyecto, no se trata por tanto de aplicar una metodología o un proceso como un martillo de oro que asegura el éxito en todos los casos sino de adecuar nuestros esquema de trabajo al producto que vamos a desarrollar.

En un entorno con una incertidumbre inherente es fundamental poder adaptarse al cambio y eso implica por un lado no poder estar atado con procesos rígidos (salvo que el contexto del proyecto o la naturaleza del producto que se desarrolla te obligue a ello) y por otro la existencia de una comunicación fluida entre todos los participantes en el proyecto pudiendo realizar, dentro de los márgenes que existan para ello, ajustes sobre condiciones o planificaciones que previamente se han establecido.

El enfoque ágil no es la consecuencia de hacer menos pesados los enfoques clásicos, no se trata de trabajar con procesos más ligeros o entregar menos documentación (no es solo eso), sino que supone un cambio más radical (entre otros): producto sobre proceso, cambio del modelo de comunicación entre las personas y adaptación al cambio.

Tener la capacidad de responder a un cambio de contexto lo antes posible, incluso de anticiparse o tener la capacidad de crear una tendencia solo puedo hacerse desde unas bases flexibles que permitan actuar de forma rápida.

Estas bases son los propios procesos organizativos pero también es cuestión de mentalidad (en general de la organización porque la adaptación al cambio es un esfuerzo común pero sobre todo de las personas que tienen poder de decisión tanto en la dirección como en los mandos intermedios). Es más, me atrevería a decir que es casi más mentalidad que procesos porque estos siempre dependerán de personas que harán más flexibles o rígidos los procesos o que incluso, llegado el momento los pueden obviar si fuera necesario.

Ahí es donde entra en juego la agilidad.

La importancia de adaptarse rápidamente al cambio no solo es cosa del desarrollo de software sino en general a cualquier aspecto de la vida. En el mundo de los negocios y de las empresas no adaptarte rápido al nuevo entorno o a un nuevo segmento de mercado puede suponer tu desaparición como organización o la insignificancia más absoluta de tu organización dentro de él.

A todo esto hay que añadirle el hecho de que los cambios de contextos, de tendencias, la aparición de más competencia y con nuevas ideas, etc… es algo continuo, no va a parar. En ocasiones requerirán menos esfuerzo de adaptación y en otras supondrá el replanteamiento o redefinición completa de determinadas líneas de actuación de la organización.

La siguiente cita de Jim Highsmith resume en pocas palabras esta circunstancia: “La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de obtener beneficios en un entorno empresarial turbulento”.

Si entiendes que la simple aplicación de una metodología te hace ágil es que no has entendido realmente lo que es ser ágil. El simple hecho de esconderte tras una metodología, de seguirla como si fuera un dogma te deja desarmado ante la adaptación al cambio porque más allá de la misma te encontrarás el vacío.

Precisamente la explosión de las metodologías ágiles ha sido un arma de doble filo, por un lado ha servido para extender el mensaje y por otro ha podido dar lugar a una mala interpretación del mismo por parte de quienes las practican.

La agilidad no tiene ataduras, puedes usar una metodología pero la misma estará a disposición del proyecto y del contexto y no al revés, ¿que hay que cambiar? si hay causa justificada se cambia y no pasa nada.

No siempre vas a poder aplicar metodologías ágiles porque para ello se tienen que dar una serie de circunstancias en el proyecto que no siempre se producen, eso lo sabemos, ¿tenemos que renunciar entonces a ser ágiles? En absoluto. Nuestro background es ágil y si las circunstancias lo permiten tendremos la oportunidad de aplicar sus fundamentos y principios, tal vez no todos, tal vez en parte, tal vez en alguna ocasión.

La agilidad tampoco es ausencia de metodología porque tener unas reglas del juego proporcionan dinamismo al equipo (que se romperá cuando se quiere mantener una reglas que no sirven para el juego que está ahora mismo sobre el tapete).

La agilidad también consiste en entender que puede haber otros puntos de vista, otra forma de hacer las cosas y en la libertad de cada uno de aplicar las prácticas, estrategias y herramientas que consideren más adecuada al contexto del proyecto.