Unificar la empresa, los datos y el código

Capítulo 4. Diseño conceptual de productos de datos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En este capítulo, aprenderás una definición nueva y directa de un producto de datos, descrito en cuatro facetas. También descubrirás un método llamado diseño del concepto primero para elaborar productos de datos y comprenderás su relación con los esquemas.

El diseño "primero el concepto" es una estrategia eficaz que salva la brecha de comunicación entre los equipos empresariales no técnicos y los equipos técnicos. Emplea herramientas universalmente comprendidas, como diagramas y hojas de cálculo, para representar ideas y retos.

La belleza del diseño del concepto primero reside en su simplicidad. Se traduce el lenguaje o lógica empresarial a un formato jerárquico, parecido a cómo funcionan JSON y JSON Schema: son lenguajes digitales que comprenden las máquinas. Al utilizar el diseño del concepto primero, se reduce el esfuerzo de convertir la lógica empresarial en código. Esto minimiza los errores e ineficiencias que suelen surgir cuando los desarrolladores y administradores de datos hacen suposiciones durante el modelado conceptual.

Imagina un producto de datos como una caja que contiene una única herramienta, completa con todo lo que el usuario necesita para realizar una tarea. Piensa en comprar a un amigo un regalo electrónico. Si al regalo le falta la pila o las instrucciones, tu amigo tendrá que buscar las piezas que le faltan, una experiencia frustrante. Así es precisamente como debes pensar en los productos de datos. Un producto de datos debe ser un paquete completo, que proporcione a los usuarios todo lo que necesitan para utilizar los datos con eficacia. El objetivo es evitar que los usuarios tengan que buscar componentes adicionales o "arreglar" elementos para que los datos sean utilizables.

El enfoque de diseño del concepto primero es la clave para crear estos productos de datos integrales. Es un método para traducir los conceptos que has derivado de las conversaciones con las partes interesadas a un formato de pseudocódigo. Este formato actúa como un relevo, permitiéndote pasar los conceptos a los profesionales de los datos para que los implementen de acuerdo con las necesidades empresariales de tu producto de datos. El diseño "primero el concepto" proporciona una representación de alto nivel de los conceptos (visual o textualmente), mientras que un esquema profundiza, formalizando estos conceptos con significado y estructuras jerárquicas.

Consejo

Considera esto: si entrevistas a cinco partes interesadas y les pides que describan un problema y los conceptos implicados, es probable que obtengas cinco perspectivas diferentes. Sin embargo, si les pides que formalicen sus definiciones en una estructura de datos de pseudocódigo, verás alineaciones y desalineaciones más concretas y sacarás a la luz las lagunas en la comprensión compartida de los conceptos y objetivos del problema.

Estar orientado a los datos se refiere a un enfoque en el que los datos están en el centro del proceso de toma de decisiones. La idea es que todas las ideas, estrategias y decisiones se basen en el análisis y la interpretación de los datos, y no sólo en la intuición o la experiencia personal. En un enfoque basado en los datos, éstos se consideran un activo fundamental, y los sistemas y procedimientos se diseñan en torno a ellos para garantizar su precisión, coherencia y disponibilidad.

Para orientarse por los datos, es crucial alinear primero a las personas con los conceptos que los datos van a representar. Aquí es donde entra en juego el diseño del concepto primero. El diseño del concepto primero consiste en definir los conceptos y sus relaciones antes de transformarlos en un modelo de datos. Empieza por comprender los requisitos empresariales, definir los conceptos clave y asegurarse de que todos los implicados tienen una comprensión compartida de lo que representan esos conceptos, para quién y por qué.

Estos conceptos constituyen la base del modelo de datos y ayudan a garantizar que refleja con precisión el escenario del mundo real que pretende representar. Para poner en práctica un diseño que dé prioridad a los conceptos, las partes interesadas deben definir estos conceptos, estructurarlos formalmente en esquemas, asignar significado al vocabulario utilizado, identificar cualquier laguna y trabajar en colaboración para alinear la comprensión de todos. Esto conduce a la creación de una comprensión compartida que satisfaga adecuadamente las necesidades de las partes interesadas. Una vez logrado este entendimiento compartido, el producto de datos está bien diseñado y listo para su aplicación.

