Como estruturar as fases do seu processo corretamente

Você já tem um pipe no ar. As fases estão lá, talvez exatamente como vieram no template, talvez com alguns ajustes que você fez para o seu contexto. O próximo passo é entender se cada fase está fazendo o trabalho que deveria fazer.

Fase bem estruturada não é questão de estética ou preferência. É o que determina se o Pipefy vai conseguir te ajudar de verdade: automatizar transições, medir tempo de ciclo, mostrar onde o processo atrasa e notificar as pessoas certas na hora certa. Tudo isso depende de fases que representam estados reais do processo, não categorias genéricas que agrupam responsabilidades de pessoas diferentes.

Este artigo te dá os critérios práticos para avaliar as fases que você tem e decidir com confiança quando separar, quando unir e quando o que está aí já está certo.

📖 O que você vai entender aqui:

O que uma fase realmente faz

No Pipefy, uma fase não é só uma coluna com nome. Ela é uma declaração sobre o estado do processo: "este card está aqui, e isso significa uma coisa específica — alguém específico precisa fazer algo específico antes de ele avançar."

Quando uma fase cumpre esse papel, ela se torna um ponto de controle. O gestor olha para o kanban e sabe exatamente o que está acontecendo com cada demanda. O responsável sabe o que precisa fazer. Uma automação sabe quando disparar.

Quando uma fase não cumpre esse papel? Quando é genérica demais, quando agrupa responsabilidades de pessoas diferentes, quando não tem critério de saída claro e o processo real acontece fora dela: em e-mails, em comentários, em conversas de corredor. O pipe vira um painel decorativo.

Os dois critérios que definem uma fase bem estruturada

Existe uma pergunta simples para avaliar qualquer fase do seu pipe:

"Quem é o responsável por esta fase e o que precisa acontecer para o card sair daqui?"

Se você consegue responder essa pergunta com clareza, a fase está bem estruturada. Se a resposta for vaga, múltipla ou incerta, a fase tem espaço para evoluir.

Critério 1 — Responsável claro. Cada fase deve ter uma pessoa ou um papel definido que age sobre o card enquanto ele está ali. Não precisa ser uma única pessoa nominal, pode ser "qualquer membro do time de TI" ou "o gestor do colaborador". O que não pode é ser "depende" ou "todo mundo". Quando a responsabilidade é difusa, o card fica parado porque ninguém sente que é seu problema resolver.

Critério 2 — Critério de saída definido. Deve existir uma condição objetiva que indica quando o card está pronto para avançar. Pode ser um checklist completado, um campo preenchido com um valor específico, uma data atingida ou uma aprovação registrada. Quando o critério de saída não existe, o card avança na base da intuição e isso impossibilita tanto a automação quanto a medição.

Quando separar uma etapa em fase própria

A decisão de criar uma fase nova deve ser orientada pelos dois critérios acima, não pelo desejo de detalhar o processo ao máximo. Mais fases não é igual a mais controle. Fases certas é igual a mais controle.

Separe em fase própria quando:

• A responsabilidade muda. Esta é a regra mais importante. Quando o trabalho passa de uma pessoa ou área para outra, esse handoff merece uma fase. No onboarding, o momento em que o RH termina a coleta de documentos e o TI precisa começar a configurar acessos é um handoff e é exatamente onde existe uma fase separada no template. Sem essa separação, o TI não sabe quando é a hora de agir.
• O critério de saída é diferente. Se duas etapas têm condições de conclusão distintas, elas pertencem a fases diferentes. "Documentos coletados" e "acessos configurados" são estados completamente diferentes do processo, cada um com seu responsável, seu prazo e seus critérios de verificação. Agrupá-los numa fase "Em andamento" torna ambos invisíveis.
• Você precisa medir o tempo separadamente. Se saber quanto tempo o TI leva para configurar acessos é informação útil para o seu processo, essa etapa precisa ser uma fase, porque o Pipefy só mede tempo dentro de fases. O que não tem fase não tem métrica.
• Você precisa de um gatilho de automação nesse ponto. Automações disparam em eventos de fase: "card entrou em X", "card saiu de Y", "card ficou em Z por mais de N dias". Se você quer enviar uma notificação automática para o gestor quando os acessos estiverem prontos, precisa de uma fase "Acessos configurados" para criar esse gatilho.

