O seu time já rodou o piloto

Olhe como as pessoas se cadastram numa ferramenta nova de trabalho e um padrão aparece rápido. Muitas chegam com uma conta pessoal em vez de corporativa, e não passam pelo setor de compras antes. Usam um endereço do Gmail, de casa, tarde num dia de semana.

A leitura fácil é curiosidade, e às vezes é só isso. A leitura mais útil é cautela.

A aritmética de pedir

Fazer a sua empresa adotar algo custa mais a você do que custa à empresa. Você precisa convencer a chefia, ou o TI, ou quem cuida do questionário de segurança. Alguém precisa gastar uma semana em análise. E depois você é a pessoa que trouxe aquilo. Ser essa pessoa é ótimo quando a ferramenta vira algo sem o qual o time não trabalha, e prejudica a sua reputação quando ela fica em silêncio sem uso, cada vez mais a cada repetição.

A maioria das pessoas consegue fazer isso duas ou três vezes por ano antes de virar o colega que corre atrás de toda novidade. Então elas guardam esse crédito, e não gastam a menos que estejam bem confiantes de que a ferramenta vai entregar.

É por isso que o teste acontece antes, em silêncio, numa conta pessoal, em tempo pessoal, com dados que não exigem aprovação de ninguém. Não porque a pessoa queira uma ferramenta pessoal. Porque ela quer saber se a coisa funciona antes de pôr o nome dela ali.

Isso é um piloto

Não tem orçamento, comitê nem critérios de saída escritos. Também tem algo que a maioria dos pilotos formais nunca tem: alguém com uma razão genuína para descobrir a verdade.

Pense em quem costuma conduzir uma avaliação dentro de uma empresa. Muitas vezes é a pessoa que sugeriu a ferramenta, o que significa que agora ela está motivada, em silêncio e com honestidade, a ter estado certa. Quem testa na própria conta não tem esse interesse. Ninguém sabe que a pessoa está experimentando, então não há decisão a defender. Ela abandona em uma semana se não ajudar e nunca menciona.

Então a pergunta diante da maioria de quem lidera não é se a empresa deveria experimentar IA. A empresa experimentou, meses atrás, numa dúzia de lugares ao mesmo tempo. A pergunta é se alguém perguntou como foi.

Para que o teste solo serve

Ele é um filtro, e um bom filtro. A maioria dos softwares não sobrevive a duas semanas de uso pessoal honesto. Se uma ferramenta é lenta, ou erra o bastante para exigir conferência, ou simplesmente não se encaixa em como você trabalha, você descobre no seu tempo sem custo para ninguém. É um serviço de verdade, e é a avaliação mais barata disponível.

O que ele não te diz é se a coisa mudaria como o seu time trabalha. Numa conta pessoal você vê se uma ferramenta escreve uma resposta decente, resume uma corrente, ou te poupa vinte minutos. Você não vê o trabalho chegando à pessoa que é dona daquela área, uma tarefa caindo com o dono certo e ficando visível até estar concluída, ou algo que uma pessoa descobriu estando lá quando um colega precisa seis semanas depois.

São perguntas diferentes, e o erro é esperar que um teste responda as duas. “Isto presta?” e “isto mudaria algo aqui?” precisam de condições diferentes, e só a primeira pode ser respondida sozinho.

O passo que quase ninguém dá

Respondida a primeira pergunta, algumas pessoas pulam direto para o movimento caro: fazer o caso, envolver o TI, virar a pessoa que defende. Mas como esse passo é caro, muitas nunca o dão, e a ferramenta morre em silêncio numa conta pessoal, tendo passado no único teste dela.

Há, porém, um passo barato no meio, e ele quase não custa nada. Rode com duas ou três pessoas do time no trabalho que vocês de fato compartilham.

É barato, talvez até de graça. Pode precisar da aprovação de alguém, ou do TI liberando acesso, mas não de um ciclo de compras, uma análise de segurança completa, ou da sua reputação apostada diante de alguém além de duas pessoas com quem você já fala todo dia. E é a primeira vez que as partes de time da ferramenta ficam visíveis, porque você precisa de mais de uma pessoa num sistema antes de encaminhamento, propriedade e conhecimento compartilhado significarem qualquer coisa.

