Vida después de trabajar más de 15 años con la misma aplicación

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.

Gestión del cambio y gestión de proyecto

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:

  • Cómo de jóvenes son los usuarios finales, si han nacido inmersos en las tecnologías digitales o no.
  • Cuánto tiempo llevan trabajando con la aplicación.
  • Cómo de grande es el cambio.
  • Quién es el sponsor del proyecto.
  • Si hay líderes negativos entre los usuarios.
  • Si se ha dejado fuera a usuarios clave.
  • Cómo es la política y dinámica interna entre áreas.
  • Si son proyectos de transición del papel a digital.
  • Cuánta es la presión que tienen los dueños del proyecto para echarlo a andar, etc.

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.

Hacer gestión del cambio de forma práctica

¿Cómo procedemos cuando notamos alguno de los anteriores signos? A continuación, algunos consejos prácticos:

1. Usuarios finales desde el momento 0

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.

2.Que los usuarios finales participen en la definición

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.

3.Las pruebas siempre las tiene que ejecutar el usuario final

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.

4.Las pruebas deben hacerse en situaciones lo más parecidas a la realidad

Esto significa que debemos probar con:

  • Casos reales (documentos reales, solicitudes reales, datos reales).
  • En los puestos de trabajo de los usuarios finales.
  • Con la red y los equipos de los usuarios finales.

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.

5.Entregas iterativas y con pruebas de usuarios finales o UATs en cada una de ellas

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.

6.UATS presenciales

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.

7.Expectativas claras

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.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

About ccathentocom