¿Cómo de ágiles reaccionan las personas ante el cambio?

El punto de partida de este artículo es un gran proyecto de desarrollo e implantación de un nuevo software SAP para más de mil usuarios en una gran empresa internacional.

Además de las funciones estándar ya disponibles en el sistema, hubo que desarrollar completamente de nuevo algunas funciones esenciales para el cliente y analizar primero los procesos existentes y optimizarlos en parte.

Los métodos ágiles están en boca de todos y a menudo se postulan como la "salvación" para todo tipo de problemas familiares de los proyectos de desarrollo de software de antaño. El enfoque relativamente rígido y lineal de la metodología (de proyecto) clásica en cascada, en la que el análisis de requisitos, la definición de la solución y la posterior fase de desarrollo y pruebas, a menudo larga, se trabajaba en pos de un resultado final totalmente definido al principio del proyecto, albergaba numerosos riesgos de no alcanzar al final el resultado deseado.

Durante la larga duración del proyecto podían surgir demasiados imprevistos: Los requisitos no podían definirse con todo detalle al principio, las partes interesadas cambiaban durante el proyecto, las tecnologías ya estaban obsoletas al final del proyecto o los requisitos originales simplemente cambiaban durante una larga fase de desarrollo o se quedaban obsoletos de repente.

El enfoque iterativo de los métodos ágiles de proyecto y desarrollo promete mucha más flexibilidad y seguridad para poder reaccionar a los cambios a medida que se producen.

Los ciclos de desarrollo cortos, normalmente de una o dos semanas, permiten definir y entregar paquetes de desarrollo manejables con menos complejidad para los "sprints" y poder reaccionar con flexibilidad a los cambios de requisitos en las posteriores y recurrentes revisiones de los sprints con los clientes.

Uno casi tiene la impresión de que todo proyecto (de desarrollo) organizado de forma ágil debería ser automáticamente un éxito. Por desgracia, no es así.

La finalización con éxito del trabajo de desarrollo no define el éxito de un gran proyecto de desarrollo de software. Por muy bien que se haya desarrollado, adaptado o ampliado el software hasta conseguir un resultado final funcional, es posible que también se hayan cumplido plenamente los requisitos del cliente:

El éxito real del proyecto sólo se alcanza cuando el nuevo software se ha implantado con éxito en la empresa y es aceptado y utilizado por la gran masa de usuarios.

La introducción de nuevos programas informáticos suele ir acompañada de la introducción de procesos nuevos o modificados. Sin embargo, los procesos que viven las personas no pueden introducirse o modificarse de forma "ágil", porque las personas siguen estando sujetas a diferentes velocidades de cambio.

Ningún proyecto o método de desarrollo, por ágil que sea, puede ayudar. Si el "factor humano" no se reconoce y se toma en serio a tiempo, incluso el proyecto de software más ágil acaba, en el mejor de los casos, con una gran pieza de software que satisface al cliente y quizá a algunas partes interesadas, pero que la gran masa de usuarios no utiliza en absoluto o lo hace de forma ineficaz.

La experiencia demuestra que el riesgo de éxito aumenta con el tamaño del grupo de usuarios finales (o de la empresa), porque a menudo ningún grupo representativo de los usuarios finales finales participó en las rondas de feedback de los distintos ciclos de desarrollo.

Por un lado, a la hora de reunir a las partes interesadas, especialmente a las de las revisiones de los sprints, se tiende a seleccionar a los empleados que ya están comprometidos y tienen una mayor afinidad con el cambio.

Además, se trata simplemente de un problema de masa: con más de 1.000 usuarios finales afectados y posiblemente varios procesos afectados, existe una probabilidad muy alta de que el pequeño grupo central del que se recogen activamente los comentarios en la fase del sprint simplemente no sea representativo.

Entonces, ¿qué se puede hacer para que un proyecto de desarrollo de software con un gran número de usuarios afectados se encamine hacia el éxito de la mejor manera posible?
Desde nuestro punto de vista, es importante combinar las ventajas de los métodos ágiles modernos con las de los métodos clásicos de gestión de proyectos y desarrollo organizativo: desarrollar ágilmente, desplegar clásicamente.

