Ep. 233 - Dados e Produtividade: Alinhando percepções e realidade

Estevam está finalizando um compilado de avaliação de produtividade do SQUAD referente ao ano de 2024, um trabalho mensal que agora, em janeiro, ele expande para um compilado mensal com foco em previsibilidade. Os desenvolvedores fazem quantas histórias em relação a quais temas por mês? Quantos story points eles usam? Tudo isso a gente já tem desde abril, quando passaram a usar o Jira. O próximo passo é avaliar o valor que cada desenvolvimento efetivamente trouxe, gerando um ROI real, não apenas qualitativo. Estevam conta que já trabalhou em empresas grandes onde ninguém olhava para o que o desenvolvedor fazia, e que, com base nisso e com o CEO da startup onde atua, montou um padrão de avaliação.

Ele mostra um mês aleatório, outubro do ano anterior, começando o review com o contexto: o que aconteceu, se alguém saiu de férias, se teve algum top down, alguma emergência. Isso vira documentação. Depois, uma visão geral com todas as colunas, do momento em que a solicitação de desenvolvimento aparece em a fazer até quando é concluída, o DOD, já testada, aprovada e em produção. Os dados por desenvolvedor mostram, por sprint, quantas histórias estão em a fazer, refinamento funcional, técnico, pronto para desenvolvimento, até concluído, permitindo ver o desempenho de cada um. Faz-se um comparativo com o mês anterior: em a fazer, por exemplo, tinha 54 e caiu para 33, o que indica que as histórias estão efetivamente saindo. O que é mais expressivo de um mês para o outro recebe pontuação. Se em testes aumentou, talvez o QA precise de ajuda ou haja alguma história mais complexa. Há ainda o histórico de histórias concluídas de todos os meses, desde agosto de 2023, mostrando quantas histórias o squad entregou mês a mês. O grande objetivo é olhar o impacto no time como um todo.

A questão da complexidade é central. Não é só sobre um número. Uma história para mudar a cor de um botão é muito diferente de uma história para lançar um PDV. Começaram olhando apenas para o throughput e viram que não fazia sentido, então passaram para story points, considerando a quantidade de histórias e o nível de complexidade. Fizeram um affinity sizing, com histórias de 1 a 21 pontos, e, junto com o tech lead, definiram exemplos para cada pontuação. Esse material de referência foi compartilhado com o time, que passou a usá-lo como base para atribuir pontuações. A visão individual mostra quantos story points cada desenvolvedor entregou, e a partir daí se percebe se alguém teve desempenho acima ou abaixo da média. Além da visão individual, há a visão por especialidade, a média de todos os desenvolvedores back-end, a média de todos os front-end, e a visão de squad. São três camadas, e os dados são totalmente abertos para o time. A ideia não é punir, mas identificar problemas, conversar, entender se há algum obstáculo pessoal ou técnico, e desobstruir o caminho.

Flor abre o episódio falando sobre a onipresença da palavra produtividade em redes sociais e no universo corporativo, especialmente para quem trabalha com conhecimento, onde é mais complexo entender se se está de fato sendo produtivo ou apenas preenchendo o tempo com tarefas. O foco são pessoas que executam tarefas complexas, criativas, intelectuais. A pergunta que fica: quem nunca acabou o dia respondendo trinta e-mails, fazendo sete reuniões, sem parar para ir ao banheiro, e se pergunta: o que eu entreguei? Qual o valor que gerei? Eu fui de fato produtiva ou estou numa grande luta?

Estevam, coordenador de produtos na startup Widtech, foi chamado para criar uma área de produtos do zero e sofre com insônia desde então. O tema da produtividade é recorrente: como escalar tudo que a equipe faz de forma quantitativa e mensurável, internamente e para os clientes.

