Ouça os substantivos
Também em 28 idiomas
English · Español · 日本語 · 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 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: a visão geral do capítulo · Próximo: Desenhe os relacionamentos
A pergunta que este módulo responde: Como encontro os primeiros traços de um modelo de dados numa conversa de negócio?
Uma das coisas que faço numa primeira conversa com um cliente é ouvir os substantivos.
Não estou falando da primeira sessão de design. Estou falando daquela conversa inicial em que ainda estou tentando entender o negócio e o que ele quer alcançar.
Eles falam. Eu escuto.
E estou atento a palavras como:
Parceiro varejista. Destinatário. Centro de distribuição. Manifesto. Entrega. Rota. Equipe. Caminhão.
Esses substantivos chamam minha atenção na hora, porque em algum lugar dessa conversa estão os primeiros traços do meu modelo de dados.
Não espero até achar que entendi o problema por completo. Começo a enxergar os dados enquanto ainda estou ouvindo: ouço os substantivos, começo a esboçar como eles se relacionam, e esse esboço me ajuda a enquadrar a próxima conversa. Às vezes, ao fim de uma primeira reunião com um cliente, já tenho meu próprio modelo de dados desenhado em particular.
Para mim, isso começa pelos substantivos.
Esqueça o Salesforce por um minuto
Seção intitulada “Esqueça o Salesforce por um minuto ”Aqui quero que você resista a um instinto que é especialmente forte se você é administrador Salesforce há algum tempo.
O cliente diz cliente, e você pensa:
Conta.
Ele diz pessoa, e você pensa:
Contato.
Ele diz centro de distribuição, e você já está se perguntando se precisa de um objeto personalizado.
Não faça isso ainda.
Neste ponto, não me importa se um cliente vai acabar virando uma Conta, uma Conta pessoal, um objeto personalizado ou outra coisa. Primeiro quero entender o negócio.
Essa é a diferença entre modelar o negócio e configurar o Salesforce. Se começo pelos objetos do Salesforce, já limitei meu raciocínio a uma implementação. Posso acabar exatamente onde esperava, mas quero chegar lá porque o negócio me levou até lá, não porque Conta e Contato eram os dois primeiros objetos que eu conhecia.
Então, por alguns minutos, esqueça o Salesforce. Ouça como as pessoas que realmente tocam o negócio descrevem o mundo delas.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”Antes de ouvir um negócio, vamos ouvir algo que todo mundo já entende. Quando ensino isto ao vivo, começo com cachorros.
Eis um cachorro: o Marcus é dono da Bella. O canil Maple Ridge a criou. Ela é uma labrador, e sabe Senta, Fica e Dá a pata.
Ouça os substantivos: Marcus, Bella, canil Maple Ridge, labrador, Senta. Mas esses são nomes: as coisas específicas. O que eu quero é o tipo de coisa a que cada nome pertence. A Bella é um Cachorro. O Marcus é um Dono. O canil Maple Ridge é um Criador. Labrador é uma Raça. Senta é um Truque. Cinco substantivos, cinco possíveis caixas.
Depois, a pergunta que faço a todo substantivo: é uma pessoa fazendo um trabalho, ou um dado? O Marcus é uma pessoa. Mas ser dono da Bella não é um trabalho; é um fato sobre a Bella, e mais cedo ou mais tarde alguém pergunta: “Quem é o dono deste cachorro?” Então o Dono pertence ao modelo. O adestrador que ensinou a Bella a dar a pata é uma pessoa fazendo um trabalho, e pode nunca precisar de uma caixa, a menos que o negócio comece a perguntar quem ensinou qual truque.
E repare na palavra possível. A Raça é mesmo uma caixa própria, ou só uma palavra escrita no cachorro? Guarde essa pergunta; vamos respondê-la quando normalizarmos, no módulo 4.
Essa é a técnica inteira, em algo pequeno. Agora vamos ouvir um negócio de verdade.
Substantivos dão possíveis entidades
Seção intitulada “Substantivos dão possíveis entidades ”Vamos ouvir a Steve Trucking, a empresa familiar que vamos usar ao longo deste curso. Ela entrega itens grandes (geladeiras, lavadoras, TVs) dos centros de distribuição de grandes varejistas até a casa das pessoas, e instala alguns deles.
Na primeira conversa ouvimos:
- Parceiro varejista (Retail Partner)
- Destinatário (Recipient)
- Centro de distribuição (Distribution Center)
- Manifesto (Manifest)
- Entrega (Delivery)
- Rota (Route)
- Equipe (Crew)
- Caminhão (Truck)
Isso já é útil. Posso começar a colocar caixas num quadro branco.
Então coloque os substantivos em retângulos. É só isso que eles são neste ponto: caixas. Sem linhas, sem cores, nada que diga Salesforce. Mais adiante no curso, formas e cores vão começar a significar algo. Por enquanto, um retângulo é apenas uma coisa de que o negócio fala.
Depois comece a orientá-los. Ao posicionar cada caixa, pense em duas coisas: como elas se relacionam entre si e que tipo de dado elas são. Parte é dado de cliente: as empresas e as pessoas com quem trabalhamos. Parte é dado transacional, como pedidos e itens de pedido: as coisas que acontecem, de novo e de novo. E parte é dado de referência, como os produtos ou serviços que uma empresa oferece: as coisas das quais o trabalho depende.
Na Steve Trucking, o Parceiro varejista e o Destinatário são dados de cliente. O Manifesto, a Entrega e a Rota são transações. O Centro de distribuição, a Equipe e o Caminhão são aquilo de que o trabalho depende.
Mas há uma palavra importante aqui: possível.
Um substantivo é uma pista. Ele não é automaticamente uma entidade, e com certeza não é automaticamente um objeto Salesforce.
Quando estou numa sessão de descoberta, anoto cada substantivo. Para cada substantivo que dizem, me faço uma pergunta: isso é uma pessoa fazendo um trabalho, ou é um dado? Um gerente de desenvolvimento de negócios é uma pessoa fazendo um trabalho. Isso é um usuário, um papel, talvez um conjunto de permissões. Pedidos, faturas, itens de linha: esses são dados. Os dois importam, mas vão parar em lugares muito diferentes do design, e separá-los cedo me poupa de desenhar uma caixa para cada cargo do organograma.
Alguns desses substantivos serão pessoas. Na Steve Trucking, é o Destinatário esperando a geladeira, as pessoas do Parceiro varejista que enviam o manifesto, e a Equipe: os motoristas e ajudantes do caminhão. Esses são papéis, e um papel pode não parecer dado. Mas quando pessoas agem sobre dados, ou se relacionam com eles, elas próprias precisam estar representadas nos dados. Quem entregou isto? Quem assinou o recebimento? Quem enviou o manifesto? Por isso muitos papéis, às vezes todos, também acabam no modelo.
Ouça como a Steve Trucking fala, e você vai notar algo. Eles nunca dizem só “cliente”. Há dois tipos de cliente. O Parceiro varejista é o grande varejista para quem a Steve Trucking entrega: ele envia o manifesto e paga por entrega. O Destinatário é a pessoa a quem a geladeira é entregue. O Destinatário a comprou na loja e talvez nunca tenha ouvido falar da Steve Trucking.
Se eu tivesse desenhado uma caixa chamada Cliente, teria misturado duas coisas completamente diferentes.
Talvez o Centro de distribuição seja importante o bastante para ter seu próprio registro, histórico, relacionamentos e atributos.
Talvez outro substantivo acabe sendo nada mais que um atributo de outra coisa.
É isso que estamos tentando descobrir. Ainda não estamos criando objetos. Estamos construindo nosso entendimento do negócio.
Agora ouça os relacionamentos
Seção intitulada “Agora ouça os relacionamentos ”Os substantivos me dão um ponto de partida. Depois ouço como o negócio os conecta.
Um Parceiro varejista opera Centros de distribuição.
Um Parceiro varejista envia um Manifesto para cada CD e dia de entrega.
Um Manifesto lista Entregas.
Uma Entrega vai para um Destinatário.
Uma Rota é a jornada de um dia com umas dez Paradas.
Uma Equipe de duas pessoas opera um Caminhão.
Agora algo está acontecendo. Não estou mais olhando para uma lista de substantivos. Estou começando a ver um modelo.
É também aqui que as perguntas começam a aparecer.
Um Parceiro varejista pode ter mais de um centro de distribuição?
Uma entrega é a mesma coisa que uma parada?
Uma parada pode entregar para dois Destinatários?
Uma equipe é sempre formada pelas mesmas duas pessoas?
Importa qual equipe estava com qual caminhão no mês passado, ou só qual caminhão ela está dirigindo hoje?
Repare no que estamos fazendo. Ainda não estamos fazendo perguntas sobre o Salesforce. Estamos fazendo perguntas de negócio. E essas respostas vão acabar guiando o design no Salesforce.
Seu primeiro modelo não precisa ser perfeito
Seção intitulada “Seu primeiro modelo não precisa ser perfeito ”Não espero que as primeiras caixas que desenho sobrevivam sem mudanças. Na verdade, eu desconfiaria se sobrevivessem.
O objetivo do primeiro modelo não é estar certo. O objetivo é nos dar algo concreto o bastante para descobrirmos onde estamos errados.
Coloque Entrega, Rota, Equipe e Caminhão no quadro e as pessoas conseguem reagir a eles.
“Na verdade, uma entrega nem sempre é um item só. Pode ser uma lavadora, uma secadora e o recolhimento das antigas.”
Ótimo. Me conte mais.
“Não atribuímos uma equipe a uma entrega. Atribuímos a equipe a uma rota.”
Ótimo. O que tem na rota?
“E se houver uma instalação, a equipe não pode fechar a parada até o checklist e as fotos estarem feitos.”
Agora estamos aprendendo algo importante.
Um diagrama transformou uma conversa vaga em algo que podemos questionar. Esse é um dos motivos pelos quais gosto de modelar cedo. Não estou tentando impressionar a sala com um diagrama bonito. Estou tentando aprender mais rápido.
O modelo faz parte da conversa.
Este é o seu modelo conceitual
Seção intitulada “Este é o seu modelo conceitual ”Há um nome formal para o que começamos a construir: um modelo de dados conceitual.
Neste nível, me interessam as coisas importantes com que o negócio se preocupa e como elas se relacionam. Ainda não estou preocupado com objetos padrão versus personalizados, nomes de API de campos, relacionamento de pesquisa versus mestre-detalhes, campos obrigatórios, índices, automação, Apex ou Flows. Essas coisas importam, e vamos chegar lá. Mas se as decidirmos antes de entender o que estamos modelando, estamos resolvendo o problema errado primeiro.
O modelo conceitual deve fazer sentido para as pessoas na sala que não conhecem o Salesforce. Esse é um teste útil. Se preciso explicar o que Delivery__c significa antes que a gerência de operações consiga ler meu diagrama, entrei na implementação cedo demais.
Quero que olhem o modelo e digam:
“Sim, é assim que nosso negócio funciona.”
Ou, melhor ainda:
“Não, não é assim que funciona.”
Porque agora tenho algo para consertar.
A mesma técnica funciona quando ninguém está falando
Seção intitulada “A mesma técnica funciona quando ninguém está falando ”Isto não é algo que uso só na descoberta com clientes. Também funciona quando o “cliente” é um documento.
Quando estou trabalhando num documento de requisitos, faço praticamente a mesma coisa. Quais são os conceitos de negócio importantes? Que relacionamentos estão sendo descritos? O que aparece repetidamente? O que tem seu próprio ciclo de vida, precisa ser identificado por si só ou precisa de histórico? O que está sendo criado, alterado, atribuído, transferido, agendado ou aposentado?
São as mesmas coisas que ouço naquela primeira reunião. Numa página, essas pistas transformam parágrafos de requisitos num modelo sobre o qual consigo raciocinar, e em perguntas melhores para a próxima conversa.
Um modelo não é só algo que você produz depois de resolver o problema. É uma das ferramentas que você usa para resolver o problema.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Ao fim desta primeira passada, estou tentando decidir:
- Quais substantivos representam possíveis entidades com significado.
- Quais palavras diferentes representam o mesmo conceito de negócio, e qual palavra esconde dois (como “cliente”).
- Quais conceitos precisam de um registro e de um ciclo de vida próprios.
- Como os principais conceitos se relacionam entre si.
- Que perguntas o negócio precisa responder antes que eu consiga modelá-los com confiança.
Ainda não estou decidindo a implementação no Salesforce. Primeiro precisamos entender o negócio bem o bastante para desenhá-lo. E, com os substantivos no quadro, a próxima coisa que quero entender são as linhas entre eles.
Além do exame: o que a IA muda. Dê um documento de requisitos a uma ferramenta de IA e ela vai encontrar os substantivos, propor entidades e esboçar relacionamentos em segundos. Use-a para acelerar a descoberta, mas não terceirize o entendimento: ela não tem como saber que “cliente” significa duas coisas diferentes na Steve Trucking, a menos que o negócio diga a você. Coloque o primeiro modelo dela diante das pessoas que tocam o negócio e pergunte: “É realmente assim que o seu negócio funciona?”