El año pasado, Emilie Schario y Taylor Murphy propusieron esta maravillosa idea de “dirigir su equipo de datos como un equipo de producto” . La premisa clave del artículo era la siguiente: los equipos de productos tienen muchas buenas prácticas que los equipos de datos se beneficiarían si adoptaran. Pero en algún punto del camino, perdimos de vista este punto y felizmente lo reemplazamos con testaferros: mantener sistemas de grado de producción para nuestros activos de datos , construir más productos de datos o definir minuciosamente qué significa producción al servicio de fortalecer los contratos de datos . Ciertamente vale la pena considerar todos estos, pero están más preocupados por el manejo adecuado de los datos y los activos de datos que por los equipos de datos que realmente generan el impacto.

La idea central aquí nunca fue cuestionar la definición y los límites del "Producto de datos" o establecer SLA para los productores de datos, sino obligarnos a reconsiderar cómo operan los equipos de datos utilizando equipos de productos como modelo.

Me gustaría pasar algún tiempo discutiendo precisamente cómo manejar su equipo de datos como un equipo de producto.

Dos ideas centrales: centrado en el usuario y proactividad

Hay dos principios básicos que encarnan los equipos de productos: centrado en el usuario y proactividad. Vamos a discutir cada uno a su vez.

Centrado en el usuario

Los mejores equipos de productos están centrados en el usuario. Hablan con sus clientes regularmente y dejan que los comentarios directos de los usuarios influyan directamente en su hoja de ruta. Este volante es el elemento vital de cualquier buen producto: garantiza que no solo sean características de envío sino que resuelvan problemas.

Los equipos de datos deben operar de la misma manera. Nos hemos enamorado demasiado de lo técnicamente interesante que puede ser nuestro trabajo y hemos olvidado que no somos refugios independientes para actividades científicas o de ingeniería: somos una unidad comercial contratada para brindar valor comercial. Y si nosotros, como los equipos de productos, no resolvemos los problemas comerciales con datos, nuestro "producto de datos" metafórico (todo el trabajo de datos que hacemos) está fallando.

Esto no significa responder de forma reactiva a las solicitudes ad hoc. Esto tampoco significa rechazar por completo los esfuerzos científicos. Simplemente significa mantenerse en sintonía con las necesidades del negocio y buscar oportunidades para ese fin. Si bien Taylor y Emilie sugieren que sus compañeros de trabajo son sus clientes, no creo que esto sea suficiente: el negocio es su cliente. Necesitas conocerlo, comprenderlo y orientar todo lo que haces en torno a él.

Proactividad

En segundo lugar, los mejores equipos de productos tienen procesos proactivos configurados para respaldar el proceso de creación de productos. Se proporcionan un espacio intencional para establecer la visión, generar ideas, perseguir proyectos apasionantes que se encuentran fuera del alcance de las solicitudes de los clientes.

Los equipos de análisis, por otro lado, rara vez operan así. Como mínimo, deberíamos dedicar algún tiempo a explorar datos fuera de las solicitudes entrantes. Y a nivel de equipo, debemos estar atentos a los patrones para que podamos diseñar intencionalmente nuestra hoja de ruta y hacer un trabajo de alto apalancamiento.

Dicho esto, el trabajo reactivo ciertamente todavía tiene su lugar: los analistas son el medio principal a través del cual la empresa puede explorar los datos, por lo que a menudo nos encontraremos necesariamente en un papel de apoyo. Pero la clave es presionar constantemente para comprender el contexto detrás de este trabajo y dejar que este contexto motive proyectos estratégicos de alto apalancamiento.

Pero, ¿cómo empezar?

El artículo original de LO tiene excelentes sugerencias a nivel de organización para hacer que todo esto sea posible: tenga suficiente personal para tener suficiente ancho de banda para ser estratégico; reunir un equipo multidisciplinar del que inspirarse. Para agregar a esto, aquí hay un par de cambios concretos a nivel de proceso que puede realizar de inmediato:

1. Establecer un proceso para la consolidación del conocimiento.‍

Poner el trabajo de su equipo en un solo lugar es un requisito previo para estar centrado en el usuario. Para que su trabajo esté centrado en el usuario, necesita una vista de todo el trabajo que se le pide que haga. Organizar su trabajo en un espacio compartido puede permitir la coincidencia de patrones en el trabajo de su equipo, equivalente a un equipo de producto que estudia los hallazgos de investigación de UX antes de la lluvia de ideas.

Este será su mayor obstáculo porque el incumplimiento es un gran problema. Las personas se esfuerzan por mantenerse en el statu quo y, con demasiada frecuencia, he visto fracasar las iniciativas de documentación/intercambio de conocimientos. Publicar trabajo en un espacio de trabajo wiki como Notion, Confluence o Dropbox paper (y para una solución específica de análisis, hiperconsulta) puede romper esta barrera.

Los componentes clave aquí para garantizar una adopción generalizada:

• Baje la fricción al uso. Por muy tentador que sea usar git y configurar un proceso de revisión por pares, las capas de proceso no garantizarán el rigor: reducirán la adopción. Haz algo fácil, ligero y concéntrate en asegurarte de que tu equipo ponga su trabajo en la herramienta.
• Establecer un andamiaje organizativo . Una vez más, use una herramienta como hiperconsulta, Notion o Confluence, con una estructura wiki que permitirá a su equipo establecer prácticas no solo en torno a la centralización, sino también a la organización . Acuerde categorías razonables y funcionales, y cree un documento central "Comience aquí" que incorpore nuevos analistas a sus prácticas.

2. Comprender íntimamente las necesidades del negocio.

No somos solo trabajadores técnicos. Somos un puente entre los datos y el resto del negocio. Y si simplemente nos sumergimos en los datos, que es solo un lado de esta conversación, no seremos tan efectivos como deberíamos.

Nos enorgullecemos de nuestra destreza técnica, pero solo somos efectivos en la medida en que sabemos por qué estamos haciendo nuestro trabajo. Sin una gran perspicacia comercial, redactaremos análisis sin sentido tras análisis hasta que nos trasladen al almacenamiento B y nuestras interacciones se releguen a la extracción de datos.

Cómo se ve esto, prácticamente hablando:

• Pregunta siempre por qué . Antes de sumergirse en SQL, asegúrese de estar alineado con sus partes interesadas en los objetivos comerciales. Escriba esto, acuerde un enfoque y, solo entonces, haga el trabajo. Esto sienta un precedente de que su participación en el proceso de toma de decisiones no se limita al trabajo técnico; como mínimo, será visto como un traductor y, en el mejor de los casos, como un socio de pensamiento.
• Preocúpate por el negocio. Suena obvio, pero con demasiada frecuencia he visto a analistas y científicos de datos cerrar los ojos ante el negocio y sumergirse en los aspectos técnicos de su trabajo. Este comportamiento es un presagio de una organización analítica verdaderamente disfuncional y de bajo impacto. Un mayor impacto generalmente no proviene de mejores análisis, sino del impacto basado en datos en niveles más altos de ejecución estratégica.

Conclusión

La naturaleza del análisis de datos ha evolucionado drásticamente en la última década. Tenemos acceso a más datos, más poder de cómputo y más herramientas que nunca. Pero aún no nos hemos dado cuenta de que debemos operar dentro de una organización con nuestros nuevos poderes. Puede ser útil aquí trasladar prácticas exitosas de otros dominios. De los equipos de productos, en particular, un enfoque centrado en el usuario y la proactividad puede significar la diferencia entre un equipo de análisis de la mesa de ayuda y uno que realmente impulsa la estrategia. Y la centralidad en el usuario y la proactividad provienen de una conciencia aguda de las necesidades comerciales y mejores prácticas de intercambio de conocimientos.

Entrada de blog original publicada en hiperconsulta.