Como avaliar o desempenho da equipe

Uma startup legal no início de sua jornada é semelhante à Sapsan. Uma equipe pequena está ganhando impulso rapidamente e se apressando para o futuro, levando várias tarefas à produção. Se o projeto se mostrou promissor, como o Skyeng, em alguns anos haverá muito mais equipes, e é possível que entre elas existam locomotivas a vapor nas quais você precise jogar constantemente lenha no forno para que pelo menos algo chegue aos usuários.


Confira ou leia a palestra de Alexey Kataev no Saint TeamLead Conf, se você não souber quais critérios formais para determinar se sua equipe é incrível . Se você deseja medir a dívida técnica em horas, em vez de operar com as categorias “um pouco”, “quanto”, “terrivelmente demais”. Se o gerente de produto acredita que uma equipe de três pessoas em um mês fará 60 tarefas - mostre a ele este artigo. Se o seu gerente interrompeu o desenvolvimento com métricas e sugere que você tome medidas com base em resultados como: "34% acham que a equipe tem um problema com o planejamento", este relatório é para você.



Sobre o palestrante: Alexei Kataev ( deusdeorum ) atua no desenvolvimento web há 15 anos. Conseguiu trabalhar como back-end, front-end, desenvolvedor fullstack e líder de equipe. Atualmente envolvido na racionalização de processos de desenvolvimento na Skyeng . Pode ser familiar para os líderes de equipe falar sobre o trabalho de uma equipe distribuída.

Agora, finalmente, passamos a palavra ao orador. Vamos começar com o contexto e avançar gradualmente para o problema principal.



Entrei para a Skyeng em 2015 e fui um dos cinco desenvolvedores - eles eram todos desenvolvedores da empresa.

Pouco mais de três anos se passaram e agora temos 15 equipes - são 68 desenvolvedores .



Todos os desenvolvedores trabalham remotamente , eles estão espalhados pelo mundo.

Vejamos os problemas que inevitavelmente surgem ao escalar uma empresa de 5 para 68 funcionários.

Na foto, Sergey é o gerente de desenvolvimento.


Uma vez tivemos uma equipe, e foi Sapsan, que correu para o futuro e realizou várias tarefas na produção. Mas não apenas tarefas, mas um pouco de dívida técnica. Então, em algum momento, inesperadamente para nós, havia muito mais equipes.

A primeira pergunta que Sergey enfrenta é se todas as nossas equipes são sapsans ou se existem motores a vapor entre nós, onde você precisa jogar lenha na fornalha.


Essa pergunta é importante porque uma situação dessas pode surgir: um gerente de produtos ou um representante de negócios entrará em contato com Sergey e dirá que não temos tempo, a equipe está trabalhando mal. Mas, de fato, o problema pode não estar apenas na equipe. O problema pode estar no relacionamento entre a equipe e o negócio ou no próprio negócio - ele pode não estabelecer metas bem ou ter planos muito otimistas.

Você precisa entender se a equipe é legal .


A segunda pergunta são os recursos da equipe : quantas tarefas podemos executar nos produtos. Esse problema é importante porque o produto sempre tem muitos planos para o futuro próximo. É importante entender se a equipe vai lidar com esses planos ou se você precisa jogar metade das tarefas. Ou talvez valha a pena contratar mais algumas pessoas para realizar todas as tarefas.


A terceira pergunta é quanta dívida técnica carregamos conosco? Esta é uma pergunta crítica, porque se sua quantidade exceder o valor limite, no final, nosso trem não poderá ir a lugar algum. Teremos que demitir a equipe, iniciar o projeto desde o início, mas não queremos permitir isso.


Finalmente - como podemos garantir que todas as equipes sejam sapsans e não trens?

1. Determinamos o quão legais nossas equipes são.

Obviamente, a primeira coisa que vem à mente é medir algumas métricas! Agora vou falar sobre a nossa experiência e como nos enganamos repetidamente.


