Mejorando lo que no se ve de Ticketbis

De Ticketbis lo primero que ven los usuarios es la página web pero detrás de ella hay mucho más, la página web es la punta del iceberg. Más de 200 profesionales en más de 21 países dedicadas a proporcionar el mejor servicio posible en el proceso de compra o venta de entradas. Una de esas partes que no se ven es el backoffice que usan las diferentes personas en diferentes departamentos (edición de contenido, atención al cliente, financiero, ...) de la empresa para desarrollar su trabajo.

Dado que el backoffice es una parte que no ve el cliente de ticketbis y en principio no es una parte que ayude directamente a mejorar el número y volumen de las ventas era una parte que hasta ahora no habíamos cuidado todo lo que podríamos haberlo hecho en algunas áreas. Pero eso no quiere decir que no sea importante, tener un buen backoffice no ayudará a mejorar las ventas o el ratio de conversión de la página de compra pero si que ayudará a que las personas que lo usan puedan desarrollar mejor su trabajo redundando en una mejora en el servicio prestado, si finalmente este mejor servicio es percibido por el cliente ayudará a fidelizarlo haciendo que en posteriores ocasiones vuelva a elegir a ticketbis para comprar o vender sus entradas. Un mejor backoffice ayudará a que las personas que lo usan puedan hacer su trabajo mejor, más rápido, evitando tareas repetitivas que no aportan valor y que podrían dedicar a otras tareas más importantes y haciendo que un mayor volumen de eventos, entradas y transacciones no se conviertan en algo inmanejable.

Este es el aspecto que tenía el backoffice hasta ahora y debajo el nuevo aspecto de un par de pantallas de ejemplo.

Aunque el cambio de aspecto no es demasiado complicado el tamaño del backoffice es suficientemente grande como para que hacerlo todo a la vez fuese difícil. Si hiciésemos el rediseño completo de una vez seguro que introduciríamos fallos en varias partes entorpeciendo el trabajo de las personas que lo usan para realizar su trabajo, también nos llevaría demasiado tiempo y nos bloquearía para seguir aportando funcionalidades, todo ello es algo a evitar. De modo que la estrategia que hemos estamos siguiendo para «refactorizar» el diseño y código es hacerlo de forma gradual, según tenemos que hacer modificaciones en algunas partes del backoffice aprovechamos para hacer el rediseño y «refactors» del código, seguro que no lo dejaremos perfecto (si es que se puede) pero al menos lo que modifiquemos lo dejaremos bastante mejor de lo que estaba. Puede que quizá en alguna parte al hacer las modificaciones introduzcamos algún error sin embargo estará localizada en la parte modificada y no se juntará con los errores que podríamos introducir en otras partes al hacerlo todo a la vez. Hay que tener en cuenta que después de más de 4 años modificando y ampliando el código del backoffice por cualquiera de los que formamos el equipo técnico como es normal hemos ido introduciendo deuda técnica, en este rediseño no solo trataremos el aspecto de la aplicación sino que también aprovecharemos para deshacernos de un poquito de esa deuda técnica.

En el aspecto la mejora ha sido notable y en algunas partes del código que no se muestran en este artículo también. En el proceso de rediseño estamos replanteándonos las librerías y herramientas que usamos y si lo consideramos sustituyéndolas por otras mejores, entre ellas hemos empezado a usar jQuery 2, Bootstrap 3, Twitter Typeahead, Mustache... a medida que vayamos teniendo necesidad de más iremos incorporando algunas otras.