Como avaliar entrega de desenvolvedor sem saber ler código: a régua que me custou uma empresa

Quatro medições que você faz sem ler uma linha de código, a história da startup que perdi perguntando prazo e anotando no caderno, e onde essa régua falha.

Na obra ninguém pergunta se está pronto: alguém conta o que está instalado e assina embaixo

Você avalia a entrega de um desenvolvedor sem ler uma linha de código medindo quatro coisas que ficam fora do relatório de sprint: o que está no ar e você consegue abrir no seu celular agora, quanto tempo passou entre alguém dizer "terminei" e aquilo chegar ao ar, o que quebrou depois e por quanto tempo ficou quebrado, e o que o time avisou que ia dar errado antes de dar errado.

Nenhuma das quatro pede vocabulário técnico. Todas pedem que você abandone a pergunta "está pronto?", porque ela tem uma resposta só, e a resposta é sempre sim.

• O que está no ar: peça o endereço e abra você mesmo, do seu celular, sem ninguém do time ao lado. Se precisa de um desenvolvedor para ligar a tela, aquilo não foi entregue, aquilo foi demonstrado.
• O intervalo entre "terminei" e "está no ar": se o código fica dez dias esperando alguém subir, o seu problema não é velocidade de programação, é a esteira que ninguém montou.
• O que quebrou depois e quanto tempo ficou quebrado: um bug em produção não diz nada sozinho, mas quatro horas até alguém perceber dizem tudo sobre o que existe de monitoramento.
• O aviso que veio antes: quem escreveu, em qual canal, em que data, que aquilo ia atrasar ou ia dar problema. Risco que só aparece depois do estrago nunca foi registrado, foi inventado na retrospectiva.

A pergunta que me custou uma empresa

A primeira medição é abrir no próprio celular, sem ninguém do time ao lado

Antes da Revin eu tive uma startup de locação de equipamento para construção civil, no formato de aplicativo. Eu era o dono, o comercial e o cara que ia atrás de obra. Não escrevia código naquela época, tinha jurado nunca mais depois de um curso de Java aos 12 anos.

Contratei desenvolvedores e fiz a única coisa que sabia fazer: perguntava o prazo, anotava no caderno e ia tocar o resto do dia.

A sprint terminava e a entrega não estava lá. Toda vez.

Por uns três anos eu achei que o problema era o time. Troquei gente, apertei prazo, pedi relatório mais detalhado, fiz reunião de acompanhamento duas vezes por semana. O caderno ficava cheio de datas e o produto continuava no mesmo lugar. Voltei a programar para conseguir entender o que me diziam, e quando entendi veio a parte que doeu: ninguém tinha mentido comigo. Eu é que não sabia ouvir. "Dá uma semana" chegava no meu caderno como promessa, e do outro lado da mesa era uma estimativa com umas três dependências penduradas, nenhuma delas sob controle de quem me respondeu. A empresa morreu. Essa régua ficou, e é a mesma que uso hoje do outro lado do balcão, quando é a minha equipe que precisa dizer um prazo e responder a pergunta "quanto tempo leva" sem empurrar o risco para a frente.

Na obra eu media. No software eu perguntava

A ironia é que eu vinha de montagem eletromecânica industrial. Fui responsável técnico pelas estruturas metálicas de um autódromo e ajudei a montar fábrica de cimento. Em obra ninguém pergunta se está pronto. Existe boletim de medição: alguém anda com a planta na mão, conta quantas toneladas de estrutura estão de pé, quantos metros de tubulação já passaram por teste de pressão, e assina embaixo. Avanço ali não é opinião de ninguém, é o que você aponta com o dedo.

No software eu desliguei esse reflexo inteiro. Aceitei conversa no lugar de medição porque imaginei que medir software exigisse ler código. Não exige. Exige escolher as poucas coisas que só existem se o trabalho existiu de verdade.

E existe uma razão para o fornecedor preferir a conversa. O modelo de contratação mais comum no mercado brasileiro, preço fechado sem previsão de continuidade, premia quem entrega o que parece pronto e depois vira as costas. Vendedor de monitoramento que entrega um endpoint de health respondendo 200 com um painel colorido em cima de dado vazio está cumprindo o contrato à risca. Cobertura de teste em 92% com metade dos testes sem nenhuma asserção também cumpre. Por fora está completo, e sob o capô não tem nada. Chamo isso de casca podre, e ela só passa porque o contratante não sabe o que medir. Quando o fornecedor sai, a conta aparece inteira de uma vez, começando pelos acessos que ninguém revogou.

