Caso de uso: como estamos trabajando en el desarrollo de una herramienta interna

Como os comentaba en este post, llevamos un año o asi, trabajando en el desarrollo de un proyecto interno para sustituir a una herramienta que lleva desde los inicios de la empresa, con casi 15 años de desarrollo. Como podréis imaginar la parte visual está basada en un diseño muy antiguo, y no está pensada para móviles o tablet, con lo cual dificulta su acceso con otros dispositivos que no sea ordenadores con pantallas grandes.

Tiene tantas funcionalidades integradas que dado que se han ido añadiendo con el tiempo, la complejidad de la interfaz es muy elevada, con una curva de aprendizaje muy larga en el tiempo. Incluso los agentes que llevan más tiempo empleándola, tienen dificultades para encontrar las cosas. Por ello el objetivo principal era optimizar los procesos de trabajo de todos los usuarios, para asi sacar datos y estadísticas y mejorar los tiempos de ejecución de tareas.

El equipo

Anteriormente se había probado realizar este proyecto solo con desarrolladores cogiendo componentes de un conocido framework. Esta vez exigimos que el equipo fuera multidisciplinar con integrantes de experiencia de usuario y sobre todo teniendo en cuenta a los usuarios desde el inicio.

El core del equipo cuenta con 1 team leader, 3 backs, 2 fronts y 2 UX/UI (una de estas personas asi mismo da soporte al team leader, asi como hace de tester). El team leader que también programa y los backs están «más o menos» al 100% con el proyecto, pero el resto además damos soporte en otras áreas de la empresa. Como podrás imaginar estamos bastante ocupados, teniendo que saber priorizar muy bien las tareas de los diferentes proyectos en los que trabajamos.

Aparte contamos con:

  • 1 persona de negocio que va haciendo análisis de como mejorar los procesos actuales ya que no queremos simplemente replicar lo antiguo,
  • 1 team leader que gestiona el desarrollo de la herramienta antigua, que con su equipo desarrolla los webservices que necesitamos,
  • el equipo de usuarios: un coordinador de los agentes, asi como agentes con algunos con años de experiencia y otros nuevos que prueban todo lo que se diseña, desarrolla y nos dan constante feedback.

Hay que comentar además que antes de comenzar el proyecto, parte de los integrantes del equipo de UX habíamos estado haciendo observación directa con los participantes con el objetivo, en esos momentos, de detectar mejoras para lo que era la herramienta actual (la que se va a sustituir ahora). Por ello ya conocíamos parte de la problemática asi como las formas de trabajar de los usuarios.

Comenzando el proyecto

Al inicio del proyecto, el equipo de desarrollo decidió la tecnología que se iba a usar. A la par desde UX realizamos un estudio de posibles interfaces para decidir cual iba a ser la estructura de diseño en la cual se iba a basar todas las pantallas. Había que tener en cuenta que aunque el 100% del trabajo de los agentes se realiza con un ordenador, se quería que no estuviera su diseño enfocado solo en desktop sino que fuera completamente adaptado a cualquier dispositivo.

Con negocio y los agentes se decidieron cuales eran las principales funcionalidades que se tenían que abordar para una primera versión, y se preparó un backlog para los primeros sprints.

Se decidió que cada semana habría una reunión los jueves con integrantes de los diferentes equipos para comentar el trabajo avanzado y revisar el backlog, y los viernes otra solo con agentes y parte del equipo desarrollo para hablar de cuestiones más propias de la interfaz y la interacción. Asi mismo los jueves se preveían los posibles webservices que íbamos a necesitar para los nuevos desarrollos, y se creaban las tareas para el equipo que los desarrollaba.

Todas las decisiones han sido tomadas conjuntamente entre todos los skateholders en base a éstas y otras reuniones diarias.

Asi mismo se pidió rotar el equipo de agentes para que no fueran siempre los mismos los que estuvieran dando feedback, y todos fueran siendo participes del proyecto.

Es una maravilla ver que todos los agentes están implicados al 100% proponiendo constantemente mejoras e ideas que entre todos evaluamos. La buena comunicación que para mi siempre es clave en cualquier proyecto, se ha conseguido desde el inicio.

Y llegó el día de la prueba real

Cuando creíamos que la primera versión estaba lista y testeada por el equipo de desarrollo y los agentes, se crearon diferentes grupos de testeo con otros agentes.

Hay que comentar que el uso de este programa es directamente en la llamada con un cliente, por lo que no podía fallar.

La nueva herramienta se encarga de avisar de que entra una llamada al agente, mostrar datos el cliente si se poseen, visualizar las reservas si es que tiene alguna pendiente, poder acciones sobre ellas, asi como realizar nuevas búsquedas y otras funcionalidades. El agente tiene constantemente al cliente al lado del teléfono y cualquier fallo implicaba que tenían que volver a la herramienta antigua y volver a buscar la información, lo que ralentizaba la atención al cliente.

Por ello, para probar bien la herramienta, fuimos haciendo que semana a semana, entrasen nuevos grupos de testeo de agentes, creando un canal directo de comunicación con ellos para que nos reportasen directamente los reportes. Es decir, la semana 1, el equipo 1 de agentes comenzó a utilizar la herramienta en las llamadas reales con clientes. A la vez se abrió un chat directo entre los integrantes y 2 miembros del equipo de desarrollo que respondían a sus dudas y creaban incidencias para el resto del equipo de trabajo en el caso de fueran necesarias. La 2º semana se abrió la herramienta a otro equipo, con su correspondiente canal, y asi hasta 1 mes donde se trabajó en paralelo con 4 equipos de prueba.

Una vez pasado el mes, ya se abrió al resto de los agentes de la empresa, se cerraron los chats con los grupos y se estableció otro canal de reporte.

A la vez de todo esto, el equipo seguía con su proceso habitual de trabajo y reuniones, continuando desarrollando nuevas funcionalidades y puliendo las mejoras que surgían.

Aun queda mucho trabajo por delante, ya que tenemos que implementar las funciones de una herramienta que lleva 15 años de vida, pero viendo lo bien que está funcionando seguiremos con esta metodología para continuar con los nuevos desarrollos.

Como punto negativo del proceso, debo comentar que sería mucho mejor que todo el equipo de desarrollo estuviera al 100% focalizado en esta herramienta y no formase parte del trabajo diario de otras partes de la empresa. Esta forma de trabajr ralentiza el trabajo, al tener que estar cambiado de proyectos y constantemente viendo que tarea es más prioritaria. Pero bueno, somos una empresa pequeña y somos pocos y es lo que hay. Aunque con orgullo debo decir que creo que superamos a otras empresas más grandes de la competencia frente a los nuevos cambios.

¿Qué te parece? ¿Me cuentas tu experiencia?

Caso de uso: como estamos trabajando en el desarrollo de una herramienta interna

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll hacia arriba