Por Leo Masri, Product Manager

Dentro del ciclo de vida de los productos de Toolbox, hay una etapa fundamental, que es la adición de nuevos features a las plataformas, o la mejora de las funcionalidades existentes. Cada nuevo feature es un desarrollo concreto con impacto en el producto, por lo que exige que se hagan análisis y estimaciones, se dediquen recursos específicos, y que dicho desarrollo pase por los test y los controles de calidad de las áreas involucradas.

En Toolbox procuramos estar siempre a la vanguardia con tecnología de alta gama, por lo que este tópico se vuelve fundamental: es lo que promueve la constante evolución de nuestros productos. Todas las semanas tenemos releases nuevas en los productos,  mientras nuestros equipos de Ventas, Producto, e Implementaciones y Soporte, que tienen una fluida comunicación con los clientes, atienden constantemente las sugerencias de mejora. Al comercializar nuestro software como un servicio, desde la nube, las actualizaciones llegan de manera aceitada y transparente a los usuarios. Los updates se realizan en los horarios de menor concurrencia de las plataformas y no requieren la instalación de parches o nuevas versiones localmente para su funcionamiento.

El puntapié inicial

El punto de entrada de una nueva funcionalidad puede ser una demanda del cliente, o bien una sugerencia de algún miembro de los equipos de Ventas, de Desarrollo o de Producto, e incluso puede venir del equipo de Legales, dado que una nueva regulación puede tener impacto en una funcionalidad existente o exigir capacidades nuevas. La iniciativa también puede emerger de la observación de otros productos similares en el mercado, o del acceso a nuevas herramientas y recursos que hacen viable proyectos que anteriormente no fueron rentables o eran muy complejos para ejecutar.

Cuando llega alguna propuesta de mejora o nueva funcionalidad, se inicia un proceso de análisis. Lo primero que se observa es si dicha funcionalidad agrega valor al producto. En otras palabras, si las modificaciones o adiciones son útiles para los distintos clientes, más allá de que el requerimiento puede haber llegado a través de uno de ellos.

Si se trata de un requerimiento particular de un único cliente, que no será aprovechado por el resto, es posible que esto no se plasme en una nueva funcionalidad. Desde Toolbox asistiremos a ese cliente brindándole toda la información necesaria para que pueda hacer el desarrollo. Esto le permitirá al cliente enriquecer sus productos sin necesidad de modificar nuestra plataforma. Ejemplos de estos casos particulares son los requerimientos específicos de reporting. En este caso nos aseguraremos de que la API del producto brinde la información que el cliente necesita y le diremos de qué manera interactuar para obtenerla y agregarla a su propio software.

Si la funcionalidad resulta interesante para una cantidad de usuarios, lo que sigue es un análisis de costo-beneficio. En este segundo análisis trabajamos de la mano de los equipos de Arquitectura y Desarrollo para que nos ayuden a estimar las horas hombre que se deben invertir en este desarrollo. La pregunta por responder es si la nueva funcionalidad podrá cumplir con las condiciones mínimas de rentabilidad sobre la inversión realizada. A veces sucede que, a pesar de la conveniencia de incluir una nueva funcionalidad, los beneficios no justifican impulsar ese nuevo desarrollo. También puede pasar que, en algunas ocasiones (por ejemplo, en los momentos previos y durante un Mundial de Fútbol), los equipos de trabajo no disponen de tiempo para encarar nuevos proyectos no relacionados con esa coyuntura. Entonces, el proyecto quedará en agenda, para una re-evaluación futura.

La maquinaria de desarrollo y despliegue

Algunas áreas dentro de Desarrollo funcionan en base a la metodología KANBAN, con backlogs (o lista de tareas) que se priorizan y actualizan semanalmente. El backlog de las áreas de desarrollo de producto es priorizado y actualizado desde la gerencia de Producto. Esto se hace en el marco de las reuniones de backlog grooming, los viernes por la mañana, donde participan Producto y Desarrollo.

Lo que sigue es el Desarrollo, testeo y aseguramiento de la calidad del producto. Cuando estas etapas fueron superadas positivamente, si se trata de una adición técnica (algo que el cliente no percibe en primer plano, como podría ser una modificación en la API, o una forma de eficientizar un proceso), pasa por una revisión de Arquitectura. Cuando se supera esta instancia, se incorpora la modificación y se pone en producción. Si no es así, como puede suceder en el caso de un cambio en la interfaz visual, entonces se lanza un test de aceptación, que lleva adelante Implementación y Soporte.

Nuestra prioridad siempre es la estabilidad de la plataforma. De manera proactiva monitoreamos el desempeño de la plataforma, para asegurar su correcto funcionamiento con cada modificación o adición. Si la performance mostrara algún error,  ejecutamos inmediatamente un rollback del despliegue, para analizar el problema y solucionarlo sin que ello interfiera con la operatoria de los clientes.

VOLVER