¿Confiamos más en las métricas que en nosotros?

Sobre métricas, capacidades humanas que ayudan en la toma de decisiones, y quién controla la visión del proyecto.

En tiempos de la IA y de los análisis predictivos, queremos plantear una reflexión sobre los límites de las estrategias basadas en datos y sus posibles puntos ciegos.

Este artículo no es una crítica a estas estrategias, ni mucho menos al análisis de datos. Es evidente que recopilar información y extraer conclusiones de ésta ayuda a descubrir oportunidades, y a crear y mejorar productos y servicios. Y una IA puede descubrir patrones en bases de datos que no son evidentes para un ser humano. Pero hay algunas falacias extendidas sobre el análisis de datos aplicado a la gestión de proyectos que conviene cuestionar.

«Es mejor tomar decisiones en base a datos que en base a tu instinto»

Cuando se habla en estos términos sobre la toma de decisiones, se presenta una dicotomía falsa. Es posible decidir en base a muchos otros factores: conocimiento, experiencia, o una comprensión holística de sistemas complejos. Separar todo eso entre blanco o negro, datos o instinto, decisiones informadas o a lo loco, es desaprovechar una riqueza de posibilidades.

Es cierto que las corazonadas pueden salir caras. Conforme una empresa crece, tomar una decisión que no se sustenta en nada puede traer consecuencias a gran escala. Hay mucha responsabilidad. Pero estar preparado para pivotar deprisa no es incompatible con unas prioridades y objetivos claros, ni equivale a saltar por capricho de una ocurrencia a otra.

Hay algunas tendencias, dentro y fuera de la gestión de proyectos, que desprestigian la creatividad humana y engloban un amplio abanico de habilidades como «intuición», para a continuación proponer los datos como la alternativa objetiva y fiable. Esto es otra falacia.

«Los datos son objetivos»

Confiar ciegamente en los datos puede llevar a engaño y a tomar malas decisiones. Los datos no surgen de la nada, y existe una subjetividad inherente en el proceso de recopilación y análisis de datos.

  • Sesgo en la selección: al decidir qué datos recopilar, se puede incurrir en un sesgo de selección. Por ejemplo, si una empresa desea evaluar la percepción de su marca en redes sociales, primero debe decidir en cuáles enfocarse. Basándose en datos históricos, si sus clientes son jóvenes, puede asumir que la mejor opción es crear cuentas en redes con mayor presencia de este sector demográfico. Los datos obtenidos pueden ser valiosos, pero ignorarán por tanto conversaciones sobre la marca en otras redes que pueden atraer a un público más maduro o profesional.
  • Interpretación de datos y sesgo de confirmación: cuando los analistas interpretan datos, pueden ser susceptibles al sesgo de confirmación, buscando información que respalde sus hipótesis previas o las expectativas de la empresa, en lugar de objetividad. Un ejemplo claro es cuando se ignoran datos que contradicen la eficacia de una campaña de marketing popular dentro de la empresa, priorizando datos que sugieren un éxito marginal.
  • Calidad y limpieza de datos: la calidad de los datos puede verse afectada por errores de entrada, datos incompletos o duplicados. Por ejemplo, si una base de datos de clientes contiene numerosos registros duplicados, el análisis podría indicar incorrectamente un mayor alcance de mercado o una efectividad de campaña inflada.
  • Sesgos en los sistemas de análisis: los algoritmos y modelos utilizados para analizar datos no son neutrales. Están diseñados por humanos y pueden incorporar sus sesgos y suposiciones. Por ejemplo, un modelo predictivo que evalúa la probabilidad de éxito de candidatos a un puesto puede estar sesgado por los criterios subjetivos de sus creadores, potencialmente discriminando contra ciertos grupos.

Por otro lado, los datos pueden tener límites y fechas de caducidad dependiendo del proyecto. Los datos históricos pueden perder relevancia rápidamente en mercados volátiles o ante cambios tecnológicos. En los entorno VUCA, las empresas que se basan en análisis de tendencias pasadas sin considerar el dinamismo del mercado pueden encontrarse desarrollando estrategias obsoletas. Y hacer predicciones a largo plazo en base a datos, aunque sean recientes, puede suponer decepciones. El entorno ha podido cambiar varias veces, o pueden surgir variables que no se consideraron en el momento de planificar.