En el proyecto de implantación de software en el que se basa este artículo, con más de mil usuarios afectados, se utilizó el probado enfoque de proyecto Sirius, que combina las ventajas de la metodología ágil Scrum con enfoques clásicos de gestión de proyectos y gestión del cambio organizativo.

Se intenta establecer lo antes posible múltiples canales de comunicación e interacción con el mayor número posible de usuarios finales (potencialmente todos).

En nuestra opinión, integrar sólo a unos pocos "usuarios clave" seleccionados no basta para lograr la aceptación del nuevo software que se va a introducir y de los cambios de proceso que se avecinan. Es mucho más importante invertir más en las áreas de comunicación y gestión del cambio, que a menudo se omiten por falta de tiempo, dinero y recursos, desde el principio del proyecto.

No puede haber demasiada información y transparencia sobre los cambios que se avecinan, ¡sino muy poca!

Fases de la metodología del proyecto Sirius

En concreto, en el presente proyecto se ha demostrado una vez más que merece la pena prestar especial atención a los siguientes puntos en las distintas fases del proyecto:

Alcance

• Tómese su tiempo para definir el alcance del proyecto con claridad y sin ambigüedades. Formúlelo de forma muy precisa y concreta. En realidad, esto es algo obvio. Pero también escriba explícitamente lo que NO tiene en el alcance.
• Formular los objetivos y NO objetivos del proyecto, además del alcance del mismo.
• Asegúrese de haber acordado el alcance y los objetivos con todas las partes interesadas.
• Comunique el alcance y los objetivos en cada oportunidad. Introduce cada taller con una breve diapositiva en la que vuelvas a dejar claro qué entra en el ámbito del proyecto y qué no.

Fase de diseño

• Asegúrese de que en la fase de diseño participa una selección representativa de usuarios: los usuarios clave que participan en el equipo central del proyecto no suelen ser suficientes para haber tenido suficientemente en cuenta a todos los grupos de usuarios en el diseño. Piense explícitamente en los equipos y usuarios de otras regiones: pueden trabajar de forma distinta a los expertos asignados al proyecto y, por tanto, tener requisitos diferentes.
• Es mejor organizar unos cuantos talleres de diseño que no suficientes: en los talleres no sólo se trata de elaborar los requisitos necesarios para el software, sino que también sirven como medio de comunicación para transmitir el proyecto y sus objetivos a los usuarios (clave). Ya en esta fase puede aumentar considerablemente la aceptación si se implica al mayor número posible de usuarios o, al menos, a representantes de los distintos grupos de usuarios.
• Integre de forma activa y explícita a los usuarios muy críticos: al formar equipos de proyecto y participantes en talleres, la gente suele evitar a los empleados considerados "difíciles". Lleva tiempo y esfuerzo captar también a los empleados problemáticos, pero de todos modos tendrá que enfrentarse a sus objeciones, como muy tarde en el momento de la implantación. Sin embargo, en esta fase inicial, aún tiene la oportunidad de reaccionar activamente y moderar las objeciones.
• Piense en el comité de empresa. No lo veas como un obstáculo, sino como una oportunidad para ganar más puntos a favor de la aceptación de tu proyecto.

Sprints de desarrollo

Utilice las revisiones del sprint para lo que están pensadas: Validar el desarrollo (parcial) entregado con las expectativas de los usuarios sobre la función entregada.

No reduzca demasiado el grupo de participantes en las sesiones de revisión e integre no sólo a los usuarios clave, sino invite a otros usuarios a las sesiones. Documente la sesión de revisión.

En este proyecto, cada revisión del sprint se realizó y grabó como una sesión web internacional. De este modo, las partes interesadas de otras regiones del mundo tienen la oportunidad de ver la revisión a posteriori. Esto es mucho mejor que "solo" enviar después un conjunto de diapositivas y actas.

Probar la función entregada (parcial) directamente en una fase de revisión después de la revisión del sprint con un grupo de prueba definido. En una reunión de revisión del sprint, por muy larga que sea, simplemente no te darás cuenta de todos los puntos.

Sólo cuando "pruebe" el componente de software entregado con varios usuarios se dará cuenta de los errores, fallos de diseño y debilidades conceptuales.

Pruebas de proceso e integración

