Uno de mis primeros trabajos fue en una consultora donde varios científicos de datos teníamos que atender los requerimientos de muchas empresas en diferentes proyectos. Yo estaba realizando un modelo de pronóstico de deserción para una compañía de telecomunicaciones. Sin embargo, no era el único realizando un modelo así para una compañía de ese sector. Resulta que en otro proyecto muy similar había otro científico de datos estimando un modelo parecido. Nuestro jefe se dio cuenta de que lo que estábamos haciendo era muy distinto y organizó una reunión entre los equipos. En esta reunión nosotros íbamos a exponer nuestras metodologías y se iba a decidir cuál era el camino correcto.
Muchas veces cuando eres científico de datos necesitas defender tus modelos. Para lograr esto es necesario tener muy claro todos los fundamentos teóricos, además de la utilidad y el objetivo de los mismos. Y sobre todo, cómo encajan en el proyecto en el que viven.
La reunión comenzó, yo propuse estimar varios modelos muy genéricos (regresión logística, redes neuronales, etc.) para calcular la probabilidad de deserción de los clientes y me centré en mostrar el funcionamiento de los modelos; una vez calculados todos se elegiría el mejor usando una métrica.
Mi contraparte mencionó que no era necesario realizar muchos modelos. Presentó un artículo en el cual se mostraba un modelo bayesiano usado específicamente para pronosticar la deserción. Se trataba de un modelo muy sofisticado que después de su etapa de entrenamiento era capaz de calcular la curva de distribución del pronóstico por medio de métodos de simulación Montecarlo.
La discusión se tornó bastante agitada, y al ver que ninguno de los dos cedía ante el otro, se determinó un duelo a muerte por cuchillos que cada proyecto tendría un modelo distinto y al final con la retroalimentación del cliente se decidiría cuál de los dos era mejor.
Dos semanas más tarde me enteré de que en el otro proyecto se estaba implementando mi propuesta metodológica. No porque fuera más fácil, menos compleja o tuviera mejores resultados, sino porque el pronóstico iba a ser usado por personas de atención al cliente que trabajaban en un call center.
Eso significaba que nuestro modelo iba a ser usado por personas sin un trasfondo matemático avanzado. Utilizar el modelo sofisticado, que ciertamente era bastante mejor que lo que yo proponía, hubiera requerido una capacitación a todo el personal del call center sobre probabilidad, funciones de densidad y funciones de densidad acumulada.
Este asunto me dio la razón, pero nunca por ninguno de los argumentos que yo expuse, sino por un factor que yo no había contemplado dentro de la ciencia de datos y que es muy relevante: las personas.
Cuando realizamos proyectos de ciencia de datos puedes estar concentrado en el factor predictivo, en la generalizabilidad del modelo, en la reproducibilidad del código o en el costo computacional del mismo. Y esto te puede llevar a tomar decisiones que perjudican directamente a las personas que van a usar tu modelo.
Diseñar soluciones basadas en las personas que tienen en cuenta la usabilidad es totalmente competitivo. Cuando no tienes en cuenta las personas las soluciones probablemente exijan habilidades que ellas no poseen, y en esto puede llegar otro científico de datos y arrebatarte tus clientes con una solución más apropiada para los usuarios.
Vengo a decirte con todas estas palabras que, aunque no exista dentro de la ruta de ciencia de datos, tú necesitas tomar el Curso de Design Thinking. Porque solamente cuando tienes en cuenta los requerimientos puntuales de las personas y el uso que le van a dar a los modelos, puedes realizar un trabajo que cumpla realmente su propósito.
Normalmente los científicos de datos no queremos relacionarnos con las personas, nos llevamos mejor con las máquinas, nos gusta enseñarles cosas y que ellas se aprendan. Pero es necesario al principio de un proyecto, que tú o alguien de tu equipo se entreviste con todas las personas que van a usar el modelo o los modelos de manera que haya una misión conjunta y unas expectativas razonables.
También me ha pasado muchas veces que el cliente piensa que la ciencia de datos es una bola de cristal que le va a decir el futuro pero cuando vamos a mirar los datos ninguna de las variables se correlacionan y terminamos tratando de pronosticar el color de los ojos por medio del color de los zapatos. Este tipo de comunicaciones mal hechas son nefastas para un proyecto y hay que prevenirlas a toda costa.
Ten en cuenta que cada modelo que realizas es distinto, tiene fuentes de datos distintas, objetivos distintos y salidas distintas (tableros, reportes, datos, pronósticos). Es posible que para ti sea muy claro lo que quieres hacer; sin embargo, los usuarios de tu modelo pueden tener visiones distintas a la tuya. Realizar procedimientos de empatía, definición, ideación, prototipado y socialización te da garantías de que tu modelo sea usado por los usuarios.
Por eso te animo a que aprendas design thinking y diseñes tus modelos con propósito. Al principio va a ser extraño, pero con el tiempo vas a entender que lo que importa es la gente, y te va a pasar como a mí, que todo el mundo me mira raro cuando comienzo a hablar de machine learning centrado en las personas. Pero no te preocupes, al contrario, al mismo tiempo muchas otras personas entenderán lo que haces al ver los resultados de tu trabajo centrado en ellas mismas.
Curso de Estadística Inferencial con R
