Lo que entendí sobre responsabilidad al dejar la consultoría
La migración a GA4 como el ejemplo perfecto donde todos hicieron su trabajo y nadie hizo el proyecto
Hubo un tiempo en mi vida que Kafka era mi obsesión. Me leí todo lo que ese hombre había escrito, sin pestañear un segundo. Aunque nunca tuvieran final, aunque fueran relatos incomprensibles. Lo que me hacía (y hace) sentir su imaginación es algo que todavía no he podido comparar con nada. Uno de los relatos que más se quedó en mi cabeza se llama “Ante la ley” y va así: un hombre del campo llega ante la puerta de la Ley, donde hay un guardián. El hombre pide permiso para entrar. El guardián le dice que no puede dejarlo pasar ahora, pero que tal vez más adelante sí. “Puedes intentar entrar a pesar de mi prohibición,” añade el guardián, “pero debes saber que soy poderoso. Y soy apenas el primero de muchos guardianes, cada uno más poderoso que el anterior.”
Así que el hombre espera. Días al principio, luego meses, luego años. Intenta sobornar al guardián, quien acepta los sobornos pero le dice que solo los acepta para que el hombre no sienta que dejó algo sin intentar. El hombre envejece esperando frente a esa puerta. Estudia al guardián durante años, aprende hasta el último detalle de su apariencia, hasta llega a conocer a las pulgas de su cuello. Pero nunca cruza la puerta.
Al final de su vida, ya muriendo, el hombre le hace al guardián una pregunta que nunca antes se había atrevido a hacer: “Todos se esfuerzan por llegar a la Ley, ¿cómo es posible que durante tantos años nadie más que yo haya pedido entrar?” El guardián se da cuenta de que el hombre está llegando a su fin, y para que sus sentidos debilitados puedan oír, le grita: “Nadie más podía entrar por aquí, porque esta entrada estaba destinada solo para ti. Ahora voy a cerrarla.”
La primera vez que lo leí me pareció una parábola sobre burocracia absurda, sobre sistemas kafkianos que te atrapan en procesos sin fin. Pero cada vez que vuelvo a él, lo que me perturba más no es el guardián ni el sistema abstracto de la Ley, es el hombre. Porque el guardián nunca le prohibió explícitamente entrar. Le advirtió, le dijo que no era aconsejable, pero también le dijo “puedes intentar entrar a pesar de mi prohibición.” La puerta, aparentemente, siempre estuvo abierta. El hombre pasó toda su vida esperando un permiso que nadie tenía realmente la autoridad de darle, esperando que alguien más tomara la responsabilidad de una decisión que solo él podía tomar.
Y reconozco esa dinámica de forma casi dolorosa cada vez que pienso en cómo funcionan los proyectos de consultoría (ojo al giro que nadie se esperaba!), específicamente en migraciones forzadas como la que ocurrió con Universal Analytics a GA4 (y que hoy usaremos como hilo conductor). Todos esperando que alguien más tome la decisión de rediseñar en lugar de simplemente migrar, todos asumiendo que hay algún guardián, alguna autoridad externa que tiene que dar permiso para hacer las cosas bien en lugar de solo hacer las cosas rápido. Y mientras todos esperan, mientras cada actor espera que otro actor tome la responsabilidad que cae justo fuera de su alcance definido, el tiempo pasa, la ventana se cierra, y eventualmente es demasiado tarde para hacer otra cosa que no sea la traducción literal que todos sabían que no era óptima pero que nadie se sentía autorizado a rechazar.
El problema no es la gente, es que nadie es responsable de las consecuencias
Cuando trabajas en consultoría, tu responsabilidad termina en un punto muy específico y claramente definido: la entrega del proyecto. Has cumplido tu responsabilidad si entregaste lo que el documento de alcance decía que ibas a entregar, dentro del tiempo acordado, dentro del presupuesto asignado, con la calidad técnica que se esperaba. Eso es lo que te miden, eso es lo que determina si el proyecto fue “exitoso” desde la perspectiva de la consultora, eso es lo que va a tu historial cuando busques el siguiente proyecto o el siguiente ascenso.
Lo que no es tu responsabilidad (lo que estructuralmente no puede ser tu responsabilidad porque no vas a estar ahí para verlo) es si el cliente puede realmente usar lo que construiste, si las decisiones arquitectónicas que tomaste siguen teniendo sentido seis meses después cuando el contexto cambió, si los atajos que tomaste porque tenías presupuesto limitado se convierten en deuda técnica que alguien va a tener que pagar eventualmente, si las asunciones que hiciste sobre cómo se usarían los datos resultan ser incorrectas cuando finalmente alguien intenta usarlos para algo importante.
No porque seas mala persona o mal profesional o porque no te importe. Literalmente no vas a estar ahí cuando esas consecuencias se materialicen. Vas a estar en otro cliente, haciendo otro proyecto, resolviendo otros problemas, y el éxito de ese nuevo proyecto también se va a medir por entrega, no por resultados a largo plazo del proyecto anterior que completaste hace seis meses. Y aunque quisieras seguir involucrado, aunque te importara profundamente qué pasa con el trabajo que hiciste, el modelo de negocio no contempla eso: las horas ya se facturaron, el proyecto ya se cerró, ya hay otros cinco clientes esperando tu tiempo.
Y del otro lado, el cliente también tiene responsabilidad limitada, pero de forma diferente y complementaria que crea un vacío peligroso en el medio. El cliente es responsable de definir qué quiere (escribir la solicitud de propuesta, aprobar el alcance, validar que lo entregado cumple requisitos) pero normalmente no tiene el conocimiento técnico especializado para saber si lo que está pidiendo es realmente lo que necesita. Están comprando tu experiencia precisamente porque no tienen internamente la capacidad de diseñar esto ellos mismos, así que dependen de que tú, como consultor, les digas qué es lo correcto, qué deberían estar pidiendo, qué riesgos deberían considerar, qué decisiones van a tener implicaciones importantes a largo plazo.
Pero tú, como consultor, no puedes decirles del todo qué es realmente lo correcto para su contexto específico porque no tienes visibilidad suficiente sobre su negocio, sobre sus prioridades estratégicas, sobre qué casos de uso van a emerger en los próximos dos años, sobre los posibles problemas o batallas que va a tener librar con otros departamentos para que su proyecto salga a la luz. Puedes dar recomendaciones generales basadas en mejores prácticas de la industria, puedes señalar riesgos obvios, pero las decisiones arquitectónicas fundamentales requieren un nivel de contexto sobre el negocio que simplemente no tienes después de dos semanas de descubrimiento y tres reuniones con responsables.
Y además, tu incentivo (aunque nadie lo diga explícitamente) es entregar lo que pidieron, no cuestionar si deberían estar pidiendo otra cosa. Porque cuestionar el alcance, proponer que tal vez necesitan algo diferente de lo que dijeron inicialmente, sugerir que deberían invertir más tiempo y más presupuesto en pensar las cosas bien antes de implementar nada, todo eso se puede interpretar como que estás tratando de inflar el proyecto, de vender más horas de las necesarias, de complicar algo que debería ser straightforward. Y aunque a veces ese cuestionamiento es exactamente lo que el cliente necesita escuchar, el riesgo de que se malinterprete como intento de vender más hace que muchos consultores sean conservadores sobre hasta dónde empujan esas conversaciones incómodas.
Las migraciones de UA a GA4: un caso perfecto de responsabilidad fragmentada
Vamos al meollo. Hace unos años (algo que seguro os pasó a muchos de vosotros) un cliente grande nos pidió migrar de UA a GA4, y estoy hablando de una empresa internacional con años de operación, equipos sofisticados, presupuestos considerables, toda la apariencia de una organización que sabe lo que hace, la conversación inicial nunca fue “¿deberíamos rediseñar nuestro sistema de medición aprovechando que de todas formas Google nos está forzando a cambiar todo?” La conversación fue “¿cuánto cuesta migrar lo que tenemos?” Y esa diferencia, aunque sutil en la superficie, aunque parece solo semántica, revela exactamente este problema de responsabilidad fragmentada que estoy describiendo.
Nosotros, como consultora, éramos responsables de hacer que la migración funcionara técnicamente. Que los eventos fluyeran de UA a GA4, que los números fueran razonablemente consistentes con lo que venían viendo, que los paneles pudieran recrearse en la nueva plataforma o en Looker Studio, que cuando el día del cambio llegara no hubiera caos ni pérdida de datos ni interrupciones que impidieran al equipo de marketing hacer su trabajo. Eso era nuestro alcance, eso era por lo que nos iban a pagar, eso era lo que determinaría si habíamos hecho nuestro trabajo correctamente según el contrato que habíamos firmado.
Y lo hicimos correctamente, quiero ser muy claro en esto porque es importante para entender que el problema no es de competencia o de esfuerzo. Construimos transformaciones en GTM que tomaban cada evento de UA tal como se disparaba y lo mapeaban a la estructura que GA4 esperaba, preservando toda la lógica que existía, toda la información que se capturaba, todas las particularidades de cómo habían implementado las cosas a lo largo de los años. Documentamos meticulosamente cada mapeo, escribimos especificaciones claras sobre qué se transformaba en qué y por qué, hicimos control de calidad exhaustivo para asegurar que los eventos se disparaban en los momentos correctos y con los datos correctos, validamos que los números en GA4 estaban suficientemente cerca de los números que UA había estado mostrando como para que la gente pudiera confiar en ellos.
El día del cambio, todo funcionó. Los eventos empezaron a fluir hacia GA4, los paneles se poblaron con datos que tenían sentido, los equipos pudieron seguir trabajando sin tener que cambiar fundamentalmente cómo hacían las cosas. El cliente estaba contento porque habíamos resuelto el problema urgente que Google les había creado al forzar la migración, lo habíamos hecho dentro del presupuesto que tenían asignado para esto, sin causar interrupciones mayores en sus operaciones diarias. Hicimos una entrega limpia, les dimos documentación sobre cómo funcionaban todas las transformaciones, respondimos preguntas durante el periodo de transición, y luego seguimos adelante al siguiente proyecto que ya estaba esperando.
Y desde nuestra perspectiva, desde la perspectiva de consultoría midiendo éxito como entrega de proyectos, esto era completamente exitoso. Habíamos tomado un problema complejo (migración forzada con fecha límite inflexible impuesta por Google, implementación heredada que había acumulado años de decisiones orgánicas sin diseño central, múltiples responsables en diferentes equipos con necesidades diferentes, presupuesto limitado porque esto se tenía que hacer dentro de la bolsa de horas que ya tenían contratada con nosotros) y habíamos entregado una solución que funcionaba, que cumplía los requisitos, que permitía al cliente seguir operando.
Pero aquí está lo que no era nuestra responsabilidad, lo que quedaba explícitamente fuera del alcance del proyecto aunque nunca se dijera en voz alta: cuestionar si esa estructura de UA que estábamos migrando tan meticulosamente había sido diseñada bien en primer lugar, si tenía sentido preservarla exactamente en GA4 dado que funciona fundamentalmente diferente de UA en formas que importan para cómo deberías estructurar eventos, si este momento de cambio forzado era potencialmente una oportunidad valiosa para arreglar problemas y ambigüedades que todos sabían que existían en el tracking actual pero que nunca habían tenido tiempo ni presupuesto para resolver porque “si funciona no lo toques” es una heurística poderosa cuando tienes cien otras prioridades.
No porque no pudiéramos ver esos problemas. Los veíamos claramente. Cuando revisabas la implementación de UA que estábamos migrando, era obvio que había eventos que existían porque alguien los había pedido hace cinco años para responder una pregunta específica de marketing que probablemente ya no era relevante, que había inconsistencias en cómo se implementaba el mismo concepto entre web y aplicación móvil porque diferentes equipos lo habían hecho en diferentes momentos sin coordinación, que había dimensiones personalizadas que tres equipos diferentes interpretaban de formas ligeramente diferentes porque nunca nadie se había sentado a escribir definiciones canónicas claras.
Pero hacer el trabajo de identificar todos esos problemas, de coordinar con todos los responsables para entender qué eventos realmente necesitaban versus cuáles eran solo inercia histórica, de rediseñar la taxonomía de eventos pensando específicamente en cómo GA4 funciona en lugar de simplemente copiar lo que existía, todo eso requeriría tiempo y presupuesto que no estaban en el proyecto. Y proponer aumentar el alcance significaba arriesgarnos a que el cliente dijera “no, solo la migración como la planteamos inicialmente” y quedáramos como los consultores que tratan de inflar proyectos, que complican cosas que deberían ser directas, que generan trabajo adicional innecesario.
Así que la decisión arquitectónica fundamental (traducción literal versus rediseño, preservar lo que existía versus aprovechar el cambio forzado para arreglar problemas conocidos) nunca se tomó explícitamente como una decisión consciente donde alguien evaluó opciones y eligió basándose en criterios claros. Se tomó implícitamente, por defecto, porque era el camino de menor resistencia dado cómo estaban estructuradas las responsabilidades y los incentivos de cada parte involucrada.
El vacío donde las decisiones arquitectónicas deberían vivir
Y esto es lo que finalmente entendí después de años de estar en ambos lados, de haber sido el consultor entregando proyectos y luego el cliente viviendo con las consecuencias de proyectos que otros consultores entregaron: hay un tipo específico de decisión que requiere simultáneamente conocimiento técnico profundo sobre cómo funcionan estas herramientas y sus implicaciones a largo plazo. Y contexto profundo sobre el negocio y sus necesidades reales y sus prioridades estratégicas. Y responsabilidad por las consecuencias a largo plazo de lo que se decide. Y en el modelo típico de consultoría, nadie tiene esas tres cosas al mismo tiempo.
Como ya hemos dicho, el consultor tiene conocimiento técnico y tal vez alguna responsabilidad limitada por la calidad técnica de lo que entrega, pero no tiene contexto profundo sobre el negocio ni responsabilidad por consecuencias a largo plazo. El cliente tiene contexto sobre el negocio y teóricamente es responsable de las consecuencias, pero no tiene conocimiento técnico suficiente para saber qué decisiones son las correctas. Y nadie tiene las tres cosas, así que las decisiones que requieren las tres cosas simplemente caen en un vacío, se toman por defecto en lugar de por diseño, se hacen implícitamente a través de lo que no se cuestiona en lugar de explícitamente a través de evaluación consciente de opciones.
Este vacío es donde viven las decisiones sobre si migrar o rediseñar, sobre si seguir lo que el proveedor recomienda o diseñar tu propio esquema, sobre si esta estructura de eventos realmente refleja tu lógica de negocio o es solo una acumulación orgánica de decisiones históricas que nadie recuerda por qué se tomaron. Y porque nadie es explícitamente responsable de tomar esas decisiones, porque están en el espacio entre las responsabilidades claramente definidas del consultor y del cliente, se toman de la forma que requiere menos coordinación, menos justificación, menos riesgo de que algo salga visiblemente mal durante el proyecto.
La puerta que siempre estuvo abierta (pero que nadie cruzó)
La mayoría de las empresas que migraron de UA a GA4 hicieron traducción literal. Y no las culpo en absoluto, tiene sentido perfecto dado las restricciones que todos enfrentaban: fecha límite inflexible impuesta por Google, presión de no interrumpir operaciones, presupuesto limitado, incertidumbre sobre si rediseñar realmente valdría la pena. Lo hicieron trabajando con consultoras profesionales que ejecutaron esas migraciones exactamente como se suponía que debían ejecutarse según el alcance definido, que entregaron trabajo de calidad técnica alta, que cumplieron con plazos y presupuestos.
No hubo negligencia ni incompetencia ni malas intenciones en ningún lado de la ecuación. Solo hubo el mismo patrón que Kafka describió hace más de un siglo: todos esperando que alguien más les diera permiso para hacer lo que debían hacer, todos asumiendo que había alguna autoridad externa que tenía que aprobar explícitamente “sí, deberías rediseñar en lugar de solo migrar,” cuando en realidad esa decisión siempre estuvo disponible para tomarla, la puerta nunca estuvo realmente cerrada, solo hacía falta que alguien asumiera la responsabilidad de cruzarla.
El consultor esperaba que el cliente dijera explícitamente “quiero que cuestiones mi estructura existente y me digas si debería cambiarla,” porque proponer eso sin que te lo pidan se siente como inflar el alcance, como tratar de vender trabajo adicional innecesario. El cliente esperaba que el consultor dijera “no deberías migrar esto tal cual, déjame explicarte por qué necesitas un rediseño,” porque para eso estás pagando a un experto, para que te diga qué deberías estar haciendo incluso cuando no lo sabes pedir. Y mientras ambos esperaban, mientras cada uno asumía que el otro tenía la autoridad o la responsabilidad de iniciar esa conversación difícil, el proyecto avanzaba por el camino de menor resistencia: migración literal, traducción uno-a-uno, preservar exactamente lo que existía porque eso es lo que nadie necesita aprobar explícitamente, lo que nadie tiene que justificar, lo que técnicamente cumple con todos los requisitos según la lectura más estrecha del alcance.
Y pasan los meses, el proyecto se entrega, la consultora se mueve al siguiente cliente, los equipos internos siguen usando el tracking migrado. Y solo años después, cuando alguien finalmente intenta hacer algo que la estructura copiada de UA no soporta bien, cuando se dan cuenta de que preservaron perfectamente todos los problemas que tenían antes solo que ahora en una plataforma diferente, cuando quieren aprovechar capacidades de GA4 que requieren haber pensado la estructura de forma diferente desde el principio, solo entonces se hace evidente que hubo una puerta, que hubo un momento cuando rediseñar era posible, cuando tenían el presupuesto asignado y la atención de los responsables y la justificación perfecta (”Google nos está forzando a cambiar de todas formas, aprovechemos para hacerlo bien”).
Pero ese momento ya pasó. La puerta que siempre estuvo abierta, que nunca estuvo realmente cerrada por ningún guardián con autoridad real para prohibir el paso, esa puerta ahora sí está cerrada. Porque ya no tienes el presupuesto, porque ya gastaste el capital político en hacer una migración y nadie quiere escuchar que ahora necesitas hacerlo de nuevo pero bien, porque hay cincuenta sistemas downstream que ya asumen la estructura actual y cambiarla requeriría coordinar un esfuerzo masivo que nadie tiene tiempo ni ganas de liderar. La ventana se cerró no porque alguien la cerrara activamente, sino porque el tiempo pasó mientras todos esperaban que alguien más tomara una decisión que nadie tenía explícitamente la autoridad de tomar pero que cualquiera podría haber tomado si hubiera asumido la responsabilidad.
El guardián que siempre seguirá en la puerta
Y esta dinámica va a seguir repitiéndose, no solo con GA4 sino con cada herramienta que se depreque, con cada migración forzada que llegue en los próximos años, con tantos otros procesos que se ejecutan sin pensar porque los incentivos estructurales que hacen que todos esperen frente a la puerta en lugar de cruzarla no han cambiado. Mientras el éxito en consultoría se mida por entrega de proyectos según alcance definido en lugar de por decisiones correctas aunque no te las pidieron explícitamente, mientras los clientes sigan asumiendo que los consultores van a decirles qué deberían hacer incluso cuando eso signifique cuestionar el brief que les dieron, mientras ambos lados esperen que el otro tome la responsabilidad de decisiones que caen en el espacio entre sus ámbitos claramente definidos, vamos a seguir produciendo proyectos técnicamente impecables que fundamentalmente desperdician oportunidades.
Porque eso es lo más perturbador del cuento de Kafka, lo que hace que no puedas dejar de pensar en él una vez que lo entiendes: el hombre del campo no hizo nada objetivamente incorrecto. Fue prudente, fue paciente, respetó al guardián, intentó todo lo que se le ocurría dentro de las reglas del sistema. Pero pasó toda su vida esperando un permiso que nadie tenía realmente la autoridad de darle porque la decisión siempre fue suya, la responsabilidad siempre fue suya, la puerta siempre estuvo destinada solo para él. Y al final, cuando ya es demasiado tarde, cuando está muriendo después de décadas de espera, se entera de que todo ese tiempo estuvo esperando frente a una puerta que existía exclusivamente para que él la cruzara, una puerta que nadie más podía cruzar precisamente porque era su decisión, su responsabilidad, su oportunidad única.
Y años después, cuando finalmente quieres hacer algo que requiere haber diseñado la estructura de forma diferente desde el principio, cuando te das cuenta de que hubo un momento cuando esto era posible y ahora ya no lo es, lo único que queda es la pregunta que el hombre le hace al guardián: “¿Por qué nadie más intentó entrar?” ¿Por qué nadie en tu organización, entre todos los consultores y product managers y data analysts y engineering leads involucrados en la migración, nadie preguntó si deberían estar rediseñando en lugar de solo copiando? ¿Por qué todos asumieron que hacer las cosas bien estaba prohibido o requería algún permiso especial, cuando en realidad solo requería que alguien tomara la responsabilidad de decir “esta puerta existe, es nuestra puerta, y voy a cruzarla aunque nadie me esté dando permiso explícito porque entiendo que la responsabilidad es mía”?
La respuesta del guardián aplica perfectamente: esa entrada estaba destinada solo para tu organización, en ese momento específico cuando Google forzó la migración y tuviste la oportunidad perfecta de repensar todo. Nadie más podía cruzarla por ti. Y ahora, años después del proyecto, con cincuenta sistemas que asumen la estructura actual y presupuesto gastado y capital político agotado, ahora esa puerta está cerrada. No porque alguien te prohibiera rediseñar, sino porque esperaste que alguien te lo permitiera cuando la decisión siempre fue tuya.