O que eu pergunto hoje, dos dois lados do balcão

O caderno enchia de datas e o produto ficava no mesmo lugar

São quatro perguntas, e elas cabem numa reunião de quarenta minutos. A resposta importa menos que a hesitação antes dela.

• "Me manda o link do que está no ar e eu abro aqui." Se vier print em vez de link, ou se vier pedido para marcar uma demonstração, você acabou de medir.
• "Da última vez que algo quebrou em produção, como vocês descobriram?" Resposta boa nomeia um alerta e um horário. Resposta ruim diz que o cliente avisou.
• "O que nesse plano depende de alguém que não está nesta mesa?" É a pergunta que eu não sabia fazer em 2017. Toda estimativa furada que vi depois tinha a resposta dela escondida.
• "Se eu trocasse de fornecedor em janeiro, o que o próximo time não conseguiria fazer sem vocês?" Aqui você descobre quanta coisa vive na cabeça de uma pessoa só.

Nenhuma delas é pegadinha. Com um time sério elas aceleram a conversa, porque o time quer registrar risco e normalmente não tem onde. Antes de assinar contrato novo, vale somar a isso as cinco perguntas que eu faria antes de contratar um desenvolvedor de app, que cobrem o pré, enquanto estas quatro cobrem o depois.

"Mas eu contratei justamente para não precisar entender disso"

Essa é a objeção que ouço em call comercial, e ela é legítima. Você não contratou engenharia para virar engenheiro. Contratou para não precisar.

Só que existe uma diferença entre entender como se escreve o código e saber se o trabalho aconteceu. Você não precisa saber soldar para conferir o boletim de medição da obra, e nunca conheci dono de obra que assinasse medição sem olhar. Em software, a maioria assina.

E o custo de não medir não é o custo do erro, é o custo do tempo que você leva para descobrir o erro. Na minha startup foram uns três anos. Com a ordem de grandeza de salário de um time sênior no Brasil hoje, que dá para conferir no nosso levantamento de salário de desenvolvedor, três anos de medição errada custam mais que o produto inteiro valia. Esse é o motivo de eu tratar dívida técnica como linha de risco de negócio e não como assunto de engenharia: ela aparece no prazo e na receita antes de aparecer no código.

IA não resolve esse pedaço, inclusive piora o disfarce. Com um agente escrevendo, a tela fica de pé muito rápido, e a sensação de avanço chega semanas antes do avanço. Já escrevi aqui o que costuma quebrar lá pelo sexto mês quando se constrói com IA sem saber avaliar arquitetura, e o padrão é esse: a medição continua sendo a única defesa de quem não lê código.

Onde essa régua falha

Ela não serve para as primeiras duas ou três semanas de um produto que ainda está sendo descoberto. Nessa fase não existe "o que está no ar", existe gente testando hipótese, e cobrar medição ali atrapalha. Também não serve para time de duas pessoas tocando a primeira versão: a esteira que eu cobro no segundo item custa uns dias de trabalho, e em projeto de seis semanas esses dias podem ser o projeto todo.

E tem o risco do outro lado. Medição virando reunião diária de prestação de contas é microgestão com nome bonito, e eu já fiz isso também, na época em que achava que relatório mais detalhado resolveria. Você quer quatro medições que o time consulta sozinho, não quatro perguntas que você repete toda manhã.

Não sei dizer onde exatamente fica a linha para cada empresa. Sei que ela existe, porque atravessei ela pelos dois lados.

O que fazer nesta semana

Abra a sua última ata de sprint e procure uma frase em que alguém registrou um risco com data, antes de o risco acontecer. Se não achar nenhuma em três meses de histórico, o problema não está na velocidade do seu time. Está no fato de que ninguém no seu contrato tem incentivo para escrever o que vai dar errado.

E aí a pergunta que você leva para a sua empresa é essa: quando o próximo prazo furar, você vai descobrir pelo painel, pelo cliente, ou por um caderno cheio de datas que ninguém mediu?