Fazer uma transferência de processo
De um processo que só você domina a um processo que outra pessoa consegue executar sem você.
The case
O problema de transferir um processo é que quem está passando conhece ele de mais. Sabe quais passos realmente importam e quais existem só por costume. Conhece a exceção que aparece a cada dois meses. Sabe que uma dependência é instável e que na sexta-feira se faz de outro jeito. Nada disso está escrito em lugar nenhum — por quê estaria, se é ela que faz.
Aí o que é transferido é o que está documentado. A outra pessoa acena, a reunião termina, e duas semanas depois chegam as perguntas que ninguém ia conseguir antecipar — porque só aparecem quando você realmente executa.
A solução não é melhor documentação. É uma ordem diferente: primeiro reconstruir o processo real, depois escrever, depois observar outra pessoa executar antes de soltar. É na observação que as lacunas aparecem. Elas sempre aparecem.
Um processo não foi transferido até outra pessoa tê-lo executado sem você. Tudo antes disso é preparação.
Transferência de processo
- Listar todos os passos do processo de memória. Sem consultar documentação ainda. O que você lembra sem ajuda é aproximadamente o que a outra pessoa precisa saber.
- Comparar a lista com a documentação existente. Anotar lacunas e contradições. A documentação costuma estar desatualizada.
- Acrescentar os detalhes não documentados. Casos especiais, exceções, o que fazer quando o passo 4 quebra. Esta é a parte que só você conhece.
- Identificar as dependências. Ferramentas, acessos, credenciais, outras pessoas. Tudo com que o processo tem contato.
- Confirmar que a outra pessoa tem tudo o que precisa para executar. Verificar os acessos antes da reunião, não durante.
- Escrever o documento de transferência. Passos em ordem, dependências e exceções indicadas. O suficiente para executar o processo sem você presente.
- Identificar as duas ou três coisas com mais chance de dar errado. O que trava, como resolver, quem chamar se não der para resolver rápido.
- Fazer o percurso completo do processo. Passo a passo, em voz alta. A outra pessoa ainda não executa.
- Observar a outra pessoa executar o processo. Só intervir se algo estiver realmente errado. Anotar o que ela pula ou ignora.
- Cobrir o que ficou faltando. Breve e direto.
- Se houver lacunas importantes, repetir. @9 se necessário.
- Combinar o que acontece se algo der errado depois que você não estiver mais. Um nome, um documento, um canal. Não: "me manda mensagem."
- Confirmar que está pronta para executar sozinha. A avaliação dela, não a sua.
Gambiarra à vontade
O passo 3 é onde a maioria das transferências falha. A versão documentada de um processo raramente é a versão que funciona de verdade — sempre tem um contorno para o que nunca foi corrigido, um atalho que virou padrão, uma verificação que existe por causa de alguma coisa que aconteceu anos atrás. Pular este passo é entregar um mapa incompleto.
O passo em que a outra pessoa executa o processo enquanto você observa (passo 9) não tem substituto quando há complexidade real. Ouvir alguém dizer que entendeu não é a mesma coisa que ver executando. O que ela pula ou onde hesita diz mais do que qualquer pergunta.
Para um processo simples, os passos 6 e 7 podem ser combinados em um documento curto. Para qualquer coisa com consequências sérias — contato com cliente, financeiro, operação — é melhor manter separados. O documento de "o que fazer se der errado" é o que alguém realmente abre sob pressão.
Depois de algumas transferências, o passo 1 fica mais fácil se você começar a documentar os processos enquanto os executa, em vez de reconstruir depois. É outro hábito, mas acelera bastante este aqui.