O que é fonte única da verdade (SSoT)

No início da minha jornada na BNP, conheci uma figura impressionante.

Kátia Salemme. Assistente administrativa

Kátia era e ainda é um pilar do conhecimento organizacional. Kátia não era apenas uma funcionária dedicada; ela era a enciclopédia viva da empresa. Precisava saber informações sobre o convênio? Kátia tinha a resposta. Curioso sobre um procedimento interno ou detalhes de um cliente? Kátia era a fonte para perguntar.

Naquela época, ela personificava o que, no mundo da tecnologia, chamamos de Single Source of Truth (SSoT) – a fonte única da verdade.”

Kátia conhecia todos os clientes, todos os procedimentos e cada detalhe relevante sobre os funcionários. Para qualquer pergunta, ela tinha a resposta.

Se você perdesse seu crachá, Kátia sabia onde encontrar um novo. Se esquecesse a senha do Wi-Fi, ela tinha todas anotadas. Ela não apenas sabia onde o papel higiênico era guardado, mas também onde comprar!

Enquanto Kátia desempenhava seu papel, a realidade é que depender de uma única pessoa para todo o conhecimento organizacional é uma estratégia que não escala. À medida que a BNP cresceu, os desafios se tornaram mais complexos e as informações mais volumosas. Imaginem a sobrecarga para Kátia – e o risco para a empresa. Fica evidente que o modelo ‘Kátia de Informação’ tem suas limitações.

É aqui que entra o conceito de Single Source of Truth (SSoT). Ao contrário de centralizar o conhecimento em uma pessoa, o SSoT propõe centralizá-lo em um sistema ou plataforma. O SSoT permite que a informação flua de forma eficiente e controlada, evitando os gargalos e inconsistências que ocorrem quando dependemos de uma ‘fonte humana’ de informações. Portanto, a transição para um modelo baseado em SSoT não é apenas uma questão de eficiência, mas uma necessidade crucial para a escala e sustentação do negócio.

A Cultura da BNP

Para entender melhor a necessidade de um SSoT na BNP, vale considerar a nossa cultura organizacional. Sempre valorizamos a liberdade e a autonomia em detrimento de processos rígidos. A decisão nunca foi imposta de cima para baixo; ao contrário, sempre confiamos na capacidade individual dos colaboradores para resolver problemas. Essa abordagem nos permitiu crescer rapidamente, fundamentados na confiança e nas entregas eficientes. No entanto, como em qualquer história de sucesso, existem desafios.

Por priorizarmos a solução de problemas acima de tudo, muitas vezes a organização dos processos acabou ficando em segundo plano. Resolvíamos o problema em questão e só depois lidávamos com a ‘bagunça’ deixada para trás. Com o crescimento da empresa, essa abordagem começou a criar silos de informação: ilhas isoladas de conhecimento que não se comunicam entre si. Cada departamento, cada equipe, tinha seu próprio conjunto de processos, ferramentas e sistemas, muitas vezes duplicados ou incompatíveis uns com os outros.
Até hoje, enfrentamos o desafio de integrar devs, time comercial e time de infraestrutura, por exemplo.

Essa realidade nos fez perceber a necessidade de um Single Source of Truth. Sem um SSoT, cada silo funciona com sua própria versão da ‘verdade’, criando desafios para a tomada de decisões e a colaboração entre equipes. Além disso, a falta de um sistema unificado leva a redundâncias, ineficiências e, o mais preocupante, a uma potencial desinformação.
Eu acredito que a implementação de um SSoT seja um passo essencial para garantir a continuidade do nosso crescimento de forma sustentável e coesa.

Achar que na BNP não documentamos nada é um erro!

É um equívoco comum pensar que, na BNP, não damos importância à documentação. Na verdade, produzimos uma quantidade significativa de informações, mas o desafio está na dispersão desses dados. Nossa cultura de inovação e resolução rápida de problemas leva à criação de muitos documentos, notas, e registros. Contudo, eles frequentemente residem em diferentes sistemas, pastas, e plataformas. Esta proliferação de informações em vários locais cria uma espécie de ‘riqueza oculta’, valiosa, porém não totalmente acessível ou aproveitada devido à sua natureza fragmentada.

O que não é SSoT

SSoT não é apenas um repositório de dados ou documentos. Não se trata meramente de um local para armazenamento de informações, mas sim de um sistema integrado e confiável, destinado a facilitar o acesso a informações precisas e atualizadas. Um SSoT não é uma plataforma de cursos, onde conteúdos desconexos e não integrados são compilados sem um planejamento centrado no usuário final e no propósito específico da informação.

Além disso, SSoT não é um canal para compartilhar comunicados de decisões da diretoria. Embora esses comunicados sejam importantes, eles não compõem por si só uma fonte única e integrada de verdade operacional e estratégica. E, definitivamente, SSoT não é sinônimo de uma intranet. Uma intranet pode conter vários tipos de informações, mas sem a integração e a governança de dados característica de um SSoT, ela serve mais como um ponto de encontro digital do que uma fonte confiável e única de informações vitais para a empresa.

