Do laboratório às operações: a passagem que ninguém planeja

A maioria dos pilotos de laboratório não fracassa dentro do laboratório. Fracassa nos três meses seguintes, quando quem construiu dá um passo atrás e quem precisa tocar nunca foi realmente consultado. Uma boa passagem começa no primeiro dia do piloto, nomeia um único dono receptor nas operações e transfere quatro coisas: a decisão, a linha de orçamento, o conhecimento prático e as métricas. Se faltar qualquer uma delas, o piloto volta discretamente para o laboratório ou desaparece.

Por que é na passagem que bons pilotos morrem

O laboratório é feito para ser diferente das operações. Anda mais rápido, tolera a ambiguidade, empresta pessoas e contorna os processos padrão. É exatamente por isso que consegue testar ideias novas. E também é por isso que suas entregas raramente se encaixam na máquina que vai precisar operá-las.

Vijay Govindarajan e Chris Trimble descrevem essa tensão em The Other Side of Innovation (2010): o "motor de desempenho" que toca o negócio de hoje é desenhado para a repetição, e o trabalho de inovação precisa de uma parceria com ele, não de um muro entre os dois. Laboratórios que tratam as operações como plateia de uma demonstração final, e não como parceiras desde o início, preparam a passagem para dar errado.

Os sintomas são conhecidos:

• O piloto "funcionou", mas ninguém nas operações concordou sobre o que "funcionar" significava.
• A equipe do laboratório era a única que entendia como aquilo rodava.
• Havia dinheiro para o piloto e nenhuma linha no orçamento operacional do ano seguinte.
• O gestor receptor herdou um serviço novo em cima das metas que já tinha, sem que nada fosse retirado.

Passo a passo: planejando a passagem desde o primeiro dia

1. Nomeie o dono receptor antes de o piloto começar

Antes de gastar uma semana no piloto, encontre a pessoa nas operações que vai ser dona do resultado se ele der certo. Não um patrocinador que gosta da ideia; o gestor cuja equipe vai tocá-lo numa terça-feira qualquer. Pergunte diretamente: "Se isto funcionar, você assume?" Se a resposta for "talvez", trate isso como uma descoberta. Um piloto sem dono receptor é um projeto de pesquisa, e deve ser delimitado e reportado como tal.

2. Combine o teste de sucesso com o receptor, por escrito

Registre, junto com o dono receptor, qual resultado faria com que ele assumisse o serviço. Limite-se a duas ou três métricas com as quais ele já se importa: tempo de ciclo, taxa de erro, custo por caso, reclamações. Uma Árvore de KPIs (árvore de direcionadores) ajuda a ligar a métrica do piloto às metas pelas quais o receptor é avaliado. Se o teste de sucesso do laboratório e o do receptor forem diferentes, vale o do receptor.

3. Coloque alguém das operações dentro da equipe do piloto

Uma pessoa da equipe receptora deve trabalhar no piloto, pelo menos em tempo parcial, desde o início. Ela percebe as regras, os sistemas e os hábitos que o laboratório deixaria passar, e leva o conhecimento de volta para casa. Essa única decisão faz mais pela passagem do que qualquer documento.

4. Desenhe o serviço futuro, não apenas o piloto

Pilotos funcionam à base de gambiarras: alguém do laboratório respondendo e-mails à mão, uma planilha no lugar de um sistema, um gestor aprovando exceções pessoalmente. Antes da decisão de escalar, desenhe um Blueprint de serviço (service blueprint) de como o serviço vai rodar sem o laboratório: cada etapa de linha de frente, cada etapa de bastidores, cada sistema e política de que ele depende. As lacunas que aparecerem são o seu plano de trabalho para a passagem.

5. Faça um pré-mortem da própria passagem

Reúna a equipe do laboratório e a equipe receptora e pergunte: "Seis meses depois da passagem, o serviço foi desligado sem alarde. O que aconteceu?" Um Pré-mortem (premortem) traz à tona os riscos reais: um contrato com fornecedor que termina, uma política que nunca foi alterada, uma equipe que perdeu vagas. Atribua cada risco a alguém.

6. Escreva a RACI do período de transição

Para cada atividade do blueprint, defina quem é responsável, quem presta contas, quem é consultado e quem é informado: durante o piloto, durante a transição e depois. Uma Matriz RACI (matriz de responsabilidades) com três períodos torna visível a mudança de dono. A cada mês, o laboratório deve prestar contas de menos coisas.

7. Garanta a linha de orçamento antes de comemorar

