De la misma manera que el evento que propició la creación de esta serie de entradas, otro evento similar ocurrió recientemente. Recorriendo la sucesión de situaciones, incidentes y actividades en orden cronológico inverso, puedo ver que otra vez, esta manía de actuar como lemmings, aparece. Este es el relato, en orden cronológico.

El equipo de desarrollo (científicos de datos en este caso), se avoca a revisar lo que el cliente nos proporciona como fuentes de datos: documentos (muchos libros de Excel), PDFs, archivos, reportes y el lago de datos. Se trata de un proyecto para crear ocho modelos predictivos.

Sin embargo, se trata de un proyecto mal planteado por parte del cliente, mal comprado por mi empleador y mucho más mal concebido por quien toma el rol de líder de proyecto en su inicio (de quien estoy casi seguro que en un breve párrafo le preguntó a Microsoft Copilot «¿cuál sería el plan de trabajo para un proyecto de ciencia de datos?» y así armó su plan de trabajo, sin saber siquiera en lo que se metía).

Adicionalmente (y para empeorar las cosas), el cliente dice que «tiene todo», pero no es así. Su proceso de adquisición de datos está en desarrollo, su lago de datos es una mera «charca», su área de IT no tiene mucha idea de los procesos que busca predecir (ninguno de los cuales está automatizado) y todo se lleva a cabo con hojas de Excel,… libros de Excel, complejos libros de Excel que llegan a tener hasta 37 pestañas, con macros, fórmulas de todo tipo y que son parte de un flujo de trabajo manual (y aún así el cliente es una empresa que mueve milles de millones de dólares al año, con miles de empleados trabajando en forma remota) por todo el planeta.

El primer problema surge cuando, desde el entorno de Microsoft Azure para machine learning, no se puede acceder a las tablas de Fabric. Sí, desde Fabric se puede revisar el contenido de las tablas, hacer queries y crear algunos notebooks, pero las instrucciones son claras: uno debe trabajar en Azure ML Studio (que está «del nabo»). Se reporta el problema, pasa el tiempo y otras prioridades se imponen (principalmente aquellas «administrativas»; las de los administradores y líderes de proyecto que buscan justificar su chamba). Con el tiempo se da una solución (de sólo lectura) para poder hacerlo, pero la solución no permite acceder a los archivos en ese lago de datos y realmente las tablas no sirven de mucho; todo lo que se necesita está en archivos aún.

Nuevamente, pasa el tiempo, hay presiones por demostrar que se está avanzando y se «hacen demos» para demostrarlo. Se invierte tiempo en «demostrar que se avanza» en lugar de avanzar. Un esfuerzo planificado para seis semanas debe demostrarse en una sola.

Finalmente, se alcanza un momento en el que el acceso a los archivos, donde están los datos que nos permitirían entrenar modelos de aprendizaje automático, pero que ahora son necesarios al menos para validar los simples sistemas de recomendación basados en reglas (que es a lo que se ha llegado ante la falta de datos), es algo que bloquea el avance del proyecto. El cliente trabaja en resolver el problema de las fuentes de datos y también en su acceso. Le toma varios días de examinación sin saber qué puede haber de malo en el workspace en el que hemos venido trabajando. La respuesta es improvisada, parcial y hecha por excepción, dando privilegios de más a sólo una persona y solicitando que para el resto se levante un ticket. La solución es de sólo lectura.

Poco después, nos enteramos de que el acceso a ese workspace en Fabric (por ser «gold«, siguiendo el esquema Medallion popularizado por Databricks) es sólo read-only. Pese a insistencias por semanas de querer tener acceso read-write, el cliente no repara en que eso no es posible por diseño: nadie (salvo los procesos de actualización) debe poder escribir en él. Es el momento en el que se redescubre aquel workspace en el que se supone que debemos enviar las salidas de los modelos.