Quando se fala em produtividade, o conceito foi herdado da era industrial, ligado à quantidade de unidades produzidas por hora, o famoso homem-hora. No trabalho do conhecimento, a coisa não é assim. Estevam cita duas frases que gosta: a primeira é que ser produtivo não é estar ocupado. Participar de uma série de reuniões no dia não necessariamente quer dizer que se foi produtivo; normalmente é pelo contrário. Existe uma desassociação entre fazer muita coisa e realmente gerar o resultado da empresa, atingir os OKRs alinhados, mexer na alavanca de negócio. A visão fabril ainda está em transição para serviços e tecnologia, e muitas empresas, especialmente as grandes, mantêm o conceito de homem-hora, questionando quanto custa a pessoa e quanto se ganha a partir do trabalho dela. Em casos extremos, questiona-se se a pessoa em home office é tão produtiva quanto presente.

Estevam acredita numa abordagem que considera três fatores: qualidade, impacto e resultado alcançado. Não é mais homem-hora. É: o que eu fiz, vou ter retrabalho? Se não vou ter retrabalho, foi algo produtivo. Qual o impacto? Como isso atingiu meus clientes? Quais foram os resultados alcançados? Qual foi o ROI efetivo? É um trabalho de formiguinha, aos poucos se chega lá. A grande diferença é que não é sobre volume, é sobre impacto e valor gerado. No trabalho criativo, não dá para medir com a mesma régua. Depende do cérebro, não se tem previsibilidade alta de quanto tempo algo vai levar. Tarefas mecânicas, em contrapartida, têm um tempo previsível.

Para quem tem dificuldade de entender se está sendo produtivo ou apenas ocupado, a chave está nos OKRs. As pequenas ações do dia a dia precisam estar alinhadas com os OKRs. Se se está fazendo algo que não está alinhado, é improdutivo, é gastar cartucho. Estevam usa a analogia de uma barrinha de estamina de videogame: ela tem um limite, e quando zera, é preciso recarregar. Não adianta querer fazer tudo. Estar em um milhão de reuniões onera o coordenador de produto, que precisa sentar com UX para repassar a lógica do user flow, criar relatório de produtividade com o team lead, fazer análise de concorrência. É preciso entender o que é valor, como a empresa enxerga valor, e agir com parcimônia. Não dá para travar todas as batalhas o tempo todo. Se não se sabe para onde se está indo, qualquer lugar serve, e isso é ocupação, não produtividade.

Estevam já trabalhou em grandes organizações como P.I.O. e PM, e se assustava com o quão solto era o monitoramento de produtividade. Na concepção dele, é preciso ter visão de curto e longo prazo. O curto prazo é entender se o squad está trabalhando como deveria, se as pessoas estão fazendo o que precisam. O longo prazo é entender, com base nos OKRs, onde se quer chegar, calcular o ROI e entender para onde os investimentos desembocam. Normalmente, ele vê muito longo prazo e pouco detalhamento no curto prazo. O framework que criou visualiza em três camadas: por desenvolvedor, por especialidade e por squad. Isso permite identificar se um desenvolvedor está com dificuldade com um tipo de linguagem de programação ou se falta algum critério de negócio. Ver isso de forma quantitativa, em gráficos, facilita dar feedback e identificar o que está acontecendo. Sem essa visão, com uma equipe de sênior, os problemas aparecem tarde, e o desenvolvedor, ocupado, não atualiza as histórias.

Os pilares principais são organização e pragmatismo. Não adianta querer ter um top-down de organização se a empresa não está organizada. Estratégia é o mapa para chegar ao objetivo. Sem organização detalhada, não se consegue mensurar o desempenho de forma individual, por especialidade ou por squad. O outro ponto é métricas: em meio a tantos frameworks e plataformas, às vezes se perde tempo e energia falando sobre ferramentas em vez de estruturar o aqui e agora, nem que seja num Excel simples. O consumidor final não se importa com o framework usado. É preciso escolher as batalhas, atender o consumidor, dar valor, atingir a alavanca de negócio definida pela diretoria.

