Cuando tu objetivo es convertirte en el mejor Revenue Management System del mercado, debes organizar un sistema de trabajo que sea eficiente y escalable en todos los departamentos.
Por Vanessa Hernández, Product Analyst en Beonprice
This article was written in Spanish. Click here for the English version.
Tras la publicación de nuestro anterior artículo sobre los principales resultados del 2020 en el departamento de tecnología de Beonprice, seguramente te preguntarás cómo hemos conseguido esas cifras y cuál es nuestra metodología de trabajo. El motivo de este nuevo artículo es describir cada paso en nuestro camino para convertirnos en el mejor Revenue Management System del mercado.
El departamento de tecnología en Beonprice
Nuestro departamento de Tecnología, aunque está constituido por un equipo muy unido que trabaja para conseguir el objetivo común, se estructura en dos grandes bloques: el equipo de producto y el equipo de desarrollo. Ambos equipos siguen la metodología de trabajo Agile, que sigue 4 principios:
1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre documentación extensiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta ante el cambio sobre seguir un plan
Con esto en mente, seguimos el framework Scrum, que se compone de sprints (periodos de una o dos semanas) durante los cuales los equipos llevan a cabo las tareas previamente planificadas, siempre con un entregable en mente.
Desde el equipo de producto nos aseguramos de que:
1. Aportamos valor añadido con nuestra solución, manteniendo siempre nuestro foco de atención en el entendimiento del problema y las necesidades de los hoteleros (Revenue managers).
2. Somos competitivos en el mercado diseñando soluciones atractivas, eficaces, de calidad y justo en el tiempo que nuestros clientes lo necesitan.
3. Definimos el alto nivel de funcionalidad y calidad para mantener el funcionamiento óptimo del sistema.
Para ello, una vez hemos recogido las necesidades de nuestros clientes, analizado el problema al que se están enfrentando y priorizado nuestro Roadmap, planificamos el Sprint Planning. Durante nuestro sprint realizamos las tareas necesarias para asegurar el buen funcionamiento de los proyectos que están por venir, a la vez que realizamos las continuas validaciones necesarias de las funcionalidades que ya han sido entregadas.
Metodologías de trabajo en Producto
De cara a los proyectos que han sido priorizados para su posterior desarrollo, Producto prepara el documento de requerimientos, el cual incluye no solo el qué sino el porqué. Así, este documento sigue una estructura tal como sigue:
· Utilizando nuestra plantilla de Lean Canvas adaptada a nuestras necesidades internas, incluimos la definición de términos, definición del problema al que el cliente se enfrenta, la propuesta de valor que el proyecto va a aportar, la ventaja competitiva que nos va a proporcionar, las métricas a medir una vez el proyecto esté finalizado, y las dependencias interdepartamentales. Esto nos ayuda a tener un resumen completo que no solo podamos compartir con el equipo de desarrollo, sino también con stakeholders, equipos de ventas y Customer excelence.
· Prototipo: Durante el proceso de especificación, se prepara un prototipo de manera que el equipo de desarrollo sepa cuál es la finalidad del proyecto en cuestión. En el caso de una nueva funcionalidad, generamos prototipos interaccionables utilizando herramientas de diseño, que ayudan a explicar de manera más eficaz la solución propuesta. En el caso de proyectos propios de algoritmo, este prototipo suele incluir los cálculos necesarios y el output esperado.
· Job Stories: A diferencia de muchas otras empresas que utilizan User Stories, en Beonprice decidimos utilizar la metodología de Intercom a través de las Job Stories (when…, I want to…, so I can…) que están más enfocadas a la situación y la motivación más que a la persona y la acción. Esto nos ayudó a que nuestro equipo técnico entendiese mejor el comportamiento de lo pedido ya que las necesidades entre nuestros usuarios son muy similares.
· Criterios de aceptación: De cara a escribir estos criterios de aceptación en un lenguaje que ambos equipos (producto y desarrollo) entiendan, utilizamos el método de BDD (Behaviour Driven Development), que describe el comportamiento del software. Este método nos ayuda además a automatizar las pruebas de validación una vez terminado el desarrollo.
· Diagrama de Flujo: En el caso de un proyecto de algoritmo, este diagrama es fundamental para el entendimiento y desarrollo del mismo. Nos ayuda a definir los datos de entrada y salida que deben aplicarse para conseguir el resultado esperado del proyecto en cuestión.
Una vez el documento de requerimientos está preparado, tenemos sesiones con los desarrolladores previas a su sprint planning para validar que la documentación estará completa, y minimizar posibles dudas que puedan surgir durante el desarrollo. Esto también nos ayuda a obtener feedback y añadir cualquier nuevo requerimiento, si esto fuera necesario.
El equipo de desarrollo
A la vez, tenemos a nuestros techies en el equipo de desarrollo, el cual, al igual que el equipo de producto, organiza sus sprints en función de las tareas necesarias de cara al desarrollo de cada proyecto. A principio del sprint establecemos cuál debería ser el entregable para el final del mismo, en función del roadmap priorizado y los documentos de requisitos provenientes del equipo de producto.
Estos equipos de desarrollo se separan en squads, y cada uno de ellos trabaja en tareas y proyectos diferentes. Esto nos ayuda a asegurar la velocidad que requerimos. Durante el sprint, además del desarrollo del mismo, mantenemos un nivel de testeo del código de al menos 80% del mismo para nuevos proyectos. Esto es conocido como TDD (Test-driven development), que incluye los test de comportamiento BDD, y nos asegura calidad en el dato.
Una vez el proyecto está desarrollado, pasamos a la fase de validación tanto interna en el equipo de desarrollo, como en el equipo de producto. Con esta validación, confirmamos que el desarrollo cumple los requisitos, y a su vez se preparan las pull requests: un squad distinto al que ha desarrollado el proyecto en cuestión analiza y valida el código.
Como podemos observar, no solo testeamos proyectos, sino también valoramos subjetivamente el desarrollo del código.
La importancia de trabajar en equipo con otros departamentos
En lo que se refiere al equipo de desarrollo, no debemos olvidarnos del pilar más importante que tenemos en tecnología, nuestros datos, y la integración de los mismos. Para ello tenemos a nuestros compañeros de Integraciones que aseguran en todo momento la integración de Beonprice con las fuentes necesarias que puedan implicar la obtención del dato, siempre y cuando nos permitan mantener nuestra buena calidad.
Hasta aquí hemos mencionado la metodología que utilizamos en Beonprice de cara a desarrollo de proyectos, pero no todo queda ahí; como ves, ¡en Beonprice no nos aburrimos! Gracias a la ayuda de nuestros compañeros del equipo de Engagement, tenemos nuestros casos de estudio. Los casos de estudio consisten en, como su propio nombre indica, casos especiales que es necesario analizar en detalle, bien sea porque el resultado del algoritmo pueda requerir explicación, o porque no está reaccionando bajo alguna casuística que no haya sido previamente identificada. Estos son de gran importancia, no solo de cara a mejora de nuestro algoritmo, sino a la mejora de potenciales funcionalidades para futuros proyectos.
Espero que este artículo haya aclarado tus dudas en lo referente a cómo conseguimos las cifras mostradas en el artículo anterior, sabemos que siempre hay lugar a mejorar la metodología de trabajo, y desde Beonprice mantenemos nuestras mentes abiertas a todo lo que conlleva mejora e incremento de la productividad.
