← Casos de uso

Fazer uma transferência de processo

De um processo que só você domina a um processo que outra pessoa consegue executar sem você.

O caso

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

  1. 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.
  2. Comparar a lista com a documentação existente.Anotar lacunas e contradições. A documentação costuma estar desatualizada.
  3. 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.
  4. Identificar as dependências.Ferramentas, acessos, credenciais, outras pessoas. Tudo com que o processo tem contato.
  5. Confirmar que a outra pessoa tem tudo o que precisa para executar.Verificar os acessos antes da reunião, não durante.
  6. Escrever o documento de transferência.Passos em ordem, dependências e exceções indicadas. O suficiente para executar o processo sem você presente.
  7. 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.
  8. Fazer o percurso completo do processo.Passo a passo, em voz alta. A outra pessoa ainda não executa.
  9. Observar a outra pessoa executar o processo.Só intervir se algo estiver realmente errado. Anotar o que ela pula ou ignora.
  10. Cobrir o que ficou faltando.Breve e direto.
  11. Se houver lacunas importantes, repetir. @9 se necessário.
  12. 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."
  13. 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.