Três pessoas por duas semanas te dizem mais que uma pessoa por um trimestre. Se funcionar, você agora tem um argumento apoiado em evidência e duas pessoas que vão te apoiar, o que leva a uma conversa completamente diferente de chegar sozinho com um entusiasmo. Se não funcionar, o experimento foi barato e você tem certeza.

Três perguntas que valem ser feitas

Se o piloto já rodou, a coisa mais barata disponível a quem lidera é a conversa depois. Custa uma conversa.

O que você já está usando, e para quê? Pergunte como pergunta, e não como auditoria. As respostas param no instante em que aquilo parece fiscalização, e a meta é aprender o que o seu time descobriu, e não pegar alguém.

O que você experimentou e abandonou? Mais informativo que o que ficou. As pessoas abandonam coisas por razões específicas, e essas razões são uma avaliação gratuita de metade do mercado.

O que você não experimentou, porque teria significado pedir permissão? É esta que importa, e quase ninguém faz. A resposta é uma lista de ferramentas que poderiam ter mudado como o trabalho acontece, filtradas pelo custo de pedir e não por nada sobre as ferramentas.

O papel do this+that na avaliação

Construímos um produto voltado a times, então temos interesse no argumento e você deve pesar isso.

Usado sozinho, o this+that faz trabalho de verdade: ele lê as mensagens que chegam nos canais que você já usa, tira as tarefas e os compromissos enterrados nelas, e mantém tudo em algum lugar que você vê. Essa parte se sustenta bem numa conta pessoal.

Mas a razão para adotá-lo é a parte que uma conta só não consegue demonstrar. O trabalho chegando à pessoa que é dona dele. Uma lista de tarefas compartilhada que sobrevive a alguém estar de férias. Conhecimento que uma pessoa registrou estando lá para todo mundo. Se você nos testou sozinho e concluiu que éramos uma caixa levemente melhor, é uma leitura justa da evidência que você tinha. E também é a evidência errada para uma decisão de time.

Então o nosso pedido é o pequeno, e não o grande. Experimente você primeiro. Se se sustentar, defenda um piloto curto com duas ou três pessoas do time, compartilhando trabalho de verdade por duas semanas. Isso ainda pode significar pedir a alguém, e pode significar o TI liberando acesso, mas é bem menos do que pedir adoção em toda a empresa.

Esse é o ponto geral, e não um apelo especial. As ferramentas mais propensas a serem subestimadas num teste de conta pessoal são aquelas cujo valor aparece entre pessoas, e a solução não é um teste solo melhor. É um segundo teste, um pouco menos solo.

Principais conclusões

• As pessoas avaliam ferramentas novas de trabalho em contas pessoais porque pedir que a empresa adote algo gasta credibilidade pessoal, e a maioria só consegue gastar isso duas ou três vezes por ano.
• Esse teste informal é um piloto de verdade e, num aspecto, melhor que a maioria das avaliações formais. Quem o conduz quer que a ferramenta funcione, mas não tem reputação apostada no veredito.
• A maioria das empresas, portanto, já rodou um piloto de IA, meses atrás, com uma dúzia de pessoas ao mesmo tempo. Muitas nem sabem disso, e pouquíssimas perguntaram o que ele produziu.
• Um teste solo responde “isto presta?” de forma barata e boa. Ele não responde “isto mudaria como trabalhamos?”, porque encaminhamento, propriedade compartilhada e conhecimento compartilhado precisam de mais de uma pessoa para significar algo.
• O passo entre os dois quase não custa nada e quase ninguém dá: rodar a ferramenta com duas ou três pessoas do time no trabalho que vocês compartilham. Pode precisar de uma aprovação ou de o TI liberar acesso, mas é um pedido bem menor que adoção em toda a empresa.
• Três pessoas por duas semanas ganham de uma pessoa por um trimestre, e isso transforma um entusiasmo em evidência mais duas pessoas que vão te apoiar.
• Para quem lidera, a conversa depois custa uma conversa. Pergunte o que as pessoas já usam, que é como você descobre que o piloto aconteceu, e então pergunte o que elas não experimentaram porque teria significado pedir permissão.