- Tags:: #✍️OwnPosts , [[Qué hago trabajando con datos en vez de estar zurriendo mierdas con un látigo]] - Date:: [[2024-10-12]] ![[IMG_4391.jpeg|300]] Esta semana he estado en el [Festival Internacional de Cinema Fantàstic de Catalunya](https://sitgesfilmfestival.com/es) y además de ver al Señor Fring en persona, he podido sacar esta reflexión a ratillos con el móvil (apologies si algo está un poco funky). **No estoy a gusto con mi profesión todavía**. Iba a decir que mi relación con ella es amor/odio, pero no, la amo. Lo que odio es LaGente™️. Me sorprende de mi mismo que cuando preparé [[✍️ Ser data-driven no es de guapas]], "la charla en la que el ponente puede abandonar su carrera profesional", me lo dejara fuera. **No he visto equipo de Data bien considerado en una compañía ever.** Me lo tomaría a lo personal, podría pensar que soy el papel del culo (de hecho en parte lo pienso, creo que tengo campo para correr), pero afortunadamente, una vez más, me salva la literatura: todos los libros (¡incluso técnicos!) que tocan analytics/science tienen una parte de autoayuda, "tolerancia a la frustración", "lidiar con los stakeholders"... Si le pasa a gente que es más lista y no es de Cartagena como yo... qué te cabe esperar. Trabajar con gente, relacionarse con otros seres humanos, no os descubro nada, es una experiencia terrorífica. [[🦜 El infierno son los Demás]], que diría [[Jean-Paul Sartre]]. PERO, trabajar con datos y gente es un dolor: es **la piedra de Sísifo de la gestión de expectativas**. "Gestión de expectativas" es el eufemismo de tener que aguantar injustos aguijonazos del personal. Ojo, no es que la gente sea malvada—solo hay un buen número de personas desagradables porque es su manera de gestionar sus inseguridades y/o tienen un Asperger sin diagnosticar, muy común en tecnología—es que trabajar con datos está lleno de esquinas puntiagudas. Los datos tienen una apariencia de familiaridad (quien más y quien menos ha hecho cuatro sumas en un Excel, hemos dado Cálculo y algo de stats), pero luego tienen muchas más aristas de las que parece. Esto es, los datos tienen bastantes "false friends". Recordatorio de cuando estudiasteis inglés: un "false friend" es una palabra en el idioma que estás aprendiendo que se parece a una de tu idioma nativo pero el significado no tiene ná que ver. E.g., "fabric" no significa "fábrica", significa "tela". Pues con los datos igual. Como dice [[Charles Wheelan]] en [[📖 Naked Statistics]]: ![[📖 Naked Statistics#^a47979]] ## Omnisciencia del tracking Da un poco igual la [[Data methodology|metodología]] que uses, encontramos falsos amigos en múltiples fases de un análisis. Empezamos por el planteamiento de una cuestión a resolver con datos: la mayor parte de las veces, cuesta mucho más hacer algo de lo que parece. Vamos, el meme de "pull up a number real fast" (ver [[🗣️ Breaking Your Data Team Out of the Service Trap]]) ![[🗣️ Breaking Your Data Team Out of the Service Trap#^df8638]] Que vale, sí, todos los campos tienen sus movidas... pero en otros campos (adyacentes) siento que la gente con la que colaboras intuye que hay "curvas cerradas" y suspenden más su juicio algo más acerca de lo que cuesta hacer algo. Así pasa en ingeniera de software por ejemplo. A pesar de que inicialmente un stakeholder pueda no tener claro cuánto trabajo lleva implementar una feature, como en el mítico XKCD... ![[IMG_4407.png|300]] ...siento que respuestas como ésta se aceptan (un poco) mejor, porque no hay tanta familiaridad con ingeniería. Aunque, como apunta [[Simon Willison]] en [[XKCD 1425 (Tasks) Turns Ten Years Old Today]], con los [[Foundation models]] lo mismo vuelven a la época oscura. Sin embargo, en Data, de alguna manera, cuando alguien piensa en una cuestión a responder con datos, da por hecho una suerte de "omnisciencia del tracking": como si se estuviera capturando y modelando absolutamente todo para contestar cualquier cuestión. Un ejemplo de [[Freepik]]: "¿cuánta gente se descarga una imagen después de editarla con IA?". Parece una pregunta inocente, pero: 1) ¿Desde cuántos sitios podemos llevarnos una imagen a edición? (ahora mismo por lo menos 3 caminos distintos, across 6-7 herramientas), 2) ¿Tenemos esas acciones trackeadas correctamente? 3)¿Cuando luego hacemos la descarga desde el editor... tenemos asociados los IDs de las imágenes que forman parte de esa creación? Etc., etc., etc. ¿Se ve el pifostio técnico que hay detrás de esta pregunta vs. lo inocente que parece? Para responder a esta cuestión, hay que tener MUCHAS cosas ya bien puestas. Por desgracia, que no se perciba la necesidad de esta precondición (y la idea de que sin esfuerzo, no ocurre mágicamente), no solo se traduce en stakeholders frustrados por lo que se tarda en responder "una sencilla pregunta", si no que es un trabajo que no se prioriza en el seno de la organización. En [[Get Me Out of Data Hell]], el autor (ingeniero de datos en Australia, internet personality), dice: ![[Get Me Out of Data Hell#^40551a]] Yo no creo que la organización valore menos ese trabajo. Creo que en Data simplemente ni se ve. Pero las consecuencias de no realizarlo sí, y no se conectan los puntos. Para más inri, se asume la responsabilidad de la calidad sobre el equipo de Data que, salvo que tengas una topología perfecta con roles de data embebidos en los equipos que desarrollan producto (ver [[Data team topologies]]), no es el que produce datos en primera instancia (solo derivados). El equipo de Data solo se puede defender ya muy tarde en el pipeline, con movidas que funcionan regulín, como test de anomalías, cuando lo verdaderamente efectivo sería hacerse cargo integrado en el ciclo de desarrollo de producto, con, por ejemplo, tests unitarios sobre los eventos que generas. ¿Quién debería ser responsable de la correcta producción y recogida de datos? Pues lo dicho: el mismo equipo que desarrolla producto. Pero es que ese equipo también es presionado por la organización para sacar cosas rapidito y dejar de lado todo lo no esencial... y en este punto, curiosamente, medir correctamente no es considerado esencial. So much for the Build-Measure-Learn loop! ![[The Lean Startup#^50ae18]] ## Las preguntas lo aguantan todo Las preguntas a resolver con daros normalmente tampoco llegan así. Llegan en una forma aún más inocente y peligrosa. En el caso anterior, llegaría en la siguiente forma: "¿cómo descarga la gente?". Esto así es incontestable: ¿qué contamos como descarga? Ese "cómo", ¿qué nos interesa?¿Frecuencia? ¿Intensidad? ¿Cuándo fue la ultima vez? Es decir, el primer bastión de frustación es que resulta muy fácil hacer preguntas genéricas con muchos gaps de indefinición pero responderlas requiere detalle extremo... y eso solo lo ves si te pones a buscar la respuesta tu. Esto dice mi guía espiritual [[Benn Stancil]]: ![[🗞️ The missing piece of the modern data stack#^6a03e0]] Que es literalmente por lo que los LLMs no van a ser la panacea ([[✍️ GPT-3 me va a quitar el trabajo, pero yo tengo que estar entrenando algoritmia de bajo nivel#En cuanto al GPT-3 y/o el no-code... nada nuevo.]].). ## Las chachas de los datos Hay una variante peor (en resultados y en el desprecio que supone) de esto, que es que en lugar de buscar colaboración con los roles de Data, un stakeholder llegue con "quiero estos datos" pero no quiera compartir contexto de para qué. Las razones os las podéis imaginar, no hay ninguna buena. Pero no esto lo que me interesa. Normalmente se argumenta con un triste "se pierde tiempo en dar ese contexto", pero es que literalmente este trabajo es todo contexto. Incluso si nos centramos solo en obtener datos, para tomar todas las decisiones que hemos visto antes, lo necesitas. Pero la historia tampoco es esta. Vamos al tercer bastión de la frustración: la interpretación incorrecta. ¿Cómo necesitas sumarizar los datos para responder a la cuestión? Porque es muy fácil meter la pata aquí también. Y es curioso, porque por desgracia algo ha entrado en el acervo popular: [Seis gráficos manipulados en las televisiones españolas](https://www.eldiario.es/economia/graficos-manipulados-television_1_2554476.html). Hay muchísimas referencias de "pitfalls" en el análisis de datos, tanto técnicas ([[📖 Probably Overthinking It]]), como de pueblo llano ([[📖 Bullshit. Contra la charlatanería]]). No pretendo hacer aquí un listado exhaustivo, pero por citar algunas muy frecuentes: - Intentar sumarizar cualquier métrica sin tener alguna idea de la distribución que hay debajo. La gente tiende a pensar (sin pensarlo explícitamente) que todo es una distribución normal. Lo más habitual en realidad en plataformas como la nuestra son unas distribuciones sesgadas con unos long tails gigantescos. Si pretendes entender, por ejemplo, como descargan tus usuarios a lo largo de sus primeros días de subscripción y crees que lo suyo es verlo con la media... pues error: la media está influenciada mucho más por un segmento pequeño de tus usuarios. [[Vicki Boykis]], una grande, lo explica perfectamente en [[The ghosts in the data]]: ![[The ghosts in the data#^906081]] - Muy íntimamente ligada a la anterior, intentar sumarizar conversion rates / tiempo hasta conversión desde primera visita (sea por cohorte o no): las conversiones tienen un delay que también es una cola larga (ver [[Conversion Rates – You Are (Most Likely) Computing Them Wrong]]). - La mítica [[Simpsons paradox|Paradoja de Simpson]] cuando quieres entender por qué varía un KPI. E.g., baja la conversión. Descompones en mobile y web y resulta que tu conversión mejora en las dos... ¡Los datos están mal! No, es que has tenido un mix shift: mobile convierte peor que web y aunque haya mejorado, has tenido más tráfico mobile que web (ver [[Answering Why Did the KPI Change Using Decomposition]]). Estas tres fuentes de frustración hay que comérselas además en múltiples iteraciones. Es difícil de antemano saber qué vas buscando y a medida que te vas encontrando, vas teniendo más preguntas. Es por todo esto que tener roles de Data como chachas de los datos no funciona (ver [[Algunas Claves Y Herramientas Para Crear Una Cultura Organizativa Basada en Datos]]). ## ¿A dónde vas a parar con esto, criatura? Con esto no quiero decir que para trabajar con datos hace falta pasar por las manos de especialistas y así justificar mi profesión. Primero porque no lo pienso, al igual que [[Vaclav Smil]] en [[📖 Numbers don't lie]]: ![[📖 Numbers don't lie#^095145]] ![[📖 Numbers don't lie#^765837]] Pero ojo, hay que ponerse. Ni siquiera en carreras técnicas diría que uno llega al mundo laboral con ese basic scientific literacy and numeracy. Segundo, porque se me ocurren cosas más interesantes que hacer con mi tiempo que contestar preguntas básicas. Antes que ver con qué frecuencia descarga un usuario, prefiero segmentarlos por comportamiento en nuestra plataforma, por ejemplo. No espero que otros roles lleguen a hacer este tipo de historias. Y tercero, porque [[✍️ Déjame sin trabajo, por favor|no me duele señalar cuando mi trabajo es bullshit]]: soy curioso y trabajador, confío en mi como para buscar alternativas para ganarme el pan. Con las ganas que tengo de abrirme un OnlyFans bien guarro. ^1ba7a6 A lo que sí voy es a que se me está haciendo bola. No me importa la dificultad sistémica (me estimula) y no me importa tampoco lo prosaico del asunto a veces (como rebuscar en la basura en versión digital).Pero, aunque vengo validado de casa, éste hacer de receptáculo de decepción y desprecios por expectativas desmedidas se me hace complicado de encajar. ![[📖 Piénsalo otra vez#^9f9ba5]] Podría tirar de resiliencia, pero ¿por qué jugar la partida en modo hard, cuando hay modos easy? No sería la primera vez que cambio el modo de dificultad a mitad ([[✍️ Acho. Qué has estado haciendo estos últimos tres años. (2015)]]).