Primeiro, tentamos monitorar a velocidade - quantas tarefas estamos implementando para o sprint. Mas acabou que metade de nossas equipes não tem sprints, eles têm Kanban. E onde há sprints, as tarefas são classificadas em horas ou em pontos da história. Ainda existem algumas equipes que apenas executam as tarefas - elas não têm Kanban, não sabem o que é o Scrum.

Isso é inconsistência de dados. Estamos tentando calcular um número em dados completamente diferentes. Ao mesmo tempo, fazer sprints em todos os lugares para que todas as equipes sejam idênticas será muito caro. Para calcular uma métrica, seria necessário alterar os processos.

Pensamos, tentamos mais algumas opções e chegamos a uma métrica simples - a implementação de planos . Também é caro, mas apenas os planos do produto precisam ser idênticos e consistentes. Alguém os leva a Jira, alguém no Google Spreadsheets, alguém cria gráficos - converter para um formato é muito mais barato do que mudar processos nas equipes.

A cada trimestre, vemos se a equipe atende aos requisitos de negócios, quantas tarefas planejadas foram concluídas.


A contagem do número de incidentes também falhou.

Registramos todos os lançamentos ou erros com falha que causaram danos à empresa e post-mortem. Sergei veio a mim como líder de equipe e disse: “Sua equipe admite mais quedas. Porque? Pensamos, olhamos e descobrimos que nossa equipe é a mais responsável e a única que registra todas as quedas. O resto age de acordo com o princípio do rápido aumento, não considerado caído.

O problema novamente é inconsistência de dados e amostragem insuficiente. Temos equipes que têm apenas um pouso - ele nunca falha. Não podemos dizer que essa equipe é melhor porque tem um projeto mais estável.

O segundo - meu tópico favorito - é distorção cognitiva . A facilidade cognitiva é quando fazemos uma conclusão que parece simples para nós e imediatamente começamos a acreditar nela. Não incluímos um pensamento crítico: se houver muitas quedas, isso significa um time ruim.

Chegamos exatamente à mesma métrica do número de incidentes, mas apenas revisamos sua implementação. Fizemos um processo no qual todas as quedas são registradas . No final de cada mês, solicitamos às pessoas que não estão interessadas em ocultar incidentes - esses são QA e produtos. Essa é uma lista completa dos problemas que ocorreram devido à falha da equipe. Eles se lembram de quando deixamos cair alguma coisa e complementamos esta lista.


Também há problemas com as pesquisas. Parece que é uma ferramenta super-universal - entrevistaremos todos (produtos, líderes de equipe, clientes) que problemas temos nas equipes. De acordo com as respostas deles, construiremos gráficos e descobriremos tudo. Mas há muitos problemas.

Em primeiro lugar, se você fizer perguntas fechadas, nenhuma conclusão poderá ser tirada desses dados. Por exemplo, perguntamos: "A equipe tem algum problema com o planejamento?" e 34% dizem que existe - e o que fazer sobre isso? Se você fizer perguntas abertas: "Quais são os problemas na equipe com a infraestrutura?" - você receberá respostas vazias, porque todo mundo tem preguiça de escrever qualquer coisa. Nenhuma conclusão pode ser tirada desses dados .

Desenvolvemos essa ideia - primeiro realizamos pesquisas como triagem e, em seguida, entrevistas para entender qual é exatamente o problema. Falaremos sobre a entrevista um pouco mais tarde.

Dei três exemplos, na verdade tentamos dezenas de métricas .

Agora usamos apenas:

• Cumprimento de planos.
• O número de incidentes.
• Pesquisas + entrevistas.

Estou enganando se disser que até medimos essas coisas simples em todas as equipes, porque a coisa mais cara é a implementação . Especialmente quando existem 15 equipes diferentes, quando o produto diz: "Sim, não precisamos disso! Teríamos que executar nossa tarefa, agora não é possível! ” É muito difícil fazer isso para medir um número em todas as equipes.

A entrevista

