Gestão de Implementação de Sistemas

Visão geral do curso

Objetivo geral: desenvolver as habilidades de gestão necessárias para conduzir implementações de sistemas de forma independente da plataforma.

Sequência: Módulo 1 → 2 → 3 → 4 → 5 → 6 — segue a ordem natural de um projeto de implementação, do levantamento até o acompanhamento.

Levantamento de Requisitos

Objetivo: sair de uma reunião com o que o cliente precisa, não só com o que ele pediu.

1. Por que esse módulo vem primeiro

Todo o resto do curso depende disso. Se o levantamento sai errado, você mapeia processo errado, o consultor implementa a coisa errada, e o cliente resiste a uma mudança que nem resolve o problema dele. A maior parte do retrabalho em projeto de implementação nasce aqui, não na etapa técnica.

2. Requisito, desejo e sintoma — a distinção que muda tudo

Cliente raramente descreve o problema. Ele descreve a dor, ou pior, já chega com a solução pronta na cabeça. Seu trabalho é separar três camadas:

• Sintoma — o que o cliente sente ou reclama. Ex: "a gente perde muito tempo procurando informação de cliente".
• Desejo — a solução que ele já imaginou. Ex: "eu preciso de um sistema com busca rápida".
• Requisito real — o que de fato resolve a causa. Ex: os dados do cliente estão espalhados em 3 lugares diferentes e ninguém sabe qual é a versão atualizada — o problema não é "busca lenta", é falta de fonte única de verdade.

Regra prática: toda vez que o cliente te der uma solução pronta, pergunte o problema por trás. A solução é hipótese dele. O problema é fato. Você trabalha com fato.

3. Técnicas de entrevista

3.1 Pergunta aberta vs. fechada

Fechada, evitar no início: "Vocês usam WhatsApp para atender cliente?" — só confirma o que você já supõe.
Aberta, usar primeiro: "Como funciona hoje o atendimento a um cliente novo, do primeiro contato até o fechamento?" — deixa o cliente revelar o processo real, com detalhes que você nem sabia perguntar.

Comece sempre aberto. Feche o cerco com perguntas fechadas só depois, para confirmar detalhes específicos.

3.2 Técnica dos 5 porquês

Pergunte "por quê" repetidamente até chegar na causa raiz — geralmente leva 3 a 5 rodadas.

Pare quando a resposta virar algo que você consegue transformar em requisito técnico ou de processo — não precisa forçar até um "porquê filosófico".

3.3 Perguntas-âncora para toda reunião de levantamento

• Como isso é feito hoje, passo a passo?
• O que acontece quando dá errado?
• Quem mais participa desse processo além de você?
• Se isso não mudasse nunca, o que continuaria doendo daqui a 6 meses?
• Existe algo que vocês tentaram resolver antes e não deu certo? Por quê?

4. Priorização de requisitos

Nem tudo que sai da reunião tem o mesmo peso. Classifique em três níveis:

Isso evita duas armadilhas: prometer tudo (e nunca entregar) ou tratar um "seria bom ter" como se fosse bloqueante.

5. Documentar de forma que o consultor consiga agir

Reporte de levantamento ruim é aquele que obriga o consultor a te chamar de novo pra entender o que você quis dizer. O bom documento responde, para cada requisito:

1. O que é (em uma frase, sem jargão)
2. Por que é necessário (o problema/causa raiz, não o sintoma)
3. Quem pediu / quem é afetado
4. Nível de prioridade (essencial / importante / desejável)
5. Alguma restrição conhecida (prazo, orçamento, sistema legado que precisa continuar funcionando)

Modelo pronto — Documento de Requisitos Levantados

CLIENTE: [nome]
DATA DA REUNIÃO: [data]
PARTICIPANTES: [nomes/cargos]

REQUISITO 1
O que é: 
Problema/causa raiz por trás: 
Quem pediu / quem é afetado: 
Prioridade: [Essencial / Importante / Desejável]
Restrições conhecidas: 

REQUISITO 2
[repetir estrutura]

OBSERVAÇÕES GERAIS DA REUNIÃO:
[qualquer contexto relevante que não virou requisito, mas ajuda a entender o cenário]

Próximo módulo: 02 — Condução de Reuniões

Condução de Reuniões

Objetivo: sair de toda reunião com decisões registradas — não com "a gente vê isso depois".

1. Por que esse módulo depende do anterior

Levantamento de requisitos te dá o quê perguntar. Condução de reuniões te dá o como extrair isso sem a reunião virar bate-papo, sem decisão nenhuma sair dali, e sem precisar marcar outra reunião só pra repetir a mesma pergunta. Uma reunião mal conduzida anula o trabalho do módulo 1: você pode ter as perguntas certas e ainda assim sair sem resposta, porque ninguém fechou nada.

2. Antes da reunião — o que prepara o terreno

Três coisas evitam a maior parte dos problemas, e nenhuma delas acontece durante a reunião:

• Pauta enviada com antecedência — mesmo que sejam 3 linhas. Ninguém participa bem de uma reunião que não sabia do que era.
• Dono de cada assunto — quem vai falar sobre o quê, e principalmente, quem tem poder de decidir sobre aquilo. Cliente manda gente que "leva pra decisão depois" o tempo todo — descubra isso antes, não durante.
• Horário de término definido — reunião sem hora pra acabar tende a virar 40 minutos de conversa e 5 minutos de decisão real.

3. A estrutura de uma reunião de implementação

O fechamento é a etapa que mais gente pula — e é a que garante que todo mundo saiu da sala com o mesmo entendimento.

4. Técnicas para manter a reunião no eixo

4.1 Parking lot (lista de espera)

Quando o assunto sai da pauta, não brigue pra voltar — anote num "estacionamento" visível (mesmo que seja um bloco de notas na tela) e diga: "boa observação, vou colocar isso na lista pra tratarmos separado, sem perder o foco de hoje." Isso valida a pessoa sem sequestrar o tempo da reunião.

4.2 Fechar decisão em voz alta

Nunca deixe uma decisão implícita. Depois que o grupo parecer alinhado, verbalize: "então ficou definido que X, certo?" — e espere confirmação clara. Metade dos "mas eu não entendi assim" nasce de decisão que nunca foi dita em voz alta, só sugerida.

4.3 Evitar o "vamos ver depois"

Toda vez que alguém empurrar uma decisão pra depois, pergunte: "depois quando, e quem fica responsável por trazer isso de volta?" Sem prazo e sem dono, "depois" quase sempre vira "nunca".

5. Perguntas-âncora para conduzir

• "Deixa eu confirmar se entendi: ficou definido que...?"
• "Isso é uma decisão pra hoje, ou precisa de mais alguém pra decidir?"
• "O que falta pra gente fechar esse ponto agora?"
• "Quem fica responsável por isso, e até quando?"

6. Erros comuns

7. Documentar: a ata precisa ser útil, não burocrática

Ata de reunião ruim é aquela que ninguém lê. A boa responde três coisas: o que foi decidido, o que ficou pendente, e quem faz o quê até quando.

Modelo pronto — Ata de Reunião

CLIENTE: [nome]
DATA: [data]
PARTICIPANTES: [nomes/cargos]
PAUTA: [o que estava previsto discutir]

DECISÕES TOMADAS:
1. [decisão] — confirmada por: [nome]
2. ...

PENDÊNCIAS (PARKING LOT):
1. [assunto] — responsável: [nome] — prazo: [data]
2. ...

PRÓXIMOS PASSOS:
[quem faz o quê até quando]

OBSERVAÇÕES:
[contexto relevante que não virou decisão, mas importa pro histórico]

Próximo módulo: 03 — Mapeamento de Processo

Mapeamento de Processo

Objetivo: transformar o que foi levantado e decidido em reunião num desenho simples que qualquer pessoa entende em segundos.

1. Por que mapear depois de levantar e conduzir

Você já sabe os requisitos (módulo 1) e já tirou decisões claras da reunião (módulo 2). Mas texto — mesmo bem escrito — não mostra onde o processo trava. Um mapa visual expõe em segundos um problema que levaria parágrafos pra explicar: "a etapa 3 depende de uma pessoa que só trabalha meio período" fica óbvio quando está desenhado, e passa despercebido quando está descrito em texto corrido.

2. As-is antes do to-be

Regra que não se negocia: mapeie o processo como ele funciona hoje (as-is) antes de desenhar como ele vai funcionar depois da implementação (to-be). Pular direto pro to-be é o erro mais comum — você acaba desenhando o processo ideal na sua cabeça, não o processo real do cliente, e perde os gargalos que só aparecem no as-is.

Se você não consegue desenhar o as-is com o cliente confirmando cada passo, você ainda não levantou o suficiente — volte pro módulo 1.

3. Notação simples — você não precisa de BPMN

Ferramentas complexas de modelagem atrapalham mais do que ajudam nessa fase. Quatro elementos resolvem a maioria dos casos:

• Início / Fim — onde o processo começa e termina
• Atividade — uma ação (retângulo, ou apenas uma linha de texto)
• Decisão — um ponto que se divide em dois caminhos (sim/não, ou opção A/B)
• Seta — a sequência, o que vem depois do quê

Pode ser desenhado no papel, no Miro, ou até em texto puro — o que importa é que o cliente consiga olhar e dizer "sim, é isso mesmo" ou "não, faltou um passo aqui".

[Cliente entra em contato]
        ↓
[Atendente responde manualmente no WhatsApp]
        ↓
[Atendente procura dados do cliente em 3 sistemas diferentes]  ← gargalo
        ↓
[Atendente monta orçamento manualmente numa planilha]
        ↓
[Envia orçamento pro cliente por e-mail]

4. Como transformar o levantamento em mapa

Pegue as respostas que você já tem do módulo 1 (principalmente a pergunta "como isso é feito hoje, passo a passo?") e:

1. Liste cada ação numa ordem cronológica, uma por linha.
2. Marque quem executa cada ação (a pessoa ou o cargo, não o sistema).
3. Marque onde existe decisão ("se o cliente já é cadastrado, pula pra etapa X").
4. Volte com o cliente e confirme passo a passo — é normal faltar 1 ou 2 etapas na primeira versão.

5. Encontrar o gargalo

Três perguntas acham quase todo gargalo de processo:

• Em qual etapa alguém fica esperando outra pessoa pra continuar?
• Qual etapa é feita manualmente e poderia ser automática?
• Qual etapa se repete mais de uma vez sem necessidade (retrabalho)?

O gargalo quase nunca é a etapa que o cliente reclama primeiro — geralmente é uma etapa "invisível" que ninguém tinha percebido, escondida no meio do fluxo.

6. Erros comuns

7. As-is vs to-be lado a lado

Depois de validado o as-is, desenhe o to-be resolvendo especificamente os gargalos encontrados — não o processo todo do zero:

Modelo pronto — Documento de Mapeamento

CLIENTE: [nome]
PROCESSO MAPEADO: [nome do processo]
DATA DE VALIDAÇÃO COM O CLIENTE: [data]

AS-IS (como funciona hoje):
1. [etapa] — responsável: [quem]
2. [etapa] — responsável: [quem]
...

GARGALOS IDENTIFICADOS:
1. [etapa] — motivo: [espera / manual / retrabalho]
...

TO-BE (proposta):
1. [etapa] — resolve qual gargalo: [referência]
...

Próximo módulo: 04 — Controle de Escopo, em breve.