Leia sobre nossas agendas de atualização aqui.

As soluções intencionais proporcionam valor de negócios imediatamente e ao longo do tempo. As arquiteturas intencionais são planejadas e entregues estrategicamente, podem ser mantidas de modo eficaz e são fáceis de ler e entender pelos humanos.

Recursos e correções são priorizados e entregues de maneiras transparentes para as partes interessadas de negócios e tecnologia. As opções de engenharia criam implementações fáceis para que as equipes de entrega e manutenção trabalhem sem recursos adicionais ou complicações. As arquiteturas intencionais são mais fáceis de possuir, manter e evoluir com os negócios porque seguem padrões de implementação claros e consistentes. Os criadores podem interpretar e implementar designs para novos recursos, e as equipes de manutenção podem entender a documentação do que foi implementado.

Você pode criar sistemas mais intencionais focando três áreas principais: estratégia, capacidade de manutenção e legibilidade.

Estratégia na arquitetura significa que os sistemas são planejados e entregues com cuidado. Isso significa que as equipes de entrega e manutenção têm uma visão clara do trabalho a ser feito hoje e no futuro e todos estão alinhados com o "por quê" do trabalho a ser feito. Isso significa que as solicitações urgentes podem ser classificadas de modo eficiente e eficiente, e as partes interessadas podem entender claramente os impactos e os prós e os contras das solicitações.

Você pode criar uma estratégia mais clara em sua arquitetura focando a priorização, o roteiro e a governança.

Priorização significa planejar a ordem e o escopo do trabalho que você entregará. A priorização envolve entender o verdadeiro impacto das entregas no negócio, avaliando esses impactos em relação a outras solicitações de trabalho e o roteiro geral para seu produto ou programa.

Uma maneira de avaliar o impacto de um determinado item de trabalho é analisar o custo real ou o benefício para o negócio. Depois de identificar os KPIs para a automação, você pode usar uma planilha de cálculo de impacto de negócios para avaliar o custo ou benefício geral da implementação. Esses cálculos podem ajudá-lo a obter alinhamento e aprovação de suas partes interessadas sobre quais automações criar e em que ordem. Eles também podem ajudá-lo a identificar automações para adiar ou evitar. Para automações, consulte design de processo para obter mais informações sobre a identificação de trabalho eficaz.

Estabelecer uma estrutura de priorização para entrega também ajudará você e suas equipes de manutenção a gerenciar as expectativas do usuário e se manter alinhado ao seu roteiro.

Algumas considerações que você pode usar para priorização incluem:

• Impacto comercial (custo/benefício) do entregável
• Quantidade de novo trabalho necessária para o entregável
• Quantidade de trabalho necessária para manter o entregável

A lista de padrões e antipadrões abaixo mostra como é a priorização correta (e ruim) quando se trata de trabalho do Salesforce. Você pode usá-los para validar seus planos de implementação ou identificar onde é necessário identificar melhor as prioridades antes de criar.

Para saber mais sobre as ferramentas disponíveis no Salesforce para obter ajuda com a priorização, consulte Ferramentas relevantes para intencional.

Um roteiro é uma visualização priorizada, validada e bem definida do que deve ser feito. Os roteiros efetivos fornecem uma visão clara do impacto comercial e do impacto tecnológico do trabalho futuro. Engajar suas partes interessadas comerciais e técnicas é uma parte importante do roteiro. Os roteiros permitem que você receba feedback e conselhos sobre a abordagem e os resultados antes de qualquer trabalho começar. Por fim, os roteiros alinham todas as partes interessadas sobre o "por quê" do trabalho no futuro.

Se sua equipe usa uma pendência, é importante entender que seu roteiro não é um resumo ou uma lista dos itens na pendência. O relacionamento é o oposto: Os itens devem entrar na pendência apenas se puderem ser vinculados de modo claro e confiável a um entregável no seu roteiro. Os roteiros de alta qualidade, criados com o engajamento das partes interessadas, fornecem às equipes de entrega e manutenção uma visão clara do que elas devem focar e como priorizar solicitações, tornando mais fácil classificar solicitações conflitantes e gerenciar as expectativas das partes interessadas.

