Como armar un equipo de alto desempeño para generar datos confiables, proyectos ágiles y con un presupuesto acotado
Una de las grandes preguntas cuando se comienza un área de datos o debe reformularse para agilizar el time to market de sus proyectos, es cuestionarse qué perfiles debe contratar, que nivel de seniority o si deben ser especialistas o generalistas.
A todos los que hemos armado un equipo nos gustaría conseguir perfiles estilo T (expertos en un área y generalistas en otras) o PI (expertos en dos áreas y generalistas en otras), pero la experiencia nos ha dicho que en Data es realmente difícil hacerlo y suelen ser realmente costosos.
Y si se intenta, mientras reduces costos; se termina armando equipos generalistas que generan proyectos deficientes.
Teniendo como resultado la acumulación de deuda técnica a mediano plazo, viéndose forzado a incrementar la dotación de ingenieros para mantener los proyectos.
En este artículo daremos nuestra visión acerca de cómo conseguir un equipo de alto desempeño uniendo varias disciplinas y desde una visión táctica.
Para comenzar vamos a describir de forma general los roles y las tareas que realizan:
- Ingeniero de software: Se encargan de diseñar, concebir y elaborar sistemas informáticos (paquetes de software), utilizando uno o varios lenguajes de programación.
- Arquitecto de software: Se encarga de definir la arquitectura de los sistemas tomando las decisiones de diseño de alto nivel y estableciendo los estándares técnicos, incluyendo plataformas, herramientas y estándares de programación
- Ingeniero de datos: Se encargan de construir y gestionar los datos y la infraestructura necesaria para almacenarlos y procesarlos. Construyen la base tecnológica para que los científicos de datos y analistas puedan realizar sus tareas
- Analista de calidad de datos: Se encargan de definir, medir y validar la calidad de los datos, combinando conocimiento obtenido desde el negocio y habilidades técnicas que automaticen el procesamiento
- Ingeniero de operación de datos (DataOps Engineer): Se encarga de mejorar la comunicación y la automatización de cómo fluyen los datos entre los administradores de datos y los usuarios de datos en diferentes partes de la organización
- Ingeniero de confiabilidad de datos (Data Reliability Engineer): Se encarga de ayudar a una organización a brindar alta disponibilidad y calidad de datos durante todo el ciclo de vida de los mismos, desde la ingesta hasta los productos finales: tableros, modelos de aprendizaje automático y conjuntos de datos de producción
Cuando vemos estos perfiles pensamos que hay algunos que vienen del mundo del software y otros que creo que podrían ser extremadamente costosos.
Entonces nos preguntamos, ¿Qué hacen aquí? ¿Tendremos alternativas? ¿Será realmente eficiente esto?
Queremos aclarar que tomamos esta decisión, dado que buscamos tener un equipo interno que sea capaz de cubrir gran parte de las tareas de desarrollo (desarrollo, despliegue y observabilidad), siendo capaz de generar entregables rápidamente.
Al leer esto, puedes estar asustado por la diversidad de los perfiles, pero te contamos los beneficios, desventajas y preocupaciones que te pueden traer.
Los principales beneficios son:
- Agilidad, al estar todos los perfiles en un equipo tendrán una visión clara y transversal de lo que realizan sus pares y entenderán el ciclo que debe realizar su trabajo
- Feedback, en el caso que haya que realizar cambios en una de las partes el feedback será más rápido y simple
- Los roles se complementan y aprenden mutuamente
- Innovación, se promueve la innovación a través de un modelo lean startup
- Externalización inteligente y eficiente en el mediano plazo
Desventajas y preocupaciones:
- El líder del equipo, debe tener una visión clara y completa de las tareas que debe realizar su equipo
- Se debe promover un liderazgo participativo, para que todos colaboren
- Se puede perder la centralización de los lineamientos y estándares de calidad
En resumen, el equipo tendrá la libertad de desarrollar capacidades de datos sin depender de otras áreas, de forma iterativa e incremental.
Para cubrir los riesgos de que los equipos no estén alineados con los estándares, se les puede proveer los estándares “corporativos” antes de comenzar o realizar revisiones cada 2 semanas o 1 mes.
Hay que recordar y transparentar que el trabajo es para la compañía y no para áreas específicas.
¿En que debo fijarme para contratar estos perfiles?
En la mayoría de las organizaciones el criterio mínimo de aceptación continúa siendo la carrera o la universidad, la mala noticia es que estas disciplinas son muy nuevas y normalmente las universidades o casas de estudios no aseguran crear un profesional que cumpla la totalidad de las exigencias requeridas.
Debemos flexibilizar estas reglas para los perfiles profesionales, una de las opciones es considerar las certificaciones de proveedores tecnológicos, dado que algunas suelen exigir conocimientos que validan la experiencia o simplemente contratar personas con experiencia comprobada en el rubro que buscamos.
Recordar que estas tecnologías cambian rápidamente, por lo tanto, no porque contratemos a alguien que tenga 10 años de experiencia va a ser el mejor, contratemos por vocación y amor a lo que hacen.
Otra opción es considerar una prueba de ingreso, pero con cuidado… Si la prueba es la típica prueba teórica que se hace a todos por igual, mejor no hacerla.
Por el contrario si las pruebas de ingreso requieren un exceso de tiempo, habrá un gran número de aspirantes que no la darán porque pensarán que el trabajo no es lo suficientemente bueno, o incluso pensar que es peor a donde están…
También puedes utilizar metodologías de contratación como Facebook donde buscan personas que sean ninja, jedi y piratas, no obstante, siempre recuerda que el aspirante te debe seleccionar, no sólo tu a él.
En nuestra opinión, creemos que es mejor hacer una prueba distinta por cada rol buscado que incluya la solución de un problema real y que la resolución de la misma no sea mayor a un par de horas.
¿Cómo suelen estar conformados los equipos?
Durante los últimos años hemos observado organizaciones que sólo tienen ingenieros de datos, y éstos utilizan distintas estrategias para dividir su equipo y cumplir con las tareas requeridas, por ejemplo: rotar los roles especialistas o delegar tareas a otras áreas para cubrir las etapas de desarrollo y operación.
Estas estrategias pueden ser efectivas desde una perspectiva estratégica, pero, van a dañar considerablemente al equipo y aumentar la rotación de los mismos.
- División de equipo: división del equipo en 50/50, donde la mitad de ingenieros de datos desarrollan capacidades y el resto, opera y las utiliza. En este escenario el segundo equipo se verá desfavorecido y aumentará considerablemente su rotación, debido a que van a considerar que su trabajo es poco motivante y desafiante
- Rotación de equipo: 50% del equipo de ingeniería de datos desarrolla durante dos semanas, mientras la otra mitad opera, en las siguientes semanas se intercambian los roles. En este escenario ambos equipos se deterioran, dado que consideran que están haciendo más trabajo que el que son remunerados
- Delegación a otras áreas: normalmente el equipo de data delega al equipo de DevOps / SRE de IT. Lo cual aumenta el tiempo de salida al mercado, los costos y la complejidad, como consecuencia que IT y Data tienen distintos objetivos y metas, por lo tanto, aumentan los roces y se pierde la eficiencia
Entonces, ¿Cómo separo el desarrollo de la operación de datos?
Años atrás el software y los datos, se veían como mundos distintos e interoperables, dado que los datos eran tratados principalmente con componentes estructurales en vez con programación orientada a objetos y/o funcional.
En la actualidad, esto ha cambiado considerablemente, debido a la utilización de tecnologías y herramientas de procesamiento, generación de infraestructura y otras mediante código, por lo tanto, cada día vemos que el futuro es código.
Por tales razones, a medida que tus proyectos de datos escalan es imposible desplegarlos manualmente, por tal razón, es necesario automatizar cada despliegue para reducir tu time to market y sus riesgos inherentes.
Considerando esto, tenemos que tener en cuenta que los ingenieros de datos no podrán realizar una automatización 100% efectiva, por lo tanto, recomendamos utilizar perfiles especialistas que los apoyen, por ejemplo: Ingenieros DataOps y/o Ingenieros de confiabilidad.
Separando las tareas de operación con un ingeniero DataOps y un ingeniero Data Reliability, tendrán un ciclo de desarrollo más eficaz y eficiente.
En caso de no conseguir estos roles puedes trabajar con un DevOps en conjunto con tus ingenieros de datos y un SRE en conjunto con ingenieros de calidad de datos para definir estándares de disponibilidad y calidad de datos (SLI, SLA y SLO).
Teniendo todos estos puntos en cuenta ahora revisaremos qué tareas deberían realizar estos roles.
Actividades específicas por roles
Entonces, ¿Qué harán los ingenieros y arquitectos de software?
Este es un punto crucial para conseguir un equipo de alto desempeño, dado que normalmente las áreas de datos se enfocan en generar ETL o ELT que les permitan desarrollar activos de datos, pero olvidan diseñar arquitecturas altamente distribuidas y que solucionen la escalabilidad de los posibles casos de uso que podrían tener.
Por ejemplo, suele ocurrir que se generan distintas áreas de ingeniería de datos por etapas del ciclo de vida de los mismos, por ejemplo:
- Área de ingesta de datos
- Área de procesamiento y transformación
- Área de delivery de datos
- Entre otras.
Donde los costos suelen ser elevados, ya que tenemos especialistas en tareas de soporte.
Otra desventaja es que los especialistas pueden sentirse no valorados y dejaran su empleo por falta de desafíos.
Es por esto, que los ingenieros y arquitectos de software, tienen un rol fundamental para definir y diseñar una arquitectura de software que permita la escalabilidad de distintos casos de usos, de igual manera se recomienda que se incluya al ingeniero DataOps para tener una mirada complementaría en el mundo de los datos.
Algunos ejemplos de servicios que pueden ser desarrollados por estos integrantes son:
- Servicios de catálogo de datos
- Servicios de registro & discovery
- Servicios de movimiento de datos
- Servicios de data wrangling
- Servicios de operación de machine learning
- Entre otros
En el caso que no se cuente con presupuesto suficiente se puede excluir al arquitecto de software, pero se debe al menos con un ingeniero de desarrollo senior con conocimientos en arquitectura de software.
Entonces, ¿Qué harán los ingenieros de datos?
Los ingenieros de datos utilizan las piezas reutilizables (desarrolladas por los ingenieros y arquitectos de software) para desarrollar sus tareas sin preocuparse de lineamientos de tecnología, mantenibilidad del código y otras tareas que normalmente están fuera de su alcance.
Dependiendo de las necesidades que tengas y de la cantidad de desarrolladores de software que poseas puedes incorporar funcionalidades de gobierno de datos en los artefactos a utilizar por los ingenieros de datos.
Por lo tanto, se enfocarán en la generación y transformación de los activos de datos para que tengan un impacto para las áreas de negocio.
Adicionalmente los ingenieros de datos pueden trabajar continuamente con los ingenieros de operación de datos (DataOps) para construir conjuntamente procesos de datos que sean eficientes, rentables y mantenibles en el tiempo.
Entonces, ¿Qué harán los ingenieros de operación de datos?
Los ingenieros de operación de datos, deben definir y estandarizar las mejores prácticas de desarrollo, estandarizar el control de versiones y su despliegue en producción, proveer los mecanismos necesarios para el monitoreo y observabilidad de los procesos de datos.
En algunas empresas hemos visto que el Ingeniero DataOps es considerado un ingeniero de datos con conocimientos adicionales de operación.
Si bien pueden haber casos que se cumpla esa regla, sugerimos que el DataOps solo tenga tareas de operación y trabaje en conjunto con los ingenieros para tener un proyectos más costo / eficiente.
Por otro lado, con respecto al monitoreo y a la observabilidad de datos, normalmente se dejaba al DataOps realizando esta tarea, pero se observó que no se conseguían resultados rápidamente, por lo tanto se decidió separarlo en un nuevo rol que está 100% dedicado a dichas tareas.
El rol de monitoreo y observabilidad de datos fue llamado Data Reliability Engineering el cual tiene como objetivo asegurar la calidad, eficiencia y resiliencia de los procesos de datos para conseguir implícitamente que la calidad y consistencia de los datos mejore considerablemente.
¿Si tengo perfiles de software, entonces cuántos ingenieros de datos debería tener?
Cómo hemos conversado en este y otros artículos, los ingenieros de datos no van a solucionar todos tus problemas de datos, por lo tanto, es importante diversificar los roles en tu equipo.
La cantidad de ingenieros de datos y desarrolladores de software dependerá de la cantidad de requerimientos que tengas del negocio y las capacidades que requieras.
Por ejemplo, si estás comenzando como área, te sugerimos una relación de 2:1, esto quiere decir 2 desarrolladores y 1 ingeniero, a medida que vayan aumentando los requerimientos de parte del negocio la razón debería aumentar por el lado de los ingenieros.
¿Cuántos ingenieros de operación de datos debería tener por ingeniero de datos?
Como hemos observado los ingenieros de operación de datos son un apoyo a los ingenieros de datos, por lo tanto, se recomienda que su relación sea de 1:3, esto quiere decir que un ingeniero de operación vs tres ingenieros de datos. Con un máximo de 5 ingenieros para equipos grandes.
Tal como el caso anterior, esto dependerá en gran medida como vayan aumentando los requerimientos y a la velocidad esperada por el negocio.
¿Qué pasa si no tengo los perfiles requeridos y tampoco el presupuesto suficiente?
En el caso que no poseas los perfiles mencionados, hay alternativas que puedes tomar, para seguir siendo eficiente.
- Promueve el trabajo colaborativo con otras áreas para recibir apoyo temporal de algunos perfiles (principalmente ingenieros y arquitectos de software)
- Si en mi organización no tenemos los perfiles, ¿puedo externalizar?
- Si, puedes externalizar, no obstante, te recomendamos que los ingenieros de datos sean internos, dado que trabajan con la lógica de tu negocio
- En el caso que no tengas el presupuesto suficiente, puedes generar planes de carrera e ir entrenando personas desde el mundo del software a datos, por ejemplo, un desarrollador de software podría convertirse en un ingeniero de datos y un DevOps podría convertirse en un DataOps
¿Quieres acelerar tus desarrollos?
Si te gusto este blog y quieres implementarlo en tu compañía no dudes en revisar nuestro servicio de Data Reliability.
¡QUIERO SABER MÁS!