Vamos fazer uma breve digressão sobre a entrevista com os desenvolvedores . Eu li vários artigos, fiz o curso de mercearia. Há muito sobre pesquisa de usuários e desenvolvimento de clientes. Eu tomei várias práticas a partir daí, e elas muito bem entraram em comunicação com os desenvolvedores.

Se seu objetivo é descobrir quais problemas a equipe tem, primeiro você deve escrever perguntas específicas para as quais procurará a resposta. Ou seja, você não joga apenas 30 perguntas, escolhe 2 ou 3 perguntas para as quais procura uma resposta. Por exemplo: a equipe tem problemas de infraestrutura; como a comunicação entre negócios e equipe é estabelecida.

Nesse caso, as perguntas devem ser:

• Aberto . A resposta para a pergunta: "Existe algum problema?" Sim! "Ele não vai lhe dizer nada."
• Neutro Uma pergunta sobre um problema é uma pergunta ruim. Melhor perguntar: "Conte-me sobre o processo de planejamento em sua equipe". Uma pessoa fala sobre o processo e você já está começando a fazer perguntas mais profundas.

Outra abordagem muito boa é a priorização . Você tem diferentes aspectos da vida em equipe. Você pergunta ao funcionário quais, em sua opinião, são os mais legais e devem permanecer os mesmos, e quais talvez sejam melhorados.

Há outra abordagem que adotei no capítulo sobre entrevistas no livro “Quem. Resolva seu problema número um "- faça perguntas como esta:" Se eu perguntasse a um produto, o que você acha, quais problemas ele nomearia? " Isso força o desenvolvedor a olhar para o cenário geral, e não de sua posição, para ver todos os problemas.

2. Avalie recursos

Agora vamos falar sobre a avaliação de recursos .

Vamos começar com a abordagem do produto - como ele normalmente avalia os recursos de sua equipe. São 3 pessoas, 20 dias úteis em um mês - multiplicamos pessoas por dias, realizamos 60 tarefas.



Obviamente, exagerei, um produto normal multiplicará isso por 60 dias de desenvolvimento. Mas isso também está errado, ninguém jamais implementará tarefas classificadas por 60 dias em 60 dias. Até o Scrum aconselha que você considere o fator de foco e multiplique por um certo número mágico, por exemplo, 0,2. De fato, de iteração para iteração, lançaremos 12, 17 e 10 tarefas. Eu acho que essa é uma avaliação muito grosseira.

Eu tenho minha própria abordagem para avaliar recursos. Para começar, consideramos o recurso total da equipe em horário comercial. Multiplicamos horas por desenvolvedores, tiramos férias e dias de folga. Suponha que você obtenha 750. Mas nem todo desenvolvimento é o próprio desenvolvimento.


Acima estão os dados reais usando um dos comandos como exemplo:

• 36,9% do tempo gasto em comunicação são reuniões, discussões, revisões técnicas, revisões de código, etc.
• 63,1% - diretamente para resolver problemas.

O produto pode contar com esses 63,1%? Não, não pode, porque as tarefas do produto são apenas parte. Ainda existe uma cota (cerca de 20%) para correção de bugs e refatoração . É isso que o timlid distribui e o produto não conta mais com esse tempo.


Também das tarefas do produto, nem todas as tarefas são aquelas que o produto planejou. Existem tarefas de produtos de outras equipes que solicitam ajuda urgente por causa do lançamento. Estimamos aproximadamente 8 a 10% das tarefas que vêm de outras equipes .


E agora temos 287 horas! Tudo seria legal se sempre encaixássemos em nossas notas. Mas nesta equipe a média de gasto foi contada - 1,51, ou seja, em média, a tarefa levou uma vez e meia mais tempo do que o estimado.


Um total de 750 permanece 189 horas para concluir as principais tarefas . Obviamente, isso é uma aproximação, mas essa fórmula tem variáveis ​​que podem ser alteradas. Por exemplo, se você dedicar um mês à refatoração, poderá substituir esse valor e descobrir com o que pode contar.

