Cambiar

La semana anterior trabajamos dejando todo al pelo para la salida en producción de una herramienta de software que instalamos en una de las empresas prestadoras de servicios públicos mas grandes del país (el nombre no importa porque tal vez algunos de mis lectores ya saben de qué hablo).

En este artículo no voy a hablar sobre las tecnologías empleadas o el diseño del producto. Quiero hablar sobre un factor que en muchas ocasiones, aquellos que nos aventuramos en el negocio del desarrollo de software olvidamos: El miedo al cambio.

Independientemente de la herramienta que vas a instalar, de las capacidades de los futuros usuarios, incluso, de la necesidad misma que se busca cubrir, siempre, siempre en gran o en menor medida encontraremos una resistencia al cambio.

Pensándolo bien, esta resistencia no sólo la encontramos en nuestros usuarios: En muchísimas ocasiones somos nosotros mismos quienes buscamos todos los peros posibles para seguir usando o trabajando sobre lo viejo y conocido en vez de tomar lo nuevo e incierto.

La verdad, no creo en eso de “mas vale viejo conocido que bueno por conocer”. Ejemplos sobran y creo que todos los tenemos. ¿Porqué entonoces, siempre encontramos peros y razones para no hacer la transición a lo nuevo?.

Creo que el miedo al cambio es un estado natural del hombre. Nos gusta repetir lo que ya aprendimos, nos gusta hacer lo que siempre hacemos. ¿Porqué? Creo que la respuesta está en la comodidad. Si ya sabemos hacer algo, ¿Para qué cambiar? ¿Aprender de nuevo? ¿Arrancar desde cero? Noooo que jartera.

Si no me creen, recuerden sus días de estudiante y díganme si es mentira que todos “escrituramos” un puesto que defendimos durante todo el semestre. A mi me gustaba la esquina izquierda, al frente del pupitre del profesor. No sólo porque podía ver todo mas claro, sino también porque en muchas ocasiones ese era el mejor punto para recibir una buena señal de la wlan instalada en la universidad.

Amamos las rutinas, odiamos los cambios intempestivos. ¿Quién no se molesta que por alguna razón la ruta a nuestro trabajo sea otra? ¿Quién no ha sentido extraño durmiendo en un lugar diferente? Intenten cambiar la rutina que siguen todas las mañanas… nos sentiremos completamente inseguros. Parece que tenemos un checklist en el cerebro que nos brinda la seguridad necesaria para hacer todo:

  1. Tomar los periódicos del dia: Listo.
  2. Ir a la cocina: Listo.
  3. Abrir la nevera: Listo.
  4. Tomar el yogourt: Listo.
  5. Tomar el cereal: Listo.
  6. Calentar el pan: Listo.
  7. Sentarse a leer: Listo.
  8. Desayunar: En progreso.

Y si por alguna razón nos toca llevar un orden distinto todo se despelota… ¡Listo! a algunos nos va a pegar mas duro que a otros, pero todos vamos a sentir en gran o menor medida el cambio en nuestras amadas rutinas.

Volviendo al cuento del software, creo que esta condicion sicológica se convierte entonces en un factor determinante en el éxito de una implantación. El planteamiento es muy sencillo, si el software no se usa no sirve. Así tenga el mejor código en sus entrañas, la mejor GUI con las mejores prácticas de accesibilidad, si no se usa, es como si no se hubiera hecho nada.
De nada sirve que le digamos al gerente que tiene “el estado del arte” en sus manos, si los usuarios del sistema no emplean una herramienta como debería hacerse, creo que nuestro trabajo estará destinado al fracaso.

Pero bueno… ¿Qué se puede hacer? Me atrevo entonces, a presentar una serie de claves para que el proceso de resistencia natural al cambio sea mas llevadero.

  1. Identifica y trabaja con los lideres. Las labores de presentación, validación y capacitación no deben estar concentradas exclusivamente en los que dentro de la estructura del proyecto llevan el título de “lideres funcionales”. Busca identificar entre los usuarios de un sistema a las personas que sobresalen entre los demás. No solo es posible que tengan una gran experiencia acumulada, sino también que, si cuentas con el apoyo de ellos en la implatanción del software, será mas fácil que los demás usuarios también te apoyen, pues seguirán el ejemplo de sus líderes naturales.
  2. Nunca menosprecies la experiencia. Por encima de todo, las personas saben de procedimientos no de herramientas. Es muy probable que el operario experto en el software que será cambiado pueda convertirse en el mejor usuario de las nuevas herramientas. Busca su opinión. Ellos viven día a día los procedimientos y de seguro podrán hacerte valiosas sugerencias para lograr un mejor ajuste de tu herramienta. Te darás cuenta que los lideres funcionales en muchas ocasiones ignoran algunos puntos simplemente porque no usan diariamente las herramientas.
  3. Vende los beneficios. A casi todos los usuarios no les interesa el motor de tu base de datos, el lenguaje de programación o el doctype que empleaste. Si tu herramienta mejora tangiblemente los procesos, reduce los tiempos que toma una transaccion o permite realizar mejor una acción, has logrado darle peso al mejor argumento de ventas: Ahorro de tiempo. Tiempo que los usuarios no van a desperdiciar, tiempo que se traduce en beneficios y en tiempo libre. Ese es el mejor argumento. Si tu producto permite realizar una acción de una forma eficiente y mas rápido, lo lograste. Ahora sólo es vender la idea.
  4. ¡Prueba y prueba! Un error en una presentación o en la semana de salida en producción puede destruir semanas de trabajo buscando la aceptación de tu herramienta.
  5. Paciencia. Por ser el último de mis consejos no es el menos importante. Siempre nos encontraremos con un usuario inconforme, molesto y en muchas ocasiones un poco agrio. No lo anules ni lo menosprecies. Es muy probable que en medio de tanta corrosión encuentres la razón de su comportamiento: Tal vez es la persona mas insegura para cambiar. Escucha sus razones, sus temores y sus deseos. Estoy seguro que encontrarás las claves para que tu software sea mejor.
Explore posts in the same categories: Codeando, Emprendimiento

3 comentarios en “Cambiar”

  1. abstruso Says:

    Toffler decía que más que poder, el conocimiento es cambio.

    De los posibles candidatos, mi favorito es este template, seguramente porque me estoy volviendo a ver los años maravillosos (bendito bittorrent).

  2. duxtin Says:

    A mi me gustaba la esquina izquierda, al frente del pupitre del profesor (…) porque en muchas ocasiones ese era el mejor punto para recibir una buena señal de la wlan instalada en la universidad.
    Qué anécdota tan geek…

    Creo que te faltó mencionar el estar convencidos de lo que hacemos para poder convencer a los demás de ello. Una duda en el último momento es fatal, y no sólo en el ámbito del software. Lo digo por experiencia propia.


  3. Es cierto lo del miedo al cambio, y eso es en todo lado, hasta en mi campo el diseño industrial; hay historias de estruendosos fracasos con diseños espectaculares, todo porque el usuario le tiene miedo al cambio.

    Curioso, el comportamiento contrario fue el que no hizo evolucionar, entonces ahi surge otra pregunta ¿pa’ donde carajo vamos?


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 )

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 )

Google+ photo

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

Conectando a %s


A %d blogueros les gusta esto: