A questão de como avaliar a eficácia do processo de desenvolvimento existe tanto quanto o próprio desenvolvimento. Muitas vezes, os desenvolvedores podem aderir à ideia de que você só precisa escrever um código de qualidade, mas todas essas otimizações, comícios, rastreamento de atividades e outros são um capricho gerencial. Os líderes, por sua vez, acreditam que, acima de tudo, é um produto e, na verdade, temos um negócio aqui, não um clube de interesses: por isso é impossível ficar sem métricas. Mas qual é a importância das métricas?
No início de setembro, realizamos uma reunião para gerentes de desenvolvimento e conversamos sobre isso com pessoas de
Plesk, Avito, Dodo Pizza, Tinkov, Agima, CIAN, Yandex. Verticais, DocDoc - bem, não esquecemos de nós mesmos. Abaixo está um aperto do que nossos convidados falaram.
Em uma equipe pequena, as métricas não são tão importantes
Quando você gerencia uma equipe de cinco a dez pessoas, você se torna uma unidade de combate acordada, um coletivo no qual todos conhecem todos. Os desenvolvedores passam tempo juntos, trabalham lado a lado e geralmente se comunicam fora do trabalho. Não é difícil fazer parte dessa equipe do STO: o líder se torna um membro de pleno direito da equipe e tem a oportunidade de se comunicar diretamente com cada pessoa. Todos os conflitos, problemas ou dificuldades que uma equipe pode encontrar são claramente visíveis e praticamente não há barreira administrativa entre a estação de serviço e seus subordinados.
Gerenciar equipes compactas em termos de avaliação de sua eficácia é muito mais simples: como não há muitos participantes no fluxo de trabalho, quaisquer soluções ou métodos ineficazes são imediatamente visíveis. E os desenvolvedores entram em contato facilmente com os mais velhos, porque se comunicam com ele diariamente.
Com uma centena de desenvolvedores, tudo é muito mais complicado
Assim que o tamanho da equipe aumenta várias vezes e não é de 5 a 10, mas de 50 a 100 pessoas, a situação muda drasticamente. Agora, o líder não pode se comunicar pessoalmente com todos, e precisamos de métricas claras e eficazes.
A primeira e mais óbvia solução são os gerenciadores de tarefas e uma análise do número de tarefas fechadas. O JIRA e ferramentas similares podem fornecer uma matriz específica de dados úteis. Por exemplo, uma análise de tarefas fechadas revelará a presença de alguns problemas sem comunicação pessoal com os desenvolvedores.
Por exemplo, quando as métricas foram formadas no DocDoc, elas inicialmente pararam em até sete indicadores, mas no final havia apenas três:
- conveniência / prazer do trabalho ;
- a proporção do prometido e o tempo gasto na tarefa;
- tempo do ciclo de vida da tarefa.
A primeira métrica é subjetiva e sinalizou a situação na equipe e no microclima como um todo. O segundo e o terceiro relacionavam-se diretamente ao desenvolvimento e refletiam parâmetros importantes na época: muitas equipes tiveram problemas para cumprir os prazos.
Outro canal para obter informações são os questionários, que também não devem ser evitados. Por exemplo, toda a equipe de desenvolvimento do Skyeng é composta por funcionários distribuídos e, devido à diferença de fuso horário, é difícil conversar pessoalmente pessoalmente. Para nós, as pesquisas periódicas no formato online foram a saída. Eles não demoram muito tempo, um funcionário pode consultá-los quando for conveniente para ele, e para isso você não precisa reservar slots no calendário ou em uma sala de reuniões no escritório de Moscou.
O problema é que os desenvolvedores nem sempre falam sobre o que os preocupa a tempo. Essas informações podem ser obtidas apenas por meio de comunicação pessoal, para que um bom CTO tenha um "horário de funcionamento" ou até mesmo uma conversa deve ser planejada com todos os líderes de equipe e desenvolvedores em sua apresentação.
Qualquer desenvolvedor deve ter o direito de marcar uma consulta com um gerente superior, ignorando o próprio líder da equipe . Caso contrário, você enfrentará a conservação dos problemas e o silêncio deles.
Comunicação com o cliente
Não importa se você trabalha em uma empresa de mercearia ou terceirização. Qualquer desenvolvimento sempre tem um cliente: interno ou externo. Em algumas empresas, é expresso explicitamente, em outras - não, mas sempre há um cliente.
O feedback do cliente é uma informação bastante importante, pois pode revelar problemas que não são visíveis de dentro e observar o processo de desenvolvimento de fora. Se o cliente está completamente satisfeito e não pode fazer nenhum comentário sobre sua interação com os desenvolvedores, nesta frente tudo está indo com mais ou menos sucesso e os problemas internos não se espalham pela equipe.
Por outro lado, é possível um cenário em que, ao que parece, o desenvolvimento está em andamento, mas, de acordo com a lembrança do cliente, é mais uma bagunça do que um produto: falha no cumprimento de prazos, problemas de comunicação, interpretação incorreta do TK. Qualquer um desses comentários é um motivo sério para aprofundar nos processos da equipe e descobrir se tudo está realmente assim. Se as palavras do cliente forem confirmadas, você precisará procurar o que causou os problemas.
Os resultados do teste podem ser inesperados. Assim, por exemplo, algumas das questões surgem devido à motivação insuficiente dos funcionários: é difícil para qualquer pessoa dar o melhor de si todos os dias e não receber incentivos para o trabalho. E, neste caso, não confunda “encorajamento” com “remuneração” (o segundo é salário). Nesse caso, incentivos materiais e não materiais são adequados: bônus, bônus, alguns eventos corporativos e fichas para os funcionários. Mesmo a substituição de equipamentos ou o
atendimento de solicitações “opcionais” dos subordinados podem mostrar aos desenvolvedores que seu trabalho é valioso e é atendido. E isso, por sua vez, aumentará o "moral" e a produtividade.
Particularmente cuidadoso nessa situação é tratar os funcionários de "apoio" que, devido a seus próprios esforços malucos, fecham os fakaps de outros membros da equipe. Existem pessoas em qualquer equipe e, mesmo que a equipe como um todo esteja indo bem, não se esqueça da contribuição desses funcionários. Porque se "queimarem", tudo voará para o abismo.
Conclusão: as métricas são inúteis sem falar com as pessoas
A idéia principal de todos os discursos sobre o tema das métricas: a verdade pode ser alcançada apenas em conversas diretas. As métricas permitem identificar quaisquer problemas no nível estatístico, mas é importante lembrar que eles mostram apenas as consequências.
- As métricas não lhe dirão que um troll começou na equipe que envenena a situação na equipe ou que eles colocaram o cara verde na equipe, que se imaginava o melhor líder de equipe que já existiu neste planeta.
- As métricas não informarão que a ferramenta introduzida recentemente não apenas prejudica todos os desenvolvedores, mas após a última atualização, também é um pedaço do código de alguém que é ineficaz em todos os sentidos.
- As métricas não informam que, no estágio de comunicação com o cliente e discussão da TK, é criada uma confusão que a equipe, em vez do "bonde" condicional, começou a criar um "bonde a partir de um pedaço de pão".
As métricas podem mostrar apenas o fato de um problema.Mas qual é a sua essência - você precisa entender no terreno. Entenda através de conversas, reuniões, pesquisas, ou seja, através da interação direta com pessoas vivas. E as métricas mostrarão onde, quando e com quem você precisa conversar, mas nada mais.
ps Na mitap, eles compartilharam seus pontos de vista:
* Sergey Lystsev (Plesk);
* Egor Tolstoi (Avito);
* Alexander Andronov (Pizza Dodo);
* Andrey Shelyokhin (Tinkov);
* Alexey Parshukov (Skyeng, ex-DocDoc);
* Andrey Ryzhkin (Agima);
Alexey Chekanov (TsIAN);
* Danila Shtan (Yandex.Vertical, ex-Tochka)
Muito obrigado!
pps Se você estiver interessado em ouvir / assistir a versão completa do mitap (também inclui questões de motivação financeira, contratação, nível de imersão em tecnologia do CTO, etc.) - escreva em um documento pessoal. O registro acabou não sendo de alta qualidade, então não começamos a publicá-lo: mas estamos sempre prontos para compartilhá-lo com aqueles que realmente precisam.