Dediquei o dia todo a isso - fiz tarefas, no Excel calculei o tempo médio, analisei - gastei muito tempo e decidi que nunca mais faria isso. Eu preciso de uma abordagem rápida para isso, para não fazê-lo com as mãos o tempo todo.

Fui aconselhado um plugin para Jira e EazyBI . Essa é uma ferramenta super complicada, ou eu não tinha habilidades suficientes, mas no meio desisti.

Eu encontrei uma maneira de criar rapidamente quaisquer relatórios.


Carregue dados do seu rastreador de tarefas para qualquer DBMS que você conheça (PostgreSQL para nós) e peça ao analista para calcular tudo. Temos o Dima, e ele calculou tudo em 2 horas.


Ao mesmo tempo, ele forneceu um monte de dados adicionais - horas extras para desenvolvedores, horas extras para tipos de tarefas, alguns fatores - nos informaram sobre suas idéias e novas hipóteses - divertidas e escaláveis: você pode usá-las imediatamente em todas as equipes.

Como aumentar o recurso

Agora, sobre como você pode acelerar uma equipe - aumente seus recursos sem aumentar o número de desenvolvedores.

Primeiro de tudo, para acelerar algo, você deve primeiro medi-lo. Normalmente contamos duas métricas:

1. Avaliação resumida inicial de tarefas para iteração em horas. Por exemplo, lançamos tarefas por 100 horas em uma semana.
   
2. E, às vezes, o tempo médio de rolagem é o momento em que a tarefa foi desenvolvida, antes de estar em produção. Essa é uma métrica mais comercial e é interessante para o produto, não para o desenvolvedor.
   

Não vou me cansar de contar ao bot Arseny, a quem escrevi no fim de semana. Toda semana ele publica um resumo - quantas tarefas realizamos.



Há duas coisas interessantes aqui:

1. O que chamo de efeito observador - avaliando algum indicador, já estamos mudando. Assim que começamos a usar esse bot, aumentamos o número de tarefas que realizamos durante a iteração.
   
2. A métrica deve ser motivadora . Comecei mostrando até que ponto não temos tempo para correr. Descobrimos que não chegamos a tempo em 10%, em 20%. Isso não motiva nada, não haverá efeito de observador.
   

A velocidade é uma métrica atrasada; não podemos influenciá-la diretamente. Isso mostra alguma coisa, mas existem métricas que afetam quais podemos influenciar a velocidade. Na minha opinião, existem dois principais:

1. A precisão das tarefas de avaliação.
Aqui fomos novamente ajudados por nosso analista encarregado Dima, que calculou o tempo real da tarefa, dependendo da avaliação inicial.


São dados reais. Acima está um gráfico do tempo real para concluir a tarefa e abaixo está nossa estimativa.

Joel Spolsky afirma que 16 horas por tarefa é o limite. Para nós, é claro que após 12 horas a avaliação não faz sentido, a variação é muito alta lá. Introduzimos realmente o soft-limit e tentamos não avaliar as tarefas por mais de 12 horas. Depois disso, decomposição ou pesquisa adicional.

2. Um desperdício de tempo, ou seja, quando os desenvolvedores gastam tempo com algo em que talvez não o gastem.
Em uma de nossas equipes, até 50% do tempo foi gasto em comunicação. Começamos a analisar e entender qual era o motivo. Descobriu-se que o problema está nos processos: todos os clientes escreviam diretamente para os desenvolvedores, faziam perguntas. Mudamos um pouco os processos, reduzimos esse tempo e melhoramos os indicadores de velocidade.

No seu caso, isso não será necessariamente uma comunicação, por exemplo, pode ser hora de implantação ou infraestrutura. Mas o pré-requisito para isso é que todos os seus desenvolvedores devem registrar o tempo. Se ninguém registra seu tempo no Jira, obviamente será muito caro implementá-lo.

3. Lidar com dívidas técnicas

Quando digo "dever técnico", visualizo-o como algo embaçado - não está claro como ele pode ser medido?


