Fundada hace casi una década por siete egresados de la Facultad de Ingeniería de la Universidad de Buenos Aires, FDV Solutions se propuso desde el inicio crear un espacio de trabajo distinto para ofrecer a sus clientes soluciones de calidad, basadas en nuevas tecnologías. “Hoy somos una empresa de unas 90 personas, tenemos nuestra oficina principal en Buenos Aires, pero también en New York y San Francisco, dado que Estados Unidos es un mercado importante para nosotros”, explica Matías Gorostegui, Solutions Architect y socio fundador de FDV Solutions.
—¿Qué clase de organizaciones puede aprovechar mejor la tercerización en el desarrollo de software?
—Creo que cualquier tipo de empresa puede aprovecharlo, si bien de distintas formas. Uno de los impulsores para tercerizar un proyecto de desarrollo o un servicio es la falta de skills o habilidades propias en la compañía. Esta carencia te lleva a buscar otra empresa que se especialice en eso. Nos pasa mucho en los últimos tiempos ver organizaciones que tienen muy maduro sus procesos de desarrollo interno sobre tecnologías tradicionales, como Java o .NET, y que cuando se les presentan la necesidad del negocio hacer desarrollos para móviles, salen a buscar expertos en terceras partes. El resto, son impulsores más tradicionales, siempre alrededor de las falta de habilidades, la falta de capacidad, o la posibilidad de hacerlo en tiempos que con recursos propios no se podría. Y otro tema muy importante es el de los costos. Si tenés un departamento de sistemas, o áreas de tecnologías, y las tenés que capacitar en nuevas tecnologías, eso tiene un tiempo y un costo importantes, y si no estás dispuesto a invertir en eso, o no tenés los recursos hacerlo, salís a pagarlo por otro lado.
Para Gorostegui, esto puede aplicar tanto en grandes organizaciones, que ya tiene sus propios departamentos de Sistemas, como en pequeñas organizaciones, con áreas de Sistemas menos maduras.
—¿Qué área, dentro de la organización, es la interlocutora con el proveedor del servicio?
—Por el perfil de FDV, muy orientado al desarrollo en sí mismo, generalmente trabajamos con interlocutores más cercanos al área de Sistemas. Es raro que trabajemos directamente con el área de Marketing, el área Comercial o el área de Recursos Humanos. Sí nos ha pasado, y tuvimos proyectos muy variados, del estilo “queremos armar un dashboard comercial”, donde trabajamos el proyecto con esa área, pero siempre con cierto auspicio del área de Sistemas. Nosotros trabajamos muy orientados a las metodologías ágiles. Particularmente siguiendo una práctica basada en Scrum. En este orden, tratamos de impulsar que todos los interlocutores necesarios estén involucrados en el proyecto. Y cuando vemos que el área de Sistemas de una compañía no tiene capacidad como para involucrarse a full en el proyecto, tratamos de convertirnos nosotros en el área de Tecnología, haciendo la gestión del proyecto, o proveyendo un analista o un desarrollador para cubrir esa falta de capacidad de ellos. Pero Sistemas será nuestra área de reporte. Para nosotros es importantísimo, a fin de asegurar el éxito del proyecto, que Sistemas esté involucrada.
—¿Cómo es el proceso de elegir un proveedor? ¿Qué factores habría que tener en cuenta?
—Se desprenden un montón de consideraciones a tener en cuenta. Si estás parado en un área del negocio y tenés que salir a elegir un proveedor de Sistemas… Las veces que nos ha tocado le pedimos a esa área de negocios una o dos reuniones con el área de Sistemas, ya sea para que ellos pudieran validar la elección, como así también para que nosotros pudiéramos entender en qué contexto nos estábamos metiendo. Muchas veces, por más que el proyecto parezca atractivo, si uno no tiene los involucrados correctos en el proyecto, no funciona, incluso si el presupuesto está.
Gorostegui asegura que lo primero es buscar en un proveedor sobre el cual se quiere tercerizar un desarrollo de software es la idoneidad técnica. Para ello es necesario que el cliente tenga identificada la necesidad y tenga una primera idea de la solución que va a encarar. “Con esto último es que va a poder evaluar si un proveedor tiene la idoneidad técnica o no para poder hacerlo, en base a casos de éxito sobre temas parecidos, referencias, partnerships que tenga (por ejemplo en FDV Solutions somos partners de Red Hat: si la empresa está pensando en implementar una de estas tecnologías y nosotros somos partners, definitivamente estamos mejor posicionados que otro que no es partner, tenemos una relación y un acceso a recursos que es distinto). Muchas veces ayudamos en este análisis preliminar, y en esto trabajamos con las áreas de negocios”.
Medida la idoneidad técnica, el proceso abarca aspectos como la evaluación de los casos de éxito, las referencias comerciales, y las referencias en colegas de la industria (en un vertical dado). “En licitaciones públicas o en procesos más formales dentro de grandes empresas, tenés que completar una serie de formularios con otro tipo de antecedentes, como balances, estatutos de la sociedad, cantidad de desarrolladores o gerentes certificados en una determinada tecnología o práctica. En los proyectos grandes hay infinidad de reuniones para pasar las distintas instancias de evaluación”.
En la propuesta final —explica Gorostegui— no sólo tiene que estar la propuesta técnica, sino también el cómo se va a concretar, “qué metodologías va a seguir el proveedor, cuáles van a ser las prácticas, cuáles los puntos de contacto, y un plan inicial con los hitos de control. Una de las cosas que tratamos de hacer, y que sugerimos a nuestros clientes que están en estas situaciones, es no embarcarse en proyectos infinitos, y en proyectos que no tengan hitos intermedios que puedan ser medibles. Si no los tiene, habría que hacer el trabajo de pensarlos. Si tenés un proyecto de dos años, hay que romperlo en proyectos de seis meses o un año como mucho, hay que hacer mucho foco en que ese proyecto ya le agregue valor a la organización, y que eso sirva de base para hacer la siguiente etapa de otros seis meses a un año, y así hacerlo realmente iterativo”.
—Existe la tentación de meter metodología ágil en todo lo que se mueve. ¿Qué papel le asignan a la metodología?
—Se intenta meter metodologías ágiles a todos, y muchas veces eso es una excusa para trabajar desprolijamente. Para trabajar con las peores prácticas. Ágiles no significa no planificar, o no estimar, o no escribir documentos. Las metodologías ágiles no dicen que trabajes desprolijo, sino que debés acomodar un proyecto y tu equipo para ser flexible, moverte rápido, no esperar a tener todo definido para arrancar a trabajar, lo cual no significa que no escribimos nunca más un documento o no cerramos nunca más una definición. Lo que también pasa es que incorporar metodologías ágiles en algunas organizaciones es un proceso costoso. Por subirse a la moda de ágiles, mucha gente dice que ya lo está haciendo, pero sigue trabajando de la misma forma en que lo hacían antes (con metodologías tradicionales o sin metodología), y ahora lo llaman ágiles. Las empresas que trabajan con metodologías ágiles en serio podrían aplicar ágiles —siempre en lo referente a desarrollo de software— en casi cualquier proyecto. Ahora, el proceso de aplicar estas metodologías lleva tiempo, la organización y las personas tienen que “comprarlo”, las metodologías ágiles están muy basadas en las personas. Al tener tanto foco en cada uno de los individuos desde la metodología, si esos individuos no se apegan a las prácticas el proyecto no tendrá un buen desarrollo. Trabajar en ágiles con un equipo en contra, está condenado al fracaso.
Gorostegui admite que en esta etapa de transición, sobre todo en el mercado argentino, puede trabajarse con interfaces más tradicionales, de cara a las áreas de negocio, pero empelado metodologías ágiles dentro del equipo de desarrollo. “Ese híbrido existe —reconoce—, hoy en día que estamos en un proceso de transición, es algo bastante común, y mucho más en el mercado argentino y de América Latina. En definitiva, cualquier proyecto puede ser ágil, pero no cualquier empresa puede aplicarlo a cualquier proyecto”.