No faltan ejemplos recientes: la pandemia o el boom de ChatGPT han sido grandes cambios con consecuencias en el mercado que no pueden predecirse en un plan de negocio a 4 años. Por ejemplo, las estrategias de retail tradicional basadas en datos pre-pandemia se encontraron inadecuadas en el contexto del aumento del comercio electrónico durante la COVID-19.

Depender en exceso del análisis de datos puede llevar a ignorar la intuición y el conocimiento contextual que los líderes y empleados aportan.

«No puedes controlar lo que no puedes medir»

Tom DeMarco hizo famoso en 1982 su principio «no puedes controlar lo que no puedes medir». Décadas después, sin embargo, se retractaba:

«Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construían el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿fue correcto el asesoramiento en métricas?, ¿sigue siendo pertinente? y, ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software? Mis respuestas son no, no y no.

Muchos proyectos han avanzado sin centrar la gestión en el control, sino en la creación de productos maravillosos como GoogleEarth o Wikipedia.
Para entender la verdadera función del control, es necesario distinguir de manera drástica entre dos tipos diferentes de proyectos:

Un proyecto de tipo A, con un coste estimado de un millón de dólares y un cálculo de retorno aproximado de 1,1 millones.
Un proyecto de tipo B, que con un coste estimado de un millón de dólares, produce un valor de más de 50 millones de dólares.

Lo inmediatamente evidente es que el control resulta importante en el proyecto A, y sin embargo su importancia es mínima en el B. Esto nos lleva a la extraña conclusión de que el control estricto es importante en los proyectos poco importantes, y viceversa.»

(Tom DeMarco, edición de julio/agosto de IEEE Software, 40 aniversario de la Ingeniería del Software)

Esta evolución en el pensamiento de DeMarco es significativa, y la distinción entre proyectos de tipo A y tipo B, fundamental: no todos los proyectos deben gestionarse de la misma manera. Los que tienen un alto potencial de retorno o impacto (tipo B) pueden beneficiarse de un enfoque más flexible y orientado a la innovación, donde el control estricto y las métricas detalladas son, quizá paradójicamente como él señala, menos importantes.

El deseo de control es más que comprensible, pero todo depende del contexto y del proyecto. No sólo por la distinción A-B que hace de DeMarco, basándose en el gran retorno de proyectos de alto riesgo. Hay muchas otras cuestiones que condicionan los proyectos: las consecuencias en caso de error, la volatilidad del mercado, o la agresividad de la competencia.

Si un error puede suponer problemas serios y el entorno del negocio es estable, entonces tiene sentido planificar y medir. Pero cuando se apunta a una diana que no para de moverse y podemos permitirnos fallar, es mejor disparar balas trazadoras y rectificar rápido el tiro. Poner el foco en la experimentación.

Existen muchas estrategias ágiles para probar ideas sin invertir demasiados recursos, algunas de las cuales exploramos en otros artículos y materiales de formación. Como suele decirse: equivócate rápido, prueba barato y pivota rápido.

Cuando las corazonadas aciertan

Igual que hay ejemplos de productos y servicios exitosos fruto de los datos, los hay basados en experiencia e «instinto» (o creatividad, o como se quiera llamar). Las pantallas táctiles como las conocemos ahora, por ejemplo, no surgieron de datos. Steve Jobs consideraba el stylus y el teclado de la Blackberry ortopédicos y poco cómodos. Creía, a nivel personal, que las interacciones entre el ser humano y la tecnología tenían que ser más orgánicas. De ahí el diseño de un nuevo sistema de detección basado en impulsos eléctricos en lugar de presión, para interactuar con la pantalla sin intermediarios. Esa idea difícilmente podría haber salido analizando el uso de dispositivos móviles de personas cuyas referencias eran los teléfonos clásicos, ordenadores con teclado y cuadernos. De hecho hay gente que echa de menos los teclados de la Blackberry.

Pero esto no fue una ocurrencia, sino una decisión basada en experiencia y en una observación intuitiva sobre la naturaleza humana: ¿es más «orgánico» escribir con un stylus o tocar directamente?

La clave de la innovación es cuestionar lo actual; proponer una antítesis. Es la evolución dialéctica del conocimiento. Y puede resultar difícil encontrar oportunidades disruptivas en datos históricos.

Los momentos «eureka» son raros, impredecibles y valiosos. Sería una lástima dejar escapar uno por falta de datos que lo respalden. Para un entorno ágil con una creatividad fértil hay que dar la bienvenida también a estas ideas y ponerlas a prueba.

Y al final, quizá debería ser la tecnología la que siga la visión humana, y no los humanos quienes sigan la visión de los datos.