Quando não separar e por que menos pode ser mais

O erro oposto ao de ter fases genéricas demais é ter fases específicas demais. Um pipe com dez, doze fases parece detalhado, mas costuma ser difícil de operar e impossível de automatizar de forma coerente.

Não crie uma fase separada quando:

• São ações dentro da mesma responsabilidade. Se o mesmo responsável executa duas ações em sequência sem passar o card para outra pessoa, essas ações podem ser itens de um checklist dentro de uma única fase. No onboarding, "apresentar a empresa" e "apresentar o local de trabalho" são dois itens do checklist do Primeiro dia, não duas fases diferentes.
• A etapa é muito breve ou sempre instantânea. Se uma etapa demora menos de alguns minutos e acontece sem intervenção humana, como o envio automático de um e-mail de boas-vindas, ela não precisa de uma fase. Uma automação resolve sem precisar criar um estado intermediário no processo.
• Você está modelando exceções, não a regra. Não construa fases para os casos que raramente acontecem. Se 5% dos onboardings têm uma etapa extra de aprovação jurídica, essa etapa pode ser tratada com um campo condicional ou uma fase opcional, não como uma fase permanente que todo card vai percorrer.

Referência rápida: quando separar e quando não separar

O template de onboarding como referência prática

O template de onboarding aplica esses critérios de forma bastante direta. A tabela abaixo mostra cada fase com seu responsável e critério de saída, o raciocínio que justifica a estrutura do template:

O que você não vai encontrar no template: uma fase para "envio do e-mail de boas-vindas" (é uma automação), uma fase para "aprovação do cadastro no RH" (é um campo dentro do Planejamento), uma fase para "devolução de equipamentos em caso de desligamento" (é uma exceção, não a regra do processo).

Como avaliar as fases do seu pipe agora

Com os critérios em mãos, a revisão do pipe é direta. Para cada fase, responda as quatro perguntas abaixo:

Checklist de revisão de fases

☐ Quem é o responsável por esta fase?
☐ O que precisa acontecer para o card sair daqui?
☐ Esta fase é diferente da anterior em responsável ou critério de saída?
☐ Você vai querer medir o tempo ou criar uma automação a partir desta fase

FAQ

Existe um número ideal de fases?

Não existe regra, mas existe um padrão observável: processos com três a sete fases bem definidas são os mais fáceis de operar, automatizar e medir. Abaixo de três, o processo costuma estar sub-representado. Acima de sete, a operação fica pesada e as automações se tornam difíceis de manter. Se o seu pipe está fora dessa faixa, vale aplicar os critérios e ver o que pode ser unido ou separado.

Posso ter fases opcionais que alguns cards percorrem e outros não?

Sim. O Pipefy permite criar automações que movem cards diretamente de uma fase para outra pulando etapas intermediárias, com base em condições de campo. Se 80% dos onboardings não precisam de uma fase de "Aprovação jurídica", você pode mantê-la no pipe e criar uma automação que pula essa fase automaticamente para os casos que não precisam dela.

E se o meu processo tiver etapas paralelas — coisas que acontecem ao mesmo tempo?

Fases no Pipefy são sequenciais, um card está em uma fase por vez. Para etapas paralelas, a solução mais comum é usar checklists dentro de uma fase para representar ações simultâneas, ou criar pipes conectados quando as etapas paralelas pertencem a times diferentes. O artigo sobre automações entre pipes cobre esse padrão.

Quando faz sentido ter fases diferentes para tipos diferentes de onboarding?

Se os fluxos de CLT e PJ têm etapas completamente distintas com responsáveis diferentes, pipes separados por tipo costumam ser mais fáceis de operar. Se as diferenças são apenas nos campos e documentos, mas as etapas são as mesmas, um único pipe com campos condicionais e automações por tipo de contrato resolve bem.

Posso reorganizar as fases depois que o pipe já tem cards?

Sim. Renomear e reordenar fases não afeta os cards existentes. Deletar uma fase com cards dentro, por outro lado, apaga os cards permanentemente, então a prática recomendada é mover os cards para outra fase antes de deletar.