Um roteiro ruim ou não existente leva a:

• Falta de clareza quanto a quando novos recursos e funcionalidades estarão disponíveis
• Prioridades conflitantes entre as partes interessadas
• Uma desconexão entre as soluções que estão sendo entregues e a visão geral da organização
• Dificuldade para entender o trabalho em andamento
• Cargas de trabalho desiguais entre equipes
• Falta de visibilidade de relacionamentos e dependências entre itens de trabalho
• Implementações paralisadas devido a dependências mal gerenciadas

As partes interessadas geralmente precisam de informações alinhadas aos seus papéis para tomar decisões. Criar roteiros eficazes requer uma compreensão clara do público e do tipo de informação de que ele precisa. Os roteiros são divididos em dois estilos para dar suporte a públicos de negócios e técnicos. Cada estilo contém dois níveis de granularidade para dar suporte a diferentes tipos de informações.

Os roteiros de negócios ajudam as partes interessadas a planejar mudanças organizacionais, aproveitar oportunidades de crescimento e manter-se alinhadas aos objetivos corporativos. Os roteiros de negócios também fornecem uma maneira de garantir que os gastos de TI estejam alinhados à visão geral dos negócios.

• Crie um roteiro de funcionalidade de negócios para mostrar às partes interessadas executivas os recursos que serão habilitados. Esse tipo de roteiro contém detalhes gerais sobre os recursos em si e como eles se alinham aos objetivos de negócios, como aumentar a eficiência operacional ou lançar uma nova linha de produtos.
• Crie um roteiro de recursos de negócios para detalhar um recurso específico e mostrar seus recursos e funcionalidades de suporte quando precisar ajudar as partes interessadas de negócios com planejamento de recursos, orçamento e gerenciamento de mudanças.

Os roteiros de tecnologia ajudam as partes interessadas técnicas com o planejamento de orçamento e alocação de recursos. Eles também ajudam as equipes de implementação a entender onde seus projetos se encaixam como parte de um panorama geral maior e identificar dependências entre equipes.

• Crie um roteiro do sistema de tecnologia para mostrar os sistemas específicos que serão implementados, junto com quaisquer dependências no nível do sistema. Esse tipo de roteiro mostra informações de alto nível do sistema e o alinhamento entre sistemas e funcionalidades de negócios.
• Crie um roteiro de componente de tecnologia para detalhar os componentes específicos de um sistema que serão implementados para ajudar com os requisitos de planejamento e habilitação de recursos. Esse tipo de roteiro mostra informações no nível do componente e requisitos de implementação (por exemplo, desenvolvimento declarativo, pro-código etc.).

Certifique-se de que seus roteiros contenham linhas do tempo realistas. Um erro comum é incluir apenas o tempo necessário para implementar um sistema sem considerar também o tempo necessário para concluir as atividades relacionadas. Isso pode resultar em alocação excessiva de membros da equipe de implementação e atrasos mais longos que o esperado. Ao criar um roteiro, considere o tempo que levará para concluir o seguinte:

• Documentação de todas as funcionalidades novas e atualizadas
• Manutenção da funcionalidade existente necessária para dar suporte a novos recursos
• Atualizações a sistemas relacionados necessárias para dar suporte a integrações
• Suporte elevado das equipes do projeto imediatamente após a ativação
• Testes, treinamento e gerenciamento de mudanças

Os roteiros de negócios e tecnologia bem alinhados comunicam uma visão holística de quando os recursos serão disponibilizados e qual tecnologia está por trás deles. A lista de padrões e antipadrões abaixo mostra a aparência dos roteiros adequados (e ruins) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de roteiro.

Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo com o roteamento, consulte ferramentas relevantes para intencional.

A governança é a estrutura que você usa para lidar com priorização, tomada de decisão e gerenciamento de mudanças com suas partes interessadas. A governança torna claro como as decisões são tomadas e comunicadas. Ele fornece maneiras consistentes para que o feedback e as solicitações entrem no processo de tomada de decisão e para que todas as partes interessadas entendam o status do trabalho de manutenção e desenvolvimento. A governança ajuda os processos de gerenciamento de versão a serem claros e consistentes e ajuda todos os membros da equipe a entender seus papéis e responsabilidades.

Sem a governança adequada, as equipes terão vários problemas, incluindo:

• Solicitações sobre recursos e funcionalidades sobrepostos chegam ad hoc
• As equipes de implementação priorizam esforços ou solicitações "mais fáceis" de partes interessadas mais influentes, sem consideração adequada de valor comercial, compensações ou metas organizacionais gerais
• Falta de processos de aprovação e revisão consistentes
• Ritmos de versão inconsistentes e qualidade
• Alta taxa de defeito, substituições, conflitos e trabalho redundante em esforços de desenvolvimento

Talvez o sinal mais claro de que um sistema não tem uma governança eficaz sejam versões lentas e complicadas. É importante reconhecer que o tamanho de um sistema de governança não é uma medida de sua eficácia. Na verdade, sistemas elaborados para governança (como aqueles encontrados em muitas grandes empresas) podem reduzir a velocidade e a frequência das versões.

A boa governança é sobre tornar difícil que personalizações ruins passem pelos estágios iniciais de desenvolvimento e colocar boas personalizações em produção de maneira previsível e consistente.

Muitas vezes, os esforços de governança são reativos. Eles são iniciados ou duplicados quando um problema, como débito técnico excessivo, começa a se tornar um problema de negócios. Em muitos casos, a resposta infeliz é que a empresa “bloqueia” os esforços de desenvolvimento e as versões, em vez de criar normas de design e automação de construção eficazes para impor esses padrões em cadeias de ferramentas de desenvolvedores e sistemas de controle de origem.

Ao criar a estrutura para seu sistema de governança do Salesforce, inclua os seguintes elementos e considere estas principais perguntas a serem respondidas:

• Pedidos de trabalho. Como os usuários podem solicitar funcionalidades ou recursos? Como os bugs são relatados?
• Priorização e planejamento de trabalho. Quem decide o que as solicitações de trabalho importam? Como o trabalho é delimitado, priorizado e aceito ou desconectado?
• Ambiente e planejamento de lançamento. Qual é o pipeline de ambiente para desenvolvimento, teste e liberação? Quem faz o que provisionar, atualizar e fornecer acesso? Quem lida com implantações e validação? Como e quando as alterações são liberadas? Como você lida com implantações ou ambientes durante um ciclo de liberação do Salesforce? (Para obter mais informações sobre isso, consulte Gerenciamento de ciclo de vida do aplicativo.)
• Propriedade do serviço e suporte à produção. Quem dá suporte a quê? Quem lida com problemas de produção de "correção rápida"? Como esses itens são testados e liberados? Quem é responsável pelos padrões gerais de segurança da organização?

A lista de padrões e antipadrões abaixo mostra como é a governança adequada (e ruim) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de governança.

Para saber mais sobre as ferramentas do Salesforce disponíveis para governança, consulte Ferramentas relevantes para intencional.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para estratégia no Padrão & Anti-Padrão Explorador.

A capacidade de manutenção significa que um sistema pode ser mantido em um estado saudável, com novos recursos entrando e débito técnico saindo do sistema regularmente e de forma previsível. Os sistemas de manutenção permitem que suas equipes proporcionem valor aos negócios com velocidade e qualidade previsíveis. A capacidade de manutenção de um sistema depende de vários fatores, incluindo o quão legível ele é, o quão solto ele está acoplado e o quão completa sua estratégia de teste é.

O mais importante é que a capacidade de manutenção de um sistema depende da simplicidade de seu design. Esta seção abrange maneiras de criar designs de soluções mais simples e aumentar a capacidade de manutenção.

