HISTORIAS DE DATA SCIENCE — UN LUGAR PARA APRENDER, CON UN TOQUE PERSONAL.

Científico de Datos “Full Stack”… o no

De la cima al suelo en una entrevista de una hora

Después de participar en investigación en Mejoramiento Animal y Genómica Humana durante un par de años, y habiendo trabajado como administrativo por doce años en la carrera de Ingeniería en Sistemas de Información (lo cual me dio acceso directo a muchos libros y otros recursos de aprendizaje), finalmente estaba listo para alistar mi CV para Ciencia de Datos. Sabía que estaba dejando mi zona de comfort pero, hey, el que no arriesga, no gana. Durante un par de meses aplique a todas las ofertas laborales que pude encontrar, tanto remotas como locales. Sabía que estaban evaluando mi perfil (gracias LinkedIn), pero no recibí ninguna llamada. Consulté a un par de reclutadores, y ellos fueron lo suficientemente amables como para decirme que la distancia entre mis estudios académicos y la posición laboral hacían difícil el recomendarme. Quedé muy frustrado.

Intentando restarle importancia, comencé a planear cómo acortar la brecha, y decidí comenzar un doctorado en el área. Supuse que el tema del título era un conflicto de la industria, y que en el mundo académico las cosas serían más razonables. Sí, demasiado inocente.
Trabaje con mi director de investigación e hicimos una Propuesta de Tesis para un Doctorado en Ingeniería en Sistemas de Información. Para resumir, dijeron que mi propuesta era fantástica, y que encajaba a la perfección… pero era veterinario. Por supuesto, quedé mucho más frustrado.

Photo by Tim Gouw on Unsplash. Así me veía en ese entonces.

Deje de intentar entrar en el campo, al menos por un tiempo. Me enfoqué en comenzar mi doctorado (ahora en Bioquímica), comencé a dictar clases en la Universidad e intenté que mi frustración se fuera, de a poco. Continué estudiando, tomando cursos de postgrado en computación paralela, redes neurales y otros temas similares.

Un año más tarde, alguien me contacto por LinkedIn, preguntando si estaba abierto a nuevas oportunidades laborales. Tatiana había visto mi perfil, siguió leyendo aún luego de ver mi título, y pensaba que podía aplicar para la posición que estaban buscando. Aún hoy no sé si pude esconder mi ansidedad y mi felicidad. Tuvimos un par de entrevistas telefónicas y luego ella arregló una reunión con el Líder de Innovación de la empresa.

Supongo que muchos de ustedes pueden identificarse con este tipo de situación. La cosa es que no estaba tan nervioso como debería haber estado. Había decidido que iba a mostrar quien era y lo que sabía. Y pasara lo que pasara, sería para mejor. Así fue que llegué a conocer a Marcelo. Es una persona destacable, con una energía contagiosa. El tipo de persona con la que te entusiasma trabajar, o al menos ese fue mi caso.

Hablamos de varias cosas. Me contó sobre la compañía, cómo gestionaban los proyectos de Ciencia de Datos, qué aspectos valoraban en un equipo y cuáles eran los roles de esos equipos. Y aquí es donde me quiero detener porque, en ese momento, no termine de entender completamente la función de cada miembro. Es por esto que, en este artículo, comentaré sobre qué pensaba en ese momento, y cuán equivocado estaba.

El Ingeniero de Datos:

Durante la entrevista: Este fue uno de los roles que descubrí durante la entrevista. Habiendo trabajado en proyectos individuales la mayoría de las veces, yo hacía todo la limpieza y organización de los datos. Así que cuando me enteré que existía un rol específico para dicha tarea, estaba un poco confundido. Por un lado, tendría más tiempo para jugar con los modelos, las features y los parámetros pero, por otro lado, sentía que perdería el control sobre el manejo y preprocesamiento de los datos crudos, tema vital en la ciencia de datos.
Vida Real: Los ingenieros de datos son los que la tienen clara, muy clara. No es sólo organizar y limpiar datos (cualquiera puede hacer eso). Ellos realmente entienden cuál es la mejor forma de entregar los datos, tanto en relación a la infraestructura como a los datos en sí mismos. Saben cuándo utilizar índicies, claves primarias y secundarias, ordenamientos personalizados, y son un diccionario SQL andante. Además, puede obtener datos de cualquier fuente, bases de datos relacionales y no relacionales, locales y remotas, archivos de cualquier tipo, imágenes, sonido, IoT, APIs, y cualquier otra sigla que se les pueda ocurrir. Manejan tecnologías con nombres extraños como NiFi, glue, lambda y otras. Pueden contestar prácticamente cualquier cosa sobre los datos, y también saben que tipo de datos se necesita para machine learning, deep learning o sólo para usar en reglas de negocio. Son los constructores de los Grandes Datos, y tienen uno de los roles de mayor importancia — sino es el más importante — necesarios para el proceso de migración de un negocio al mundo digital. Son increíbles.

