Veronica Meza
Por qué si un usuario se ha pasado más de 1 año con una aplicación, ya puede trabajar en piloto automático, pero si se pasa trabajando con el mismo software más de 15 años, ya no ve vida después de esa aplicación. El usuario ya tiene sus vicios, trabaja con los ojos cerrados, sabe todos los hacks del programa, sabe cómo buscar, cómo encontrar, cómo sortear los fallos que le pueda dar.
Hay proyectos cuya complejidad se encuentra más en que los usuarios se sientan cómodos trabajando con la nueva aplicación, que en la customización de la aplicación en sí para cubrir su caso de uso.
Incluso aunque sepan que el software actual tiene muchas limitaciones (cada vez que hay que añadir un nuevo campo es un suplicio, ya no tienen soporte, pueden perder datos, etc.) su vieja aplicación es lo natural y no pueden ver más allá de ella.
Hace poco leí un artículo sobre si la gestión del cambio engloba la gestión de proyectos, cuál es la diferencia, si va primero el huevo que la gallina, etc. La verdad, no me quedó muy claro qué engloba qué. Lo cierto es que hay proyectos cuya gestión puede ser muy organizada, impecable, se cumplen los tiempos, etc., pero a los usuarios no les da la gana de usar el software. Le tienen resistencia, les parece todo más difícil, sienten que están trabajando más de lo que lo hacían con su vieja aplicación.
Y tú te cuestionas: ¿pero qué ha pasado aquí? Hemos tenido una ejecución del proyecto impecable y, sin embargo, estamos teniendo problemas. Gestión del cambio. No le dimos mucha importancia. ¡Error!
A veces es difícil, pero hay que ponerse en la piel del usuario que lleva haciendo las cosas de la misma manera por muchos años. ¡Claro que le va a costar cambiar!
Probablemente, cualquier estudioso de administración, Project Management, etc., te diría que la gestión del cambio es clave en cualquier proyecto. O que no hay proyecto sin gestión del cambio. La realidad con la que yo me he encontrado es que, aunque siempre debe hacerse algo de gestión del cambio, en algunos proyectos es más importante que en otros. Depende de muchos factores:
Pero hay signos que puedes reconocer para entender que vas a tener que hacer un esfuerzo grande en gestión del cambio en un proyecto y, definitivamente, que los usuarios lleven mucho tiempo trabajando con la misma herramienta es uno de ellos.
¿Cómo procedemos cuando notamos alguno de los anteriores signos? A continuación, algunos consejos prácticos:
Desde la presentación del proyecto los usuarios tienen que tener co-reponsabilidad sobre el resultado del proyecto y la única forma de hacer a alguien responsable es lograr que esa persona haya colaborado de forma activa en el proyecto.
Por más extraño que parezca, nos seguimos encontrando proyectos en los que no tenemos acceso directo a los usuarios finales. Tenemos acceso a sus jefes o al equipo de IT. Pero es que sus jefes o IT no se pasan horas trabajando con la aplicación antigua. No conocen todas las excepciones que tienen las tareas y procesos. Cuanto a más bajo nivel seamos capaces de llegar, mejor vamos a conocer la realidad de la operación.
Siento decir esto, pero las pruebas que realizan usuarios que no son de negocio, valen de poco o nada. Incluso si tienen casos de testeo que seguir, las pruebas realizadas por departamentos de testeo o por técnicos, al final son las mismas pruebas que puedo realizar yo. Si un usuario no es de negocio, no sabe lo que está haciendo y no va a detectar las posibles fallas del proceso.
Esto significa que debemos probar con:
Unas pruebas de esta naturaleza nos van a ayudar a detectar excepciones al flujo definido, problemas técnicos, de equipos o de infraestructura que van a tener los usuarios, información que nos falta, etc.
Hay que conseguir que los usuarios se encuentren familiarizados con la herramienta, que le pierdan el miedo. Esto solo se puede conseguir mediante el uso de la plataforma. Cuanto más la prueben, más la sientan, mejor la conozcan, más proclives van a ser a usarla.
Además, las entregas iterativas nos van a ayudar a detectar a tiempo errores de diseño, bugs o fallos de código, casos que no han sido contemplados, etc.
Hay usuarios más independientes que otros. Aunque no lo creamos, cada vez que el software falla o pasa algo que el usuario no espera – por su culpa o por la del software- el usuario se lleva un susto. Pierde la confianza en el software y le da miedo tocar demasiado. Si le acompañamos de cuerpo presente, podremos tranquilizarlo. Podremos decirle: «mira, esto ha pasado porque lo hiciste así, y lo tienes que hacer de esta manera», «no te preocupes, no pasa nada. Puedes cambiarlo desde aquí». Tener a alguien allí, le imprime confianza al usuario. Tiene el apoyo que necesita para solucionarlo.
Hay que ser claros con los usuarios. Hay que explicarles que el software falla. Tenemos que contarles que como toda cosa en la vida, la aplicación necesita un tiempo de rodaje. Nuestra promesa no debe ser la incorrecta.
«No te puedo prometer que el software no va a fallar. Te puedo prometer que estaré allí para solucionar lo que haga falta»
Nosotros por eso manejamos tiempos de BLP. Son semanas de estabilización después de la puesta en producción. El usuario sabe que va a encontrar errores y nuestro equipo sabe que tiene que mostrar especial presteza para resolverlos.
Existen varias opciones para controlar el acceso y mitigar el riesgo sobre la información sensible que se almacena en el servicio de gestión documental. Repasamos las funcionalidades que pueden ayudarte.
La optimización de los flujos de trabajo con un sistema de gestión documental es esencial para aumentar la eficiencia y la productividad de una empresa.
No subestimes el valor de contar con un sistema de gestión documental en tu empresa, el impacto positivo que puede tener en es significativo.
