Ascolta i sostantivi
Disponibile anche in 28 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · 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)
Modulo 1 di 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: la panoramica del capitolo · Successivo: Disegna le relazioni
La domanda a cui risponde questo modulo: Come trovo gli inizi di un modello dati in una conversazione di business?
Una delle cose che faccio alla prima chiamata con un cliente è ascoltare i sostantivi.
Non parlo della prima sessione di progettazione. Parlo di quella conversazione iniziale in cui sto ancora cercando di capire il business e cosa vuole ottenere.
Loro parlano. Io ascolto.
E ascolto parole come:
Partner retail. Destinatario. Centro di distribuzione. Manifesto di carico. Consegna. Percorso. Squadra. Camion.
Quei sostantivi attirano subito la mia attenzione, perché da qualche parte in quella conversazione ci sono gli inizi del mio modello dati.
Non aspetto di pensare di aver capito del tutto il problema. Comincio a vedere i dati mentre sto ancora ascoltando: sento i sostantivi, inizio ad abbozzare come si collegano, e quello schizzo mi aiuta a impostare la conversazione successiva. A volte, alla fine di un primo incontro con un cliente, ho già disegnato il mio modello dati personale.
Per me, tutto comincia dai sostantivi.
Dimentica Salesforce per un minuto
Sezione intitolata “Dimentica Salesforce per un minuto ”Qui voglio che tu resista a un istinto particolarmente forte se fai l’amministratore Salesforce da un po’.
Il cliente dice cliente, e tu pensi:
Account.
Dice persona, e tu pensi:
Contatto.
Dice centro di distribuzione, e ti stai già chiedendo se ti serve un oggetto personalizzato.
Non farlo ancora.
A questo punto non mi interessa se alla fine un cliente diventerà un Account, un Account personale, un oggetto personalizzato o qualcos’altro. Prima voglio capire il business.
Questa è la differenza tra modellare il business e configurare Salesforce. Se parto dagli oggetti Salesforce, ho già limitato il mio pensiero a una sola implementazione. Potrei arrivare esattamente dove mi aspettavo, ma voglio arrivarci perché mi ci ha portato il business, non perché Account e Contatto erano i primi due oggetti che conoscevo.
Quindi, per qualche minuto, dimentica Salesforce. Ascolta come le persone che gestiscono davvero il business descrivono il loro mondo.
Seduto, resta, modello
Sezione intitolata “Seduto, resta, modello ”Prima di ascoltare un business, ascoltiamo qualcosa che tutti capiscono già. Quando lo insegno dal vivo, comincio dai cani.
Ecco un cane: Marcus è il proprietario di Bella. L’ha allevata Maple Ridge Kennels. È un Labrador, e conosce Seduto, Resta e Dai la zampa.
Ascolta i sostantivi: Marcus, Bella, Maple Ridge Kennels, Labrador, Seduto. Quelli però sono nomi: le cose specifiche. Quello che voglio è il tipo di cosa a cui appartiene ciascun nome. Bella è un Cane. Marcus è un Proprietario. Maple Ridge Kennels è un Allevatore. Labrador è una Razza. Seduto è un Esercizio. Cinque sostantivi, cinque riquadri candidati.
Poi la domanda che faccio a ogni sostantivo: è una persona che svolge un lavoro, o un dato? Marcus è una persona. Ma possedere Bella non è un lavoro; è un fatto che riguarda Bella, e prima o poi qualcuno chiede: “Di chi è questo cane?”. Quindi il Proprietario va nel modello. L’addestratore che ha insegnato a Bella a dare la zampa è una persona che svolge un lavoro, e potrebbe non aver mai bisogno di un riquadro, a meno che il business non cominci a chiedere chi ha insegnato quale esercizio.
E nota la parola candidato. Razza è davvero un riquadro a sé, o solo una parola scritta sul cane? Tieni a mente questa domanda; le risponderemo quando normalizzeremo nel modulo 4.
Questa è tutta la tecnica, su qualcosa di piccolo. Ora ascoltiamo un business vero.
I sostantivi ti danno entità candidate
Sezione intitolata “I sostantivi ti danno entità candidate ”Ascoltiamo Steve Trucking, l’azienda familiare che useremo in tutto il corso. Consegna articoli ingombranti (frigoriferi, lavatrici, TV) dai centri di distribuzione delle grandi catene fino alle case delle persone, e ne installa alcuni.
Nella prima conversazione sentiamo:
- Partner retail
- Destinatario
- Centro di distribuzione
- Manifesto di carico
- Consegna
- Percorso
- Squadra
- Camion
È già utile. Posso iniziare a mettere dei riquadri su una lavagna.
Quindi metti i sostantivi in rettangoli. A questo punto non sono altro che questo: riquadri. Niente linee, niente colori, niente che dica Salesforce. Più avanti nel corso forme e colori inizieranno a significare qualcosa. Per ora un rettangolo è solo una cosa di cui parla il business.
Poi inizia a orientarli. Mentre posizioni ogni riquadro, devi pensare a due cose: come si collegano tra loro, e che tipo di dati sono. Alcuni sono dati dei clienti: le aziende e le persone con cui lavoriamo. Alcuni sono dati transazionali, come gli ordini e le righe d’ordine: le cose che succedono, ancora e ancora. E alcuni sono dati di riferimento, come i prodotti o i servizi che un’azienda offre: le cose da cui dipende il lavoro.
In Steve Trucking, il Partner retail e il Destinatario sono dati dei clienti. Il Manifesto di carico, la Consegna e il Percorso sono transazioni. Il Centro di distribuzione, la Squadra e il Camion sono ciò da cui dipende il lavoro.
Ma qui c’è una parola importante: candidata.
Un sostantivo è un indizio. Non è automaticamente un’entità, e di certo non è automaticamente un oggetto Salesforce.
Quando sono in una sessione di discovery, scrivo ogni sostantivo. Per ogni sostantivo che dicono, mi pongo una domanda: è una persona che svolge un lavoro, o è un dato? Un business development manager è una persona che svolge un lavoro. È un utente, un ruolo, forse un set di autorizzazioni. Ordini, fatture, righe: quelli sono dati. Contano entrambi, ma finiscono in punti molto diversi del progetto, e distinguerli presto mi evita di disegnare un riquadro per ogni qualifica dell’organigramma.
Ora, alcuni di quei sostantivi saranno persone. In Steve Trucking sono il Destinatario che aspetta il frigorifero, le persone del Partner retail che inviano il manifesto di carico, e la Squadra: autisti e aiutanti sul camion. Sono ruoli, e un ruolo può non sembrare un dato. Ma quando le persone agiscono sui dati, o vi sono collegate, devono essere rappresentate anch’esse nei dati. Chi ha fatto questa consegna? Chi ha firmato? Chi ha inviato il manifesto? Così molti ruoli, a volte tutti, finiscono anch’essi nel modello.
Ascolta come parla Steve Trucking, e noterai una cosa. Non dicono mai semplicemente “cliente”. Ci sono due tipi di cliente. Il Partner retail è la grande catena per conto della quale Steve Trucking consegna: invia il manifesto di carico e paga per ogni consegna. Il Destinatario è la persona a cui viene consegnato il frigorifero. Il Destinatario l’ha comprato in negozio e potrebbe non aver mai sentito parlare di Steve Trucking.
Se avessi disegnato un solo riquadro chiamato Cliente, avrei mescolato due cose completamente diverse.
Forse il Centro di distribuzione è abbastanza importante da avere un proprio record, una propria storia, proprie relazioni e propri attributi.
Forse un altro sostantivo si rivelerà nient’altro che un attributo di qualcos’altro.
È questo che cerchiamo di scoprire. Non stiamo ancora creando oggetti. Stiamo costruendo la nostra comprensione del business.
Ora ascolta le relazioni
Sezione intitolata “Ora ascolta le relazioni ”I sostantivi mi danno un punto di partenza. Poi ascolto come il business li collega.
Un Partner retail gestisce dei Centri di distribuzione.
Un Partner retail invia un Manifesto di carico per ogni CD e giorno di consegna.
Un Manifesto di carico elenca delle Consegne.
Una Consegna va a un Destinatario.
Un Percorso è il giro di una giornata, con una decina di Tappe.
Una Squadra di due persone guida un Camion.
Ora sta succedendo qualcosa. Non sto più guardando un elenco di sostantivi. Sto iniziando a vedere un modello.
È anche qui che iniziano a comparire le domande.
Un Partner retail può avere più di un centro di distribuzione?
Una consegna è la stessa cosa di una tappa?
Una tappa può servire due Destinatari?
Una squadra è sempre formata dalle stesse due persone?
Ci interessa quale squadra aveva quale camion il mese scorso, o solo quale camion guida oggi?
Nota cosa stiamo facendo. Non stiamo ancora ponendo domande su Salesforce. Stiamo ponendo domande di business. E quelle risposte alla fine guideranno il progetto Salesforce.
Il tuo primo modello non deve essere perfetto
Sezione intitolata “Il tuo primo modello non deve essere perfetto ”Non mi aspetto che i primi riquadri che disegno sopravvivano invariati. Anzi, mi insospettirebbe se lo facessero.
Lo scopo del primo modello non è essere giusto. Lo scopo è darci qualcosa di abbastanza concreto da scoprire dove sbagliamo.
Metti Consegna, Percorso, Squadra e Camion sulla lavagna e le persone possono reagire.
“In realtà una consegna non è sempre un solo articolo. Potrebbe essere una lavatrice, un’asciugatrice e il ritiro di quelle vecchie.”
Bene. Dimmi di più.
“Non assegniamo una squadra a una consegna. Assegniamo la squadra a un percorso.”
Ottimo. Cosa c’è nel percorso?
“E se c’è un’installazione, la squadra non può chiudere la tappa finché checklist e foto non sono completate.”
Ora stiamo imparando qualcosa di importante.
Un diagramma ha trasformato una conversazione vaga in qualcosa che possiamo mettere in discussione. È uno dei motivi per cui mi piace modellare presto. Non sto cercando di impressionare la stanza con un bel diagramma. Sto cercando di imparare più in fretta.
Il modello fa parte della conversazione.
Questo è il tuo modello concettuale
Sezione intitolata “Questo è il tuo modello concettuale ”Ciò che abbiamo iniziato a costruire ha un nome formale: un modello dati concettuale.
A questo livello mi interessano le cose importanti per il business e come si collegano. Non mi preoccupo ancora di oggetti standard o personalizzati, nomi API dei campi, relazione di ricerca o master-dettaglio, campi obbligatori, indici, automazione, Apex o Flow. Sono cose che contano, e ci arriveremo. Ma se le decidiamo prima di capire cosa stiamo modellando, risolviamo per primo il problema sbagliato.
Il modello concettuale dovrebbe avere senso per le persone nella stanza che non conoscono Salesforce. È una prova utile. Se devo spiegare cosa significa Delivery__c prima che il responsabile delle operazioni riesca a leggere il mio diagramma, sono passato troppo presto all’implementazione.
Voglio che guardino il modello e dicano:
“Sì, il nostro business funziona così.”
O, ancora meglio:
“No, non funziona così.”
Perché ora ho qualcosa da correggere.
La stessa tecnica funziona quando nessuno parla
Sezione intitolata “La stessa tecnica funziona quando nessuno parla ”Non è qualcosa che uso solo nella discovery con i clienti. Funziona anche quando il “cliente” è un documento.
Quando lavoro su un documento dei requisiti, faccio più o meno la stessa cosa. Quali sono i concetti di business importanti? Quali relazioni vengono descritte? Cosa compare ripetutamente? Cosa ha un proprio ciclo di vita, deve essere identificato a sé o ha bisogno di uno storico? Cosa viene creato, modificato, assegnato, trasferito, pianificato o ritirato?
Sono le stesse cose che ascolto in quel primo incontro. Sulla pagina, quegli indizi trasformano paragrafi di requisiti in un modello su cui posso ragionare, e in domande migliori per la conversazione successiva.
Un modello non è solo qualcosa che produci dopo aver risolto il problema. È uno degli strumenti che usi per risolverlo.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”Alla fine di questo primo passaggio, cerco di decidere:
- Quali sostantivi rappresentano entità candidate significative.
- Quali parole diverse rappresentano lo stesso concetto di business, e quale singola parola ne nasconde due (come “cliente”).
- Quali concetti hanno bisogno di un proprio record e di un proprio ciclo di vita.
- Come i concetti principali si collegano tra loro.
- A quali domande deve rispondere il business prima che io possa modellarli con sicurezza.
Non sto ancora decidendo l’implementazione Salesforce. Prima dobbiamo capire il business abbastanza bene da disegnarlo. E una volta che i sostantivi sono sulla lavagna, la cosa successiva che voglio capire sono le linee tra loro.
Oltre l’esame: cosa cambia l’IA. Dai a uno strumento di IA un documento dei requisiti e troverà i sostantivi, proporrà entità e abbozzerà relazioni in pochi secondi. Usalo per accelerare la discovery, ma non delegare la comprensione: non può sapere che “cliente” significa due cose diverse in Steve Trucking a meno che non te lo dica il business. Metti il suo primo modello davanti alle persone che gestiscono il business e chiedi: “Il vostro business funziona davvero così?”