Um processo de decisão
The Kanso Filter.
Seis perguntas antes de uma mudança ser entregue.
Aplicamos isto antes de recomendar qualquer mudança a uma equipa de serviço. A maioria das mudanças que falham não falha na fase de construção. São entregues sem uma resposta clara a uma destas seis perguntas. O filtro força essas respostas antes de o trabalho começar, quando ainda é barato agir sobre elas. Use-o nas suas próprias decisões, nas propostas de fornecedores e nas nossas.
Por que existe
Começou como um registo de trabalho que não levou a lado nenhum.
Continuávamos a ver mudanças ser entregues que acrescentavam um fluxo de trabalho, uma integração, um ecrã, e seis meses depois, os números pelos quais a equipa era avaliada não tinham mudado. O esforço era real. O resultado não. Por isso escrevemos as perguntas que, em retrospetiva, teriam impedido cada uma dessas mudanças antes de alguém as construir. Essa lista é o filtro. É deliberadamente direto: se uma mudança não consegue responder a estas perguntas, a decisão honesta é não a fazer.
Cada uma identifica um modo de falha antes da entrega.
01
Elimina um passo?
Passos são cliques, campos de formulário, pesquisas, transferências, decisões que a equipa tem de tomar.
02
Move uma métrica que é sua?
Tempo de tratamento, esforço do cliente, CSAT, resolução no primeiro contacto, valor de vida. Escolha a que a equipa é avaliada, não a mais fácil de contar.
03
Melhora a precisão ou a qualidade?
Mensurável. Nomeie a métrica antes da implementação.
04
Minimiza a carga de manutenção?
Pese a manutenção contínua, os pontos únicos de falha e a dívida técnica que a equipa carrega depois, não apenas o tempo que poupa.
05
A funcionalidade nativa supera o desenvolvimento personalizado?
Os roadmaps das plataformas avançam mais depressa do que o código personalizado.
06
Consegue nomear a métrica que deve mover e como a vai medir?
Nomeie a medida e a janela antes de começar, para poder dizer depois se funcionou.
O que fazer a seguir
Decida com base em melhoria material, não em custo poupado.
Uma mudança ganha o seu lugar quando move uma métrica sua o suficiente para se notar. O custo poupado é um dado, não o teste. Se não conseguir nomear a métrica, o alvo e a janela antes de começar, não consegue dizer depois se a mudança funcionou, e é assim que uma mudança falha silenciosamente: ninguém definiu a medida que o teria demonstrado. Por isso falhe-a depressa. Elimine a ideia fraca na fase das perguntas, onde custa uma tarde, não depois da construção, onde custa um trimestre. O objetivo do filtro é gastar essa tarde.
Experimente agora
Pontue a sua mudança.
Responda a cada pergunta para a mudança que está a ponderar. O veredicto atualiza-se à medida que avança. Nada do que escrever sai do seu browser.
01
Elimina um passo?
02
Move uma métrica que é sua?
03
Melhora a precisão ou a qualidade?
04
Minimiza a carga de manutenção?
05
A funcionalidade nativa supera o desenvolvimento personalizado?
06
Consegue nomear a métrica que deve mover e como a vai medir?
Veredicto corrente
0 de 6 respondidas afirmativamente
Corre inteiramente no seu browser. Não vemos as suas respostas nem as armazenamos.
Como usar
Percorra as seis perguntas por ordem. Depois decida.
- Todas as seis afirmativasEntregue.
- Quatro ou cincoEntregue com notas explícitas sobre as lacunas.
- Menos de quatroNão entregue. O âmbito não está certo, ou a mudança não retornará o suficiente para justificar a manutenção.
Porque é que as mudanças falham
Uma mudança raramente falha por ter sido mal construída.
Falha porque ninguém nomeou a métrica que devia mover, pelo que ninguém pôde avaliar depois se o tinha feito. Ou porque a manutenção cresceu silenciosamente até superar o valor. Ou porque a plataforma entregou o mesmo nativamente três meses depois e o desenvolvimento personalizado tornou-se um passivo.
A solução não é mais disciplina na fase de construção. É decidir bem antes da construção. Escolha a métrica que é sua, acorde o alvo e a janela, e verifique se a funcionalidade nativa o leva à maior parte do caminho primeiro. Se uma mudança não consegue demonstrar uma melhoria material, a decisão certa é geralmente não a fazer.
Exemplo prático
Implementar IA de etiquetagem automática no Zendesk.
O filtro aplicado, linha a linha, a uma decisão real.
| # | Pergunta | Veredicto | Notas |
|---|---|---|---|
| 01 | Elimina um passo? | Sim | Elimina a etiquetagem manual em 80% dos tickets. |
| 02 | Move uma métrica que é sua? | Sim | Um routing mais rápido reduz o tempo até à primeira resposta; ~45 seg × 30.000 tickets/mês = 375 horas devolvidas à fila. |
| 03 | Melhora a precisão? | Talvez | Requer comparação com a linha de base antes do go-live. |
| 04 | Minimiza a carga de manutenção? | Talvez | Retreino trimestral do modelo (pequeno), sem novo ponto único de falha, mas tem de ganhar o seu lugar. |
| 05 | A funcionalidade nativa supera o desenvolvimento personalizado? | Talvez | Verifique primeiro a etiquetagem automática nativa do Zendesk. |
| 06 | Consegue nomear a métrica que deve mover e como a vai medir? | Sim | Precisão de etiquetagem e routing nomeada à partida, acompanhada semanalmente face a uma linha de base. |
| Resultado do filtro | Entregue se a funcionalidade nativa não cobrir a taxonomia. Caso contrário, use a nativa. | ||
Tem uma mudança em ponderação?
Financiamos um número limitado de avaliações Maturity Mapping para equipas com um problema de serviço ativo. Candidate-se com a métrica que quer mover, e se não for adequado, diremo-lo.