Matando avaliações 360: como paramos de avaliar as pessoas e começamos a gerenciar o trabalho

Olá! Meu nome é Vitalina e sou gerente de contas em SToFU Systems.

Somos o tipo de empresa onde os processos nascem em movimento e só depois ganham nomes, regras e supervisão de adultos. No início não tínhamos escola própria de gestão, por isso copiamos o que “todo mundo copia”. Um desses hábitos de gerenciamento emprestados foi o feedback 360º.

No papel, o 360 parece algo justo e maduro. Muitas fontes. Menos preconceito. "Objetividade". Hummm!

Na prática, o 360 separou silenciosamente a equipe em vez de fortalecê-la. Formalmente, parecia correto, enquanto o trabalho real caminhava na direção errada. Então nós cortamos isso. Vamos passo a passo.

O que é 360?

360 é quando você coleta feedback sobre uma pessoa “de todos os lados”: do gerente, colegas, companheiros de equipe adjacentes e, às vezes, clientes. Geralmente é um questionário com avaliações e perguntas como “o que vai bem”, “o que atrapalha”, “o que deve ser mudado”.

Nós também fizemos isso. Enviamos um questionário, coletamos respostas, agregamos e escrevemos recomendações. Formalmente, tudo parecia arrumado. Havia pontos de dados. Houve conclusões. Havia um "plano de desenvolvimento".

Para deixar claro de que tipo de “questionário” estamos falando, darei um exemplo bem simplificado do que costuma ser perguntado no 360. Esta é a lógica típica do formulário, parafraseado.

Por exemplo: “O que uma pessoa deve continuar a fazer?”. Depois: “O que uma pessoa deve começar a fazer?”. Depois: “O que uma pessoa deve parar de fazer?”. E outra pergunta que sempre parece inocente: “Descreva uma situação em que a interação foi difícil e por quê”.

E o resumo muitas vezes parece um pequeno relatório elaborado por um olho coletivo que tudo vê. Mais ou menos assim:

Pontos fortes: realiza tarefas rapidamente, ajuda os outros, não desaparece do radar. Riscos: “pronto” às vezes significa “quase pronto”, a discussão nas reuniões pode ser acirrada, no chat ele responde em fragmentos. O que fazer a seguir: chegar a um acordo sobre a Definição de Pronto, sincronizar as expectativas, chegar a um acordo sobre o formato de escalonamento.

No papel está tudo bem. Lindo, até. Mas há um detalhe. Foi escrito por pessoas que trabalham juntas todos os dias. E depois de adicionar anonimato ou atrasar feedback "para depois", deixa de ser uma ferramenta de desenvolvimento e começa a viver uma vida própria. Imagine uma equipe de projeto de cinco pessoas. Então alguém diz: “Aqui está um feedback anônimo”. Anônimo. Em uma equipe de cinco. E nesta realidade, o 360 começa a mostrar a sua verdadeira face.

Por que o 360 se tornou uma ferramenta para separar a equipe

1. Ponto um. Elogio - uma linha, crítica - um romance de três volumes

Quando as coisas vão bem, as pessoas escrevem brevemente. "Está tudo bem." "Trabalho confortável." "Bom trabalho". Este é um feedback no nível de um adesivo em um caderno escolar. Quando algo está errado, a literatura começa. Com detalhes, com exemplos, com emoções. E tecnicamente isso é normal: negativo é mais fácil de especificar do que positivo. Mas em 360 há o problema: todo esse "romance" volta então para uma pessoa como um generalizado veredicto da equipe.

Mesmo que você expresse isso da maneira mais gentil possível, o cérebro humano lê assim: "Todos nós nos reunimos e anotamos o que há de errado com você." E é isso. Depois disso, qualquer tentativa de “feedback construtivo” parece uma audiência em tribunal. Você queria uma ferramenta de desenvolvimento e conseguiu um tribunal coletivo.

Sinceramente, perguntámo-nos: o que é que estamos realmente a tentar fazer com essa prática? Disciplina o formato, sim, mas isso destrói a confiança.

Da vida é assim. Um relatório chega a uma pessoa, onde há três frases “está tudo bem” e duas telas negativas. E o cérebro, claro, lembra-se das duas marcas negativas com mais nitidez do que das três positivas. "não está bem". Porque é assim que a atenção é organizada: dói, então é importante! E a partir desse ponto, a pessoa avança em direção à autodefesa em vez do desenvolvimento. Eles começar a provar o contrário, ou que “era o contexto”, ou que “vocês também não são santos”. E neste momento o 360 se transforma em um ritual onde todos como se quisessem o bem, mas acabou como sempre.

2. Ponto dois. O anonimato em uma equipe pequena é autoengano

Existe um conto de fadas familiar sobre gerenciamento: “O feedback anônimo elimina o medo”. Anonimato? Realmente? Em pequenas equipes de projeto? Na realidade, quase sempre significa “Vou adivinhar quem escreveu isto!”.

Uma pessoa recebe vários comentários desagradáveis ​​e depois chega à próxima reunião do projeto onde essas mesmas 3-5 pessoas estão sentadas. Eles não pensam em “desenvolvimento organizacional”. Eles pensam: "Qual foi um de vocês?" E isso inicia um processo muito tóxico: todos permanece aparentemente educado, mas por baixo há uma camada oculta de desconfiança.

Nem sempre explode em conflito aberto. Simplesmente deixa o time mais frio. Menos coeso. Menos disposto a ajudar. E então nos perguntamos por que as pessoas não compartilham seus problemas "nos estágios iniciais". Mas porque eles já são uma vez compartilhado - e devolvido a eles anonimamente uma lista de reivindicações.

3. Assim que o 360 afeta as decisões de promoção, os jogos começam

Aqui estava a coisa mais interessante. E o mais triste.

Numa das nossas discussões de coordenação, notámos algo estranho. Uma pessoa pode ser educada, solidária e fácil de trabalhar nas ligações. Dentro da equipe eles podem parecer um amor completo. E então você entrega a eles um questionário "anônimo" onde eles podem "avaliar os outros", e de repente a pontuação cai ou as críticas tornam-se excessivas. Nós mesmos vimos esse efeito. Funcionou diretamente contra a integridade.

Imagine a situação. Você diz à equipe: "As avaliações de 360° contam para promoção." E no mesmo segundo, você vira parte do equipe em jogadores, não em colegas. Porque se o botão “influência” aparecer no sistema, alguém irá pressioná-lo. Nem sempre do mal. Às vezes, apenas por sentir injustiça ("e por que ele está sendo promovido, ele está..."). Às vezes da competição. Às vezes porque “é assim que o mundo funciona”. E naquele momento você consegue o que queria evite: política, jogos, notas "mais baixas, por precaução".

Essa, aliás, é uma das razões pelas quais muitos pesquisadores e os profissionais são aconselhados a compartilhar feedback para o desenvolvimento e decisões administrativas (dinheiro, notas, promoção). O CIPD é bastante direto: falar sobre é melhor separar as avaliações/decisões administrativas das conversas, onde o feedback é dado para fins de desenvolvimento. Aqui está um PDF da revisão de evidências (resumo da prática): www.cipd.org/...​e-review_tcm18-111378.pdf

4. Ponto quatro (nosso doloroso insight). 360 muitas vezes substitui o trabalho do gerente

Depois de vários ciclos, acabamos com uma frase que primeiro soou como um insulto e depois como verdade.

Se um gerente precisa de um 360 para entender como as pessoas estão trabalhando e onde estão os problemas, esse gerente não possui um sistema de sinais observáveis. Não há métricas. Não há conversas regulares. Não há ritmo. Ou tudo isso existe "em algum lugar", mas não está realmente sendo usado.

E o 360 vira muleta: “vamos agora recolher o questionário e finalmente aprenderemos a verdade." E então você não entende a "verdade" e uma imagem emocional, multiplicada pelo anonimato, suposições e jogos políticos.

Para manter isso fundamentado, adicionarei uma referência.

