Diez tareas no equivalen a diez unidades de trabajo.
Un programa de transformación puede asignar diez tareas a un arquitecto de soluciones y otras diez a un responsable funcional. Sobre el papel, la carga parece equilibrada. El dashboard está en verde. El plan de recursos resulta defendible.
Sin embargo, un grupo de tareas puede realizarse de forma individual, con información estable, herramientas especializadas y margen para investigar, probar, corregir y volver a intentarlo. El otro puede exigir entrar en un workshop con información incompleta, reconciliar versiones operativas contradictorias, proteger la intención estratégica, interpretar restricciones del sistema y ayudar a que varios directivos tomen una decisión relevante antes de que termine la reunión.
Ambos tipos de trabajo son imprescindibles. Pero no representan unidades equivalentes de esfuerzo.
Aquí es donde la planificación basada en el número de tareas empieza a engañar. Registra actividad visible, pero aplana las condiciones bajo las que debe ejecutarse. Cuenta el workshop, no la preparación, interpretación, negociación y recuperación que contiene. Registra el requisito, pero no la ambigüedad absorbida para convertirlo en una definición coherente. Ve el flujo configurado, pero no las decisiones operativas que hicieron posible configurarlo.
El resultado es un fallo recurrente de gobierno: el trabajo estratégico-funcional se infravalora precisamente porque su producto no es la configuración, sino la claridad que permite configurarla.
La falacia de contar tareas
Contar tareas sirve para medir volumen. El problema aparece cuando ese volumen se utiliza como sustituto de la capacidad.
Una tarea es apenas una etiqueta. No indica cuánto juicio profesional requiere, qué grado de estabilidad tiene la información disponible, cuántos actores intervienen, qué consecuencias tendría una respuesta prematura ni cuánto costaría corregir el resultado posteriormente.
Comparemos dos líneas de un plan de transformación:
- Configurar en el sistema una regla de aprobación ya validada.
- Definir la regla de aprobación para un modelo operativo multinacional.
La primera puede ser técnicamente compleja. La segunda puede exigir que finanzas, operaciones, compliance y tecnología acuerden dónde residen los derechos de decisión, qué excepciones son legítimas, qué evidencias se necesitan y cómo se gobernarán las prácticas locales. Hasta cerrar esas decisiones, todavía no existe una regla estable que pueda configurarse.
Contabilizar ambas como una tarea crea una falsa equivalencia y oculta que tienen un peso de ejecución distinto.
Esto no significa que el trabajo funcional sea más difícil o más valioso que el técnico. Los equipos técnicos gestionan su propia complejidad profunda: arquitectura, seguridad, integraciones, integridad de datos, rendimiento, mantenibilidad y decisiones de diseño que pueden condicionar la organización durante años. El argumento es más preciso: la complejidad se manifiesta de forma diferente según el rol, y las métricas convencionales no capturan esas diferencias con el mismo nivel de fidelidad.
Cuando la capacidad se asigna únicamente por volumen, se sobrecarga con facilidad a quienes concentran ambigüedad, coordinación transversal y soporte a decisiones en directo. Esa sobrecarga permanece oculta hasta que las decisiones se ralentizan, los workshops se repiten, los requisitos cambian o los equipos técnicos reciben inputs incompletos, contradictorios o tardíos.
Todo lo que contiene una tarea funcional
En los programas de transformación, el trabajo estratégico-funcional suele describirse mediante verbos aparentemente sencillos:
- explorar;
- definir;
- alinear;
- validar;
- estandarizar;
- adaptar;
- aprobar.
Cada verbo puede ocultar varias capas de trabajo simultáneas.
Para “definir” un proceso futuro, alguien debe comprender cómo funciona realmente la operación, no solo cómo está documentada; distinguir una variación legítima de una costumbre heredada; identificar dependencias entre equipos y sistemas; descubrir restricciones regulatorias o comerciales; decidir qué excepciones deben mantenerse; traducir el resultado a requisitos; y explicar las implicaciones a personas con prioridades y lenguajes profesionales distintos.
El mapa final puede parecer sencillo porque la complejidad ya ha sido procesada.
Este fenómeno es el descuento de la intangibilidad: los programas de transformación tienden a infravalorar el trabajo que elimina incertidumbre porque su resultado es claridad, no un artefacto técnico visible.
Un objeto configurado puede contarse. Una integración puede demostrarse. Un defecto puede registrarse. Pero una contradicción resuelta antes de comenzar la configuración no deja una huella equivalente. Su valor aparece en aquello que no sucede: menos retrabajo, menos escalados, datos más coherentes, mejor adopción y decisiones que siguen siendo válidas después de la reunión.
Cuando la configuración parece evidente, alguien ya ha absorbido la ambigüedad.
La brecha de exposición funcional
La carga no reside únicamente en lo que debe resolverse. También está en las condiciones bajo las que se resuelve.
Muchas tareas estratégico-funcionales se ejecutan en directo: sesiones de discovery, workshops de diseño, comités de dirección, validaciones operativas y revisiones ejecutivas. La persona responsable rara vez se limita a presentar una respuesta completamente cerrada. Puede estar interpretando información nueva, cuestionando supuestos y protegiendo el alineamiento mientras el propio trabajo continúa desarrollándose.
Esta es la brecha de exposición funcional: la diferencia no medida entre realizar una tarea y realizarla mientras otras personas interpretan, cuestionan y juzgan en tiempo real su significado, sus supuestos y sus consecuencias.
La exposición en directo puede concentrar en una misma ventana:
- análisis de información incompleta;
- facilitación entre intereses contrapuestos;
- traducción entre lenguaje operativo y técnico;
- explicación rigurosa de la incertidumbre;
- protección de la intención estratégica;
- soporte inmediato a decisiones;
- juicio profesional bajo escrutinio.
Esto no convierte automáticamente cualquier reunión en trabajo de alto valor. Muchas reuniones están mal diseñadas, tienen demasiados asistentes o sencillamente no deberían celebrarse. La exposición solo añade peso de ejecución cuando la sesión gestiona ambigüedad, coordinación o consecuencias reales.
Tampoco significa que el cuestionamiento sea negativo. El reto bien planteado mejora la decisión. Pero solo funciona cuando las personas pueden reconocer incertidumbre, solicitar información y poner a prueba supuestos sin ser penalizadas por hacerlo. La investigación de Amy Edmondson sobre seguridad psicológica relaciona la percepción compartida de que asumir riesgos interpersonales es seguro con el aprendizaje de los equipos. En transformación, una sala que reprime las dudas puede parecer muy decidida mientras produce requisitos más débiles y correcciones posteriores más costosas.
La tarea funcional no solo se ejecuta. Se interpreta, negocia, defiende y, con frecuencia, se evalúa mientras todavía está siendo completada.
La carga de traducción entre estrategia y sistemas
“Recoger requisitos” describe mal gran parte de este trabajo. La expresión sugiere que los requisitos ya existen en forma estable y solo hay que recopilarlos.
En realidad, las organizaciones suelen comenzar con intenciones, problemas, prácticas locales, excepciones, políticas, incentivos y versiones contradictorias sobre cómo debería funcionar la operación. Nada de eso constituye todavía una especificación ejecutable. Debe analizarse, reconciliarse y convertirse en decisiones que un equipo técnico pueda implementar sin perder el significado empresarial original.
Esa conversión es la carga de traducción.
Convierte:
| Desde | Hacia |
|---|---|
| Intención estratégica | Capacidades prioritarias y criterios de decisión |
| Realidad operativa | Procesos y requisitos de sistema |
| Prácticas y excepciones locales | Reglas gobernadas y variantes justificadas |
| Conflicto entre stakeholders | Decisiones explícitas y ownership |
| Conocimiento fragmentado | Un diseño objetivo coherente |
| Riesgo y ambigüedad | Acciones, controles y dependencias secuenciadas |
| Resultados deseados | Condiciones ejecutables de configuración y adopción |
Traducir no es transcribir. Exige juicio, síntesis y capacidad para preservar el significado entre lenguajes profesionales diferentes.
La disciplina de ingeniería de requisitos trata este trabajo como un ciclo de elicitación, análisis, especificación, validación y gestión, no como una transferencia administrativa de peticiones. La investigación empírica realizada en empresas y países distintos también ha identificado problemas recurrentes como requisitos incompletos, fallos de comunicación y objetivos móviles. No son simples defectos documentales: indican que la organización todavía no ha convertido plenamente su intención operativa en una base estable para la entrega.
Cuando nadie asume explícitamente esa carga —o el rol existe, pero carece de capacidad— los equipos técnicos reciben inputs inestables. Los síntomas posteriores parecen técnicos: reconfiguraciones, personalizaciones, defectos de interfaz, correcciones de datos o resistencia a la adopción. Sin embargo, su origen puede estar en una ambigüedad de negocio no resuelta.
La estrategia no se configura sola.
La interrupción también forma parte de la carga
Los roles estratégico-funcionales suelen ocupar el punto de intersección de varios workstreams. Se mueven entre prioridades ejecutivas, diseño de procesos, preguntas de proveedores, excepciones operativas, problemas de datos, impactos de cambio y escalados urgentes.
Esa posición genera valor porque conecta el programa. También genera una carga que el recuento de tareas rara vez registra.
La investigación sobre cambio de tareas muestra que una parte de la atención puede permanecer vinculada a la actividad anterior después del cambio, perjudicando el rendimiento en la siguiente. Los experimentos sobre interrupciones en tareas de oficina también han observado que las personas pueden compensar trabajando más rápido, pero con mayor carga percibida, estrés, frustración, presión temporal y esfuerzo.
La conclusión ejecutiva no es eliminar cualquier interrupción. La transformación siempre incluirá escalados y descubrimiento. La conclusión es que una agenda fragmentada por workshops y decisiones imprevistas no convierte automáticamente los huecos restantes en capacidad productiva íntegra.
Un comité de una hora puede consumir bastante más de una hora de peso de ejecución. Puede requerir preparación a partir de varias fuentes, síntesis en directo, documentación de decisiones, seguimiento con equipos afectados y recuperación cognitiva antes de volver a un trabajo profundo.
Un plan que reserva únicamente la hora visible está infravalorando la demanda real.
La paradoja de la visibilidad
El buen trabajo estratégico-funcional suele hacerse invisible.
Cuando la ambigüedad se resuelve pronto, el requisito parece obvio. Cuando los stakeholders se alinean antes de construir, la configuración parece sencilla. Cuando las excepciones están gobernadas, el proceso objetivo parece limpio. Cuando las dependencias se detectan con antelación, la secuencia de entrega parece natural.
Esta es la paradoja de la visibilidad: cuanto mejor se realiza la clarificación upstream, más sencilla parece la ejecución downstream y menos visible resulta la complejidad ya absorbida.
La complejidad técnica deja evidencias en arquitecturas, código, interfaces, tickets, pruebas y comportamiento del sistema. La complejidad funcional suele dejar una decisión, una definición y una sala que finalmente puede avanzar.
Este trabajo desaparece dentro de la claridad que crea.
La paradoja importa porque el gobierno tiende a reconocer aquello que permanece visible. Si el sponsor solo observa un resultado limpio, puede concluir que el rol upstream tenía poca carga o que todavía puede asumir más. El programa concentra entonces ambigüedad y exposición en unas pocas personas hasta convertirlas en cuellos de botella, reducir la calidad de las decisiones o depender de un esfuerzo individual insostenible.
Del volumen de tareas al peso de ejecución
Los líderes de transformación necesitan una lente mejor. No una fórmula universal ni otra capa burocrática, sino una manera práctica de ajustar cómo se dimensiona y gobierna el trabajo.
En Guruti lo expresamos así:
El peso de ejecución es el volumen de tareas ajustado por complejidad, ambigüedad, coordinación, exposición y consecuencias.
La interrupción, la reversibilidad, la preparación y la recuperación también pueden modificar de forma material la carga.
Este es un marco de gestión, no una ecuación científicamente validada. Su función es mejorar las preguntas y las decisiones antes de que un recuento aparentemente preciso produzca un plan de recursos falso.
| Dimensión | Pregunta de gobierno |
|---|---|
| Complejidad cognitiva | ¿Cuánto análisis, síntesis y juicio exige la tarea? |
| Ambigüedad | ¿Hasta qué punto la información es incompleta, contradictoria o inestable? |
| Densidad de stakeholders | ¿Cuántas partes, intereses, handoffs y dependencias deben reconciliarse? |
| Exposición en directo | ¿El trabajo debe completarse o defenderse en tiempo real bajo escrutinio? |
| Carga de interrupción | ¿Cuánto se fragmenta mediante cambios de contexto, escalados e inputs imprevistos? |
| Consecuencias | ¿Qué impacto downstream puede generar una respuesta incompleta o prematura? |
| Reversibilidad | ¿Con qué facilidad puede corregirse la decisión después de aplicarla? |
| Preparación y recuperación | ¿Qué trabajo invisible ocurre antes y después del evento visible? |
El modelo es deliberadamente cualitativo. El objetivo no es asignar puntuaciones teatrales a cada tarea, sino identificar qué trabajo necesita otra protección de capacidad, secuencia o diseño de roles.
Qué cambia en la práctica
1. Separar volumen y peso en los planes de capacidad
No pregunte únicamente cuántas tareas tiene asignadas una persona. Identifique cuáles concentran ambigüedad, stakeholders, exposición y consecuencias. Diez acciones bien definidas pueden convivir; diez workshops intensivos en decisiones probablemente no.
2. Tratar los workshops como eventos de entrega
Los workshops de alto impacto necesitan capacidad explícita antes y después. La reunión visible es el centro del trabajo, no su duración completa. Deben definirse la decisión esperada, las evidencias necesarias, el ownership de la síntesis y lo que ocurrirá cuando la sala se cierre.
3. Hacer explícito el ownership de la traducción
Nombre el rol que convierte intención operativa en diseño ejecutable. Concédale autoridad para exponer contradicciones, exigir decisiones y proteger la coherencia entre workstreams. No deje la traducción como una responsabilidad informal entre negocio y tecnología.
4. Medir la preparación de decisiones
No controle únicamente tareas completadas. Compruebe si los supuestos están explícitos, los stakeholders alineados, las excepciones gobernadas, las dependencias visibles y la decisión suficientemente estable para construir sobre ella.
5. Diseñar conjuntamente capacidad funcional y técnica
No proteja un lado disminuyendo el otro. Los equipos técnicos necesitan inputs estables y acceso al contexto operativo. Los funcionales necesitan conocer pronto las restricciones del sistema y las consecuencias arquitectónicas. El mejor modelo reduce la pérdida de significado en ambas direcciones.
6. Proteger las condiciones para decir la verdad
Los sponsors deben esperar preguntas, incertidumbre e información incompleta durante el diseño. Si cada workshop debe representar certeza, los supuestos débiles sobrevivirán más tiempo. En este contexto, la seguridad psicológica no es blandura: es una condición para exponer el riesgo antes de que se convierta en comportamiento del sistema.
Una brecha transversal a cualquier despliegue
En un ERP aparece cuando un flujo de aprobación “sencillo” depende de derechos de decisión todavía no resueltos entre entidades.
En un PMS o ecosistema hotelero aparece cuando PMS, CRS, distribución y pagos requieren reconciliar política comercial, experiencia del huésped, excepciones operativas y ownership antes de diseñar una integración.
En un CRM aparece cuando la configuración del funnel depende de que marketing, ventas, servicio y finanzas compartan definiciones, criterios de cualificación y reglas de ownership.
En un HRIS aparece cuando la estandarización global debe distinguir requisitos regulatorios reales de prácticas locales heredadas.
En una plataforma de datos o IA aparece cuando una decisión aparentemente técnica depende de definiciones comunes, calidad de datos, accountability y condiciones de uso operativo.
En una integración post-adquisición aparece cuando “estandarizar el proceso” significa decidir qué prácticas heredadas representan necesidades legítimas y cuáles reproducen simplemente la historia.
La tecnología cambia. La brecha entre intención, realidad operativa y ejecución técnica se repite.
Diagnóstico para el comité ejecutivo
Antes de aprobar el siguiente plan de capacidad, pregunte:
- ¿Qué roles concentran la mayor cantidad de ambigüedad todavía no resuelta?
- ¿Dónde debe convertirse conocimiento transversal en diseño ejecutable?
- ¿Qué tareas exigen respuestas creíbles en directo, con poco margen para revisarlas después?
- ¿Hemos incluido preparación, documentación, seguimiento y recuperación alrededor de los eventos decisorios?
- ¿Hay personas clave fragmentadas entre demasiados workstreams para mantener un análisis profundo?
- ¿Qué decisiones combinan consecuencias elevadas y baja reversibilidad?
- ¿Pueden los equipos reconocer información ausente y cuestionar supuestos antes de construir?
- ¿Estamos confundiendo un resultado downstream limpio con poco esfuerzo upstream?
Si estas preguntas no aparecen, el programa puede estar midiendo la actividad con precisión y comprendiendo mal la carga.
Gobernar el peso real de la ejecución
Las transformaciones no fracasan porque todas las tareas sean difíciles. Fracasan cuando el trabajo difícil se identifica mal, recibe capacidad insuficiente o se realiza bajo condiciones que debilitan las decisiones de las que depende la entrega.
El número de tareas seguirá siendo útil. Las horas seguirán siendo necesarias. Los entregables continuarán siendo visibles. Pero ninguno de estos elementos, por sí solo, revela el peso real del trabajo que convierte estrategia en decisiones operativas y decisiones operativas en sistemas.
Un gobierno maduro reconoce la interdependencia: el trabajo estratégico-funcional crea la claridad que el trabajo técnico convierte en realidad; el trabajo técnico expone restricciones que mejoran las decisiones funcionales. Ambos necesitan modelos de capacidad que reflejen cómo se manifiesta verdaderamente su complejidad.
El objetivo no es repartir reconocimiento. Es ejecutar mejor.
Porque entre estrategia y sistemas existe una carga sustancial de traducción. Si no se reconoce, dimensiona y gobierna, la organización termina configurando tecnología sobre decisiones incompletas.
La estrategia no se configura sola.
Si su plan de transformación parece equilibrado sobre el papel, pero sigue limitado por decisiones lentas, requisitos inestables o roles integradores sobrecargados, Guruti puede ayudarle a rediseñar el gobierno entre estrategia, operaciones y sistemas.
Explore Fractional CxO & Transformation PMO y Transformation Strategy & Operating Models, o reserve una sesión de trabajo confidencial para identificar dónde se está ignorando el verdadero peso de ejecución.
Base de evidencia y límites editoriales
Los cinco conceptos —falacia de contar tareas, brecha de exposición funcional, descuento de la intangibilidad, carga de traducción y paradoja de la visibilidad— y la lente de peso de ejecución son marcos de gestión desarrollados por Guruti. Se proponen como herramientas prácticas de gobierno, no como constructos científicos validados ni como un modelo cuantitativo universal.
Las fuentes externas respaldan mecanismos concretos del artículo:
- Sophie Leroy, “Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching Between Work Tasks”, Organizational Behavior and Human Decision Processes 109, n.º 2 (2009): 168–181. DOI: https://doi.org/10.1016/j.obhdp.2009.04.002
- Gloria Mark, Daniela Gudith y Ulrich Klocke, “The Cost of Interrupted Work: More Speed and Stress”, CHI 2008 Proceedings (2008): 107–110. DOI: https://doi.org/10.1145/1357054.1357072
- Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly 44, n.º 2 (1999): 350–383. DOI: https://doi.org/10.2307/2666999
- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering. https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:29148:ed-2:v1:en
- Daniel Méndez Fernández et al., “Naming the Pain in Requirements Engineering: Contemporary Problems, Causes, and Effects in Practice”, Empirical Software Engineering 22 (2017): 2298–2338. DOI: https://doi.org/10.1007/s10664-016-9451-7
No se ha importado al artículo ninguna cifra estadística procedente de estas fuentes. Sus resultados se han parafraseado de manera conservadora y únicamente para explicar el mecanismo correspondiente.