Se eu lhe disser que temos exatamente 648 horas de serviço técnico em uma das equipes, você não acredita em mim. Mas vou lhe dizer o algoritmo pelo qual o medimos.


Reunimos uma equipe a cada trimestre como um todo (chamamos de reunião de refatoração) e criamos cartões: que muletas (nossas e outras) as pessoas viam no código, decisões duvidosas e outras coisas ruins, por exemplo, versões antigas de bibliotecas - qualquer coisa. Depois que geramos um monte dessas placas, para cada uma delas escrevemos a resolução - o que fazer com ela. Talvez não faça nada, porque não é um dever técnico, ou você precisa atualizar a versão da biblioteca, refatorar, etc. Em seguida, criamos tickets em Jira, onde escrevemos: "Esse é o problema - essa é a sua solução".

E aqui temos 150 ingressos em Jira - o que fazer com eles?



Depois disso, realizamos uma pesquisa que leva 10 minutos para um desenvolvedor. Cada desenvolvedor atribui uma classificação de 1 a 5, onde 1 - "Algum dia faremos na próxima vida" e 5 - "Precisamos fazer agora, isso nos atrasa bastante". Adicionamos essa classificação diretamente ao ticket em Jira. Criamos um campo personalizado, chamado de "Prioridade de refatoração" e, por meio dele, obtemos uma lista priorizada de nossos problemas e dívidas técnicas. Depois de avaliar as primeiras 10–20 e depois multiplicar a cauda pela classificação média (temos preguiça de avaliar todos os 150 tickets), obtemos dívida técnica em horas .

Por que precisamos disso? Realizamos essa avaliação uma vez por trimestre. Se tivéssemos 700 horas no primeiro trimestre e depois se tornasse, por exemplo, 800, tudo está em ordem. E se chegou a 1400, significa que há uma ameaça e é necessário aumentar a cota para refatoração - concorde com o negócio que agora refatoraremos um mês inteiro ou 40% do tempo todo.

Bem, resolvemos o problema da dívida técnica, está travado.


Mas vamos falar sobre os motivos que levam à sua ocorrência. Isso geralmente é uma revisão de código ruim.

Revisão de código incorreta

Um dos principais motivos para uma revisão ruim do código é o fator de barramento. Aprendemos a formalizar o fator de ônibus . Tomamos uma equipe, escrevemos uma lista de áreas relevantes para essa equipe, por exemplo, para uma equipe de plataforma: comunicação por vídeo, sincronização de exercícios, ferramentas. Cada desenvolvedor atribui uma classificação de 1 a 3:

• 1 - "Não entendo o que é, ouvi algumas vezes".
• 2 - "Eu posso fazer tarefas nesta área."
• 3 - “Sou um super especialista nessa área.”

Curiosamente, para algumas áreas não havia um único especialista na equipe, ninguém sabia como isso funciona.

Como resolvemos o problema com o fator de barramento ?

Em seguida, calculamos o valor mediano de cada área e conduzimos uma série de relatórios em reuniões regulares da equipe, nas quais especialistas informavam a equipe inteira sobre essas áreas. Obviamente, esse método não se adapta muito bem, mas, primeiro, há um vídeo desses relatórios e, segundo, é uma maneira muito rápida. Agora, toda a equipe sabe mais ou menos como as chamadas de vídeo funcionam. Em algumas áreas, ainda não escrevemos documentação, mas fizemos a tarefa de escrever documentação. Algum dia vamos escrever.


Agora, sobre a revisão de código quando não há tempo suficiente. , review code review. pull requests, code review . , , - , review. - — , — , code review .

. — , .

4.

. , , cross review . -, : , , , . , . , .

, Google Suite : , , , .

— - .


-, . , , Continuous Integration ..

- — , . — , . , , , , , , . -.

:

• , , .
• - .
• , .
• .

, .

• QA- — 10 , .
• , - Skyeng - . — , , .
• open source, , .

Telegram (@ax8080) facebook , .

, Call for Papers TeamLead Conf 2019, 25–26 , . , , , .

! , .