Más vale maña que fuerza

Con el desarrollo de software a medida, una parte que suele quedar olvidada y a la que no siempre se le da importancia que se debería, es el soporte técnico posterior. Ese periodo de garantía que damos al cliente frente a la aparición de errores, las horas de mantenimiento que tenga contratadas, o incluso a asistencia remota en el uso de la aplicación. Por muy bien planificado y pensado que tengamos el proyecto, al final los desarrolladores somos humanos y cometemos errores, o simplemente no consideramos que una situación pueda llegar a suceder.

No existen programas con cero problemas, sólo programas con problemas que no han sido detectados todavía. Para ilustrar esto último, recuerdo una ocasión en la que me llamó un usuario quejándose de que una pantalla de cálculo de presupuestos no sumaba bien al introducir un precio. Evidentemente a la vez que hablaba por teléfono, yo estaba probando la misma acción descrita y verificaba que el resultado para mi era satisfactorio. No lo entendía, pero por costumbre siempre tiendo a creer al usuario si me dice que algo va mal, así que le pedí por favor que me compartiera pantalla. ¡Quedé estupefacto cuando vi que en el campo de importe escribía literalmente, me lo invento, 1.560,30, literalmente! ¡Con su punto de millar y todo! - ¿Pero alguna vez has puesto el punto de millar en una calculadora? - le dije sorprendido. Nunca hay que subestimar la capacidad del usuario a encontrar errores o problemas de usabilidad.

Como decía, el soporte técnico posterior a veces puede decantar el balance de un proyecto de beneficioso a un auténtico problema (en tiempo y dinero). - Esto se soluciona con un buen análisis previo - diréis, y en parte es verdad, pero no solucionaréis el 100% de los problemas, ni te evitará que si el usuario hace las cosas como no debe, experimente problemas y entonces se ponga en contacto con soporte técnico.

Resolución de incidencias

Ante una incidencia de un cliente, debido al día a día, es fácil y lógico que procuremos solucionarla lo antes posible con tal de que pueda proseguir con su trabajo (y nosotros el nuestro antes de la interrupción). La mayoría de veces, en entornos CRM, suele ser un problema de introducción de datos o incluso debido a que el usuario no ha realizado correctamente algún procedimiento. A grandes rasgos, siempre seguimos los mismos pasos:

1. Recopilación de datos del problema: Notificación de la incidencia.
2. Reproducción del problema: Si no se reproduce, es difícil saber qué sucede.
3. Identificación del origen del problema: Lo que yo llamo "tirar del hilo".
4. Solución del problema: Revirtiendo o actualizando un cambio.

Una vez solucionada la situación cerramos la incidencia, notificamos al cliente que ya puede proseguir y continuamos con lo que estábamos trabajando antes de la incidencia. Si se trataba de un error de programación, con suerte, aquí termina la historia. El problema lo tenemos cuando el origen del problema ha sido por un mal uso de la aplicación por parte del usuario, léase:

• Un dato mal introducido.
• La falta de cumplimentar un dato.
• Se ha olvidado realizar un paso.
• Incoherencia de datos.
• Desconocimiento del funcionamiento de la aplicación (Falta de formación)

Llega un día en que te das cuenta que necesitas una cantidad de recursos dedicados única y exclusivamente a atender incidencias.

En estos casos, si nos hemos limitado a corregir el dato o a explicar al usuario qué ha hecho mal, lo más probable es que el problema vuelva a reproducirse pasado un tiempo y de forma periódica. Si a esto le sumas el número de usuarios que acceden a una aplicación, y lo multiplicas por el número de aplicaciones distintas (horizontales) que tienes desplegadas, llega un día en que te das cuenta que necesitas una cantidad de recursos dedicados única y exclusivamente a atender incidencias.

Atacando al foco de las llamas

Hace unos años, en el departamento, tuve que afrontar una situación de disminución y rotación elevada de personal en poco más de un mes. Este hecho provocó que las incidencias que se venían sucediendo habitualmente no eran cerradas tan ágilmente y se iban acumulando, con el problema que eso implicaba. Por cuestiones de curva de aprendizaje de todos los distintos proyectos, estaba claro que la solución al corto plazo no pasaba por contratar más recursos. Tampoco pasaba por intentar rendir el 200% con el personal veterano. Al final la solución, aunque parecía que todavía se nos acumularía más trabajo, pasó por:

1. Sacrificar rapidez en la resolución del problema: Salvo si la incidencia no era bloqueante, íbamos a tardar más en cerrar la incidencia.
2. Invertir el tiempo que fuera necesario en implementar procesos/algoritmos/ayudas en pantalla: Desde verificaciones previas a una acción, hasta un simple pero esclarecedor mensaje para el usuario, pueden marcar la diferencia entre que el usuario abra una incidencia porque está bloqueado, a que el usuario se percate de que algo está haciendo mal y sepa cómo solucionar su bloqueo por sí solo.
3. Dotar, si fuera necesario, de la funcionalidad necesaria al usuario para que sea autosuficiente: A veces el usuario se equivoca en una acción que, por diseño inicial, es irreversible desde la interfaz de usuario. Dotando a un usuario encargado o administrador de una simple pantalla de gestiones avanzadas para que pueda revertir cambios (con todas las verificaciones pertinentes y ayudas en pantalla necesarias) evitas que el usuario deba recurrir al servicio técnico para que reviertas un cambio.

Gracias a esta estrategia conseguimos que las incidencias recurrentes no se volvieran a repetir en un gran porcentaje, y a las pocas semanas, con menos personal y sin tanta experiencia, habíamos recuperado el ritmo de trabajo. Incluso ha habido casos de usuarios que habitualmente reportaban incidencias que ya no han vuelto a abrir una incidencia más desde entonces. 

Si sólo corriges el resultado erróneo o corrupto, no estás evitando que vuelva a reproducirse.

Es como en un incendio: apagando las llamas de alrededor no extingues el incendio, sino que debes dirigir el chorro de agua al foco del incendio. Pues lo mismo sucede frente a un problema: Si sólo corriges el resultado erróneo o corrupto, no estás evitando que vuelva a reproducirse. Casi siempre invertirás menos tiempo en trazar e implementar una solución permanente, que no en la suma de todas y cada una de las veces que vuelva a reproducirse el problema a lo largo del tiempo.