Os Principais Pontos para uma Documentação Técnica de Negócios com Arquitetura de Sistemas
Tags: programming, learning, documentation, dataengineering
Published: 2024-07-10 21:24:17

Percebo que muitos profissionais tem dificuldade em como estruturar ou desenvolver uma boa documentação técnica. É imprescindível documentar os processos de negócios e suas regras, além de descrever como o técnico se alinha a cada processo de negócio. Não deixar de incluir quais são as ferramentas/frameworks utilizados, detalhar uma arquitetura técnica até a parte de infraestrutura, não deixando de constar as áreas envolvidas e que são impactadas.
Portanto, com minhas experiências, eu estruturei um padrão com tópicos super pertinentes na hora de redigir uma documentação, deixando pequenas explicações ao longo de cada tópico para te inspirar e assim desenvolver belas documentações funcionais e que com certeza muitas pessoas vão agradecer, além de você.
Centralizar informações é essencial para o nosso trabalho; entender como começou e o atual faz muitas dúvidas serem sanadas, além de estar registrado caso alguém esteja ausente.

## Título da Documentação
Na composição do título, seja objetivo, utilizando padrões como: `<Sistema + Ação>`
> Sugestão: `<nome do sistema> - Processos de Negócio e Mapeamento Técnico`

## Descrição
Descreva de forma objetiva, incluindo o propósito da documentação.
> Exemplo: Nesta documentação, você encontrará como o modelo de negócio funciona, juntamente com processos e funcionalidades técnicas principais.

## Conteúdo da Documentação
Explique como o negócio e os processos técnicos se integram ao modelo da empresa. Isso pode incluir arquitetura, explicações dos processos de negócios até detalhes técnicos, mencionando melhorias operacionais discutidas em conversas ou vídeos, redução de custos, otimização de processos ou melhorias.

> Sugestão: Utilize tabelas para melhorar a visualização, podendo ser do tipo Excel ou feita em markdown (recomendo muito o site: [Markdown Guide](https://www.markdownguide.org/basic-syntax/)).

Segue um exemplo simples:

| Sistema         | Ambiente | Tabela   | Link completo             |
| --------------- | -------- | -------- | ------------------------- |
| Nome do sistema | PRD      | dbo.xpto | [https://link.completo](https://link.completo) |

## Requisitos Técnicos
Liste os requisitos de hardware, software e outras infraestruturas necessárias para implementar e/ou acessar, descrevendo links importantes e quem contatar, como solicitar acessos.

## Procedimentos de Implementação
Detalhe passo a passo como foi a implementação, incluindo configuração inicial, treinamento necessário para a equipe e ajustes operacionais. Você pode também descrever a ideia, funcionamento e processos técnicos com documentações de referência, links relevantes ou relatórios.

> **Importante: Descrever pontos de falha, resoluções atuais, assim como áreas para melhoria e atenção.**

## Monitoramento e Manutenção
Especifique como monitorar o desempenho dos processos ao longo do tempo e os procedimentos de manutenção preventiva para garantir sua eficácia contínua.

## Segurança e Privacidade
Descreva quaisquer considerações de segurança cibernética e privacidade de dados relacionadas às ferramentas da arquitetura e como elas são abordadas. 

> É interessante trazer pontos de governança de dados, visando uma área de dados, trazer padrões dentro da empresa. Um exemplo bem simples é o Data Contract, para mapear e democratizar os dados.

## Impacto no Negócio
Avalie o impacto esperado das operações nos principais indicadores de desempenho do negócio, como receita, custos operacionais, satisfação do cliente/empresa, etc. É importante identificar as áreas e processos dependentes para prever quem estará envolvido nesses sistemas.

### Sugestões
- Crie tabelas que referenciam quais áreas/pessoas são impactadas. Lembre-se de comparar o antes e o depois dos processos, por exemplo: pessoas necessárias para iniciar um processo e pessoas dependentes dos resultados.

> Essa informação é ouro dentro de uma documentação, principalmente em sistemas legados, muitas vezes é necessário realizar um discovery muito longo de conversas com vários stakeholders até encontrar pessoas certas, isso quando você não encontra e quando descontinua algum serviço ou fica indisponível a pessoa aparece, rs.

## Observações

> Coloque aqui observações importantes, pontos relevantes que merecem atenção e que talvez não se enquadre nos pontos acima, ou simplesmente dedique essa sessão para maior visibilidade das principais observações.

---
## Conclusão
Desejo que com este artigo você tenha desenvolvido uma excelente habilidade na escrita de documentação de negócios e arquitetura técnica. Obrigada por ler até o final, abraçosssss!

> Autora: Anna Karoliny Matias dos Santos, Data Engineer