Piloto e ciclo de feedback

Go-live · 5.2

Porque é importante agora

Os UAT no ambiente de aceitação mostram se as funcionalidades funcionam; um piloto mostra se o sistema funciona para a sua organização. A diferença é que o piloto confronta as pessoas com “sim, a partir de segunda esta é a tua nova ferramenta” — só aí se vê a fricção real. Salte esta etapa e o seu rollout alargado torna-se o seu piloto.

O que entrega?

Charter do piloto

Scope, participantes, período, critérios de sucesso — acordados à partida.

Canal e ritmo de feedback

Stand-up diário, retro semanal, formulário anónimo, ou uma mistura.

Registo de issues com priorização

Show-stoppers, bloqueios, nice-to-haves — com dono e prazo.

Relatório go/no-go

Com números de adoção, qualidade do trabalho concluído e citações qualitativas.

Perguntas-chave

1Que grupo faz o piloto — um departamento, um edifício, um corte transversal? Que combinação dá o workflow mais representativo?
2Durante quanto tempo — duas, quatro, seis semanas? Tempo suficiente para tocar em todos os ritmos recorrentes (atividades semanais, mensais, trimestrais), curto o bastante para manter o momentum.
3Piloto total ou parcial — o grupo piloto trabalha apenas em Gfacility (ferramenta antiga desligada) ou em paralelo? Em paralelo é mais seguro mas esconde a fricção.
4Critérios de sucesso — mensuráveis, acordados à partida: taxa de adoção > 80%, CSAT médio > 4, sem issues P1 abertos depois da semana 2, etc.
5Mecânica de feedback — como capta problemas sem que tudo passe pelo "chat-sombra" entre colegas? Um stand-up diário de 15 min costuma funcionar melhor.
6Quem responde ao feedback e com que SLA? Os pilotos morrem quando o feedback desaparece num buraco negro.
7Champions — quem do grupo piloto se torna o seu embaixador informal a ajudar colegas e a canalizar feedback?
8Comunicação — ao grupo piloto (expectativas, ajuda) e ao resto da organização (porque não eles ainda, o que vem a seguir)?
9E se for no-go — que decisão se segue ao falhanço? Extensão, fix-and-restart, redução de scope, ou pausa? Decida isto antes do piloto, não depois.
10Hand-off — o que continua o grupo piloto a fazer depois do go-live? Conhecem melhor o Gfacility — não os deixe sair.

Modelo — Charter de piloto

Aspeto	Preenchimento
Grupo piloto	Equipa de facility Bruxelas (12) + helpdesk IT N1 (8) = 20 pessoas
Período	4 semanas, de seg 15/06 a sex 10/07
Módulos em scope	Tickets, reservas, visitantes
Fora de scope	Catering, app mobile, reporting Power BI
Total vs paralelo	Total — a ferramenta antiga fica só de leitura para o grupo piloto
Critérios de sucesso	Adoção > 85%, CSAT > 4.0, ≤ 3 issues P1 abertos depois da semana 3, throughput pelo menos igual ao da ferramenta antiga
Ritmo de feedback	Stand-up diário às 9:00 (15 min) nas primeiras 2 semanas; depois 2×/semana
Dono dos issues	PM (recolha) → tech lead (triagem) → responsável (SLA por prioridade)
Decisão no-go	Comité de direção decide 7d antes do go-live planeado com base no relatório final

Modelo — Registo de issues

ID	Descrição	Tipo	Prio	Estado	Bloqueia go-live?	Dono
P-001	Add-in do Outlook não carrega em versões antigas	Bug	P1	Aberto	Sim	Integration lead
P-002	Categorização "outros" em falta	Config	P2	Corrigido	Não	Configurador
P-003	Desejo: edição em massa de reservas	Funcionalidade	P4	Em espera	Não	Product owner
…	…	…	…	…	…	…

← Migração de dados e limpeza Seguinte: Formação e gestão da mudança →