Use isto quando precisar mostrar um lançamento como uma sequência: os marcos no topo, um card por fase com seu objetivo, tarefas, riscos e a barra de saída que permite avançar.
Este é um exemplar copiável. Leve o bloco <section class="demo"> abaixo para uma lição construída a partir de assets/lesson-template.html — os tokens de design já combinam.
Uma grande mudança raramente acontece toda de uma vez. Você a divide em fases que seguem em ordem, e só passa para a próxima fase quando a atual cumpre sua barra de saída — a prova de que é seguro continuar. A faixa no topo é o mapa; cada card abaixo dá um zoom em uma fase.
Pense nisso como… mudar de casa cômodo por cômodo. Você não despeja a casa inteira no gramado. Você embala um cômodo, confere que nada quebrou, então começa o próximo — e mantém a chaleira na tomada até o fim, para sempre poder fazer um chá.
Projeto Lançamento de login único (SSO)Janela Q3 → Q4Responsável Equipe de Identidade e Acesso
Progresso1 de 4 fases concluídas
Clique em um marco — ou foque a barra e use ←→ — para abrir o card da fase.
Fase 1 · Concluída
Descoberta
Semanas 1–3
Objetivo: Saber exatamente o que faz login hoje, para que nada fique bloqueado amanhã. Inventarie todo app, conta e caminho de login antes de mexer em produção.
Tarefas
Inventariar todos os apps e seus métodos de login (SAML, OIDC, senha, chave de API)
Mapear contas de serviço e logins compartilhados sem dono humano
Escolher o provedor de identidade e confirmar suporte a provisionamento SCIM
Esboçar o mapeamento grupo → papel para acesso de menor privilégio
Critérios de saída
Inventário de apps aprovado, com um dono por app
Cada caminho de login classificado como pronto para SSO ou precisa de ajustes
IdP escolhido e aquisição aprovada
Riscos e mitigações
MédioApps ocultos que ninguém listouCruze o inventário com os logs de acesso do SSO/proxy. Mitigação: janela de anistia de 2 semanas para autorregistrar apps.
BaixoContas de serviço órfãsAlguns daemons fazem login com credenciais compartilhadas. Mitigação: marque cada uma como identidade de máquina; exclua do SSO humano.
Fase 2 · Em andamento
Piloto
Semanas 4–7
Objetivo: Provar que o SSO funciona para pessoas reais em apps reais — com o antigo login por senha ainda disponível como rede de segurança. Comece com uma equipe voluntária.
Tarefas
Conectar o IdP aos 3 apps mais usados (e-mail, chat, hospedagem de código)
Inscrever a equipe piloto (~25 pessoas) e ativar o MFA
Manter o login por senha como fallback — ainda não o desative
Escrever o runbook do help desk para bloqueios e recuperação
Critérios de saída
Equipe piloto faz login via SSO por 2 semanas sem problemas bloqueantes
Taxa de sucesso de login ≥ 99%; tempo mediano de login abaixo de 5s
Fluxo de recuperação testado de ponta a ponta pelo menos uma vez
Riscos e mitigações
AltoQueda do IdP bloqueia todo mundoSe o provedor cair, ninguém faz login. Mitigação: mantenha o fallback por senha ativo; documente uma conta admin de emergência (break-glass) guardada offline.
MédioFadiga de MFA e configuração abandonadaAs pessoas pulam a inscrição ou aprovam prompts no automático. Mitigação: prompts com correspondência numérica; clínica de inscrição ao vivo; prazo claro.
BaixoErros no mapeamento de gruposUm grupo errado concede acesso demais. Mitigação: comece somente leitura; revise o relatório de acesso antes da fase 3.
Fase 3 · Planejada
Lançamento
Semanas 8–13
Objetivo: Levar a empresa inteira para o SSO, equipe por equipe, enquanto o fallback por senha ainda existe. Abrangência sem quebrar nada.
Tarefas
Integrar apps e equipes em ondas (~2 departamentos por semana)
Ativar o auto-provisionamento e desprovisionamento via SCIM
Migrar os apps restantes que "precisam de ajustes" ou conceder exceções
Montar um painel de autoatendimento com o status por equipe
Critérios de saída
≥ 95% do pessoal ativo no SSO; o restante com uma exceção datada
Desprovisionamento automático verificado: um usuário removido perde o acesso em até 1h
Volume de chamados do help desk de volta ao patamar normal
Riscos e mitigações
AltoApp legado não fala SSOUma ferramenta antiga só aceita senhas. Mitigação: coloque um proxy de acesso à frente dela, ou conceda uma exceção rastreada com data de término.
MédioHelp desk sobrecarregado pelas ondasEquipes demais de uma vez inundam o suporte. Mitigação: limite o tamanho das ondas; pause o cronograma se os chamados ultrapassarem o limite.
Fase 4 · Planejada
Imposição
Semanas 14–16
Objetivo: Remover a rede de segurança. Desligar o login por senha para que o SSO seja a única forma de entrar — o passo que de fato entrega o ganho de segurança.
Tarefas
Desativar o fallback por senha, um app por vez, deixando o mais movimentado por último
Impor MFA e políticas de acesso condicional em toda a organização
Aposentar contas locais obsoletas e rotacionar quaisquer segredos remanescentes
Manter a conta break-glass; alertar a cada uso dela
Critérios de saída
Login por senha desativado em todos os lugares, exceto exceções documentadas
100% dos logins humanos passam por SSO + MFA
Relatório de auditoria aprovado; plano de rollback aposentado
Riscos e mitigações
AltoA virada bloqueia um papel críticoDesativar senhas deixa uma conta não mapeada na mão. Mitigação: faça as viradas fora do horário de pico; janela de rollback de 30 min; admin de plantão com acesso break-glass.
MédioIdentidades de máquina esquecidasUm cron job ainda usa senha. Mitigação: varra os logs de autenticação em busca de logins fora do SSO por 1 semana antes de desativar cada app.
O que é, de fato, um critério de saída
Um critério de saída é um portão mensurável, não uma sensação. "O piloto foi bem" não é um portão; "sucesso de login ≥ 99% ao longo de 2 semanas com o fluxo de recuperação testado" é. Uma fase não pode avançar até que toda caixa esteja marcada, o que mantém o plano honesto sob pressão de cronograma.
Por que o fallback sobrevive até a fase 4
O caminho por senha permanece vivo ao longo de Descoberta, Piloto e Lançamento justamente para que uma queda do provedor ou um grupo mal mapeado nunca vire um bloqueio total. A fase 4 ("Imposição") é a única que remove as redes de segurança — por isso carrega o risco de severidade mais alta e a janela de rollback mais apertada.
Lendo as severidades de risco
Alto — pode causar bloqueio em toda a empresa ou exposição de dados; sempre acompanhado de uma mitigação de rollback ou break-glass.
Médio — degrada a experiência ou inunda o suporte; mitigado por ritmo e ferramentas.
Baixo — raio de impacto contido; mitigado por etapas de revisão.
A barra de marcos como máquina de estados
Cada segmento carrega um status — done, active ou todo — e selecionar um deles troca o role="tabpanel" visível. Em uma lição real, você guiaria esses estados a partir do rastreador do projeto, para que a barra reflita a realidade ao vivo em vez do plano no papel.
Leia da esquerda → direita: cada fase só pode avançar depois de cumprir seu portão de saída. O fallback por senha (tracejado) sobrevive às fases 1–3 e é finalmente cortado na Imposição.