<- Volver al listado
Un fracaso y un éxito en Finizens: Adaptando la metodología al proyectoEn algún momento todos hemos escuchado eso de “the right tool for the job”, y más aún en el mundillo tecnológico. Tendemos a orientar este concepto a las cosas tangibles, pero este consejo se puede aplicar mucho más allá de herramientas de desarrollo, frameworks o librerías.
Mi primera gran aventura en el mundo startapil comenzó allá por 2010, en aquel momento tomaba forma Dokify, un saas que facilita la coordinación entre empresas. En pocos meses ampliamos el equipo y entre QA, SysAdmin, UI/UX y devs teníamos un equipo muy bien montado.
No teníamos un volumen muy grande en cuanto al número de tareas pero cada una requería bastante tiempo de desarrollo. Tomamos ideas de diferentes metodologías ágiles, y terminamos adoptando un proceso de desarrollo propio que funcionó perfectamente. Conseguimos alcanzar un buen ritmo de desarrollo manteniendo la calidad en los resultados.
A finales de 2015 parte del equipo pasamos a Finizens, somos la primera plataforma financiera 100% digital que te permite rentabilizar tus ahorros sin esfuerzo. Éramos un equipo ya engranado y funcionando, listo para crear un nuevo producto. Durante las fases iniciales mantuvimos el mismo proceso de trabajo, pero a medida que la empresa avanzaba y el equipo crecía nos empezaron a saltar algunas “alarmas”.
Siendo prácticamente las mismas personas y usando un stack tecnológico similar, el mismo proceso dejó de funcionar poco a poco. Pasar de un modelo de negocio B2B a B2C, el cambio de una compañía con financiación orgánica a estar respaldados por VC o simplemente la cantidad de oportunidades que presenta el sector fintech a día de hoy son sólo algunos ejemplos de las diferencias entre ambos proyectos. Estaba claro que teníamos que adaptarnos al medio y hacer cambios en nuestra metodología. Teníamos que cambiar nuestra manera de organizarnos.
Decidimos adoptar progresivamente Scrum para resolver nuestros principales problemas: dar visibilidad frente a negocio tanto del trabajo actual como de la capacidad a corto y largo plazo, alinear mucho mejor el área de tecnología a las necesidades de la compañía y, muy importante, no quemar al equipo de desarrollo.
Hoy llevamos 6 meses trabajando con esta metodología y podemos decir que ha sido una “herramienta” más que adecuada para resolver nuestro problema. Aún nos queda mucho camino que recorrer e innumerables puntos de mejora, pero estamos perfectamente preparados para seguir creciendo.
Como equipo la lección que nos llevamos es que no existe una metodología perfecta: Analiza las necesidades de tu proyecto, escoge la que mejor se adapte a ellas, y no dejes de iterar para mejorar día a día.