Um piloto financiado pelo orçamento do laboratório não tem futuro, a menos que alguém o leve para um orçamento operacional. Trabalhe cedo com a área financeira: quanto vai custar operar em escala, sai de qual linha, a partir de quando? Se o ciclo orçamentário fechar antes de o piloto terminar, peça uma linha provisória com base no teste de sucesso.

8. Faça a passagem com um checklist e uma data

Use um Checklist de implantação (checklist de go-live) que cubra pessoas treinadas, procedimentos escritos, sistemas configurados, políticas alteradas, suporte organizado e métricas funcionando. Defina uma data de passagem e anuncie-a com um Plano de comunicação com stakeholders, para que equipes, clientes e líderes saibam quem passa a ser dono do serviço.

9. Fique de plantão, depois saia de cena

Combine um período fixo, muitas vezes um ou dois ciclos do serviço, em que o laboratório continua disponível para dúvidas. Depois disso, o laboratório deixa de participar. Se o serviço não consegue rodar sem o laboratório, a passagem não aconteceu.

O que de fato é transferido

Ajuda nomear as quatro coisas que precisam mudar de mãos, porque os laboratórios muitas vezes transferem só uma.

Confira cada linha antes da data de passagem. Um piloto que transferiu três das quatro ainda é um piloto do laboratório.

Exemplo ilustrativo

Ilustrativo. O laboratório da autoridade de transportes de uma cidade testou um novo processo para tratar reclamações de acessibilidade. No piloto, dois designers do laboratório faziam a triagem das reclamações à mão e retornavam a ligação para cada reclamante em até 48 horas. A satisfação subiu e o piloto foi declarado um sucesso.

Quando o laboratório apresentou os resultados, a diretora de atendimento ao cliente perguntou quem faria as ligações. Sua equipe não tinha orçamento para isso, e o sistema de reclamações não conseguia sinalizar os casos de acessibilidade. O piloto ficou parado por cinco meses.

O laboratório recomeçou com a diretora como dona receptora. Uma atendente sênior entrou na equipe por seis semanas. Juntas, as equipes desenharam um blueprint que substituiu a triagem manual por uma nova categoria no sistema existente, combinaram um retorno em 72 horas que a equipe conseguiria de fato sustentar e levaram o custo para o orçamento do serviço do ano seguinte. O laboratório ficou de plantão por um trimestre e depois saiu de cena. A meta de 72 horas impressionava menos do que o piloto. E sobreviveu.

O que fazer e o que evitar

Faça

• Nomeie o dono receptor antes de o piloto começar.
• Deixe o receptor definir o sucesso nas métricas dele.
• Coloque uma pessoa das operações dentro da equipe do piloto.
• Desenhe a versão em escala sem as gambiarras do laboratório.
• Defina uma data a partir da qual o laboratório deixa de participar.

Evite

• Apresentar um piloto pronto às operações como surpresa.
• Entregar uma apresentação de slides e chamar isso de transferência.
• Medir o sucesso apenas com métricas do laboratório, como "ideias testadas".
• Acrescentar um serviço novo ao trabalho de uma equipe sem retirar outra coisa; uma Lista do que parar de fazer (stop doing list) ajuda aqui.
• Manter o laboratório como dono permanente "só por enquanto".

Perguntas frequentes

Quando o laboratório deve passar um piloto para as operações? Quando o teste de sucesso do dono receptor for atingido e as quatro transferências (decisão, orçamento, conhecimento prático, métricas) puderem ser concluídas. O planejamento começa no início do piloto; a passagem em si acontece quando a versão em escala consegue rodar sem gente do laboratório.

Quem deve ser dono de uma inovação depois do piloto? O gestor cuja equipe vai tocá-la no dia a dia, não o patrocinador nem o laboratório. Se ninguém assim aceitar assumir, o piloto deve ser encerrado ou redesenhado, o que é um desfecho legítimo. Veja como encerrar bem um projeto.

Por que pilotos bem-sucedidos não conseguem escalar? Normalmente porque os pilotos funcionam à base de gambiarras e de atenção emprestada que não existem em escala, e porque ninguém levou o custo de operação para um orçamento operacional. A solução é desenhar a versão em escala durante o piloto, não depois.

Para onde ir agora

Para o quadro mais amplo, leia o que é um laboratório de inovação e por que a maioria fracassa e 5 motivos pelos quais laboratórios de inovação são fechados no segundo ano; um laboratório que não passa nada adiante raramente sobrevive ao segundo orçamento. Os guias de método que sustentam a maior parte da passagem são o Blueprint de serviço (service blueprint), a Matriz RACI (matriz de responsabilidades), o Pré-mortem (premortem) e o Checklist de implantação (checklist de go-live).