Blog
Como documentar os processos da sua empresa sem perder o juízo

SOPs, fluxos de trabalho, guias de onboarding: todo mundo sabe que eles deveriam existir. Ninguém tem tempo para escrevê-los. A resposta é uma documentação que se escreve sozinha.
Toda empresa em crescimento chega a um ponto em que o fundador ou gestor pensa: "Precisamos documentar nossos processos." O fluxo de trabalho de faturamento. As etapas de onboarding do cliente. O checklist de garantia de qualidade. O processo de contratação. O procedimento de escalonamento. Todas as coisas que os membros experientes da equipe guardam na cabeça e os novos membros precisam aprender por osmose.
O raciocínio está correto. Processos documentados reduzem erros, aceleram o onboarding, tornam a empresa menos dependente de pessoas específicas e fornecem a base para melhorias (você não pode melhorar o que não pode ver). A lacuna entre empresas com processos documentados e aquelas sem cresce a cada contratação, porque cada nova pessoa ou lê a documentação ou consome o tempo de outra pessoa aprendendo verbalmente.
O problema é que escrever a documentação de processos é um trabalho ingrato, e a documentação fica desatualizada quase imediatamente.
Por que a documentação de processos falha
Escrever é doloroso. A pessoa que conhece o processo (geralmente o membro mais experiente e ocupado da equipe) precisa parar de fazer o trabalho produtivo, mudar para o modo de escrita e produzir um documento claro e passo a passo que faça sentido para alguém que nunca realizou a tarefa. Essa mudança de contexto é cognitivamente cara, a tarefa parece de baixa prioridade em comparação com o trabalho real e leva muito mais tempo do que qualquer um estima.
A documentação nasce incompleta. Os processos têm exceções, casos isolados e decisões subjetivas que o redator não pensa em documentar porque os resolve automaticamente. O POP (Procedimento Operacional Padrão) escrito cobre o caminho ideal. Na primeira vez que um novo contratado encontra uma exceção, o POP não ajuda e ele acaba perguntando à pessoa experiente de qualquer maneira.
A documentação fica desatualizada instantaneamente. Os processos evoluem continuamente por meio de pequenos ajustes que ninguém lembra de refletir na documentação. O POP estava correto quando foi escrito. Três meses depois, duas etapas mudaram, uma ferramenta foi trocada e uma etapa de aprovação foi adicionada. O documento agora descreve um processo que não existe, e segui-lo cria mais problemas do que resolve.
Ninguém faz a manutenção. A documentação de processos não tem um dono natural. A pessoa que a escreveu já passou para outras prioridades. As pessoas que a seguem não se sentem responsáveis por atualizá-la. A documentação se afasta da realidade até que alguém perceba, o que geralmente acontece quando um novo contratado segue as instruções desatualizadas e produz o resultado errado.
A alternativa da autoescrita
A alternativa para escrever a documentação de processos manualmente é deixar que ela se escreva sozinha a partir da atividade que define o processo.
Os processos da sua equipe já estão expressos no trabalho diário: as discussões no Slack sobre como lidar com a solicitação de um cliente, a reunião onde a equipe detalhou as etapas de onboarding, a troca de e-mails que documenta o fluxo de aprovação, o checklist na ferramenta de gestão de projetos que registra as etapas de garantia de qualidade.
A documentação que se escreve sozinha captura essas expressões do processo e as estrutura em documentação. O histórico do Slack onde a equipe discutiu "é assim que lidamos com solicitações de reembolso" se torna um procedimento de reembolso documentado. A reunião onde o líder de operações orientou um novo contratado pelas etapas de onboarding de clientes se torna um guia de onboarding. A discussão recorrente sobre como lidar com um caso isolado específico se torna um procedimento de exceção documentado.
A documentação permanece atualizada porque é gerada a partir da atividade contínua. Quando o processo muda (uma nova etapa é adicionada, uma ferramenta é trocada, uma aprovação é removida), a mudança é discutida no Slack ou em uma reunião, e a documentação se atualiza para refletir isso. O problema da obsolescência que mata os POPs escritos manualmente não se aplica porque a documentação é derivada da realidade, e não mantida paralelamente a ela.
Como isso se parece na prática
Onboarding de clientes. Em vez de escrever um POP de onboarding, conecte as fontes onde a atividade de onboarding acontece: o canal do Slack onde a equipe discute novas configurações de clientes, as gravações de reuniões onde as chamadas de onboarding são realizadas, a correspondência por e-mail com novos clientes. O sistema de autoescrita captura o processo à medida que ele é executado e produz uma documentação que reflete como o onboarding realmente funciona, incluindo as etapas informais e exceções que um POP escrito manualmente deixaria passar.
Processo de vendas. As etapas de uma negociação, as etapas de aprovação para descontos, o processo de transição entre vendas e entrega: tudo capturado a partir da atividade no CRM, discussões no Slack e gravações de reuniões. O manual de vendas se escreve sozinho a partir de negociações reais, em vez de ser elaborado por alguém tentando descrever uma versão idealizada.
Fluxos de trabalho de engenharia. O procedimento de implantação, os padrões de revisão de código, o protocolo de resposta a incidentes: tudo capturado a partir da atividade no GitHub, canais de engenharia no Slack e reuniões de retrospectiva (post-mortem). A wiki de engenharia permanece atualizada à medida que as práticas evoluem.
Operações e administrativo. O fluxo de trabalho de faturamento, o processo de aprovação de despesas, as etapas de gestão de fornecedores: capturados a partir das discussões e comunicações onde esses processos são executados e refinados.
Primeiros passos
Você não precisa documentar todos os processos de uma vez. Comece pelo processo que causa mais dor quando não está documentado, normalmente aquilo que sua equipe pergunta com mais frequência ou o que os novos contratados levam mais tempo para aprender.
Conecte as fontes onde esse processo é discutido e executado. Deixe o sistema de autoescrita gerar a documentação inicial. Revise e refine (essa é uma tarefa de quinze minutos, em vez de um projeto de escrita de dois dias). Depois, expanda para o próximo processo.
Ao longo dos meses, a biblioteca de documentação cresce junto com a atividade da equipe. Cada processo fica documentado, atualizado e pesquisável. Os novos contratados podem encontrar a resposta para "como o X funciona?" sem precisar perguntar, o que significa que os membros experientes da equipe que atualmente respondem a essa pergunta várias vezes por mês ganham seu tempo de volta.
Perguntas frequentes
A documentação gerada automaticamente não ficará confusa demais para ser usada? O sistema de autoescrita produz uma documentação estruturada e com fontes citadas, em vez de transcrições brutas. O resultado é um resumo do processo com etapas, exceções e links para as discussões de origem. Você apenas revisa e refina, em vez de escrever do zero, o que é uma tarefa muito menor.
E quanto aos processos que envolvem informações confidenciais? Controles de acesso garantem que a documentação do processo seja visível apenas para as pessoas que devem visualizá-la. Você pode configurar quais fontes são capturadas e quais são excluídas, e a arquitetura de privacidade mantém os mesmos limites de acesso das ferramentas subjacentes.
Como lidamos com processos que envolvem várias equipes? Processos interdepartamentais são capturados a partir dos canais onde são discutidos entre as equipes. O sistema de autoescrita não respeita barreiras de equipe na sua captura (a menos que seja configurado para isso), o que significa que os processos multifuncionais são documentados de forma mais completa do que seriam em um sistema manual onde cada equipe documenta apenas a sua parte.
E se o processo for informal e não documentado? Esse é o caso mais comum, e é onde a documentação que se escreve sozinha tem mais valor. Se o processo é realizado e discutido, mas nunca foi formalmente documentado, o sistema de autoescrita o captura a partir das discussões e gera a primeira documentação. Um processo informal que é capturado é mais útil do que um processo formal que foi escrito uma vez e ficou obsoleto.
Isso funciona para setores regulamentados? Processos documentados costumam ser um requisito de conformidade em setores regulamentados. A documentação que se escreve sozinha fornece uma documentação de processos auditável e com fontes citadas, que pode ser revisada e aprovada por meio do fluxo de conformidade da organização. A documentação é mais confiável do que POPs mantidos manualmente porque reflete a prática real, e não a prática pretendida.
Podemos usar isso para documentação de ISO ou gestão de qualidade? A documentação que se escreve sozinha oferece uma base sólida para sistemas de gestão de qualidade. O resultado estruturado e com fontes citadas pode ser revisado e aprovado através dos seus processos de qualidade existentes. Para uma certificação formal, você revisaria e aprovaria a documentação gerada como faria com qualquer POP escrito manualmente, mas a criação inicial e a manutenção contínua são tratadas pelo sistema.
E se nossos processos ainda não forem consistentes? O sistema de autoescrita captura os processos como eles são realmente realizados, o que torna as inconsistências visíveis. Se três pessoas lidam com reembolsos de maneiras diferentes, la documentação refletirá as três abordagens, que é o ponto de partida para a padronização. Você não pode padronizar o que não pode ver, e a documentação torna o estado atual visível.
Como lidamos com mudanças de processos? As mudanças de processos geralmente são discutidas no Slack ou em reuniões antes de serem implementadas. O sistema de autoescrita captura essas discussões e atualiza a documentação para refletir o novo processo. Não há uma etapa separada de "atualizar o POP" porque a documentação deriva da atividade, em vez de ser mantida paralelamente a ela.
Podemos exportar a documentação do processo? Sim. A documentação está acessível através da API e pode ser exportada em formatos padrão. Se você precisar compartilhar a documentação de processos com auditores externos, clientes ou parceiros, o conteúdo pode ser exportado ou publicado como uma página compartilhável.
E quanto aos processos que envolvem ferramentas externas ou etapas físicas? A documentação captura a discussão e a tomada de decisões em torno do processo a partir das suas ferramentas de comunicação. Etapas físicas ou etapas em ferramentas externas que não estão conectadas não serão capturadas automaticamente, mas podem ser documentadas manualmente e integradas ao conteúdo gerado automaticamente. A abordagem híbrida (gerada automaticamente para o que pode ser capturado, manual para o que não pode) ainda economiza um tempo significativo em comparação com a documentação totalmente manual.
Leitura recomendada: Ninguém lê a wiki, Sua equipe continua fazendo as mesmas perguntas, Como construir um cérebro para a empresa. Páginas relacionadas: Documentos que se escrevem sozinhos, Documentos que se autoescrevem, Onboarding.
Outros posts do blog:

The Creative's Cold Start Problem

How to Stop Losing Momentum Between Study Sessions

Your Future Self Can't Read Your Mind

The Hemingway Bridge: Stop Working So You Can Start Again

Your ERP Has the Answers. Nobody Can Find Them.

The Usability Layer Your Business Systems Are Missing

Notas Feitas à Mão vs. Digitais: Você Não Deveria Ter que Escolher

Por que suas anotações manuscritas não podem ser pesquisadas (e o que fazer a respeito)