Em 26 de abril, na conferência
KnowledgeConf 2019 , foi entregue o relatório “Revisão de desempenho e identificação de conhecimento secreto”. Normalmente, falamos sobre tecnologia, no entanto, para se desenvolver como empresa, estamos longe de fazer exatamente isso. Esta apresentação, dedicada aos engenheiros e seu desenvolvimento, é um bom exemplo disso. Se você é um líder de equipe ou pensa em como garantir o crescimento dos funcionários em uma equipe, este artigo (e o próprio relatório) pode ser útil.
Por tradição, temos o prazer de apresentar um
vídeo com o relatório (50 minutos, muito mais informativo que o artigo), e abaixo está o seu aperto em forma de texto, enriquecido com alguns detalhes que não foram ouvidos no próprio relatório.
Por que análise de desempenho?
Antes da Flant, eu era o CTO da empresa de desenvolvimento. Queria que a equipe crescesse, fosse capaz de resolver tarefas cada vez mais complexas e que os funcionários melhorassem suas habilidades. E para isso, foram necessárias duas coisas:
- Regras de crescimento transparente.
- Feedback.
Era necessário obter algumas regras pelas quais um funcionário pudesse se desenvolver na empresa e pelas quais era possível fornecer feedback oportuno para ajudar com os problemas ao longo do caminho.
É fácil construir uma carreira?
Como se viu, não. Mesmo se você tiver descrições de cargos de um funcionário de nível superior, não poderá usar apenas um conjunto de palavras-chave e dizer que essas são as etapas necessárias para aprimorar sua carreira. Se você disser a um funcionário: "Aprenda Symfony 4, PostgreSQL e MySQL", isso não ajudará muito. Não ensine a ele
todo o MySQL! Os detalhes são importantes, portanto, alguns meios de medir as habilidades de uma pessoa serão necessários ... algo como uma
régua .
Imagine uma régua, mas em vez de divisões, ela possui níveis qualitativos de habilidade que podem ser distinguidos naturalmente. Se tivéssemos essa linha, poderíamos vincular tarefas reais, experiência real e materiais de treinamento específicos a ela. Então
Infelizmente, não: na prática, essa linha acaba sendo um tópico separado para as “guerras sagradas”, pois é impossível dizer com precisão matemática se uma pessoa sabe como implementar lógica de negócios complexa ou não. Mas há boas notícias: na mesma prática, a
precisão matemática não é tão necessária . Você pode usar o método de avaliação de especialistas: para dar ao funcionário mais experiente e mais imerso na situação a oportunidade de tomar uma decisão sobre pertencer ao nível de habilidades e, a partir disso, já desenvolver.
Temos de fechar os olhos à baixa precisão, à escalabilidade medíocre do método e muito mais, mas, ao mesmo tempo, podemos admitir que esse método lida muito bem com sua tarefa. Não é só isso - até hoje é muito usado onde. Freqüentemente, um líder de equipe pode muito bem agir como um “especialista” em sua equipe, e isso é aprox.
É fácil dar feedback?
Parece lógico que você precise se reunir periodicamente (por exemplo, uma vez por trimestre) com um funcionário e fornecer feedback. E tente organizá-lo para que o processo seja cheio de significado, e não um culto à carga. Parece uma boa ideia seguir nossas “linhas” com habilidades:
... organize a partir deles um espaço N-dimensional e diga à pessoa onde ele está nesse espaço, depois concorde sobre onde ele seguirá:
É difícil imaginar o espaço N-dimensional, para que possamos usar uma tabela para esses fins. Linhas serão nossas habilidades e, em colunas - o nível de desenvolvimento da habilidade. Se realizarmos duas dessas sessões, podemos ver aproximadamente a seguinte figura:
... que, ao que parece, nos convencerá da fidelidade do caminho escolhido e das ferramentas escolhidas - afinal, as pessoas estão se desenvolvendo. E quando a massa crítica muda, você pode aumentar o salário do funcionário e alterar a placa de identificação para sua posição, por exemplo, dizendo que ele agora é desenvolvedor PHP intermediário.
Mas como tudo acontece na prática?
Em teoria, isso parece legal e transparente. Fiz tentativas de iniciar o mecanismo dessa forma - e elas eram ... francamente, não de verdade. Para mim, as tentativas de meus colegas no workshop também não foram inspiradoras. Os principais problemas são:
- Nem todos os funcionários respondem igualmente bem ao feedback . É fácil encontrar-se em uma situação em que a questão da falta de autoridade surge acentuadamente e, nessas condições, é difícil fazer uma avaliação especializada.
- Destacar as principais habilidades usadas para avaliá-las acaba sendo uma história não trivial na prática - especialmente se você é uma pessoa do arado. É difícil ignorar os detalhes e encontrar um equilíbrio entre precisão e generalização.
- A presença de tal “feedback” e “escada” não se correlacionou com a motivação dos funcionários. Se eles se desenvolveram, são mais contrários ao sistema do que graças a ele.
A necessidade de Flant de avaliar o desempenho
Quando cheguei à Flant, vi vários problemas que me fizeram pensar na Análise de Desempenho, a saber:
- Os engenheiros não entendiam por que deveriam crescer, em que direção deveriam se desenvolver. Às vezes, essa pergunta era formulada, mas uma resposta clara podia ser obtida muito raramente.
- Os engenheiros não sentiram envolvimento na empresa, não sentiram o retorno sobre ela e sua participação em sua carreira.
- A empresa iniciou um crescimento ativo e, nessas condições, é especialmente necessário criar mecanismos compreensíveis e funcionais para transformar novatos em engenheiros e gerentes experientes.
Portanto, eu realmente queria destacar as habilidades necessárias para cada uma das posições e criar condições para o crescimento da carreira.
Mas nem tudo era tão óbvio ...
Procurando uma lista de habilidades
Aconteceu que ninguém pode destacar os requisitos para as habilidades dos engenheiros de DevOps e geralmente destacar quaisquer "níveis de habilidade". A descrição mais próxima dessa posição está no imortal Robert Heinlein:
Qualquer pessoa deve ser capaz de trocar fraldas, planejar invasões, abater porcos, construir prédios, controlar navios, escrever sonetos, manter contas, construir muros, colocar ossos <...>, programar computadores, cozinhar deliciosamente, lutar bem, morrer digno.
Ou seja, os líderes de equipe esperavam e formaram seu pessoal como engenheiros de fullstack, capazes de descobrir corretamente os detalhes da tarefa e resolver todos os problemas técnicos, e trazê-la para produção.
Claro, isso me inspirou. É ótimo trabalhar em uma empresa onde todos são lutadores universais, uma personalidade versátil e um excelente engenheiro! Foi ofuscado apenas pelo fato de que tudo parecia uma
enorme caverna escura com conhecimento secreto, o que é assustador de entrar . Eu não queria condenar os engenheiros a essas viagens.
Como você deve ter adivinhado, dezenas de tecnologias com centenas de nuances estavam escondidas. Como não limitamos nossos clientes a escolher a pilha tecnológica para suas aplicações, nosso engenheiro é confrontado com uma ampla variedade de bancos de dados, servidores de filas, estruturas e idiomas, ferramentas de diagnóstico, desenvolvimento e depuração, além de recursos de diferentes datacenters e plataformas.Nos últimos cinco anos, testemunhei uma mudança fundamental: se antes era quase considerada a norma quando o diretor técnico declarou: "Trabalhamos na plataforma X com o banco de dados Y e não trabalhamos em mais nada", agora algumas estações de serviço podem até deixar de lado controle de pilha, contando com microsserviços e o slogan (
bastante controverso ): "Se quebrar, é mais fácil reescrever tudo do zero".
Sob essas condições, compilar uma
lista de tecnologias para avaliar funcionários não é uma tarefa trivial. E mantê-lo constantemente atualizado é muito trabalhoso e difícil de organizar. Portanto, tentamos encontrar uma solução e queremos compartilhá-la.
Repensando o PR
Decidimos tentar um caminho diferente, mas primeiro, repensar nossas ações e expectativas. Ao lançar o Review, nós:
- ... tentou fazer medições de desempenho dos funcionários;
- ... conversei com eles;
- ... esperavam que, no final, se tornassem mais felizes, melhor compreendendo suas perspectivas e seu crescimento esperado na carreira.
Investimos cerca de um mês e meio para repensar esses pontos e, abaixo, vou contar o que aconteceu.
Avaliação de desempenho
Por acaso, olhei para algo assim na tentativa de entender o que pode estar errado aqui:
E em algum momento surgiu um pensamento interessante: um excesso de informação é retratado aqui. De fato, “divisões” específicas não são tão importantes - uma imagem pode ser simplificada para isso:
Estamos interessados na
velocidade do desenvolvimento, e não no fato de uma pessoa ter atingido um nível específico. Houve algum desenvolvimento? Muita gente aprendeu ou pouco? Isso é um indicador real!
Investigando os segredos da lista de habilidades
Antes, chegamos à conclusão de que a lista de habilidades é um conhecimento secreto para nós: os engenheiros são capazes de fazer algo, fazer algo todos os dias, mas é difícil formular exatamente o que.
Uma das maneiras de revelar o conhecimento secreto é “na esteira”, ou seja: consertar o que está acontecendo e depois analisá-lo.
Assim como podemos seguir as pegadas na floresta que esquilos, raposas e ursos são encontrados lá, tentaremos revelar conhecimento secreto ...
Projeto piloto
Timlid Peter concordou em participar do projeto piloto para lançar o Review em um formulário atualizado. Peter mergulhou nas idéias e planejamos reuniões com os funcionários. Como resultado da auto-preparação, Peter formulou esse feedback sobre um de seus engenheiros, Leonid:
Este é um exemplo de feedback de baixa qualidade: se você tivesse ouvido falar de si mesmo nessas formulações, dificilmente o ajudaria. Mesmo que tudo seja formulado com mais clareza no cabeçalho do timlid (o que não é totalmente um fato), registrar informações neste formulário não é muito útil, porque após seis meses esses "traços" não trarão nenhum benefício - mesmo o autor não se lembrará do que se trata.
Gostaríamos que o feedback fosse o mais objetivo possível, educado e, em vez disso, ajudasse a aprender mais um sobre o outro do que como um meio de "motivar".
Líder em treinamento de relações públicas
Como resultado, formulamos as seguintes regras para a preparação de relações públicas para líderes de equipe:
- Antes de cada revisão, você precisa alocar de meia hora a uma hora e meia para se preparar. É melhor preparar o dia anterior, e não no mesmo dia.
- Passe por todos os rastreadores (sistemas de tickets, mensageiros, sistemas de karma, etc.), mesmo que o líder seja muito preguiçoso e resista, apelando para sua bela memória. Veja as anotações de uma revisão anterior.
- Escreva vários pontos para discussão. Esses resumos devem conter:
- Fatos, com justificativa na forma de links para rastreadores;
- A atitude pessoal do revisor: uma explicação de por que ele (a) destacou (a) este item e o que é tão importante nele.
A propósito, postamos exemplos de palavras ruins e boas aqui .Processo PR
A revisão em si é
sempre em tempo integral . Apesar de trabalharmos remotamente, não há dúvida de qualquer revisão por meio de documentos / questionários / serviços. No nosso caso, a comunicação é realizada pelo Google Hangouts e há um líder de equipe, engenheiro, RH e, se necessário, outras partes interessadas.
Uma revisão passa por várias etapas:
- Fale sobre a distração para sintonizar uma conversa um com o outro.
- A história que uma pessoa fez bem , pela qual quero agradecer e explicar por que isso é importante. Afinal, queremos que esse bem seja feito ainda mais?
- Denuncie inequivocamente ruim : violação de acordos, disciplina e outras coisas que você considera imperdoáveis e indiscutíveis.
- Discuta incompreensível ou controverso de acordo com as seguintes regras:
- Identifique os fatos e a atitude pessoal em relação a esses fatos.
- Faça uma pergunta geral (como “O que você acha disso?”) Para obter mais informações do funcionário sobre o problema.
- Para fazer a pergunta: o funcionário acha que há um problema? Pode acontecer que, por algumas razões pessoais, ele não considere isso importante. Precisamos ter certeza de que ele compartilha nossa percepção.
- Para fazer a pergunta: o que exatamente o próprio empregado fará para resolver o problema?
- Se um funcionário não compartilhar seu problema, oferecer soluções desarticuladas - é altamente provável que ele não faça nada com ele. E não faz sentido pressioná-lo nessa situação - é melhor tentar entender por que esse é o caso.
- Peça feedback de um funcionário. Sua vida na empresa durante esse ciclo correspondeu às suas expectativas? Se você realmente foi capaz de criar um diálogo antes, então, nesse estágio, você receberá um feedback, e não um lamento arrastado, como costuma ser o caso.
- Fale sobre salário : você aumenta e, se não, o que especificamente precisa ser corrigido para aumentá-lo. A questão do salário é muito importante e complexa e, em geral, é o principal motivo para um funcionário participar da Análise de Desempenho. Suspeita-se que não faz sentido tentar iniciar alguns processos de revisão, se isso não afetar o salário, mas não for 100% ...
Total:
Resultados do primeiro ano
Uma análise dos registros acumulados durante o primeiro ano nos ajudou a:
- abrir o véu de sigilo da identidade de nossos engenheiros;
- reabastecer a base de conhecimento com instruções e informações que causam mais problemas aos funcionários;
- melhorar o clima em equipes.
Os engenheiros começaram
a crescer de maneira muito
mais tangível e rápida , eles tinham um entendimento da direção para construir sua carreira.
Outros momentos significativos:
- Os iniciantes começaram a resolver os problemas de uma maneira mais construtiva quando se adaptaram: os gerentes subitamente descobriram por si mesmos que podiam conversar com o recém-chegado sobre problemas ... e ele seria corrigido!
- Tornou-se mais claro que tipo de funcionários esperamos na empresa, portanto os requisitos para contratação foram ajustados.
- Tornou-se mais óbvio para os funcionários o que eles poderiam querer e quais perspectivas de desenvolvimento eles têm.
- Os esboços apareceram na matriz de competências e existe um mecanismo para sua constante atualização.
Retrato engenheiro
Pode parecer óbvio que um engenheiro, por exemplo, realmente ama o que está fazendo e gosta de trabalhar ... Enfim - aqui estão quatro habilidades que acabaram sendo as mais exigidas (por uma ampla margem):
Outras habilidades importantes foram:
Vamos tentar descobrir no segundo ano
Enquanto isso, um leitor
atento aos detalhes pode perceber que não medimos muito o desempenho ... Talvez, com o tempo, a lista de habilidades seja estabelecida e uma matriz adequada de competências seja formada, ou introduziremos outro sistema de classificação.
Além disso, agora estamos procurando maneiras de transmitir o treinamento para conduzir uma revisão entre os gerentes - ainda não temos uma solução pronta.
Uma questão complexa separada que não é tão fácil de formalizar é a relação entre o sistema de avaliação e a questão dos salários dos funcionários. Parece-nos que esse problema é diretamente determinado pelo modelo de negócios da empresa, e a solução para um negócio pode não ser muito adequada para outro. (
Já falamos sobre o nosso modelo no centro: somos construídos quase como uma franquia e, à medida que a eficiência e a competência da equipe aumentam, ela tem dinheiro para os salários.)
Vídeos e slides
Vídeo da apresentação (~ 50 minutos):
Apresentação do relatório:
PS
Você também pode estar interessado nas seguintes publicações:
Entre outros relatórios em nosso blog: