Pular para o conteúdo

Framework SkilLab

SHIFT Lens: cinco lentes para ler qualquer iniciativa de mudança (Celemi Cayenne)

Stakeholders · Hypothesis · Initiative · Friction · Time

SHIFT Lens (Stakeholders · Hypothesis · Initiative · Friction · Time) é um framework SkilLab para estruturar uma iniciativa de mudança organizacional em cinco dimensões testáveis antes do roll-out. Cada dimensão exige resposta explícita do sponsor, e cada lente faltante é fonte previsível de falha posterior.

Diagrama do framework SHIFT Lens: cinco lentes para ler qualquer iniciativa de mudança (Celemi Cayenne)

As cinco lentes

Stakeholders. Quem ganha, quem perde, quem decide. Mapa explícito de poder e interesse. Sem stakeholder mapping, a mudança colide com vetos invisíveis.

Hypothesis. Qual hipótese a mudança testa. “Se fizermos X, observaremos Y”. Sem hipótese explícita, a mudança vira articulação política sem critério de avaliação.

Initiative. Qual iniciativa concreta prova ou refuta a hipótese. Piloto mínimo viável, não roll-out total. Sem piloto, falha cara e desnecessária.

Friction. Onde a inércia organizacional aparecerá. Pontos de trava previsíveis: política, processos, sistemas, cultura. Mapear antes evita surpresa de campo.

Time. Em que janela a hipótese é avaliada. 90 dias, 6 meses, 12 meses. Sem prazo de teste explícito, a iniciativa entra em loop infinito.

Como aplicar

Aplique SHIFT Lens como briefing de uma página antes de aprovar qualquer iniciativa de mudança organizacional. O sponsor responde às cinco perguntas em texto. Sponsors que travam em Hypothesis ou Time costumam ser os que mais reclamam de “falta de execução” depois.

Celemi Cayenne é o complemento experiencial. Times conduzem mudança simulada e usam SHIFT Lens no debrief para nomear o que faltou.

Posts relacionados

Quando usar

  • Antes de aprovar roll-out de iniciativa de transformação organizacional.
  • Para preparar um sponsor que precisa defender mudança internamente.
  • Em retrospectiva pós-mudança para identificar o que faltou no design.

Quando NÃO usar

  • Mudanças operacionais menores onde over-engineering custa mais que o erro.
  • Iniciativas técnicas isoladas sem implicação organizacional.