La transformación en una organización centrada en los datos comienza con un enfoque de diseño que da prioridad al concepto, fomentando una cultura en la que las decisiones se toman basándose en los datos, lo que conduce a una mayor eficiencia, mejores conocimientos y una toma de decisiones más informada. Este capítulo es tu manual operativo. Como defensor de los datos, eres el enlace crucial entre las partes interesadas del negocio, los datos y los equipos de codificación. El capítulo 5 profundizará en los pormenores de la implementación. Por ahora, centrémonos en tu papel en la creación de un producto de datos convincente y eficaz.

Envases y productos: Un ejemplo con el café

Como hemos establecido, los datos deben considerarse un producto, y para recalcarlo vamos a utilizar un producto real, el café, como ejemplo para hablar de datos. Imagínate que eres un productor artesanal de café. Tu oficio gira en torno a un conocimiento detallado de las variedades de café y del proceso de transformación de los granos crudos en una tentadora infusión. Viajas a Colombia, uno de los principales países productores de café del mundo, para obtener los mejores granos y colaborar con los agricultores locales para garantizar unos métodos óptimos de recolección y procesamiento.

Optas por el tostado en lotes pequeños para mantener un control meticuloso del proceso, ajustando las condiciones de tostado para conseguir el perfil de sabor perfecto. A diferencia de los tostadores comerciales a gran escala, tu enfoque íntimo permite obtener un sabor más definido y refinado. Cada lote, incluso los del mismo origen, exige ajustes únicos basados en factores como la edad de los granos y las condiciones ambientales de tueste.

Una vez terminado el tueste, envasas los granos para protegerlos del oxígeno y la luz, y les pones una etiqueta en la que se indique la marca, el tipo de café, el nivel de tueste y otra información pertinente. Tu esperanza es llamar la atención de los compradores potenciales con tu tentadora mezcla y tu atractivo envase.

En una cafetería local, una mujer, empresaria de día y madre de noche, ve tu café en grano. Intrigada por el envase artesanal y previendo un largo día de resolver complejos problemas financieros, decide que tu café sería una forma excelente de empezar su jornada laboral. Así que compra tu producto.

No compraría el café si careciera del etiquetado adecuado. Ni la tienda lo vendería si no cumpliera la normativa de la FDA, incluido un etiquetado claro sobre el origen. Así que, antes de poder disfrutar del café, el cliente interactúa con el envase.

La bolsa proporciona contexto: indica el origen del café (Colombia), el fabricante (tú, el productor de café artesanal) y la finalidad del producto (suministrar café orgánico artesanal de tueste medio directamente de los agricultores). También contiene información nutricional y una lista de ingredientes, una estructura normalizada que explica la composición del producto. El código de barras de la bolsa permite a la tienda identificar el producto concreto que se compra, eliminando cualquier ambigüedad sobre la transacción. Sólo después de estas interacciones con el envase y la tienda puede el cliente utilizar el producto que contiene la bolsa: tus deliciosos granos de café.

En esta analogía, los granos de café simbolizan los datos. La diferencia entre los datos en bruto y un producto de datos radica en los elementos contextuales adicionales: quién, qué, cuál, por qué, cómo y dónde. Al igual que una bolsa de granos de café debe cumplir determinados requisitos antes de ser almacenada en la estantería y adquirida por un cliente, un producto de datos de calidad debe cumplir normas similares para que una organización pueda distribuirlo y utilizarlo con seguridad. Dejar lagunas entre los datos y los productos de datos suele dar lugar a despilfarros e ineficiencias en la forma en que las organizaciones gestionan los datos.

Las cuatro facetas de un producto de datos

Un producto de datos encapsula tanto los datos como su envoltorio en un objeto único y autónomo. Como gestor de productos de datos, tu papel es maximizar el valor del producto de datos, que se mide por la utilidad y la calidad de la experiencia del usuario para la persona que trabaja con los datos y su valor financiero. Un producto de datos bien diseñado tiene medidas y métricas claras, similares a los productos comerciales orientados al cliente, como los servicios de suscripción o los bienes físicos.

Si una empresa ya está monetizando sus datos vendiéndolos a otras empresas, inherentemente está tratando sus datos como un producto. Sin embargo, considerar los datos como un producto es aún más crucial cuando se piensa en los clientes internos, es decir, los empleados de la empresa. Los mismos principios y buenas prácticas que se aplican para crear productos de datos valiosos, fáciles de usar y alineados con la empresa para los clientes externos, deben utilizarse también para los productos de datos destinados al uso interno. Tanto si el producto de datos se dirige al exterior como al interior, sigue siendo un producto de la empresa y debe tratarse con el mismo nivel de cuidado, precisión y calidad. El valor de tratar los datos como un producto no se limita a las transacciones externas; es igualmente crucial para el tratamiento interno de los datos y los procesos de toma de decisiones.