El Científico de Datos:
Durante la entrevista: Hey, éste lo conozco, pense. Este rol, de hecho, es el más conocido del área. Es el encargado de que las computadoras “aprendan”. Esta a cargo de todo — bueno, así pensaba entonces. Pero escubrí durante la entrevista que ya no haría el preprocesamiento. Así que mi trabajo sería más simple de lo que pensé. Solo conocer mis matemáticas, entender mis modelos y optimizar todo para obtener el mejor resultado posible.

“Los Grandes Datos no tienen que ver con los datos” — Gary King, Harvard University. Explicando que obtener muchos datos es fácil, pero que el valor real está en la analítica.

Vida Real: Los ingenieros de datos también son llamados plomeros de datos. Su rol es vital, pero frecuentemente no los notan. Los científicos, por otro lado, son los que hacen que un proyecto sea exitoso o no. No hay areas grises acá, un proyecto puede ir increíblemente bien, o fallar estrepitósamente. Y el culpable es el científico. Éste es el rol encargado de brindar nuevo valor al negocio. Ya sea que se busque ayudar en la toma de decisiones a través de modelos predictivos, o utilizar tecnologías modernas para automatizar u optimizar un proceso, ésta es la etapa en la que realmente se puede determinar si un proyecto llegará a algo útil o no. En relación al código propiamente dicho, este rol no es necesariamente el más hábil, ni el más limpio. Los Jupyter Notebooks suelen ser un desastre, con muchas idas y vueltas para hacer pruebas. Sólo limpiamos el código cuando va a ir a producción, y eso está muy mal, por muchas razones. Hay una necesidad real de “Buenas Prácticas de Ingeniería de Software para Científicos de Datos”, y es un fenómeno que lentamente está comenzando a suceder. Los científicos de datos, sin embargo, sí tienen que entender qué sucede detrás de esas librerías “mágicas”. ¿Cuál es la matemática detras, cuándo y por qué debería usar este o aquel modelo? ¿Cómo debería manejar valores nulos o extremos, eliminarlos o imputarlos? Los científicos además deben introducirse en el dominio de negocio. Esto es obligatorio. De lo contrario, no podrán entender cómo empoderar al negocio y qué puede hacerse para desarrollar estas poderosas herramientas de gestión, y todo el esfuerzo realizado será en vano.

El Dev Ops / Data Ops:
Durante la entrevista: Otro rol nuevo. El término Dev Ops no me era desconocido, si bien no tenía claro exactamente qué hacía uno. Pero el poco conocimiento que tenía no era erróneo. Están a cargo de fijar el entorno de desarrollo, testing y producción y de resolver cualquier asunto relacionado a la infraestructura y la comunicación entre los diversos procesos de desarrollo. Una vez más, en mi rol académico en un área poco amigable con la informática, había trabajado como gestor de la configuración en varios proyectos, tanto desde el punto de vista del hardware como del software, por lo que no vi demasiada complejidad en este rol. Ja!
Vida Real: Este es uno de los roles más anónimos, junto al ingeniero de datos, uno de los que más pasan desapercibidos. También es, en mi opinión, el más difícil de caracterizar, y seguramente fallaré al hacerlo. DataOps deriva, obviamente, del DevOps, pero no es una simple aplicación de las mismas metodologías y filosofías al entorno de Datos. En cambio, el Data Ops es el “join” de todos los procesos de Ciencia de Datos, y también hace las veces de orquestador de las entradas y salidas de los distintos roles. Es el encargado de crear un entorno en el que los científicos de datos puedan trabajar de forma cómoda y fácil, con todos los lenguajes y librerías que nos gustan. Además conoce cómo comunicar todo el trabajo realizado por los ingenieros de datos a los científicos de datos. Finalmente, son los arquitectos que diseñan la mejor forma para implementar los modelos en producción, y levantan los entornos necesarios para dicha implementación. Por todo esto, los DataOps deben conocer la esencia de cada rol, para poder facilitar las tareas llevadas a cabo.

