archivo

Archivo de la etiqueta: adaptación al cambio

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.

¿Qué es Scrum?, ¿un proceso o un marco de trabajo?, una cosa es lo que piense y otra lo que se hace realmente.

La agilidad es colaboración entre personas y capacidad de adaptación al contexto y al cambio, esto implica que en esencia y de partida no te debes “casar” con ninguna estrategia, metodología o práctica de desarrollo ya que debes seleccionar aquella que mejor se adapte a las condiciones y contexto del proyecto y cambiarla parcial o totalmente si hiciera falta por la propia evolución del proyecto (por la propia necesidad de adaptación al cambio).

Querer aplicar Scrum sí o sí no es ágil en esencia. Aplicarlo en contextos donde sí sea una estrategia favorable pero limitarte por la ortodoxia de las prácticas tampoco es ser ágil. Lo que es ágil es tener la mente abierta a elegir las prácticas que más pueden convenir al proyecto, adaptar aquellas otras que lo requieran y descartar las que no procedan.

La ortodoxia por encima de todo convertirá a Scrum en un proceso y precisamente no es eso lo que queremos. Por eso siempre insisto a las personas que se están iniciando en el agilismo en que no se limiten exclusivamente a leer o asistir a conferencias y cursos (que por otra parte serán interesantísimos y serán atajos para comprender conceptos y comportamientos que llevan tiempo y experiencia aprender y sobre todo asimilar) sino que experimenten desde las bases del Manifiesto Ágil.

Decía Epícteto que: “El error del anciano es que pretende enjuiciar el hoy con el criterio del ayer”.

Y eso pasa en muchas organizaciones y le pasa a muchos gestores, jefes de proyecto y desarrolladores, los cuales están sufriendo precisamente por no entender que los nuevos contextos de trabajo requieren una adaptación, reinterpretación o una modificación sensible de estrategias, ideas, procesos y métodos de trabajo que tal vez funcionaron y fueron un éxito en el pasado pero que en el presente no resultan válidas o no lo suficiente como para que sea rentable o viable su utilización.

Si algo funciona no lo toques. Esa es una máxima para muchos en el desarrollo de software pero ten en cuenta que eso solo es válido para modificaciones que puedan considerarse prescindibles para el producto o cuya realización por riesgo y coste sea conveniente pensarla dos veces antes de aplicarla.

Sin embargo, cuando algo que funciona cada vez lo hace menos y vemos que más pronto que tarde nos dará problemas es necesario cambiar.

Esto implicará salir de nuestra zona de seguridad pero no queda otra si queremos seguir progresando y no quedarnos en una situación en la que cuando queramos cambiar sea demasiado tarde.

Decía Heráclito que: “Nada es permanente a excepción del cambio”.

Tenlo siempre presente en los proyectos de desarrollo de software, de ahí la necesidad de ir realizando ajustes y evaluarlos en base a una evolución (los últimos trabajos o sprints realizados) que viene a ser lo que seria la retrospectiva. Ésta tiene como referencia las personas y el proyecto.

La adaptación al cambio no solo se debe realizar mirando para atrás, sino también debe considerar el presente y lo próximo que nos vamos a encontrar (lo que podemos analizar más objetivamente), la perspectiva y lo que puede suceder más adelante, las prospectiva.

En los proyectos es muy frecuente encontrarnos con que se obvia la retrospectiva confiando en que el método por sí solo, sin tener en cuenta la efectividad que está proporcionando, será uno de los instrumentos (el principal) que permitirá conseguir unos resultados satisfactorio.

Pero lo más curioso es encontrarnos también con que se obvia la perspectiva, lo que está pasando. Esto es así porque no se quiere hacer el esfuerzo de levantar la cabeza y ver lo que está sucediendo. Es cierto que el conocimiento y la experiencia permiten detectar riesgos en situaciones no tan evidentes pero también lo es que resulta mucho más complicado hacerlo si no se intenta y simplemente nos dejamos ir por los continuos fuegos que salen en los proyectos o por no querer hacer ese esfuerzo adicional.

Recordemos también que la perspectiva es diferente en cada individuo por lo que no está de más contar con todas aquellas opiniones que puedan proporcionar valor.

La prospectiva es más complicada. Cuanto más nos alejemos del presente más nos encontraremos en el marco de la hipótesis y es ahí donde las experiencias pasadas y nuestra lectura del contexto dentro y fuera del proyecto pueden marcar la diferencia.

En resumen la adaptación al cambio requiere mirar hacia detrás y hacia adelante sin olvidar el presente (es más, en los proyectos es lo más importante, es el ahora, donde tenemos la capacidad de tomar decisiones que a corto, medio y/o largo plazo puedan permitir realizar cambios que permitan conseguir nuestros objetivos).

Lo que sí es seguro, como decía Heráclito, que el cambio llegará y mejor que estés preparado para adelantarte a él y/o reaccionar cuanto antes.

He leído una cita de Lao-Tsé que viene a sumarse a otras tantas que os he ido comentando en el blog y se basa en la necesidad de reaccionar si se va en la dirección equivocada.

“Si no cambias de dirección, puedes terminar a donde te estás dirigiendo”.

Ese problema ha dado lugar al fracaso de innumerables proyectos de desarrollo de software y el trasfondo real, en la mayoría de los casos es económico. Es decir, unos porque no están dispuestos a pagar más (y lo mismo tienen razón) y otros porque no están dispuestos a perder (más) dinero (y lo mismo también tienen razón).

Por tanto, se tira de contrato o se tira de requisitos y se trata de llegar a una solución que probablemente no sea satisfactoria porque ya se ha detectado que el sentido que ha tomado el proyecto no era el correcto. Parcheando y parcheando se tratará de conseguir algo. Lamentablemente ese algo en muchos casos será un fracaso que terminará costando más dinero que si se hubieran tomado las decisiones en el momento adecuado.

Es mejor reaccionar en el momento adecuado y tratar de buscar una solución real al problema, no una que se sabe de antemano que no va a llevar a ningún sitio.

La efectividad de la reacción será mayor cuanto más nos hayamos anticipado a la ocurrencia del problema, sin embargo, lo importante siempre será la intención de adaptarse al cambio, ya que de esa manera, podremos afrontar el trabajo que se requiere para poner todo en el camino correcto.