La experiencia del usuario con un producto de datos comienza en el momento en que se encuentra con él. Si un usuario abre un archivo CSV y le cuesta entender los nombres de las columnas, su experiencia de usuario es deficiente. Podemos medir la experiencia del usuario con los datos del mismo modo que un gestor de productos mediría la usabilidad de un formulario web, incluyendo el tiempo empleado, el número de clics y cualquier problema que provoque abandonos u oportunidades perdidas.

Como gestor de productos de datos, tu función es crear experiencias fantásticas de productos de datos. Los productos de datos de alta calidad, fáciles de usar y alineados con el negocio ahorran tiempo, infunden confianza y están optimizados para los objetivos empresariales. Son, sin duda, un activo valioso para tu organización.

Sin embargo, si tu producto de datos no es un objeto autónomo, está incompleto y es de calidad inferior. La Figura 4-1 muestra las cuatro facetas de un producto de datos bien elaborado, que al igual que un producto físico, encapsula las dimensiones necesarias para minimizar la ambigüedad y reducir las lagunas de conocimiento y los puntos ciegos de nuestros datos.

Figura 4-1. Las cuatro facetas de un producto de datos tienen por objeto garantizar la higiene de los datos, tal como se describe en el Prefacio, de modo que cualquier persona que utilice datos disponga de todo lo necesario para trabajar con ellos de forma eficiente y eficaz en un objeto autónomo.

Un producto de datos bien diseñado, al igual que nuestro café artesanal, presenta las siguientes características. Piensa en ellas como en las cuatro facetas de una piedra preciosa:

Datos

Esto es el qué: la información real contenida en el producto de datos.

Estructura

Esta faceta trata del cómo. ¿Cómo se espera que se formatee la información cuando se comunique?

Significado

Esta faceta aborda el qué. ¿Qué definición de una palabra se pretende, dados el lenguaje y los conceptos transmitidos?

Contexto

Esto responde al por qué, dónde y quién. ¿Por qué se creó el producto y cuál es el problema que resuelve? ¿Dónde puede encontrarse (API, base de datos, tabla, linaje)? ¿Quién es responsable de la gobernanza, los acuerdos de nivel de servicio (SLA), los controles de acceso basados en funciones (RBAC), y quién lo creó?

Estas cuatro facetas ayudan a transformar los meros datos en un producto de datos significativo. Al igual que los granos de café por sí solos no darían lugar a la misma experiencia sin su envoltorio cuidadosamente diseñado, los datos por sí solos no son tan impactantes sin la estructura, el significado y el contexto adecuados.

Desde la perspectiva de un producto de datos, si tienes datos pero no las demás facetas en un objeto contenido, tienes un producto de datos incompleto y de mala calidad. La Figura 4-2 lo ilustra mejor comparándolo con un producto de granos de café.

Figura 4-2. Un producto de datos tiene cuatro facetas principales: datos, estructura, significado y contexto. Esto encapsula completamente en un único objeto (producto) los elementos clave que necesita un usuario de datos para trabajar eficazmente con ellos.

Un enfoque de producto de datos también hace que la búsqueda de datos y la búsqueda en los datos sea más eficaz, porque estás normalizando cómo se organiza la información sobre los datos, lo que puede ahorrar una enorme cantidad de tiempo.

Consejo