Medir produtividade com pessoas é delicado. Os maiores riscos incluem desgringolar para um lado que não é legal nem para o desenvolvedor nem para a liderança. O primeiro ponto é ter tato e empatia: entender o momento da pessoa, se está voltando de férias, se está passando por algo. É preciso contexto, não adianta avaliar o número pelo número. O recorte temporal do que está acontecendo no squad é fundamental. Avaliam-se três informações principais: lead time, o tempo que uma história leva de a fazer até close com o DOD; throughput, o número de histórias concluídas pelo desenvolvedor e pelo squad; e story points, o nível de complexidade de cada história. Isso é feito em conjunto, co-criado. Depois de entender o contexto, avalia-se a parte quantitativa, e então faz sentido falar com o tech lead, com o diretor de operações. Com base nos dados, se um desenvolvedor júnior está acima da média, cabe uma promoção, um reconhecimento. Se está abaixo, vale um feedback, entender o que está acontecendo, se aproximar. A ferramenta é boa ou ruim de acordo com a forma de usá-la. Usada de forma humana e efetiva, é positiva. Usada só pela produtividade, sem contexto, sem entender o momento do funcionário, é negativa. A visão de curto prazo não se sustenta a longo prazo: as pessoas saem, o turnover aumenta, e para uma pessoa nova passar pelo processo de maturação, perde-se produtividade. Bons profissionais, se gostam de onde estão, atraem outros bons profissionais, por boas recomendações, exposição no Glassdoor, eventos. É preciso equilíbrio entre agora e depois.

O framework está em constante movimento. Não era algo que usavam no começo; viram a necessidade porque avaliar apenas o quanto cada pessoa entrega não faz sentido, pois há complexidades diferentes. Olharam para o mercado, viram o que outras startups faziam, adaptaram o story point, o Scrum, sem usar ao pé da letra, mas adaptando ao cenário, ao tamanho da organização, ao estágio de maturidade ágil, ao nível das pessoas. Falam com outras pessoas de startups, especialmente foodtech, trocam insights e adaptam. O papel de Estevam, como coordenador de produto em estrutura enxuta sem team lead, muitas vezes assume essa função, revezando com o tech lead em trocas constantes.

Sobre sobrecarga, Estevam cita a analogia do pastel do podcast Product Girls: não tem problema comer pastel uma vez ou outra, mas se se come só pastel, vai passar mal. Eventualmente surge imprevisto, é normal, especialmente em tecnologia. Mas se acontece imprevisto o tempo todo, algo está errado: não estão refinando direito as histórias, não estão comportando o capacite adequado, estão colocando mais histórias do que o squad aguenta, ou o comercial está vendendo além do que o squad consegue seguir. São sintomas que indicam o que está acontecendo. Não se pode correr atrás do rabo o tempo todo. Imprevistos acontecem, mas se muda a rota o tempo todo, não faz sentido. É preciso escolher as batalhas, focar no core business, no que o cliente vê mais valor. O que não é prioridade fica para o roadmap, para uma sessão de discovery mais aprofundada.

Além das demandas, outros fatores interferem no foco. Momento de carreira da pessoa: um perfil júnior que quer uma promoção vai se dedicar mais, o que é bom, mas é preciso tomar cuidado para não gerar burnout ou expectativas irreais. Gerenciamento de expectativas é essencial, especialmente com o pessoal mais novo, que pensa que em um ano já será promovido. Há também a questão da disputa de egos entre áreas. Se duas áreas têm rixa, como conciliar? O squad não precisa ver a cozinha; está ocupado codando, testando, produzindo. Quem recebe a maior carga é o coordenador, que repassa de outro modo. Se duas diretorias brigam e solicitam coisas gigantescas, é preciso decidir com base nos OKRs, nos objetivos, e postergar o que não faz sentido naquele momento. Blindar o squad é fundamental.

Sobre alta performance e saúde mental, a ferramenta em si depende de como é utilizada. Estevam dá um exemplo prático: um desenvolvedor estava com dificuldade em um produto porque usavam uma linguagem de programação nova para ele. Ele é ótimo, muito capacitado, mas demorou para dar sequência. Os números decaíram. Em vez de dar um feedback negativo imediato, entenderam o contexto: ele está aprendendo a linguagem, tem uma curva de aprendizado. Deixaram um tempo maior. Se só olhassem para o quantitativo, teriam dado um sinal vermelho errado. Entendendo o contexto, direcionaram de forma adequada. Sem o quantitativo, a discussão vira achismo, e quem tem o cargo maior sempre tem a percepção melhor. É preciso dado.