Você pode criar soluções mais fáceis de manter focando duas chaves: usar funcionalidade padrão sobre personalizada e lidar com débito técnico.

O Salesforce oferece uma gama de soluções pré-criadas (Sales Cloud, Service Cloud e muitas soluções do setor do Salesforce), além da flexibilidade para criar suas próprias soluções personalizadas. Os serviços básicos que alimentam as próprias soluções de nuvem da Salesforce também estão disponíveis para quaisquer soluções personalizadas criadas na Salesforce Customer 360 Platform. Use os serviços e soluções predefinidos do Salesforce como uma base confiável para o máximo possível de suas soluções.

O uso de serviços de plataforma predefinidos tem dois benefícios distintos. Primeiro, seus aplicativos naturalmente se beneficiam das inovações mais recentes do Salesforce a cada versão. Em segundo lugar, suas equipes de desenvolvimento podem se concentrar em expandir e aprofundar os recursos de negócios fornecidos por suas soluções do Salesforce em vez de lidar com o trabalho pesado arquitetônico básico.

Escolher adequadamente quando usar a funcionalidade padrão e quando criar a funcionalidade personalizada não é um desafio do ponto de vista arquitetônico. As chaves são:

• Personalizar a plataforma significa modificar e estender, não copiar. Ao projetar ou avaliar sua arquitetura, você deve perguntar: Isso já existe em algum lugar na Salesforce Platform? Se a resposta for "Sim, mas...[insira alterações que uma parte interessada quer aqui...]", use o recurso pré-construído na plataforma. O trabalho arquitetônico a ser feito é identificar as maneiras mais úteis de configurar o recurso pré-construído do Salesforce para atender às expectativas de negócios.
• Nenhuma personalização é trivial. Ao longo do tempo, cada alteração tem consequências. Se você precisar implementar uma solução personalizada, pode mitigar a inevitável débeda técnica que seu sistema vai acumular escolhendo usar tecnologia de baixo código sempre que possível e criando unidades compostables em suas implementações.
• Considere o espectro build-buy. O Salesforce AppExchange é um mercado de aplicativos e soluções para estender o Salesforce. Os aplicativos AppExchange podem fornecer funcionalidade sem a sobrecarga envolvida na criação e manutenção de uma solução personalizada. Considere o seguinte ao avaliar soluções do AppExchange:
  • Identifique os recursos e lacunas da solução. O ideal é encontrar um aplicativo que atenda a todos os seus requisitos de negócios. Na realidade, talvez você não encontre um ajuste perfeito. Conforme você avalia soluções, mapeie a funcionalidade na solução potencial para uma lista priorizada de requisitos de negócios. Isso vai ajudá-lo a encontrar a solução que melhor atende aos seus requisitos mais críticos.
  • Use sandboxes e avaliações gratuitas. Use períodos de avaliação gratuitos para avaliar aplicativos em ambientes de sandbox e identificar o melhor ajuste. Determine se os aplicativos exigirão que você faça alterações de configuração que entrem em conflito com sua configuração existente.
  • Considere os custos de curto e longo prazo. Avalie as economias de manutenção de aplicativo de longo prazo em relação aos custos recorrentes de aplicativos baseados em assinatura. Evite cenários em que você tenha que pagar custos recorrentes por muitas funcionalidades que suas partes interessadas de negócios nunca usarão.
• Use os modelos de dados predefinidos do Salesforce. O Salesforce fornece modelos de dados predefinidos para Vendas, Serviços e uma variedade de verticais do setor. Usar os modelos de dados fornecidos pelo Salesforce garante que os recursos no seu sistema sejam definidos apenas uma vez (elimina redundância e silos), estabelece uma única fonte de verdade em todo o sistema, facilita a compreensão dos dados do aplicativo com análise, facilita o uso dos serviços de inteligência artificial predefinidos do Salesforce, reduz os custos de manutenção (reduzindo as personalizações que você precisa dar suporte) e reduz o débito técnico.