“A veces, las cosas más comunes pueden convertirse en extraordinarias, simplemente por hacerlas con la gente indicada”— Nicholas Sparks

El Desarrollador:
Durante la entrevista: Ok, éste estaba bastante claro. Es quien recibe el modelo y lo pone en producción, tal vez con una API, una web app o algún otro desarrollo de software. Personalmente, ya había desarrollado aplicaciones con backend en python y frontend en shiny, que estaban (y aún están) siendo usadas. El desarrollo es algo que siempre me entusiasmo, aún considerando que todavía no me llevo bien con Javascript y, por lo tanto, no soy muy bueno haciendo front end.
Real Life: Desde el inicio este fue el rol más claro. El desarrollador es aquel que desarrolla (duh!) la aplicación que será utilizada por los analistas o la gestión, utilizando los modelos creados por el científico y los datos procesados por el ingeniero. Aún si este es un rol importante, usualmente es llevado a cabo por equipos externos. No es un rol inherente a la ciencia de datos en el sentido que no tiene que conocer ni los datos ni los modelos. Sin embargo, si alguien del equipo asume este rol, la solución final será mucho más robusta y aprovechable para el negocio. Esto se debe a que tener el conocimiento del dominio relacionado al negocio de datos permite que el desarrollador entienda la forma más amigable y útil de exponer estos datos a analistas.

El Analista de negocios:
Durante la entrevista: La verdad, ni siquiera había pensado en este rol. En el mundo académico, las visualizaciones se hacen pensando en publicaciones científicas, y son bastante básicas. No tienen interactividad, ni se actualizan automáticamente… sólo son gráficos planos. Sin embargo, este rol tiene mucho sentido al trabajar en el ámbito de negocios. Además, era una cosa menos por la que preocuparse, ya que sería otro el que resuma la información.
Vida Real: Los analistas son artistas de la información. Reciben una tabla de datos y la transforman en cosas hermosas. No es una tarea sencilla, tienen que entender cómo resumir toda la información valiosa que reciben, conocer profundamente el negocio del cliente. Y tienen que elegir las mejores formas de mostrar esa información, no sólo seleccionando el mejor gráfico o tabla, sino también “lograr que venda”. El equipo de Inteligencia de Negocios es, en mi opinión, el que consigue la venta en una empresa de datos. También ayudan a darle forma a la salida de los procesos, ya que serán los consumidores de la misma. Ellos crean las herramientas para conquistar esas difíciles reuniones con los clientes, creando gráficos increíbles en tiempo real de los cuales podemos presumir.

Los Jefes

El Lider de Proyecto:
Durante la entrevista: Jefe número 1, o eso es lo que pensaba. Aunque mi líder me lo explicó de una forma más amigable, entendí que era la persona que nos pondría la suficiente presión como para alcanzar las metas a tiempo. Debía conocer cuánto tiempo me llevaría cada tarea, y me recordaría cuando estuviera atrasado. Sin embargo, este fue uno de los roles en los que más me equivoque.

