Continuando con las entregas sobre el paso a paso para proyectos de datos (El paso a paso para el desarrollo de un proyecto de datos), esta semana está relacionado con el entendimiento del problema para poder abordarlo.
Parte 2 de 5: Recibir y estudiar la solicitud del proyecto de datos
Todo proyecto de datos comienza con una solicitud de alguien que desea que se utilicen los datos para dar respuesta a alguna problemática detectada y cuando la persona que lo plantea sabe qué se desea hacer, pero el cómo casi siempre lo desconoce, por lo que el científico de datos se convierte en un traductor entre qué hacer y cómo hacerlo. Esto porque muchas veces aparece la solicitud como una inquietud general: “necesitamos entender mejor a los clientes”, “queremos controlar los costos”, “ocupamos un tablero” o “tenemos muchos datos y no sabemos qué hacer con ellos”. Para quien trabaja como científico de datos, esta etapa es decisiva porque marca la dirección de todo el trabajo posterior y debe estar claro la labor que se espera de él.
Recibir una solicitud no significa aceptarla de inmediato tal como fue expresada, debe ser escucharla con atención, entender el contexto y convertirla en un problema claro que debe resolver. Si alguien pide “analizar ventas”, se debe preguntar: ¿ventas de qué periodo?, ¿por producto, cliente, zona o vendedor?, ¿se busca explicar lo ocurrido o anticipar lo que podría pasar?, ¿qué decisión se tomará con el resultado? Estas preguntas no son trámites; son aspectos que clarifican la necesidad de negocio y guían el proyecto de datos a ejecutar.
Otro aspecto para clarificar es que no siempre quien solicita el análisis es quien usará los resultados. Puede haber gerencias, equipos operativos, clientes internos, personal técnico y personas responsables de tomar decisiones. Comprender quién necesita qué, ayuda a definir el lenguaje, el nivel de detalle y el tipo de producto final. Un tablero para una gerencia no debe diseñarse igual que una base de datos para un equipo técnico o para entes externos.
Una pregunta relevante es ¿Cómo sé que el proyecto fue exitoso? Los proyectos de datos se deben efectuar si tienen utilidad y cumplen un propósito, por ejemplo: reduce tiempos de revisión, mejora la calidad de una decisión, permite detectar riesgos, facilita el seguimiento de indicadores o genera aprendizajes. Sin criterios de éxito, el proyecto puede terminar produciendo muchos gráficos, pero no utilidad. También conviene definir restricciones: tiempo disponible, calidad de los datos, recursos técnicos, confidencialidad, permisos de acceso y alcance real del trabajo.
Cuando se está trabajando en la revisión de la solicitud del proyecto no se debe prometer resultados que los datos no pueden sostener. Tampoco se debe complicar innecesariamente una solicitud sencilla. El valor está en formular bien el problema y cuando la pregunta queda clara, el proyecto avanza con más orden, se reducen errores y se aprovecha mejor el tiempo. Para los científicos de datos, esta es una gran lección: antes de programar, graficar o modelar, hay que entender qué decisión se quiere mejorar. Ahí empieza el verdadero trabajo con datos.
La siguiente entrega seguiremos conversando al respecto.
