En este artículo te quiero contar sobre la que llamo la «zona de histeria» del cliente. Ese lugar y momento en el que el cliente considera que todo lo que hacemos está mal y que el sistema que le desarrollamos es una porquería.
Primero explicaré la secuencia a través de la cual se llega a eso y luego, intentaré contarte lo que hago para evitarlo.
Contenido
Un comienzo normal, con algún que otro bug
Todo comienza de forma excelente. Se implementa un sistema, el cliente está contento en general. Le gustaría hacerle algunos cambios al producto final, pero en líneas generales tiene todo lo que necesitaba.
Al otro día manda un mail. Realiza una operación simple para ver un reporte y obtiene un error. Es el primer bug de la aplicación. Tomamos nota y si es algo sencillo que no requiere demasiado análisis, se resuelve. Si es algo más complejo, se analiza qué impacto está teniendo en función de la cantidad de usuarios del sistema. ¿Hay que arreglarlo ya o puede esperar unos días hasta que tengamos una nueva versión donde incluiremos también otros arreglos de bugs que seguirán surgiendo?
Empiezan a caer más bugs
A la semana ya empiezan a haber demasiados bugs. Son alrededor de diez, entre algunos sencillos de solucionar, otros complejos y preocupantes y otros que son incomprobables.
Como desarrollador, uno acepta que pudo haberse equivocado y tiene la cabeza abierta lo suficiente como para entender que pudo no haber considerado algunas posibilidades. Por lo tanto acepta cualquier reporte de bug como válido hasta que logra o no reproducirlo. Es como el principio de inocencia, pero aplicado al cliente, a quien le creemos lo que nos dice, salvo que probemos que se equivoca.
Llegando al final de la segunda semana, empezamos a manejar los bugs en una lista, o de forma separada dentro del sistema de tracking que se use.
El cliente empezó a reportar cosas ya demasiado raras. Como que el listado de reportes que es la parte central de la aplicación y que nunca falló, no aparece a veces. Algún usuario reporta que la sesión se le cerró al enviar un formulario. Otro dice que no puede ver en pantalla un botón que todos los otros usuario sí pueden ver.
La zona de histeria
Pasado el mes, el tono del cliente a esta altura deja de ser amable. Empieza a sospechar que el sistema que compró no funciona. Que detrás de cada click que hace o de cada tecla que toca, puede estar la destrucción de toda la información que viene generando. Empieza a echarle la culpa al sistema de cosas que tienen relación con él y otras que pasan totalmente por fuera.
Los usuarios hablan entre ellos y empieza a correrse la voz de que el sistema está mal hecho. Que el que lo programó lo hizo mal.
Los usuarios con menos experiencia, por ejemplo aquellos que no pueden discernir para qué operaciones necesitan tener internet y para cuáles no, empiezan a fomentar una especie de culto en el cual el sistema es el causante de todos o la gran mayoría de los problemas del lugar de trabajo. Como no entiende la diferencia, si ven que la impresora no imprime bien, inducen erróneamente que es culpa del nuevo sistema.
Los reportes de bugs empiezan a multiplicarse. La mayoría son disparatados y una pequeña minoría tienen algo de sentido.
Los desarrolladores nos convertimos en los grandes culpables. Nuestro contacto y a quien llamamos “cliente” empieza a albergar resentimiento contra nuestra persona y nos lo manifiesta a veces con ironía y otras veces con palabras fuertes. Hay quienes llegan a los insultos.
El sonido del teléfono comienza a convertirse en el más diabólico del mundo. El cliente llama a cada rato y muy nervioso por un problema del sistema. Finalmente se da cuenta que el que se estaba equivocando era él. Pero a los 10 minutos vuelve a llamar. Otra vez se había equivocado él. Pide disculpas.
A los dos meses, y aún con parches aplicados, la histeria se volvió colectiva. Todo el mundo sospecha que el sistema fue diseñado y programado por el mismísimo demonio. El cliente llama a las 8 AM. porque el auto no le arranca y cree, convencido, que el programa que hicimos tiene algo que ver.
El último párrafo exagera un poco, pero está clara la idea.
Una reacción desmedida
Una vez que nos sentamos tranquilos, vemos que la mayoría de los bugs reportados estaban causados porque el usuario no entendió cómo funcionaba el sistema a pesar de haber sido capacitado y de haberle entregado un manual. El botón que no aparecía era porque el usuario no había scrolleado la pantalla. Al que se le había cerrado la sesión al enviar el formulario, se había ido a una reunión y luego a almorzar y al volver quiso enviar un formulario que había dejado incompleto. Ya era tarde, la sesión había caducado.
¿Cuántas veces te ha pasado algo así? Generalmente esto lo sufre quien trabaja por cuenta propia o quienes ponen la cara con el cliente. Los que se blindan en las áreas de desarrollo están aislados de este problema.
A veces depende también del cliente. Especialmente del contacto particular, la persona que representa al cliente. Su forma de ser, su nivel de profesionalismo y su trato son fundamentales para la etapa post implementación.
¿Cómo evitar la zona de histeria?
¿Cómo se puede evitar llegar a ese estado de histeria donde somos los máximos culpables de todos los problemas del cliente? ¿Hay una forma de hacerlo o es algo ineludible de todo proyecto de desarrollo?
El tiempo, la capacitación y, especialmente, la experiencia me han ayudado a poder evitar o minimizar al máximo la estadía del cliente en la zona de histeria.
Esto es lo que he aprendido:
Trabajar a conciencia
Si algo está bien hecho, tiene muchas menos posibilidades de fallar. Si el análisis ha sido completo y detallado. Si se ha hecho un diseño de la aplicación a nivel datos y un modelo de clases. Si se ha reparado en la arquitectura, si se ha programado a conciencia y si se han utilizado pruebas automatizadas, entonces es más difícil que el programa falle.
Invertir en testing
Esto quiere decir invertir tiempo y dinero. La idea aquí es “No le demos al cliente la posibilidad de que pueda reportarnos un bug”. Es una meta imposible de alcanzar porque todo sistema tiene siempre fallas, pero tenemos que apuntar a que no las tenga. El testing es una herramienta fundamental.
Darle importancia a la usabilidad
El usuario tiene que poder interpretar lo que dice la pantalla para orientarse y poder hacer lo que necesita. Personalmente subestimé esta área durante mucho tiempo. En un proyecto reciente descubrí que detenerse en la usabilidad puede ahorrar muchas horas de capacitación y soporte post implementación.
Escribir un manual del sistema
Siempre escribo un manual con capturas de pantalla para los usuarios. Muchos pensarán que es una pérdida de tiempo y que “no lo van a leer”. Es cierto, no lo leen. Pero cuando llaman para reportar un bug o quejarse de algún funcionamiento, los remito directamente al manual. Les pido que lean una parte y vean que estaba explicado allí. Que el sistema no está funcionando mal, sólo que ellos no han entendido como funciona. Esto hace que el usuario se sienta un tonto precipitado, lo cual es bueno, ya que la próxima vez revisará el manual, o le preguntará a algún compañero antes de intentar reportar un bug que no existe o llamar para quejarse porque simplemente no sabe usar el sistema.
Usar herramientas de tracking de incidencias
Esto sirve para llevar la cuenta de cuántos bugs se han reportado e identificar duplicados. También permite asignar urgencias y, si trabajamos en equipo, saber quién se está encargando de cada problema. La idea es contar con una herramienta colaborativa que esté alojada en algún servidor que sea de acceso para todo el equipo de desarrollo.
Capacitar al usuario.
Muchas veces cuando diseñamos un programa, estamos modelando un sistema que tiene reglas de negocios complejas. Por lo tanto, por más usabilidad que haya, hay funciones y operaciones muy concretas que implican que el usuario debe saber exactamente qué está haciendo. Para que entienda, un manual puede ser algo muy frío y distante. Es mejor una breve capacitación en persona. Un tour por las funcionalidades, con una explicación de ejemplo. Siempre haciendo que sea el mismo usuario el que realice los pasos. Uno es solamente una guía. Ese es también el momento para responder preguntas.
Incluir una etapa de prueba
Siempre que sea posible hay que intentar incluir en el proyecto una etapa de prueba. Esto consiste en un tiempo en el que el sistema se instala de forma temporal y donde el cliente debe tener la obligación de utilizarlo con el objetivo de: ver si cumple con lo que necesita, solicitar ajustes, proponer mejoras y encontrar errores.
Usar integración continua
Realizar despliegues de forma manual, subiendo archivos, es cosa del pasado. Hoy en día hay muy buenas herramientas para automatizar el proceso de despliegue. Esto sirve para que esta etapa sea más limpia y esté libre de errores. Siempre que sea posible, es prudente utilizar alguna herramienta de integración continua.
Trabajar con ambientes
El ambiente de producción debe ser donde el sistema está corriendo. Un ambiente de stage puede servir para hacer pruebas antes de pasar a producción. Y un ambiente de desarrollo para ir volcando los cambios diarios. Se pueden tener más y quizás unificar stage con el de pruebas, pero no tener un ambiente idéntico al de producción donde probar es peligroso.
Resumiendo
Y eso es todo lo que te puedo contar respecto a la zona de histeria del cliente. Me ha pasado muchas veces cuando recién comenzaba, especialmente como líder de proyectos.
Siguiendo algunos de los lineamientos que tengo acá, se puede evitar. Y si tenés habilidades sociales se te hará mucho más fácil persuadirlo y hacerle bajar un cambio.