É assim tão simples. Como você pode ver nos padrões e antipadrões abaixo, os antipadrões se resumem a replicar recursos padrão em uma solução personalizada, ou usar tecnologia mais complexa para entregar personalizações.

Na prática, você pode encontrar um cenário em que um antipadrão de funcionalidade personalizada é visto pelas partes interessadas da empresa como a melhor ou única maneira viável de avançar. Nesses casos, é essencial que você explique às partes interessadas as compensações envolvidas na escolha desse caminho e, em seguida, documente cuidadosamente a decisão, sua fundamentação e sua implementação. Essa também é uma área em que fornecer valor essencial antecipadamente e se adaptar ao longo do tempo pode ajudar as partes interessadas a entender melhor o melhor caminho a seguir.

Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo a aumentar a capacidade de manutenção, consulte ferramentas relevantes para intencional.

O débito técnico é uma parte natural de qualquer sistema. Os designs de som de ontem podem se tornar antipadrões quando a tecnologia ou as necessidades de negócios mudam. Talvez algo criado para preencher uma lacuna na funcionalidade da Salesforce Platform repentinamente se torne redundante com uma nova versão do Salesforce ou lançamento de produto. Talvez uma tecnologia mais eficiente ou flexível substitua uma tecnologia que você já implementou. O débito técnico pode ser criado de várias maneiras.

Um dos principais benefícios da criação de aplicativos com a Salesforce Customer 360 Platform é a compatibilidade retroativa integrada na plataforma. Isso significa que as novas inovações de plataforma podem alterar o padrão que você deve usar para soluções avançando, mas a função diária das soluções que você criou em tecnologias anteriores do Salesforce continuará funcionando. Ao longo do tempo, qualquer solução baseada em tecnologia mais antiga começará a criar riscos ou gargalos para adicionar novos recursos aos seus aplicativos e diminuirá a integridade geral da solução.

Planejar e realizar trabalho regular para lidar com o débito técnico é essencial para manter designs saudáveis e simples em uma solução do Salesforce. Não planejar, auditar e remediar o débito técnico é uma maneira segura de criar um sistema mal arquitetado.

Uma maneira de minimizar a dívida técnica é evitá-la o máximo possível, evitando atalhos e preferindo a funcionalidade padrão em vez da funcionalidade personalizada. Atalhos, como valores embutidos em código, podem ser tentadores para economizar tempo, mas, no longo prazo, criam débito que deve ser reembolsado.

As chaves para lidar com o débito técnico de uma perspectiva arquitetônica incluem:

• Identificar o custo ou os benefícios reais da ação e da inatividade
• Roadmapping adequado
• Criação de soluções compostas

A dificuldade pode ser alinhar as partes interessadas a tomar medidas. Algumas partes interessadas podem perceber a manutenção em andamento como abordando "erros de ontem" ou removendo dos recursos que desejam que seu orçamento suporte.

Mostrar os reais impactos de negócios de ação e inatividade, junto com entregas e cronogramas claramente definidos, pode ajudar suas partes interessadas a entender o valor e a prioridade relativa de lidar com o débito técnico. Fazer o trabalho consistentemente para conectar o débito técnico aos impactos de negócios não apenas ajudará suas partes interessadas a entender melhor o trabalho a ser feito. Ela também o ajudará a garantir que você esteja identificando e lidando com o débito técnico de maneiras que realmente beneficiam os usuários.

A lista de padrões e antipadrões abaixo mostra como é um gerenciamento de débito técnico adequado (e ruim) para uma organização do Salesforce.

Para saber mais sobre as ferramentas do Salesforce que podem ajudá-lo com dívidas técnicas, consulte Ferramentas relevantes para intencional.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para manutenção no Padrão & Anti-Padrão Explorador.

