Ouça os substantivos
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 sustenta-se sozinho. Anterior: a visão geral do capítulo · Próximo: Desenhe as relações
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 a falar da primeira sessão de design. Estou a falar daquela conversa inicial em que ainda estou a tentar entender o negócio e o que ele quer alcançar.
Eles falam. Eu escuto.
E estou atento a palavras como:
Parceiro retalhista. Destinatário. Centro de distribuição. Manifesto. Entrega. Rota. Equipa. Camião.
Estes substantivos chamam-me logo a atenção, porque algures nessa 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 ver os dados enquanto ainda estou a ouvir: ouço os substantivos, começo a esboçar como se relacionam, e esse esboço ajuda-me a enquadrar a conversa seguinte. Às vezes, no fim de uma primeira reunião com um cliente, já tenho o meu próprio modelo de dados desenhado em privado.
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 resista a um instinto que é especialmente forte se é administrador Salesforce há algum tempo.
O cliente diz cliente, e pensa:
Conta.
Diz pessoa, e pensa:
Contacto.
Diz centro de distribuição, e já se está a perguntar se precisa de um objeto personalizado.
Não faça isso ainda.
Neste ponto, não me importa se um cliente vai acabar por ser 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 o 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 Contacto eram os dois primeiros objetos que eu conhecia.
Por isso, durante alguns minutos, esqueça o Salesforce. Ouça como as pessoas que realmente fazem o negócio funcionar descrevem o seu mundo.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”Antes de ouvir um negócio, vamos ouvir algo que toda a gente já entende. Quando ensino isto ao vivo, começo com cães.
Eis um cão: o Marcus é dono da Bella. O canil Maple Ridge criou-a. É 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 Cão. 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 cada substantivo: é uma pessoa a fazer um trabalho, ou um dado? O Marcus é uma pessoa. Mas ser dono da Bella não é um trabalho; é um facto sobre a Bella, e mais cedo ou mais tarde alguém pergunta: «Quem é o dono deste cão?» Por isso, o Dono pertence ao modelo. O treinador que ensinou a Bella a dar a pata é uma pessoa a fazer um trabalho, e pode nunca precisar de uma caixa, a menos que o negócio comece a perguntar quem ensinou que truque.
E repare na palavra possível. A Raça é mesmo uma caixa própria, ou só uma palavra escrita no cão? 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. Entrega artigos grandes (frigoríficos, máquinas de lavar, televisores) dos centros de distribuição de grandes retalhistas até casa das pessoas, e instala alguns deles.
Na primeira conversa ouvimos:
- Parceiro retalhista (Retail Partner)
- Destinatário (Recipient)
- Centro de distribuição (Distribution Center)
- Manifesto (Manifest)
- Entrega (Delivery)
- Rota (Route)
- Equipa (Crew)
- Camião (Truck)
Isto já é útil. Posso começar a pôr caixas num quadro branco.
Por isso, ponha os substantivos em retângulos. É só isso que 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 agora, 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 se relacionam entre si e que tipo de dado são. Uma parte são dados de cliente: as empresas e as pessoas com quem trabalhamos. Outra parte são dados transacionais, como encomendas e itens de encomenda: as coisas que acontecem, uma e outra vez. E outra parte são dados de referência, como os produtos ou serviços que uma empresa oferece: as coisas de que o trabalho depende.
Na Steve Trucking, o Parceiro retalhista 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 Equipa e o Camião são aquilo de que o trabalho depende.
Mas há uma palavra importante aqui: possível.
Um substantivo é uma pista. 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, faço-me uma pergunta: isto é uma pessoa a fazer um trabalho, ou é um dado? Um gestor de desenvolvimento de negócio é uma pessoa a fazer um trabalho. Isso é um utilizador, uma função, talvez um conjunto de permissões. Encomendas, faturas, itens de linha: esses são dados. Os dois importam, mas vão parar a lugares muito diferentes do design, e separá-los cedo poupa-me a desenhar uma caixa para cada cargo do organograma.
Alguns destes substantivos serão pessoas. Na Steve Trucking, é o Destinatário à espera do frigorífico, as pessoas do Parceiro retalhista que enviam o manifesto, e a Equipa: os motoristas e ajudantes do camião. Estes são papéis, e um papel pode não parecer um dado. Mas quando as pessoas agem sobre dados, ou se relacionam com eles, elas próprias precisam de estar representadas nos dados. Quem entregou isto? Quem assinou a receção? 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 vai reparar em algo. Nunca dizem só «cliente». Há dois tipos de cliente. O Parceiro retalhista é o grande retalhista para quem a Steve Trucking entrega: envia o manifesto e paga por entrega. O Destinatário é a pessoa a quem o frigorífico é entregue. O Destinatário comprou-o 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 suficientemente importante para ter o seu próprio registo, histórico, relações e atributos.
Talvez outro substantivo acabe por não ser mais do que um atributo de outra coisa.
É isso que estamos a tentar descobrir. Ainda não estamos a criar objetos. Estamos a construir o nosso entendimento do negócio.
Agora ouça as relações
Seção intitulada “Agora ouça as relações ”Os substantivos dão-me um ponto de partida. Depois ouço como o negócio os liga.
Um Parceiro retalhista opera Centros de distribuição.
Um Parceiro retalhista 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 Paragens.
Uma Equipa de duas pessoas opera um Camião.
Agora algo está a acontecer. Já não estou a olhar para uma lista de substantivos. Estou a começar a ver um modelo.
É também aqui que as perguntas começam a aparecer.
Um Parceiro retalhista pode ter mais do que um centro de distribuição?
Uma entrega é o mesmo que uma paragem?
Uma paragem pode entregar a dois Destinatários?
Uma equipa é sempre formada pelas mesmas duas pessoas?
Importa que equipa estava com que camião no mês passado, ou só que camião está a conduzir hoje?
Repare no que estamos a fazer. Ainda não estamos a fazer perguntas sobre o Salesforce. Estamos a fazer perguntas de negócio. E essas respostas vão acabar por guiar o design no Salesforce.
O seu primeiro modelo não precisa de ser perfeito
Seção intitulada “O seu primeiro modelo não precisa de 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 é dar-nos algo suficientemente concreto para descobrirmos onde estamos errados.
Ponha Entrega, Rota, Equipa e Camião no quadro e as pessoas conseguem reagir a eles.
«Na verdade, uma entrega nem sempre é um só artigo. Pode ser uma máquina de lavar, uma máquina de secar e a recolha das antigas.»
Ótimo. Conte-me mais.
«Não atribuímos uma equipa a uma entrega. Atribuímos a equipa a uma rota.»
Ótimo. O que há na rota?
«E se houver uma instalação, a equipa não pode fechar a paragem até a checklist e as fotografias estarem feitas.»
Agora estamos a aprender 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 a tentar impressionar a sala com um diagrama bonito. Estou a tentar aprender mais depressa.
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, interessam-me as coisas importantes com que o negócio se preocupa e como se relacionam. Ainda não estou preocupado com objetos padrão versus personalizados, nomes de API de campos, relação de pesquisa versus mestre-detalhe, campos obrigatórios, índices, automação, Apex ou Flows. Essas coisas importam, e vamos lá chegar. Mas se as decidirmos antes de entender o que estamos a modelar, estamos a resolver primeiro o problema errado.
O modelo conceitual deve fazer sentido para as pessoas na sala que não conhecem o Salesforce. É um teste útil. Se preciso de explicar o que Delivery__c significa antes de a direção de operações conseguir ler o meu diagrama, entrei na implementação cedo demais.
Quero que olhem para o modelo e digam:
«Sim, é assim que o nosso negócio funciona.»
Ou, melhor ainda:
«Não, não é assim que funciona.»
Porque agora tenho algo para corrigir.
A mesma técnica funciona quando ninguém está a falar
Seção intitulada “A mesma técnica funciona quando ninguém está a falar ”Isto não é algo que uso só na descoberta com clientes. Também funciona quando o «cliente» é um documento.
Quando estou a trabalhar num documento de requisitos, faço praticamente o mesmo. Quais são os conceitos de negócio importantes? Que relações estão a ser descritas? O que aparece repetidamente? O que tem o seu próprio ciclo de vida, precisa de ser identificado por si só ou precisa de histórico? O que está a ser criado, alterado, atribuído, transferido, agendado ou retirado?
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 conversa seguinte.
Um modelo não é só algo que se produz depois de resolver o problema. É uma das ferramentas que se usam para resolver o problema.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”No fim desta primeira passagem, estou a tentar decidir:
- Que substantivos representam possíveis entidades com significado.
- Que palavras diferentes representam o mesmo conceito de negócio, e que palavra esconde dois (como «cliente»).
- Que conceitos precisam de um registo e de um ciclo de vida próprios.
- Como os principais conceitos se relacionam entre si.
- Que perguntas o negócio precisa de responder antes de eu conseguir modelá-los com confiança.
Ainda não estou a decidir a implementação no Salesforce. Primeiro precisamos de entender o negócio suficientemente bem para o desenhar. 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 encontra os substantivos, propõe entidades e esboça relações em segundos. Use-a para acelerar a descoberta, mas não subcontrate o entendimento: ela não tem como saber que «cliente» significa duas coisas diferentes na Steve Trucking, a menos que o negócio lho diga. Ponha o primeiro modelo dela diante das pessoas que fazem o negócio funcionar e pergunte: «É realmente assim que o seu negócio funciona?»