O que é SSoT?

Em uma frase “gestão do conteúdo a partir de uma ferramenta única”. Segundo esse conceito, então, todo o conteúdo (técnico e não técnico) de uma empresa deve ser centralizado em uma base de conhecimento acessível para toda organização.

A ideia, portanto, é criar um ponto de centralização de conhecimento que sirva como referência, para garantir que todo mundo tenha acesso às mesmas informações.

Para variar, mais um “OPS”

Se você me acompanha há algum tempo, já me ouviu falar de vários “OPS”:

• DevOps
• DevSecOps
• TeamOps
• FinOps
• MLOps
• AIOps
• DataOps
• e por aí vai…

Mas eu gostaria de te apresentar mais um! DocOps (Documentation Operations) ou Operações de Documentação surgiu da metodologia DevOps (para variar) e o objetivo é o mesmo do DevOps. Porém, o DocOps é focado no desenvolvimento de documentação.

Essa “metodologia” por assim dizer, é defendida pelas comunidades “Write the docs” e “RTFM”.

Eles oferecem um framework para garantir uma documentação em constante melhoria.

Separe pelo menos 20 minutos por semana (você consegue 😜).

1. Junte o que você e seu time produziram de informação, planeje sobre o que escreverá.
2. Escreva! Pode usar o GPT, mas lembre-se de revisar.
3. Estruture de uma forma que faça sentido, tente estruturar como uma história com começo, meio, fim e um objetivo claro.
4. Revise, peça ajuda de outros leitores, corrija imperfeições.
5. Divulgue! De nada vale termos a informação se ninguém sabe que ela existe.
6. Avalie novamente se a informação continua relevante.
7. Na próxima semana, repita o processo.

Como encarar o SSoT: A abordagem “Handbook-first”

Imagine um caderninho de notas que você leva sempre embaixo do braço, pronto para ser consultado a qualquer momento. Este caderninho contém tudo o que você precisa saber: procedimentos, políticas, detalhes de projetos, e até mesmo insights valiosos sobre a cultura da empresa. Agora, pense neste caderninho em um formato digital, acessível a todos na organização. Essa é a essência da abordagem handbook-first para o SSoT.

Só que não usamos o caderninho apenas para ler, mas também para anotar o que achamos importante ou necessário para o futuro. Cada processo, cada decisão e cada aprendizado são registrados e armazenados nesse ‘caderninho digital’. Desta forma, todos na organização têm acesso ao mesmo conjunto de informações confiáveis e atualizadas. Não é apenas uma questão de armazenar dados, mas de criar uma cultura onde a informação é compartilhada, revista e atualizada continuamente.

Com essa abordagem, nosso ‘caderninho de notas’ torna-se uma ferramenta poderosa, um verdadeiro Single Source of Truth, essencial para o crescimento e sucesso contínuos da nossa empresa. E enfim, podemos deixar a Kátia em paz.

Quais documentos armazenar no SSoT (por equipe)

Cada equipe precisa de informações diferentes. Aqui estou deixando algumas sugestões do que você pode escrever.

Para todas as equipes

• Anotações de reuniões
• Processos e diagramas de fluxo de trabalho
• Objetivos e OKRs
• Planos de projeto
• Guias de integração para novos colaboradores
• Revisões de desempenho

Para time de produtos específicos

• Exigências do produto
• Lançamentos de produtos
• Roadmap do produto
• Documentação técnica
• Manual do produto

Vendas e Marketing

• Planos de campanha e projeto
• Apresentações
• Diretrizes de marca e comunicação
• Bibliotecas de imagens
• Kit de imprensa
• Materiais de discurso de RFP
• Documentação do cliente

Gestão de pessoas (RH)

• Políticas da empresa
• Diretório da empresa
• Manuais de integração
• Acompanhamento de férias anuais e calendários

Service Desk e Suporte ao Cliente

• Base de conhecimento
• FAQs
• Respostas Prontas

Equipe de desenvolvimento / OPS

• Boas práticas e exigências técnicas
• Tecnologias e stack utilizada
• Runbooks de DevOps
• Análises retrospectivas de incidentes
• Guias para solução de problemas
• READMEs

Com exemplos práticos e uma abordagem handbook-first, tornamos o conhecimento acessível e útil, capacitando cada membro da equipe a contribuir de forma mais efetiva para o nosso crescimento contínuo.
Espero que eu tenha conseguido explicar esse conceito tão necessário para ganhar escala. Desejo boa sorte com tudo que você construir e boa escrita!

Referências

DocOps — Write the Docs

RTFM – Wikipédia, a enciclopédia livre (wikipedia.org)

The importance of a handbook-first approach to communication | The GitLab Handbook

Single Source of Truth (SSOT): entenda as vantagens – TOTVS

Shared Reality | The GitLab Handbook

Implementing single source of truth in an enterprise architecture | Enable Architect (redhat.com)