No seu núcleo, o conceito de legibilidade é criar consistência que facilite a compreensão das coisas. A criação de sistemas legíveis alinha as equipes de entrega e manutenção e ajuda as pessoas que não conhecem o sistema a entender rapidamente como as peças se encaixam. Isso significa que sua equipe pode ser menos dependente de pessoas individuais com Knowledge institucional ou histórico para integrar efetivamente fornecedores ou novos membros da equipe. Isso significa que indivíduos habilidosos em uma equipe podem se concentrar na qualidade e nos prós e os contras das escolhas que estão sendo feitas, pois a configuração e o código do sistema são fáceis para os humanos lerem e entenderem. A legibilidade pode acelerar os processos de governança e garantia de qualidade e ajudar as equipes a identificar melhor quando podem estar criando personalizações redundantes. Também pode aumentar as chances de ter um sistema que se comporte de maneiras reutilizáveis e testáveis.

Você pode aumentar a legibilidade por meio de padrões de design e documentação eficazes.

Os padrões de design fornecem orientação para manter todas as personalizações consistentes, mesmo nas fases mais iniciais do desenvolvimento. Os padrões de design atuam como proteções, mantendo todas as equipes de entrega e de manutenção trabalhando em seu sistema alinhadas sobre como abordar e implementar personalizações. Definir padrões de design ajuda a aumentar a produtividade de suas equipes de entrega e manutenção, facilita a realização de revisões de código e arquitetura e fornece uma base para uma melhor documentação.

Sem padrões de design, as equipes têm maior probabilidade de trabalhar em silos. Sem a consistência que os padrões de design fornecem, as empresas terão dificuldade para:

• Fornecedores e equipes de desenvolvimento usando padrões e abordagens ad hoc entre soluções, potencialmente introduzindo antipadrões e reduzindo a reutilizabilidade (consulte Separação de preocupações).
• Maior tempo para resolver problemas de produção e equipes de suporte necessárias para integrar novos membros da equipe e ajudá-los a entender um conjunto distinto de padrões e abordagens.
• Mala colaboração entre equipes, redundâncias no trabalho entre equipes, tempo perdido para resolver conflitos e bugs descobertos durante testes de integração.
• Maior frustração e maiores taxas de rotatividade.

Um benefício importante dos padrões de design vem das conversas e decisões que as partes interessadas devem tomar para criá-los. Especificamente, o processo oferece aos seus negócios e leads de tecnologia a oportunidade de alinhar o design ideal para seus negócios.

Inclua o seguinte em seus padrões de design

• Convenções de nomenclatura para metadados do Salesforce. Defina um conjunto de convenções para como cada personalização em um sistema deve ser nomeada. Boas convenções de nomenclatura não apenas impõem consistência nos nomes de objetos, campos, códigos, fluxos e outros elementos do seu sistema. As boas convenções de nomenclatura também ajudam as equipes de desenvolvimento a usar nomes que transmitem informações sobre o propósito e a funcionalidade do que estão criando. Como resultado, outras partes interessadas podem entender melhor uma personalização específica apenas vendo seu nome.
• Padrões de projeto aprovados e seus casos de uso. Estabeleça uma biblioteca de Padrão e Anti-Padrão Explorador, junto com informações importantes sobre quando (e quando não) usar cada padrão. A biblioteca pode incluir padrões de acionador do Apex obrigatórios ou padrões de orquestração de fluxo com base na composibilidade desejada no seu sistema.
• Ambiente de desenvolvimento e orientação sobre ferramentas. Mantenha uma lista clara das ferramentas que as equipes de desenvolvimento devem usar para seu trabalho. Isso pode incluir cadeias de ferramentas e idiomas aprovados para qualquer pessoa que escreva código ou recursos declarativos aprovados (ou não) para desenvolvimento com baixa codificação. Seus padrões podem incluir uma lista de sistemas de controle de origem para personalização e documentação e etapas de check-in/check-out obrigatórias. Eles também podem incluir uma lista de ambientes a serem usados para diferentes tipos de trabalho de desenvolvimento.

Junto com a definição desses padrões, você precisará decidir como e onde mantê-los e armazená-los. Se as equipes em toda a sua empresa não conseguirem encontrar seus padrões de design (ou nem sequer souberem que existem), elas não serão eficazes. O ideal é que seus padrões de design fiquem no mesmo sistema que sua documentação (consulte a próxima seção para saber mais).