Para más información sobre la diferencia entre buscar en datos y buscar datos, echa un vistazo a El Catálogo de Datos Empresariales, de Ole Olesen-Bagneux (O'Reilly, 2023):

• Búsqueda de datos. Es fundamental que los empleados puedan encontrar datos fácil y rápidamente.

• Buscar en los datos. Es igualmente vital que los empleados puedan entender qué significan los conceptos de los datos, como los nombres de las columnas. Elimina la ambigüedad.

Una estrategia de datos unificada significa reducir el despilfarro y la ineficacia. Tener los datos, la estructura, el significado y el contexto ubicados en sistemas y lugares separados -o carecer de ellos por completo- añade cantidades increíbles de complejidad y caos a tus prácticas de gestión de datos.

Reúne el conjunto de datos, los metadatos, la gestión semántica, la gobernanza, etc. en una unidad única y completa: el producto de datos. Hacerlo producirá una experiencia de datos mucho mejor, que en última instancia será más eficaz y eficiente desde una perspectiva empresarial operativa, porque tus usuarios de datos no perderán tiempo buscando o utilizando múltiples sistemas para combinarlos manualmente. Y esto es lo que un buen diseño del producto de datos hará por tu organización.

Empezar con el Diseño Primero el Concepto

Uno de los autores de este libro, Ron, ha tenido varias experiencias con empresas que fueron revolucionarias para él como consultor. Para ilustrar estas experiencias, considera los siguientes ejemplos del mundo real (que se han fusionado y alterado para mantener en privado la identidad de las empresas).

Imagina que trabajas con la Empresa A, que obtiene unos ingresos de mil millones de dólares al año de un único producto estrella, una empresa que ha sido histórica y fiablemente dominante en su categoría en todo el mercado mundial. Su competidor más feroz, la Empresa B, acaba de lanzar una versión de IA de su producto similar, lo que ejerce una inmensa presión sobre los ejecutivos de nivel C de la Empresa A para que demuestren a su junta directiva que la empresa sigue siendo innovadora y tiene una respuesta a la nueva amenaza. La empresa A lidera actualmente la cuota de mercado, pero no es especialmente conocida por ser innovadora, y si no se ofrece pronto una solución de IA, existe una posibilidad muy real de que los clientes se pasen a la empresa B, lo que podría tener consecuencias negativas nefastas para la empresa A.

Para responder a la amenaza, se contrata a un equipo de científicos de datos e ingenieros de aprendizaje automático de primera categoría. Se les pagan salarios fantásticos: el dinero no es problema y no se escatiman gastos para contratar al equipo que los ejecutivos de nivel C puedan señalar como "el mejor del mundo".

Sin embargo, después de varios años, el equipo sigue sin poder crear una versión de IA del producto. Los plazos siguen retrasándose, y los equipos se culpan unos a otros. Entonces, los ejecutivos de nivel C hacen lo que hacen la mayoría de los ejecutivos: contratar a caros consultores para que les resuelvan el problema, creyendo que sus equipos internamente no podrían hacerlo. La cara empresa consultora procede a cobrar decenas de millones en honorarios de consultoría para traer equipos enteros de expertos caros y los servicios de computación en nube más potentes.

Se contrata a casi un centenar de personas o se las saca de otros equipos, de modo que el esfuerzo renovado tiene éxito, ¡y comienza la construcción del producto de IA! Pero un año después, el producto de IA sigue siendo terrible, los usuarios odian la experiencia, la IA no funciona muy bien, y ahora los ejecutivos de nivel C tienen que decir a su junta directiva que han malgastado años y muchas decenas de millones de dólares sin conseguir absolutamente nada.

Este es el punto de la historia en el que se trajo a Ron para ver qué podía encontrar, y el resultado fue que, en menos de un año, se construyó el motor de IA con una fracción del equipo, el tiempo y el coste del esfuerzo anterior. La técnica que se utilizó y perfeccionó a lo largo de muchos problemas, en muchas industrias y años, acabó llamándose diseño del concepto primero.

Nuestro énfasis en el diseño del concepto primero está en la palabra primero. Subraya la importancia de no precipitarse en el desarrollo, el diseño o las decisiones empresariales hasta que todos los conceptos estén meticulosamente diseñados y acordados por todas las partes interesadas. Para los equipos más técnicos, podrías describir este proceso como diseño del esquema primero, aunque el diseño del concepto primero es un término mucho más accesible para las personas no técnicas.

Un plan para unificar

Para ayudar a los líderes a comprender el poder transformador de la unificación dentro de una organización, dividamos el viaje en tres fases fundamentales: evaluar, alinear y acelerar. Cada fase sirve como bloque de construcción, y juntas ofrecen una vía estructurada para impulsar el cambio con eficacia, como se ilustra en la Figura 4-3:

Figura 4-3. Las tres fases de la unificación pueden resumirse utilizando este diagrama de flujo para explicar las actividades de unificación en un resumen de alto nivel. Tanto si eres un defensor de los datos interno como externo, ofrecer una descripción clara de cómo será la transformación puede ayudar a recabar apoyos.

1. Evaluar. El primer paso es una evaluación exhaustiva del estado actual de tu organización. Reúnete con las principales partes interesadas para escuchar, recopilar ideas y evaluar los distintos puntos de vista. La fase de evaluación comienza con un diseño conceptual para traducir las perspectivas de las partes interesadas en conceptos organizados y jerarquizados. Esto no sólo ayuda a recopilar datos, sino también a establecer una forma común de captar las perspectivas y el lenguaje en todos los departamentos. Con la ayuda de una hoja de cálculo o una pizarra bien diseñada, esta fase permite a todos comprender mejor las alineaciones o disparidades existentes.

2. Alinear. Armado con una evaluación exhaustiva, el siguiente paso es alinear las perspectivas dispares. El Capítulo 6 presenta la brújula conceptual, una herramienta diseñada para iluminar con precisión las diferencias entre las perspectivas de las partes interesadas. Sin embargo, esto también requiere una herramienta para conectar todos los hilos de las redes organizativas que utilizan esos conceptos, y los campeones de datos utilizarán el marco de gobierno de datos CLEAN, tratado en el Capítulo 7, para seguir un enfoque metódico y estructurado. Esta fase garantiza que todo el mundo esté en la misma página, lo que prepara a la organización para una acción específica.

3. Acelera. Una vez que los conceptos están definidos, alineados y conectados con una higiene de datos adecuada, están listos para ser descritos en el contexto de medidas de éxito y métricas que midan el progreso. Las principales herramientas de la fase de aceleración son los mapas de procesos anotados, tratados en el Capítulo 9, y los espectros de éxito y las estrategias de diseño de la UX del Capítulo 10. Las herramientas de la fase de aceleración permiten a los equipos de distintos ámbitos -negocio, datos, código, diseño, etc.- alinearse con una hoja de ruta de ejecución y unos criterios de medición claros.

La elaboración de productos de datos impecables requiere un compromiso riguroso con el principio de higiene de los datos, como se detalla en "Lo que no puedes ver puede matarte, y lo mismo ocurre con los datos". La progresión sistemática a través de las fases de evaluar, alinear y acelerar sirve para eliminar amenazas sutiles como la ambigüedad y las disparidades de conocimientos, sentando las bases de una colaboración mejorada, una toma de decisiones precisa y una productividad optimizada. Cuando nos adherimos a la higiene de los datos y, al mismo tiempo, mantenemos los principios generales de alineación entre los procesos y las redes organizativas, allanamos el camino para los avances en innovación, las iniciativas de ciencia de datos y la racionalización operativa.

Haciéndose eco de las ideas del Dr. Semmelweis sobre la indispensabilidad de la higiene de las manos en la atención sanitaria (véase "Lo que no puedes ver puede matarte, y lo mismo ocurre con los datos"), el valor de la higiene de los datos queda meridianamente claro. Al igual que el papel fundamental del lavado de manos en medicina, una higiene impecable de los datos es la base que garantiza que las organizaciones no sólo estén protegidas, sino que prosperen. Ignorar la higiene de los datos puede tener consecuencias desastrosas.

Evaluar, alinear y acelerar no es sólo un mantra; es nuestro mapa.

Cartografiar el terreno conceptual: Evaluar los conceptos

La fase de evaluación es una exploración estructurada de la mente colectiva de tu equipo. Se trata de una serie de entrevistas individuales con las principales partes interesadas y colaboradores de todo el equipo. Esto incluye a desarrolladores, diseñadores, gestores de productos, científicos de datos y otros. Esta fase consiste en pedir a las personas que entrevistes que compartan su perspectiva sobre el trabajo que hacen:

1. Describe los problemas importantes que hay que resolver. Pide a las personas que describan en qué problemas están trabajando, hacia qué objetivos, qué acciones emprenden y cómo se mide el éxito con los resultados. Sus descripciones pueden ser visuales en una pizarra o en un documento como PowerPoint, Excel o Google Docs.

2. Aclara los conceptos importantes que contienen. Con el mapa de los problemas, objetivos, acciones y métricas de éxito más importantes en la mano, explótalos con tu entrevistado. Simplemente capta las palabras y sus significados en un lenguaje sencillo, y si hay cálculos (como beneficios o compromiso del cliente), pídeles que especifiquen exactamente cómo se miden. La mejor forma de hacerlo es en una hoja de cálculo, cuyo ejemplo se muestra en la Figura 4-4.

3. Ordena los conceptos en relaciones jerárquicas. Una vez que tengas algunos significados, pide a la gente que descomponga los conceptos en componentes más granulares en una estructura jerárquica de relación padre-hijo o hijo-hermano. Es el mismo formato que utiliza un esquema. También es mejor hacerlo en el formato de hoja de cálculo que se muestra en la Figura 4-4.

Figura 4-4. Uso de una hoja de cálculo para el diseño del primer concepto. Se utilizan tres columnas para cualquier concepto: Nivel nº, Tipo (objeto, número, texto, lista, etc.) y Definición. Éstas son las que se utilizan para crear el significado de los conceptos. Cuando quieras añadir un subconcepto (también conocido como concepto hijo), añades esos conceptos hijos en la columna que representa el siguiente nivel. Por ejemplo, para el concepto Producto (nivel 1), el concepto hijo Título se añade en el nivel 2. Esta superposición de niveles de conceptos se convierte en una estructura jerárquica, que es otra forma de decir un esquema.

Tu evaluación será la siguiente. Recopila todas las perspectivas de los interesados y colaboradores y muestra lo alineadas o desalineadas que están. Ahora tienes una forma cuantitativa de proporcionar información a los líderes y al equipo, mostrando que, por ejemplo, de cinco personas, sólo dos estaban de acuerdo exactamente en lo que significan determinados conceptos y en cómo se estructuran. ¿Cómo puede un equipo colaborar eficazmente si no está unificado en torno a los conceptos que los datos y el código deben captar? Normalmente no pueden. Y si pides a un diseñador, un ingeniero de datos, un comercial, un líder empresarial y un ingeniero de software que den con el significado y la estructura de los conceptos, todos ellos tendrán sus propias perspectivas particulares.

Consejo

El paso fundamental en el diseño del concepto primero es siempre anteponer la comprensión de la constelación de conceptos a la toma de decisiones para invertir (negocio), analizar (datos) y construir (código).

La Figura 4-4 muestra una hoja de cálculo que actúa como esquema. Representa visualmente la jerarquía de conceptos de un producto, ilustrando los niveles de ordenación y las entidades previstas en cada nivel. Este enfoque acerca el diseño de esquemas a todo el mundo, no sólo a los desarrolladores. Ofrece una forma única y accesible de elaborar estructuras de conceptos similares a cómo se crearían en JSON.

La organización de los conceptos en este formato CSV difiere de un esquema tradicional. Un esquema tradicional se centra principalmente en la estructura jerárquica de los conceptos, mientras que este esquema basado en CSV integra tanto la estructura como el significado. Por tanto, no es sólo una hoja de cálculo; es una representación completa que incluye información semántica junto a la jerarquía conceptual. Este enfoque integrado ayuda a prevenir y reducir la ambigüedad, mejorando así la eficacia en la gestión de datos y el desarrollo de sistemas.

Facilitar la evaluación de la alineación conceptual entre equipos técnicos y no técnicos

La Figura 4-5 muestra un ejemplo real, o una instancia, de un producto de café, construido utilizando el modelo proporcionado por el esquema de la Figura 4-4. Esencialmente, la Figura 4-4 esboza la estructura esperada de un objeto producto, y la Figura 4-5 demuestra cómo rellenar esa estructura con datos específicos sobre un producto real.

El verdadero poder de los esquemas conceptuales, como se demuestra en la Figura 4-5, reside en su accesibilidad y en la sencillez que aportan a la expresión de la lógica empresarial. Utilizando una hoja de cálculo sencilla, la lógica empresarial puede traducirse sin problemas y directamente en objetos JSON. Este enfoque mejora enormemente la eficacia y elimina un importante punto problemático: la tarea, a menudo compleja y propensa a errores, de traducir el lenguaje de los interesados en el negocio en requisitos técnicos funcionales.

Los desarrolladores se enfrentan con frecuencia al reto de traducir los requisitos empresariales en código funcional. Los líderes empresariales suelen articular sus necesidades basándose en su perspectiva, arraigada en la estrategia empresarial, las demandas de los clientes o las tendencias del mercado. Sin embargo, estas necesidades no siempre se comunican en términos que los desarrolladores puedan traducir fácilmente en un diseño técnico. Esta brecha en la comunicación no se debe a una falta de esfuerzo por ambas partes, sino más bien a que el negocio y el desarrollo son dos dominios distintos con su propia jerga, perspectivas y prioridades.

El reto reside en el hecho de que los desarrolladores no leen la mente. No pueden intuir los intrincados matices de un requisito empresarial a menos que se les explique explícitamente. Cuando no se cumplen las expectativas, a menudo se produce frustración y culpa, y los desarrolladores cargan con la culpa por no entender lo "obvio". Esta situación da lugar a una pérdida de tiempo, recursos y relaciones tensas entre los equipos. Además, crea un entorno de constantes revisiones, retrasos en los proyectos y productos finales de calidad inferior.

Figura 4-5. Un esquema conceptual. El esquema conceptual de la Figura 4-4 puede mapearse uno a uno a una representación JSON. Este mapeo facilita que los equipos técnicos y no técnicos comprendan dónde están alineados o desalineados en la forma de modelar y comunicar los conceptos utilizados entre equipos y sistemas tecnológicos, y de integrarlos en procesos empresariales funcionales.

Los esquemas conceptuales pueden ayudar a salvar esta brecha de comunicación. Proporcionan un lenguaje común tanto a los líderes empresariales como a los desarrolladores para articular y comprender los requisitos. Al organizar los conceptos de una manera estructurada y jerárquica que incluye tanto el significado como la estructura, los esquemas conceptuales ofrecen una hoja de ruta clara para los desarrolladores. Permiten a los desarrolladores ver lo que imaginan los líderes empresariales, en un formato que puede traducirse directamente en código. Este enfoque reduce la ambigüedad, garantiza la alineación de las expectativas y agiliza el proceso de convertir la lógica empresarial en requisitos funcionales, lo que conduce a proyectos más exitosos y a una mejor relación de trabajo entre los equipos.

JSON y los esquemas JSON, al ser lenguajes legibles tanto por humanos como por máquinas, son elementos cruciales del diseño del concepto primero. Durante la fase de evaluación de la unificación, es esencial incluir en tu evaluación tanto a los equipos técnicos como a los no técnicos. El objetivo es evaluar la alineación general de la organización en lo que respecta a los datos vertical y horizontalmente en varios dominios.

Consejo

Si los aspectos técnicos te parecen desalentadores, no te preocupes. No tienes que escudriñar el código personalmente. En lugar de ello, colabora estrechamente con un desarrollador que pueda examinar las estructuras de datos del código y aportar información sobre la alineación o desalineación entre los equipos técnicos y no técnicos.

Si el equipo técnico necesita más datos de los que el equipo empresarial ha definido en su representación, está perfectamente bien. Puede haber una necesidad técnica legítima de información adicional. No obstante, es crucial que los equipos de negocio, datos y código lleguen a un consenso sobre las representaciones de los conceptos fundamentales, alineándolas con el primer paso de nuestra evaluación: definir los problemas críticos a resolver y su contexto, incluyendo objetivos, acciones y métricas de éxito.

La fase de evaluación no consiste únicamente en medir las diferencias conceptuales entre los miembros del equipo o entre las representaciones codificadas de los conceptos. También consiste en calibrar las disparidades entre los conceptos y los problemas, objetivos, acciones y métricas de éxito definidos.

En la aventura de consultoría descrita anteriormente, Ron descubrió que una sola palabra -sólo una- que se utilizaba en las métricas de éxito tenía diferentes interpretaciones en los distintos equipos. Para el equipo empresarial, la palabra adaptable significaba que el éxito estaba ligado a la capacidad de su producto actual para adaptar la experiencia del usuario a su modelo de negocio actual, que estaba, casualmente, ligado a los KPI que medían su éxito, bonificaciones, etc. En cambio, el equipo de ciencia de datos evaluó el éxito de ser adaptable basándose en la precisión con la que sus modelos predictivos podían adaptar la experiencia del usuario, no optimizada para los KPI del equipo empresarial, sino para lo que era mejor para la experiencia del usuario.

Puedes aplicar el diseño del concepto primero literalmente a cualquier cosa que pueda conceptualizarse, incluidas las métricas de éxito. Una vez que hayas realizado tus evaluaciones, mostrando las lagunas de alineación, puedes empezar a trabajar en la alineación de los equipos con un esquema compartido de diseño del concepto primero, que exploraremos más adelante en el libro. El capítulo 5 explica cómo un gestor de productos de datos o un campeón de datos debe familiarizarse con los aspectos técnicos de la implementación y el uso de esquemas con el Esquema JSON, lo que permitirá a los equipos técnicos empezar a diseñar esquemas con fines técnicos.

Suave es lento, lento es rápido

La frase "ir despacio para ir suave, ir suave para ir rápido" subraya la importancia de tomarse el tiempo necesario para aprender a hacer algo correctamente antes de centrarse en la velocidad. Este enfoque se aplica por igual al aprendizaje de un instrumento musical y al aprendizaje de cómo alinear los esfuerzos de innovación.

Evaluar primero los conceptos, como se muestra en la Figura 4-4, es una forma sencilla de hacer preguntas básicas a los interesados, conocer sus problemas y averiguar en qué difieren sus opiniones de las de otros interesados. Esta evaluación es de vital importancia, aunque parezca que ralentiza considerablemente a tu equipo. Algunas de las preguntas que merece la pena hacer pueden parecer tontas, obvias o incluso insultantes. Sin embargo, una y otra vez en consultoría, hemos comprobado que estas preguntas obvias nunca se han planteado, y el resultado suelen ser errores muy costosos relacionados con los datos.

Consejo

Unificar es una práctica continua. Si aparecen desajustes, es importante volver a empezar el proceso y revisar tus esquemas de conceptos iniciales para identificar dónde pueden haber surgido malentendidos.

Éstos son algunos de los beneficios que obtendrás con la unificación:

• En los entornos en los que se da prioridad a la alineación y ésta prospera, los equipos colaboran con mucha más fluidez y son capaces de intercambiar ideas, conocimientos y recursos. Esta colaboración conduce a una cultura de aprendizaje y mejora continuos, que capacitará a tu organización para adaptarse y responder rápidamente a los retos.

• La capacidad de adaptarse y responder al cambio es crucial para el éxito de cualquier empresa. La alineación significa una mejor comprensión de cómo operar de forma más ágil y adaptable, ya que los equipos están mejor equipados para comprender las implicaciones de las nuevas percepciones, tendencias y requisitos cambiantes.

• Un resultado desafortunado de los cuellos de botella en torno a la gestión centralizada de datos es que algunos equipos se desesperan tanto por encontrar soluciones que rodean al equipo de gestión centralizada de datos y construyen o contratan sus propias soluciones de datos para avanzar. Sin embargo, no implicar al equipo de datos en las decisiones sobre la arquitectura o el almacenamiento de datos puede provocar problemas de calidad de los datos, infracciones de seguridad y deuda técnica. Asegurarse de que todos están alineados permite a los equipos que se enfrentan a cuellos de botella avanzar con mucho menos riesgo, porque saben exactamente qué conceptos alinear y cómo hacerlo.

Resumen

En este capítulo se analizó la importancia de los productos de datos internos de las organizaciones, estableciendo comparaciones con los productos comerciales orientados al cliente. Enfatizó la necesidad de una buena experiencia de usuario en los productos de datos y subrayó el papel de un gestor de productos de datos en la creación de excelentes experiencias de productos de datos.

Las cuatro facetas de un producto de datos son los datos, la estructura, el significado y el contexto. En este capítulo se han ilustrado estas facetas utilizando una analogía con el grano de café, afirmando que un producto de datos sin alguna de estas facetas está incompleto y es de calidad inferior.

Vimos cómo un enfoque basado en productos de datos hace que la búsqueda de datos sea más eficaz al normalizar cómo se organiza la información sobre los datos. Se discutió la diferencia entre buscar en datos y buscar datos.

Aprendimos que ser Ágil, en el contexto de unificar, aboga por reducir el despilfarro y la ineficacia reuniendo el conjunto de datos, los metadatos, la gestión semántica y la gobernanza en una única unidad completa: un producto de datos. Este enfoque mejora la experiencia de los datos al agilizar los procesos relacionados con ellos, y demuestra ser más eficaz y eficiente en comparación con los métodos tradicionales para convertirse en una organización basada en datos.

Describimos los tres pasos para unificar: evaluar, alinear, acelerar. La fase de evaluación implica una exploración estructurada de la mente colectiva del equipo para comprender las lagunas y la gravedad de la desalineación entre los equipos. La fase de alineación se centra en disipar las ilusiones de comunicación y lograr una alineación eficaz en todos los niveles de la organización. La fase de aceleración hace hincapié en iterar rápidamente para obtener retroalimentación e implantar y probar soluciones de forma ágil.

Por último, revisamos los riesgos de acelerar sin unificar satisfactoriamente: hacerlo podría llevar a construir más rápido lo que no se debe. Unificar da prioridad a la precisión antes de centrarse en la velocidad y hace hincapié en alinear continuamente los esfuerzos del equipo de datos con los objetivos generales de la organización.

Ir entre niveles altos y bajos de abstracción en tu búsqueda de la unificación es la estrategia que seguirás aprendiendo a lo largo de este libro. En el Capítulo 5, tú, el campeón de los datos, pasarás de pensar de una forma estratégica de alto nivel sobre la unificación de conceptos a una forma de pensar de bajo nivel sobre la unificación de conceptos a nivel de código utilizando el Esquema JSON.