Escucha los sustantivos
También en 28 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 1 de 6 del capítulo Modelar los datos con sentido, capítulo 2 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: la presentación del capítulo · Siguiente: Dibuja las relaciones
La pregunta que responde este módulo: ¿Cómo encuentro el comienzo de un modelo de datos en una conversación de negocio?
Una de las cosas que hago en una primera llamada con un cliente es escuchar los sustantivos.
No me refiero a la primera sesión de diseño. Me refiero a esa conversación inicial en la que todavía intento entender el negocio y lo que quieren lograr.
Ellos hablan. Yo escucho.
Y estoy atento a palabras como:
Socio minorista. Destinatario. Centro de distribución. Manifiesto. Entrega. Ruta. Equipo. Camión.
Esos sustantivos captan mi atención de inmediato, porque en algún lugar de esa conversación está el comienzo de mi modelo de datos.
No espero a creer que entiendo el problema por completo. Empiezo a ver los datos mientras todavía escucho: oigo los sustantivos, empiezo a esbozar cómo se relacionan, y ese esbozo me ayuda a enfocar la siguiente conversación. A veces, al terminar una primera reunión con un cliente, ya tengo dibujado mi propio modelo de datos privado.
Para mí, todo empieza con los sustantivos.
Olvida Salesforce por un minuto
Sección titulada «Olvida Salesforce por un minuto »Aquí es donde quiero que resistas un instinto que es especialmente fuerte si llevas un tiempo como administrador de Salesforce.
El cliente habla de sus clientes, y tú piensas:
Cuenta.
Habla de una persona, y tú piensas:
Contacto.
Habla de un centro de distribución, y ya te estás preguntando si necesitas un objeto personalizado.
No lo hagas todavía.
A estas alturas, no me importa si un cliente termina siendo una Cuenta, una Cuenta personal, un objeto personalizado u otra cosa. Primero quiero entender el negocio.
Esa es la diferencia entre modelar el negocio y configurar Salesforce. Si empiezo por los objetos de Salesforce, ya he limitado mi pensamiento a una sola implementación. Puede que termine exactamente donde esperaba, pero quiero llegar ahí porque el negocio me llevó, no porque Cuenta y Contacto fueran los dos primeros objetos que conocía.
Así que, durante unos minutos, olvida Salesforce. Escucha cómo describen su mundo las personas que realmente dirigen el negocio.
Sentado, quieto, modelo
Sección titulada «Sentado, quieto, modelo »Antes de escuchar a un negocio, escuchemos algo que todo el mundo ya entiende. Cuando enseño esto en vivo, empiezo con perros.
Aquí hay un perro: Marcus es el dueño de Bella. Maple Ridge Kennels la crió. Es una labrador y sabe Sentado, Quieto y Dar la pata.
Escucha los sustantivos: Marcus, Bella, Maple Ridge Kennels, labrador, Sentado. Pero esos son nombres: las cosas concretas. Lo que quiero es el tipo de cosa al que pertenece cada nombre. Bella es un Perro. Marcus es un Dueño. Maple Ridge Kennels es un Criador. Labrador es una Raza. Sentado es un Truco. Cinco sustantivos, cinco cajas candidatas.
Luego, la pregunta que le hago a cada sustantivo: ¿es una persona haciendo un trabajo, o es un dato? Marcus es una persona. Pero ser dueño de Bella no es un trabajo; es un hecho sobre Bella, y tarde o temprano alguien pregunta: “¿De quién es este perro?”. Así que el Dueño pertenece al modelo. El entrenador que le enseñó a Bella a dar la pata es una persona haciendo un trabajo, y quizá nunca necesite una caja, a menos que el negocio empiece a preguntar quién enseñó qué truco.
Y fíjate en la palabra candidata. ¿La Raza es realmente una caja propia, o solo una palabra escrita sobre el perro? Guarda esa pregunta; la responderemos cuando normalicemos en el módulo 4.
Esa es toda la técnica, sobre algo pequeño. Ahora escuchemos a un negocio real.
Los sustantivos te dan entidades candidatas
Sección titulada «Los sustantivos te dan entidades candidatas »Escuchemos a Steve Trucking, la empresa familiar que usaremos durante todo el curso. Entrega artículos grandes (refrigeradores, lavadoras, televisores) desde los centros de distribución de grandes minoristas hasta los hogares de las personas, e instala algunos de ellos.
En la primera conversación oímos:
- Socio minorista (Retail Partner)
- Destinatario (Recipient)
- Centro de distribución (Distribution Center)
- Manifiesto (Manifest)
- Entrega (Delivery)
- Ruta (Route)
- Equipo (Crew)
- Camión (Truck)
Eso ya es útil. Puedo empezar a poner cajas en una pizarra.
Así que pon los sustantivos en rectángulos. Eso es todo lo que son en este punto: cajas. Sin líneas, sin colores, nada que diga Salesforce. Más adelante en el curso, las formas y los colores empezarán a significar algo. Por ahora, un rectángulo es solo algo de lo que habla el negocio.
Después empieza a orientarlos. Al colocar cada caja, conviene pensar en dos cosas: cómo se relacionan entre sí y qué tipo de datos son. Algunos son datos de clientes: las empresas y las personas con las que trabajamos. Otros son datos transaccionales, como los pedidos y sus líneas: las cosas que ocurren una y otra vez. Y otros son datos de referencia, como los productos o servicios que ofrece una empresa: aquello de lo que depende el trabajo.
En Steve Trucking, el Socio minorista y el Destinatario son datos de clientes. El Manifiesto, la Entrega y la Ruta son transacciones. El Centro de distribución, el Equipo y el Camión son aquello de lo que depende el trabajo.
Pero aquí hay una palabra importante: candidata.
Un sustantivo es una pista. No es automáticamente una entidad, y desde luego no es automáticamente un objeto de Salesforce.
Cuando estoy en una sesión de descubrimiento, anoto cada sustantivo. Con cada sustantivo que dicen, me hago una pregunta: ¿es una persona haciendo un trabajo, o es un dato? Un gerente de desarrollo de negocio es una persona haciendo un trabajo. Eso es un usuario, una función, quizás un conjunto de permisos. Pedidos, facturas, líneas de pedido: esos son datos. Ambos importan, pero terminan en lugares muy distintos del diseño, y separarlos pronto me evita dibujar una caja por cada puesto del organigrama.
Ahora bien, algunos de esos sustantivos serán personas. En Steve Trucking, son el Destinatario que espera el refrigerador, las personas del Socio minorista que envían el manifiesto y el Equipo: los conductores y ayudantes del camión. Son roles, y un rol puede no parecer un dato. Pero cuando las personas actúan sobre los datos, o están relacionadas con ellos, tienen que estar representadas en los propios datos. ¿Quién entregó esto? ¿Quién firmó la recepción? ¿Quién envió el manifiesto? Así que muchos roles, a veces todos, también terminan en el modelo.
Escucha cómo habla Steve Trucking y notarás algo. Nunca dicen simplemente «cliente». Hay dos tipos de cliente. El Socio minorista es el gran minorista para el que Steve Trucking entrega: envía el manifiesto y paga por entrega. El Destinatario es la persona a la que se le entrega el refrigerador. El Destinatario lo compró en la tienda y puede que nunca haya oído hablar de Steve Trucking.
Si hubiera dibujado una caja llamada Cliente, habría mezclado dos cosas completamente distintas.
Quizás el Centro de distribución sea lo bastante importante como para tener su propio registro, historial, relaciones y atributos.
Quizás otro sustantivo resulte no ser más que un atributo de otra cosa.
Eso es lo que intentamos descubrir. Todavía no estamos creando objetos. Estamos construyendo nuestra comprensión del negocio.
Ahora escucha las relaciones
Sección titulada «Ahora escucha las relaciones »Los sustantivos me dan un punto de partida. Luego escucho cómo los conecta el negocio.
Un Socio minorista opera Centros de distribución.
Un Socio minorista envía un Manifiesto por cada centro de distribución y día de entrega.
Un Manifiesto enumera Entregas.
Una Entrega va a un Destinatario.
Una Ruta es el recorrido de un día con unas diez Paradas.
Un Equipo de dos personas maneja un Camión.
Ahora algo está pasando. Ya no estoy mirando una lista de sustantivos. Estoy empezando a ver un modelo.
Aquí es también donde empiezan a aparecer las preguntas.
¿Puede un Socio minorista tener más de un centro de distribución?
¿Es una entrega lo mismo que una parada?
¿Puede una parada entregar a dos Destinatarios?
¿Un equipo está siempre formado por las mismas dos personas?
¿Nos importa qué equipo tuvo qué camión el mes pasado, o solo qué camión conducen hoy?
Fíjate en lo que estamos haciendo. Todavía no hacemos preguntas sobre Salesforce. Hacemos preguntas de negocio. Y esas respuestas acabarán guiando el diseño en Salesforce.
Tu primer modelo no tiene que ser perfecto
Sección titulada «Tu primer modelo no tiene que ser perfecto »No espero que las primeras cajas que dibujo sobrevivan sin cambios. De hecho, sospecharía si lo hicieran.
El objetivo del primer modelo no es acertar. El objetivo es darnos algo lo bastante concreto como para descubrir en qué nos equivocamos.
Pon Entrega, Ruta, Equipo y Camión en la pizarra y la gente podrá reaccionar.
«En realidad, una entrega no siempre es un solo artículo. Puede ser una lavadora, una secadora y la retirada de las viejas.»
Bien. Cuéntame más.
«No asignamos un equipo a una entrega. Asignamos el equipo a una ruta.»
Genial. ¿Qué hay en la ruta?
«Y si hay una instalación, el equipo no puede cerrar la parada hasta completar la lista de verificación y las fotos.»
Ahora estamos aprendiendo algo importante.
Un diagrama ha convertido una conversación vaga en algo que podemos cuestionar. Esa es una de las razones por las que me gusta modelar pronto. No intento impresionar a la sala con un diagrama bonito. Intento aprender más rápido.
El modelo es parte de la conversación.
Este es tu modelo conceptual
Sección titulada «Este es tu modelo conceptual »Lo que hemos empezado a construir tiene un nombre formal: un modelo de datos conceptual.
En este nivel, me interesan las cosas importantes que le importan al negocio y cómo se relacionan. Todavía no me preocupan los objetos estándar frente a los personalizados, los nombres de API de los campos, las relaciones de búsqueda frente a las de principal-detalle, los campos obligatorios, los índices, la automatización, Apex ni los Flows. Esas cosas importan, y llegaremos a ellas. Pero si las decidimos antes de entender lo que estamos modelando, estamos resolviendo primero el problema equivocado.
El modelo conceptual debe tener sentido para las personas de la sala que no conocen Salesforce. Es una prueba útil. Si tengo que explicar qué significa Delivery__c antes de que el gerente de operaciones pueda leer mi diagrama, he pasado a la implementación demasiado pronto.
Quiero que miren el modelo y digan:
«Sí, así funciona nuestro negocio.»
O, mejor aún:
«No, así no funciona.»
Porque entonces tengo algo que corregir.
La misma técnica funciona cuando nadie está hablando
Sección titulada «La misma técnica funciona cuando nadie está hablando »No es algo que use solo en el descubrimiento con clientes. También funciona cuando el «cliente» es un documento.
Cuando trabajo con un documento de requisitos, hago prácticamente lo mismo. ¿Cuáles son los conceptos de negocio importantes? ¿Qué relaciones se describen? ¿Qué aparece una y otra vez? ¿Qué tiene su propio ciclo de vida, necesita identificarse por sí mismo o necesita historial? ¿Qué se crea, se cambia, se asigna, se transfiere, se programa o se retira?
Son las mismas cosas que escucho en esa primera reunión. En una página, esas pistas convierten párrafos de requisitos en un modelo sobre el que puedo razonar, y en mejores preguntas para la siguiente conversación.
Un modelo no es solo algo que produces después de haber resuelto el problema. Es una de las herramientas que usas para resolverlo.
Lo que decide un arquitecto aquí
Sección titulada «Lo que decide un arquitecto aquí »Al terminar esta primera pasada, intento decidir:
- Qué sustantivos representan entidades candidatas con sentido.
- Qué palabras distintas representan el mismo concepto de negocio, y qué palabra esconde dos (como «cliente»).
- Qué conceptos necesitan un registro y un ciclo de vida propios.
- Cómo se relacionan entre sí los conceptos principales.
- Qué preguntas tiene que responder el negocio antes de que pueda modelarlos con confianza.
No estoy decidiendo todavía la implementación en Salesforce. Primero necesitamos entender el negocio lo bastante bien como para dibujarlo. Y una vez que tenemos los sustantivos en la pizarra, lo siguiente que quiero entender son las líneas entre ellos.
Más allá del examen: lo que cambia la IA. Dale a una herramienta de IA un documento de requisitos y encontrará los sustantivos, propondrá entidades y esbozará relaciones en segundos. Úsala para acelerar el descubrimiento, pero no delegues la comprensión: no puede saber que «cliente» significa dos cosas distintas en Steve Trucking a menos que el negocio te lo diga. Pon su primer modelo delante de las personas que dirigen el negocio y pregunta: «¿De verdad así funciona su negocio?»