Pruebe una ejecución completa del proceso lo antes posible. En cuanto la suma de los desarrollos parciales de los sprints permita probar el proceso completo, pruébelo, de nuevo con varios usuarios. Lo que funcionó bien en las pruebas de los sprints individuales no funciona automáticamente bien en la ejecución completa del proceso.

Amplíe el grupo de probadores para la integración final y las UAT. Haga que también prueben aquí usuarios que no participaron en las pruebas del sprint. Se ha demostrado una y otra vez que los usuarios que participaron en todas las revisiones del sprint ya no evalúan el software en su totalidad de forma imparcial hacia el final.

Roll0ut

Utilice todos los medios modernos disponibles en su concepto de formación para la implantación del nuevo software. Además del manual obligatorio, cree versiones breves para las funciones esenciales que los usuarios necesitan en su trabajo diario.

Produzca vídeos tutoriales breves para las funcionalidades más importantes. No es necesario que sean muy elaborados; al contrario, se fomenta la aceptación si los "empleados para empleados" hablan de estos vídeos.

Utilice un punto central de recogida de toda la información sobre su proyecto: material de formación, preguntas frecuentes, tutoriales, sesiones web, noticias, etc. Comuníquelo, por ejemplo en una página de la intranet, una y otra vez a lo largo de todo el proyecto. Incluya el enlace a esta página en cualquier material publicado por su proyecto.

Para las sesiones de formación, hay que tener en cuenta las zonas horarias del personal de las otras sedes. Siempre se olvida que una sesión web a una hora que nos viene bien en Alemania se convierte en un evento nocturno para los colegas de Asia o Estados Unidos.

Aumentará significativamente la aceptación de su proyecto si tiene en cuenta activamente esta circunstancia y programa explícitamente sesiones de formación e información también en horarios convenientes para los usuarios que viven en el extranjero.

Comunicación de acompañamiento, marketing y gestión del cambio organizativo: Las actividades de este bloque se descuidan una y otra vez, ya que muchos las consideran lastres innecesarios y generadores de costes. Sin embargo, ¡es exactamente lo contrario!

Aquí es donde se decide si el proyecto tendrá éxito al final o no:

Informar a la organización sobre el proyecto y sus objetivos. Repítalo con regularidad e informe de los avances. Utiliza todos los medios a tu alcance para ello, sobre todo en grandes empresas.

Cuanta más transparencia, más fácil le resultará el despliegue. En este caso concreto, además de boletines informativos periódicos, se celebraron mensualmente breves sesiones web informativas sobre el proyecto, dirigidas a todos los usuarios potencialmente afectados.

Todo el mundo podía participar. Las sesiones se siguieron grabando para dar a todos los usuarios la oportunidad de verlas.

Además, se colgaron grandes "hojas informativas" en las salas de los equipos de las distintas sedes, que presentaban de forma concisa toda la información importante sobre el proyecto en una sola página. Además, el equipo del proyecto visitó a muchos equipos en sus reuniones de equipo y les presentó el proyecto.

Sobre el tema de la comunicación, todo lo que se puede decir es: No existe el exceso. Hable de su proyecto y de los objetivos que persigue con él tanto y tan a menudo como sea posible; empiece a hacerlo ya al principio del proyecto.

Piense en el proceso de cambio por el que deben pasar y pasarán todos los empleados. Intenta proporcionarles la mayor transparencia informativa posible.

Conclusión

Los métodos ágiles en los proyectos de desarrollo han facilitado enormemente la consecución del resultado final deseado de forma selectiva. Sin embargo, completar el software en el plazo X no convierte automáticamente el proyecto en un éxito.

Sólo cuando los usuarios acepten el nuevo software e incluso, en el mejor de los casos, lo perciban como una ayuda en su trabajo diario, podrá considerarse que todo el proyecto ha sido un éxito, al menos así lo entiende Sirius.

En cuanto se trata de personas y de su enfoque individual del cambio, los métodos ágiles son de ayuda limitada. Cuando se trata del cambio, las personas solo son "ágiles" hasta cierto punto.

Afortunadamente, los métodos de proyecto clásicos siguen ofreciendo aquí conceptos sensatos y correctos, sólo hay que aplicarlos con seriedad. Con la combinación correcta de los métodos adecuados para el fin adecuado, el próximo proyecto también volverá a ser un éxito.