O papel do gestor, no caso do coordenador de produto, é de facilitador. A área de produto é uma anomalia: é tudo e não é nada ao mesmo tempo. Precisa mostrar o valor o tempo todo. É uma amálgama de várias áreas e especialidades. O gestor precisa olhar para os objetivos da empresa, entender como chegar lá, e nesse processo fazer a gestão de pessoas. Se um funcionário está com problema de saúde ou psicológico, quem vê de imediato é a liderança média, não a alta. É preciso ter tato para falar com a pessoa, entender como ajudar, nem que seja indicando um especialista, e repassar a informação para a alta liderança com cuidado, porque a resposta pode ser drástica. Criar um ambiente de confiança, segurança e autonomia é essencial para que as pessoas compartilhem. Sem isso, se tem só o número, e as decisões podem ser equivocadas.

Os maiores erros de líderes ao medir produtividade incluem: cada um no seu quadrado, ou seja, não ter conhecimento técnico suficiente para dar feedback e não entender a lógica por trás da programação, o que leva a ser mal interpretado pelo desenvolvedor. O papel é facilitar a comunicação, não dar um feedback super técnico. Outro erro é não olhar para a produtividade de forma saudável e programada. Há empresas onde um desenvolvedor se mata toda semana, recebe solicitações direto do CEO e do diretor, mas não é visto. É preciso sistemas para mapear tudo. Poucas empresas fazem isso; muitas olham só para o objetivo, mas nem mensuram a alavanca de negócio. Já viu desenvolvedor com dois ou três empregos que não participa dos ritos. A Microsoft cunhou o termo paranoia de produtividade: gestores apontavam que a produtividade estava caindo por causa do home office, enquanto os colaboradores apontavam que estava aumentando. Não é sobre controlar o tempo todo, mas sobre alinhar entregáveis. Se todas as datas são furadas constantemente, algo está errado. É preciso sair do achismo, mapear o processo. Não é a percepção do diretor, do tech lead; é quantitativo. Já aconteceu de a percepção estar errada e os relatórios mostrarem que o desenvolvedor era um dos mais produtivos do squad.

Outro erro comum é focar em métricas superficiais, o microgerenciamento: ver quantas horas a pessoa trabalhou, quantas tarefas foram concluídas, em vez de olhar para o impacto real, o valor gerado. Se o desenvolvedor faz o que combinou para a sprint em dois dias, pode jogar Fortnite depois. Não é problema. Mas é preciso comprometimento com o que foi programado. Não é preciso puxar o desenvolvedor o tempo todo. É preciso um sistema para monitorar, ter registro, ter histórico, entender o que cada um está fazendo, quanto tempo está levando. Mas não é preciso cobrar o tempo todo. Monitorar é monitorar o trabalho, não o trabalhador. É um adesivo que a equipe tem: eu vou monitorar o trabalho, não o trabalhador. Seja o Zé, o João, a Maria, é sobre por que aquilo está naquele lugar, está andando daquela forma.

A dica final de Estevam é tratar a questão de gestão como um produto digital. Assim como se fala de tagueamento, monitoramento, mensuração, comparação, reinvenção e reteste em produto digital, a mesma abordagem se aplica à gestão. É preciso entender como as pessoas estão desempenhando, se está sendo efetivo, se está recebendo elogios da alta liderança, se os ponteiros de negócio estão mudando. Se não, é hora de testar, buscar outra referência, outra forma de fazer. E principalmente guardar dados: não se pode depender de achismo, não se pode depender de percepção. É preciso depender de dados. Se houve melhora ou piora, é preciso entender por quê. O equilíbrio entre curto prazo e longo prazo é constante. Produtividade não é sobre fazer tudo, mas sobre fazer o que precisa ser feito, o que tem impacto, o que gera valor. Estevam deixa as portas abertas para quem quiser trocar uma ideia sobre produtividade na prática. E encerra com uma mensagem: produtos não é tão sexy quanto vendem no LinkedIn, é suor, sangue, lágrimas, mas tem muito potencial de crescimento e de organização mais efetiva. A comunidade de produto é valiosa porque, se alguém tem um problema, normalmente vai ter alguém disposto a ajudar. Olhar para o amiguinho do lado, ver um artigo, um episódio de podcast, chamar alguém, aproveitar a rede.