Há um estudo sobre feedback de múltiplas fontes. Sua conclusão é basicamente: “não espere mágica”. Numa meta-análise de 24 estudos longitudinais, Smither, London e Riley escrevem que a melhoria após O feedback 360 geralmente é modesto e você não deve esperar um grande "atualização em massa" após uma onda de feedback. A chance de melhoria aumenta quando a pessoa vê uma necessidade real de mudança, aceita o feedback, acredita que pode mudar, estabelece metas concretas, e realmente faz alguma coisa, em vez de apenas "ler um PDF e seguir em frente." Aqui está o próprio texto (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

Ok, removemos o 360. O que o substituiu?

Paramos de medir as pessoas pela contagem de ingressos

Um ingresso pode acomodar uma semana de pesquisa, uma decisão difícil, dez chamadas e apenas 20 linhas de código. Em outro, 50 recursos que realmente surgiram de uma execução do agente de IA em 20 minutos.

Se você está apenas medindo tickets, na verdade você está medindo como seu processo reduz o trabalho em pedaços

É por isso que mudamos a pergunta. A melhor pergunta tornou-se: O que foi entregue, que valor criou, qual foi a qualidade, foi previsível e os status foram honestos?

Como definimos “resultado” sem teatro de gestão

Convergimos para uma estrutura simples.

Um resultado é quando o valor é entregue, a qualidade é aceitável, a equipe é previsível e o progresso é transparente.

O valor não é "o código está escrito". É “o usuário ou cliente obteve um resultado melhor” ou “ficou mais fácil para a equipe para apoiar o sistema".

Qualidade não é "Gosto do seu código". São consequências: bugs no produto, incidentes, revisões.

Previsibilidade não é “sempre conseguimos”. É: "compreendemos honestamente para que temos tempo e o que não temos, e não mentimos para nós mesmos sobre isso."

Transparência é quando o “quase pronto” não se transforma em filosofia de vida.

Métricas

Quando as pessoas ouvem a palavra "métricas", muitas imediatamente lembre-se do trabalhador ligeiramente traumatizado por experiências anteriores: aquele que foi espancado na cabeça com números.

As métricas não devem ser um chicote. Deveriam ser óculos. Sem eles, um gestor fica muitas vezes cego. E quando o gestor fica cego, ele passa a buscar “objetividade” nos questionários. Bem, você entendeu.

Deixamos as métricas no nível da equipe, pois a maioria dos problemas são sistêmicos! E se quisermos corrigir o processo em vez de procurar culpados, então precisamos medir o processo!

Sinceramente, não inventamos nada aqui. DORA (DevOps Investigação e Avaliação) já promove uma abordagem muito prática conjunto de métricas de entrega: a rapidez com que você entrega a mudança e quão dolorosos são os fracassos quando as mudanças dão errado. Aqui está o guia rápido: dora.dev/guides/dora-metrics.

Há também uma observação importante que gostaria de deixar claro na parede para quem sempre quis fazer métricas de KPI: "não faça da métrica o objetivo"! Porque assim que você diz "precisamos implantar N vezes por dia", parte do a equipe começa a implantar um número em vez de valor. Este é o velho história de que uma vez que uma métrica se torna o objetivo, ela deixa de ser um indicador. DORA refere-se explicitamente à lei de Goodhart e descreve armadilhas típicas. Aqui está a página sobre as "quatro/cinco chaves" em palavras simples: dora.dev/...​s/dora-metrics-four-keys

E mais uma coisa importante que DORA normalmente enfatiza: contexto é importante. Essas métricas são melhor visualizadas em um equipe ou serviço e ao longo do tempo, não comparando um aplicativo móvel com um mainframe ou uma pequena equipe com plataforma para 200 pessoas.

Se você não é uma equipe técnica, a lógica é a mesma. Em vez de "deploy" você pode ter "o cliente aceitou o resultado"; em vez de "incidente" você pode ter "escalada"; em vez de "reverter", "retrabalhar após o alinhamento". A questão ainda é a mesma: com que rapidez movemos o valor através do sistema e quanto o erro nos custa.

E agora - o muito importante “não faça isso”. Não converta essas métricas em KPIs individuais! Porque aí as pessoas começam a otimizar o número em vez de melhorar o produto. KPI em "implantações" e, de repente, você tem implantações por implantações. KPI sobre “tempo de ciclo” e as tarefas são divididas ao ponto do absurdo apenas para “fechá-las rapidamente”, enquanto as partes difíceis desaparecem silenciosamente nas sombras. KPI sobre “incidentes” e os incidentes começam a ser renomeados como “peculiaridades” ou “cenários inesperados do usuário”.

A primeira coisa que nos ajudou foi a previsibilidade. Simples pergunta: o que prometemos no planejamento e o que realmente foi dado. Não por vergonha. Para compreensão. Porque se você prometer constantemente 10 e cumprir 6, então o problema não são os “preguiçosos”. O problema está na estimativa, prioridades, WIP, bloqueadores, mudança de contexto. Em outras palavras, na gestão.

O segundo é o prazo de entrega. Quanto tempo leva a tarefa? no caminho de “levado para o trabalho” para “realmente entregue”. É muito preocupante. Porque muitas vezes acontece que "escrevemos código" rapidamente, mas "entregamos" devagar. E então você pode ver onde está o gargalo: revisão, teste, liberação, reconciliação, dependências.

O terceiro é o WIP. Se a equipe estiver "trabalhando" ao mesmo tempo dez problemas de uma vez, então ninguém está realmente fazendo nada. Mais precisamente, todo mundo está fazendo tudo ao mesmo tempo. E então nos perguntamos por que o progresso parece lento e nervoso. Quando o cérebro está espalhado em uma camada fina em dez tarefas, não se torna mais produtivo. Apenas se torna mais cansado.

Outra coisa que nos ajudou a pensar com mais clareza foi esta: se quisermos que o trabalho avance mais rapidamente no sistema, a resposta muitas vezes é não pressionar mais as pessoas. É para reduzir o tamanho do lote. Mudanças menores são mais fáceis de revisar, testar, liberar e reverter. DORA afirma diretamente a mesma coisa: lotes menores geralmente melhoram a velocidade e a estabilidade. Parece óbvio até que uma equipe realmente tente viver de acordo com isso por um mês.

Qualidade: paramos de discutir “me parece” e começamos a olhar para as consequências

Avaliar a “qualidade” com questionários é uma má ideia. Porque "qualidade" no questionário, muitas vezes trata-se de simpatia, estilo e gosto.

Passamos para as consequências.

Quantos defeitos atingiram a produção. Quão sérios eles eram? Como a tendência está mudando?

Quantos incidentes tivemos. Quanto tempo levamos para nos recuperar? Os mesmos motivos se repetem?

Quantas revisões. Quantas tarefas foram “aprovadas” e depois devolvidas. Porque "pronto" acabou por não estar pronto.

Você não está mais discutindo sobre “quem é o melhor”. Você vê o que realmente está acontecendo com o produto.

Uma conclusão contraintuitiva: por que avaliar uma pessoa?

Quanto mais cavamos, mais frequentemente nos deparamos com uma pergunta estranha.

Por que avaliamos uma pessoa? Recusar uma promoção? Para mostrar quem é a “estrela”? Para comparar pessoas?

E quando conversamos sobre isso honestamente, descobriu-se que a maioria das nossas necessidades reais não era sobre classificação pessoas. Eles tratavam do desempenho da equipe: estamos fazendo o que prometemos, a qualidade é boa, o trabalho é previsível, estamos esgotados e o cliente consegue o que eles esperam?

Ou seja, sobre o sistema.

E se sim, então o primeiro objeto de avaliação é a equipe e o processo. E não uma pessoa como alvo.

A equipe está com baixo desempenho, então revisamos todo o cadeia: contratação, integração, definição de tarefas, planejamento, revisão, teste, liberação, comunicação, dependências. Isto é gerencialmente mais difícil, sim. Mas é mais honesto.

Às vezes parece muito realista. Por exemplo, quando “não tivemos tempo de novo”, a primeira pergunta não é “quem está desacelerando”, e "onde o tempo desapareceu". Porque o tempo pode desaparecer em espera: as tarefas ficam ociosas em revisão, em teste, bloqueado por acordo ou há simplesmente muitos deles em paralelo.

Quando alguém está com dificuldades, o que verificamos primeiro

Às vezes também vemos situações em que alguém “não puxa”. Mas em vez de um questionário, fazemos um diagnóstico simples.

Esse problema sempre existiu? Se sim, o problema provavelmente na contratação ou integração. Nesse caso, você corrige o processo de contratação, não a pessoa com questionários.

Antes era normal e depois piorou? Então pode ser o contexto: esgotamento, mudança de tarefas, conflito de papéis, circunstâncias pessoais. Esta é a zona de trabalho gerencial normal: descobrir o que aconteceu, diminuir a carga, ajudar a pessoa a se recuperar controle e crie um plano de recuperação curto de 2 a 4 semanas.

A pessoa tem uma compreensão clara do que é sucesso parece em um futuro próximo? Porque muitas vezes o problema não é que a pessoa é "fraca". É que os colocamos no nevoeiro e chamou isso de expectativas.

E mais uma nuance que também tínhamos. Se uma pessoa falhou várias vezes, o gerente pode às vezes aumentar subjetivamente bar: "agora prove que você não é um fracasso." Isso geralmente funciona em um nível subconsciente e funciona mal para a equipe. Geralmente é melhor fazer o oposto: reduzir o escopo, diminuir as tarefas, remova o ruído, dê a uma pessoa a chance de fazer algumas coisas bem de forma consistente e recuperar a autoconfiança. Esta é uma tarefa difícil para gerentes. E é exatamente por isso que olhamos bem de perto nos gerentes que contratamos.

Conclusões

Claro que o 360 pode funcionar. Em grandes empresas, onde o anonimato é realmente possível.

Quando a equipe já possui uma cultura de feedback direto, e 360 ​​é um sinal adicional, não o principal "verdade".

Nós não tínhamos isso. Tínhamos equipes pequenas, ritmo acelerado e alto custo de desconfiança.

O 360 parecia uma ferramenta adulta no papel. Em nosso realidade, tornou-se um mecanismo que reúne o medo em um só lugar, suposições, competição e "julgamento coletivo".

Cortamos 360 e voltamos ao básico: métricas de equipe simples, conversas abertas e status transparentes.

Materiais e links (se você quiser se aprofundar)

DORA, software delivery performance metrics. Uma explicação fundamentada das cinco métricas e das armadilhas em que as equipes caem quando as utilizam indevidamente.

DORA, DORA’s software delivery performance metrics. Versão curta com histórico "por que quatro/cinco" e um aviso sobre jogos com métricas.

DORA Research: 2024, DORA Report. Relatório completo (baixe o PDF em vários idiomas).

Smither, London (2005), meta-analysis on multisource feedback. Por que você não deve esperar um efeito mágico de uma onda 360.

CIPD, Performance feedback: an evidence review (PDF). Sobre como o feedback funciona/não funciona e por que confundir “avaliação” com “desenvolvimento” é muitas vezes prejudicial.

CCL, 360 Degree Assessment & Feedback: Best Practices Guidelines. Se você ainda faz um 360, há algo em que pensar antes do início, não depois do incêndio.

CCL, SBI feedback model. Uma estrutura muito simples para feedback "sem atalhos".

Google SRE, Postmortem Culture: Learning from Failure. Sobre postmortems inocentes e por que a cultura envergonhada está matando o aprendizado.

Amy Edmondson (1999), Psychological Safety (PDF). Fonte primária sobre segurança psicológica em equipes.

WEF, Feedforward technique. Sobre como mudar o feedback na direção de “o que faremos a seguir” e não “o que aconteceu ontem”.

Goodhart’s law. Uma das “antiteorias” mais úteis para quem quer fazer métricas de KPI.

Perguntas para a comunidade

O que a comunidade pensa sobre o 360? Você usa isso? Como tem sido sua experiência?

Como resolver o problema do “anonimato” quando a equipe é pequena e todos entendem tudo?

E quais métricas de entrega/qualidade realmente ajudam você a gerenciar o processo, em vez de elaborar relatórios bonitos?

Obrigado pelo seu tempo e atenção.