A lista de padrões e antipadrões abaixo mostra a aparência de padrões de design adequados (e ruins) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar seus padrões de design.

Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo a definir padrões de design, consulte Ferramentas relevantes para intencional.

A documentação explica o que, como e por quê do seu sistema. Sem uma documentação consistente e consistente, as equipes gastam muito tempo tentando entender o sistema como ele é (e possivelmente mal compreendendo recursos e personalizações).

A criação de uma boa documentação leva tempo. Embora a maioria das equipes concorde em que a documentação é importante para projetos grandes, pode ser uma etapa tentadora para ignorar ao fazer alterações rápidas, como atualizações de configuração ou pequenos ajustes em uma automação. Não documentar as alterações feitas no seu sistema é sempre antipadrão. Ignorar a documentação pode economizar um pouco de tempo com antecedência, mas a quantidade de tempo necessária para solucionar problemas de uma organização que não está devidamente documentada vai excluir essas economias de tempo. Sempre inclua tempo suficiente para criar a documentação em todas as suas estimativas, independentemente do nível de esforço necessário para as atualizações que você planeja fazer.

A falta de documentação clara pode levar a vários problemas, incluindo:

• Ciclos de desenvolvimento gastos em refazer implementações existentes
• Discussões repetitivas revisitando ou confundindo decisões anteriores
• Integração mais longa para novos membros da equipe ou fornecedores
• Excesso de dependência de indivíduos com Knowledge institucional ou histórico
• Arquiteturas redundantes para dar suporte a recursos iguais ou semelhantes em todo o negócio
• Dificuldade para comunicar o propósito e o valor da sua solução às principais partes interessadas

Para soluções do Salesforce, mantenha a documentação para:

• Visões gerais de soluções. Os diagramas permitem que você e suas partes interessadas visualizem soluções em vários níveis de detalhes. A estrutura de diagrama do Salesforce ajuda você a criar diagramas que mostram as funcionalidades de negócios das soluções, bem como os detalhes de implementação técnica.
• Registros de decisão. Mantenha um registro das opções consideradas, compensações, decisão final e raciocínio em um local central que todos os membros da equipe possam acessar para consulta futura.
• Código. O formato do código em si é uma parte fundamental da documentação, e isso pode (e deve) estar alinhado às suas normas de design. Você também quer ter um registro de informações-chave e atualizá-lo a cada modificação de um código. Para todas as classes, acionadores e componentes, documente o seguinte:
  • Quem criou o código
  • Quando o código foi escrito
  • O que o código deve fazer
  • Dependências principais
  • Todas as alterações
• Personalizar declarativo. Para cada tipo de personalização que pode ser feita aos metadados em sua organização, o Salesforce fornece atributos integrados para que as equipes forneçam informações úteis sobre o propósito e a intenção dos metadados. Como parte de seus padrões de design, inclua como as equipes devem usar esses recursos integrados e como eles devem dar um nome a personalizações declarativas. Mantenha também um registro de informações-chave idêntico ao que você usa para código.

Desenvolver um conjunto de normas de documentação para garantir que todos os membros da equipe atuais e futuros possam interpretar documentos da mesma maneira. (As normas de design podem ajudar com isso.) Também é importante considerar como os usuários poderão pesquisar na documentação para encontrar seções ou termos relevantes. Conforme seu sistema envelhece e cresce em complexidade, sua documentação também aumentará. A utilidade das informações na sua documentação estará diretamente relacionada à frequência, à rapidez e à facilidade com que os usuários podem pesquisar e localizar itens relevantes.

A lista de padrões e antipadrões abaixo mostra a aparência da documentação adequada (e ruim) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de documentação.

Para aprender mais sobre ferramentas do Salesforce para documentação, consulte Ferramentas relevantes para intencional.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para legibilidade no Padrão & Anti-Padrão Explorador.

Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.