Vida Real: Este es difícil de explicar, porque se quien lo va a leer. Para ser honesto, el líder de proyecto tiene una gran responsabilidad. Esta a cargo de asegurarse que los proyectos cumplan los plazos. Ese es un trabajo realmente complejo en cualquier disciplina de software, pero se vuelve extremadamente complejo en ciencia de datos. El método científico es, inherentemente, atemporal. Es un proceso creativo y, como tal, se muestra complicado para estructurar y evaluar. ¿Cómo puntuar la productividad de un equipo que no puede darte plazos estimados hasta que ha superado las fases iniciales, y cómo calificas un modelo que puede no resultar útil, pero cuyo proceso se llevó a cabo de forma brillante? Aún peor, el Líder de Proyecto tiene otra responsabilidad, aunque muchas veces no se ve. Un buen ambiente de trabajo, la motivación y “felicidad” del equipo dependen, en mi opinión, por lo menos un 65% del líder. Un buen líder de proyecto puede mantener un ambiente de trabajo divertido y agradable, y mantener la moral de los colaboradores aún cuando un proyecto falla. Se considera a sí mismo uno más del equipo, pero es el primero en defender ese equipo ante clientes irracionales o abusivos. En cambio, un mal líder de proyecto puede hacer que el trabajo en equipo se vuelva un experiencia muy desagradable, gestionando mal los tiempos, eligiendo culpables e intentando llevarse los méritos en los proyectos que salen bien. He vivido ambos tipos de líderes y, en mi opinión, el rol del Líder, en ciencia de datos y en todas las demás disciplinas, debe ser seleccionado con extremo cuidado, tomando especial consideración en las habilidades blandas y el tipo de persona que es candidato.

El Product Owner:
Durante la entrevista: Jefe número 2. Acá estuve taan equivocado, de nuevo. Me imagine que este rol lo realizaba el cliente, es decir, una persona que siempre quiere el trabajo hecho con la mayor funcionalidad en el menor tiempo y pagando la menor cantidad posible. Tal vez no era el que presionaba con el tiempo, pero quien evaluaría los resultados. Nunca imagine el valor real de este colaborador durante la entrevista. En cambio, lo vi más como un obstáculo.
Vida Real: Este es, sin lugar a dudas, el rol externo más útil para el proceso de ciencia de datos. El Product Owner entiende la generalidad del proceso, pero viene desde el dominio del negocio. Puede detectar las necesidades del cliente aún antes de que el cliente la conozca. Y es un gran comunicador, pudiendo traducir el lenguaje de negocio a los científicos, y vicecersa. He estado en proyectos que no tenían product owner, otros en los que el product owner no estaba comprometido con el resultado, y finalmente trabaje con muy buenos product owners, que estaban realmente comprometidos, y puedo decir que hay una gran diferencia en el proceso de ciencia de datos. Cada entregable es mucho mejor — por lo que el producto final también lo es — cuando el product owner existe y es fácilmente accesible.

El Unicornio Dorado — Científico de Datos Full Stack

Entonces, cuando me fui de mi primer entrevista, estaba confiado de ser un científico full stack (no experimentado, pero creía saber de todo). Para aquellos que no estén familiarizados con el término, viene desde el desarrollo web y se refiere al programador que sabe hacer el backend (la parte lógica de una aplicación) y el frontend (la interfaz de usuario). Pensaba que podría tomar cualquier rol en el proceso de ciencia de datos, sin demasiadas dificultades. Sólo necesitaba aprender un par de tecnologías, pero entendía cada paso del proceso y los había llevado a cabo durante mis investigaciones. ¡Ja! No hay unicornios en la vida real, y los dorados son especialmente raros. Cada rol tiene sus particularidades y cada miembro maneja un enorme conjunto de conocimientos y habilidades. Si bien todo esto es cierto, estoy seguro que comenzaremos a ver ofertas laborales en búsqueda de científicos de datos full stack cada vez más frecuentementes. Ya paso en otras áreas, y seguro pasará de nuevo.
De todas formas, no creo que la búsqueda esté completamente errada. Por mi parte, seguiré buscando alcanzar ese mágico conocimiento. Probablemente tendré un conocimiento más profundo de uno o dos roles, pero la gente con conocimiento global de los procesos de ciencia de datos son extremadamente valiosos. Una persona que pueda tomar cualquier rol, aún sin ser el mejor en ese rubro, toma una gran importancia en un campo como este, que evoluciona constantemente. Esta capacidad, inclusive, habla de la resiliencia y adaptabilidad de una persona, las cuales son, en mi opinión, las habilidades blandas más importantes en nuestro campo. Pero escribiré sobre eso en futuros artículos.

Quiero agradecer a Tatiana, Marcelo, Leandro y Mauricio por darme la oportunidad de demostrar lo que puedo hacer, y a todos en mi equipo y en toda la empresa por mantener un increíble ambiente de trabajo.