É possível que você diga: “A matriz de competências? Sério? ” Provavelmente você já ouviu algo sobre essa ferramenta e chegou a conclusões sobre o motivo de não usá-la. Talvez não fosse antes, ou como o argumento assassino "aconteceu historicamente ...".

De fato, essa é uma ferramenta completamente lógica e não uma nova que pode ser muito útil. E você pode implementá-lo de maneiras completamente diferentes, o que tentaremos provar para você em casos práticos de duas equipes diferentes - suporte técnico e desenvolvimento. Com base neles, você poderá estimar os custos de mão-de-obra (eles podem ser muito diferentes) e descobrir uma maneira mais adequada para você nessa direção.

E o que os dragões têm a ver com isso, explicaremos abaixo.



Este artigo é baseado no nosso com Konstantin Kaftan no TeamLead Conf . Konstantin Timlid, Departamento de Suporte Técnico do IPONWEB, e eu sou o escritor técnico da equipe de desenvolvimento do IPONWEB, envolvida na gestão do conhecimento.

A história é baseada em casos práticos do IPONWEB; portanto, primeiro conheça a empresa um pouco para que você possa entender se esse material está próximo de você.

Nosso RH, mediante solicitação de uma imagem legal de marketing que falará sobre nossa esfera, deu o seguinte:


De fato, o IPONWEB está desenvolvendo plataformas para clientes que se envolvem em publicidade online. Estamos trabalhando no modelo de software como serviço (ou melhor, plataforma como serviço). Temos muitos componentes: servidor HTTP, algoritmo de previsão, interface do usuário, relatórios. Lógica de negócios para cerca de 50 projetos escritos em Lua.

Também temos o carro-chefe BidSwitch, que começou como um spin-off. Estamos mais interessados ​​na integração de parceiros (lado da demanda, lado da oferta), por isso temos muitos registros. É o mesmo projeto, na mesma pilha, mas é grande o suficiente, possui detalhes e uma linha de suporte técnico dedicada, que a Konstantin lidera.

Por que escolhemos o nome "Dragons Live Here", o que isso significa? Tão cedo, nos mapas medievais, locais designados onde não se sabe o que está acontecendo - como o Terra Incognita. Há duas histórias sobre isso. O primeiro é sobre a estrutura das habilidades e habilidades que a equipe possui e, quanto maior a equipe, mais Terra Incognita existem; e falar sobre o segundo um pouco mais tarde.

Como chegamos aqui

Aconteceu que nós (Svetlana e Konstantin) não costumamos nos sobrepor no trabalho e que apenas enviamos solicitações sobre o mesmo assunto apenas no site da conferência . Então decidimos nos unir - parecia-nos que isso seria mais interessante para todos.

Perfis da equipe

Equipe de suporte técnico da Konstantin:

• Número de funcionários: 10 a 12 pessoas.
• Distância Timlid: curta - tudo é visível um ao outro.
• Um conjunto de habilidades: um conjunto muito diversificado de habilidades, competências, ferramentas de trabalho - isso se deve ao fato de termos uma maneira de extrair novas tarefas para nós de colegas de outras equipes e departamentos.
• Estilo de trabalho: roubar tarefas dos colegas. Isso é feito, primeiramente, para diluir a rotina de suporte, portanto, não é muito interessante analisar o mesmo tipo de solicitações dia após dia. Em segundo lugar, para ver quem está recebendo o quê e para delinear a direção do desenvolvimento.

Minha equipe de desenvolvimento Lua :

• Número de funcionários: 40 pessoas, mas o número está mudando constantemente;
• Distância com o líder da equipe: tempo suficiente devido às especificidades da estrutura de gestão da empresa (é matriz). Ou seja, o líder da equipe não vê todos os desenvolvedores diariamente e não sabe exatamente quais são suas tarefas diárias.
• Conjunto de habilidades: mais ou menos uniforme. Os desenvolvedores escrevem a lógica de negócios em Lua, mas, ao mesmo tempo, todos entram na unidade de negócios, ou seja, em uma união de projetos, por exemplo, se eles vendem espaços de anúncio ou compram anúncios como anunciante.
• Estilo de trabalho: tarefas específicas, fator de barramento. Frequentemente, o conhecimento está concentrado na cabeça dos indivíduos, nem toda a equipe é intercambiável.

São necessárias descrições de comando para deixar claro como nossas implementações de matriz diferem. Vamos tentar descrever como diferentes equipes foram em direção a isso, o que aconteceu no final, porque as estruturas, mensagens, objetivos, gatilhos e resultados finais foram um pouco diferentes.

Objetivos e gatilhos

Na equipe de suporte técnico:

• Quem está fazendo o que? Era necessário descobrir quando tudo ficou demais e deixou de caber na minha cabeça, quem estava fazendo o que, quem e o que era capaz e em que nível.
• Quais especialistas estão faltando? Como resultado, quem está faltando para concluir as tarefas, quem precisa ser treinado.
• Quais competências são comuns e necessárias para todos? O principal é entender na etapa de seleção o que é comum e obrigatório, o que precisa ser escrito para o RH no perfil do candidato ideal.

Na equipe de desenvolvimento, os objetivos e gatilhos eram ligeiramente diferentes. O incentivo inicial foi precisamente a gestão do conhecimento, porque, como já mencionado, temos um negócio muito específico - o Ad Tech. A probabilidade de alguém receber conhecimento pronto é bastante baixa e, ao mesmo tempo, para um desenvolvedor, o conhecimento das especificidades do negócio é muito importante.

No Dev Team, era necessário:

• Acelere os iniciantes . A inclusão de longo prazo dos desenvolvedores no projeto é uma grande dor. A integração levou cerca de seis meses, ou seja, mais de um período de teste, o que significa que treinaremos o desenvolvedor às nossas próprias custas.
• Entenda a estrutura do conhecimento, avalie lacunas no conhecimento , encontre pontos brancos, trace um plano de treinamento, trace caminhos de crescimento individuais.
• Devido à estrutura da matriz, é necessário distribuir os desenvolvedores de maneira mais uniforme entre as unidades e tarefas de negócios e não ofender ninguém. Ou seja, não envie todos os idosos para uma unidade de negócios.

Havia também um objetivo secundário - tornar o processo de análise de desempenho mais transparente e compreensível, a fim de formular objetivos em um único sistema de coordenadas.

Revisão de desempenho

A análise de desempenho é o padrão da nossa empresa. Uma vez a cada N meses, uma revisão de desempenho é realizada com cada funcionário na presença do funcionário, seu líder de equipe, usando um RH ou um notário público como árbitro. Na análise de desempenho, examinamos o que o funcionário fez das tarefas definidas, o que ele não obteve, se não obteve, por que, o que mais gostaríamos de alcançar, o que podemos oferecer. Depois disso, novas metas e objetivos são definidos, o próximo prazo é definido.

Na equipe de suporte, esse período é bastante curto, porque não há projetos grandes e com tempo estendido - são 3, no máximo, 4 meses. A equipe de desenvolvimento possui ciclos de revisão semestrais. Anteriormente, os prazos eram mais longos, simplesmente porque os desenvolvedores podem delinear melhor um roteiro. Em algumas outras equipes de desenvolvimento, por exemplo, a revisão de desempenho do front-end também ocorre a cada 3-4 meses. Talvez o intervalo não tenha nada a ver com o desenvolvimento ou o apoio da equipe, mas aconteceu conosco.

Por que você precisa de uma matriz de competências

Há um ano, nossa empresa passou por um período de intenso crescimento, havia mais pessoas, mais ferramentas, mais tarefas, mais. A certa altura, ficou claro que, sem os documentos certos, é difícil entender o que estava acontecendo. E encontramos uma solução para como sistematizar informações: sobre tarefas; ferramentas e habilidades; funcionários.

Por que você precisa de tudo isso? Você aprenderá sobre nossos casos práticos, mas poderá ter uma pergunta razoável - como entender que eu preciso disso?

Se você tiver problemas semelhantes aos que indicamos acima, ou seja, você não entende o conjunto completo de tarefas de seus desenvolvedores, introduza por muito tempo novos funcionários e outros problemas que já foram mencionados, provavelmente precisará disso.

Por onde começar

Por onde começar, diremos pelo nosso exemplo.

Na equipe de suporte técnico, identificamos as tarefas em que estamos envolvidos; tarefas decompostas em manipulações separadas; descobriu quais ferramentas um funcionário deveria saber para trabalhar em um setor específico.

Abaixo está um exemplo um pouco simplificado.


A equipe possui funcionários Batman, Joker, Flash e Ivanov e tarefas padrão:

• diagnóstico geral de tráfego;
• diagnóstico de tráfego de negócios;
• monitoramento de implantação;
• testando a integração de novos parceiros, DSP e SSP, compradores e vendedores.

Das ferramentas que temos:

• O uSIicer permite que você obtenha números de negociação muito detalhados;
• O Grafite fornece dados de status do sistema em tempo real;
• Google BigQuery (BQ) - nossos registros ficam lá;
• Grafana, que permite agregar métricas do Graphite, é conveniente colocar alertas, se necessário;
• Ul-ajustes na interface administrativa, que permitem alterar os parâmetros de tráfego para um parceiro, par comercial, data center etc.

Então descobrimos quem sabe o quê e até que ponto.


2 - um especialista que pode ensinar; 1 - significa que uma pessoa sabe mais ou menos; células vazias, para não ofender ninguém.

Resumimos em uma tabela:


As ferramentas que não são necessárias em uma determinada tarefa são destacadas em cinza. Por exemplo, para diagnóstico geral, não precisamos conhecer o BQ e o Grafana. O resultado foi uma imagem bastante interessante.

Nezhdanchiki (Suporte)

Surgiram várias pessoas inesperadas que ajudaram a entender:

• Quais dos colegas quais habilidades devem ser desenvolvidas para atraí-los para novas tarefas? (Indique a direção do desenvolvimento);
• Onde podem surgir problemas em caso de perda de funcionário?
• Quão adequado é o salário do funcionário para seu conjunto de tarefas?
• Quão bem a equipe é formada e treinada?

Mais adiante, abordaremos cada um dos pontos.

Vamos voltar para a mesa.



Formalmente, Batman está ocupado com diagnósticos gerais. A tabela mostra que o Coringa, se necessário, o substituirá bem, considerando que ele ainda é um especialista em UI - por que não? Ou seja, o Batman é substituível aqui.

O curinga geralmente é bem feito - ele é experiente em quase todos os lugares, exceto talvez implantar o monitoramento, mas isso pode ser ensinado.



É sabido que o Coringa passa seu tempo livre de maneira um tanto excêntrica e pode ficar sem emprego a qualquer momento. O que acontecerá então? Então tudo ficará triste com o diagnóstico do tráfego de negócios.

Além disso, não temos um especialista em BQ! Ou seja, é urgente puxar alguém, treinar. Por exemplo, você pode ensinar Batman BQ e Ivanov - Graphite.



Mesmo com um sistema de avaliação simplificado, você pode obter uma certa quantia para cada um dos funcionários, a fim de entender como ele é competente e versado. Essas estimativas lançaram outro inesperado.

Duas outras coisas interessantes são a quantidade total da equipe e sua pontuação média. A rigor, esses números por si só não são particularmente interessantes - a dinâmica de suas mudanças de mês para mês é interessante. Se, por algum motivo, o total começar a cair, provavelmente alguém foi embora e um funcionário fraco apareceu - um problema com a configuração, é necessário entrar em contato com o RH. Se a média começou a cair, isso significa que algo está errado com o treinamento - o líder da equipe e o único líder da equipe são os culpados.

É importante que, neste caso, seja uma ferramenta de líder de equipe que não seja mostrada aos funcionários, porque as avaliações são subjetivas.

Equipe de desenvolvimento

Tudo é um pouco mais democrático no Dev Team, ou talvez apenas tenhamos complicado nossa tarefa. A lista de habilidades na equipe de desenvolvimento é maior, embora a uniformidade das tarefas seja provavelmente maior.

Reunimos conselhos de 4 desenvolvedores experientes (incluindo líder de equipe e especialista em gerenciamento de conhecimento), fizemos brainstorming e analisamos tarefas e habilidades. Simplesmente andamos passo a passo e com base em nossos sentimentos pessoais, mas várias pessoas analisaram as tarefas, as colocaram em habilidades, formaram uma lista.

No início, era uma lista, depois foi estruturada em habilidades mais universais, que incluem codificação e habilidades de negócios separadamente, porque para nossos desenvolvedores essa é uma parte importante. E a partir dessa lista de habilidades já formadas na matriz.

A primeira iteração da matriz não incluiu as chamadas soft skills, ou seja, o que não pode ser chamado de hard skills. Isso é algo relacionado ao trabalho diário e até parte de habilidades críticas, incluindo: planejamento; comunicação com a equipe; a capacidade de gerenciar o processo de desenvolvimento em mini-grupos ou por si mesmo; capacidade de formular requisitos, por exemplo, durante uma revisão de código.

Não incluímos imediatamente todas essas habilidades, porque não entendemos como avaliá-las com precisão.

Na segunda iteração, eles entraram no sistema de avaliação:

• decomposição de tarefas e tudo relacionado a ela;
• Código de documentação e auto-documentação
• a capacidade de se comunicar com o gerente do projeto, isto é, de entender o que ele está dizendo e de colocar as perguntas necessárias por sua vez;
• a capacidade de formular corretamente comentários sobre revisões de código etc.

A propósito, sobre soft skills em apoio. O fato é que as habilidades sociais da equipe de desenvolvimento exigem uma avaliação separada. No entanto, são necessárias qualidades pessoais desejáveis apenas para o desenvolvedor da equipe de suporte. Se uma pessoa foi contratada, ela já a possui por padrão.

No desenvolvimento, abandonamos o próprio conceito de "soft skills" e o chamamos de habilidades universais. Eles não incluem, por exemplo, o conhecimento do idioma inglês ou o fato de você não enfurecer sua equipe - isso não ocorre porque está mais próximo das habilidades sociais e descreve a natureza de uma pessoa. Avaliamos habilidades em algum lugar à beira e, portanto, criamos esse nome - habilidades universais .

Quando a lista de habilidades estava pronta, nós as avaliamos usando uma pesquisa contínua. Realizamos um exame real no qual algumas das perguntas sugeriram uma resposta definitiva e algumas discutiram situações de trabalho: "O que devo fazer se alguém atrasa ou não faz alguma coisa?", "Como você implementaria essa ou aquela funcionalidade no projeto?" . Isso nos ajudou muito, porque essa parte das perguntas me permitiu conversar com um grande número de desenvolvedores.

Em seguida, classificamos os desenvolvedores em uma escala de 1 a 3 para cada habilidade.

Aquelas habilidades que não pudemos avaliar com a ajuda da pesquisa inicial, avaliamos com a ajuda de colegas (peers), ou seja, eles pediram para avaliar colegas. Naquela época, não tínhamos líderes de grupo, caso contrário, eles poderiam ter feito isso.

Essa matriz se parece com isso.



Obviamente, não foi possível encaixar tudo na imagem; portanto, algumas coisas, por exemplo, correlações e o perfil dos desenvolvedores não são claras aqui. Mas, mesmo assim, você pode avaliar aproximadamente o que acontece e ver quão claramente é e o que você pode medir.

As cores são consistentes com a nota. As mesmas métricas foram deduzidas como na equipe de suporte - média total e várias em habilidades.

Vamos prestar atenção no Dev8. Da tabela, verifica-se que é como se o primeiro candidato a demissão. Mas, primeiro, ele tem conhecimento específico em uma das posições, por isso precisamos dele. Mais importante, porém, esta tabela não é uma ferramenta de disparo . Também vou contar sobre isso, não começamos tudo por isso.

Média de habilidades - este é o trabalho, cujos resultados devem ser formados em um plano de como aumentar a habilidade. Ou seja, se os desenvolvedores não sabem de algo, isso não é problema deles. Isso significa que não lhes fornecemos informações suficientes e, em geral, o conhecimento de algumas das habilidades geralmente não é suficiente na empresa. Você precisa escrever a documentação ou criar algum tipo de playground para que eles possam praticar, ou comprar algum tipo de curso externo para que eles possam aprender, conduzir uma Sessão de Compartilhamento de Conhecimento, enviá-los para aprender um com o outro, trabalhar juntos por um tempo, inclua a pessoa em outro projeto. Pode haver diferentes opções para o compartilhamento de conhecimento. O ponto principal é que você deve primeiro realizar um evento e só depois falar sobre a dinâmica.

É importante observar que, como nossa empresa possui uma estrutura matricial, nem todos os desenvolvedores precisam de algumas habilidades. Eles os receberão quando concluirem a tarefa associada a essa habilidade. Caso contrário, não faz sentido, especialmente se a habilidade não estiver incluída na lista crítica. Por exemplo, em alguma parte dos projetos não há uPredict, essa não é uma habilidade crítica. Em geral, essa abordagem nos ajudou a formular quais habilidades são essenciais e quais não são e o que um especialista pode recuperar quando tiver uma tarefa tão prática.

Outro ponto importante sobre a classificação. Inicialmente cometemos um erro, o que provocou mais do que a resistência da equipe - não verbalizamos o valor das classificações 1, 2 e 3. Eles estavam na nossa cabeça no nível da intuição, mas não podíamos responder por que um desenvolvedor conseguiu 1, e o segundo - 2. Os desenvolvedores compartilharam os resultados da propagação entre si e isso provocou conflitos. Diferentemente do grupo de suporte, relatamos classificações pessoais mediante solicitação, mas não estranhos.

Você precisa definir e transmitir isso claramente a todos, por exemplo, que no conhecimento de Lua a pontuação é:

• 1 - significa que o desenvolvedor conhece todos os operadores básicos, sabe trabalhar com estruturas de dados e escrever classes de funções;
• 2 - sabe como organizar o código em bibliotecas, trabalha consistentemente com eles ao longo do projeto e sabe o que são metatables;
• 3 - conhece as especificidades da empresa e projetos, por exemplo, quais são as corotinas (as especificidades de como nosso servidor trabalha com Lua), como o código C ++ funciona com o código Lua, quais restrições ele impõe, como é interpretado, código compilado, como nosso compilador JIT.

Então você pode decompor cada habilidade, porque em algum lugar no nível da intuição você já a possui.

Nota para si mesmo:

• Verbalize o sistema de classificação, mesmo que você não mostre a ninguém.
• Nos estágios iniciais, tente incluir desenvolvedores experientes. Você sabe quem pode ter a maior resistência, inclua-os imediatamente no trabalho. Remova todas as objeções com antecedência, como é feito nas vendas.

Como implementar

Quando a matriz principal estava pronta, na equipe de desenvolvimento, anexamos métricas a ela . Basicamente, foi a porcentagem de classificações máximas de habilidades, o que permite que você dê uma nota ao desenvolvedor.

Além de avaliações de habilidades individuais, precisávamos classificar os desenvolvedores. Tivemos as notas A, B e C - algo como junior, middle, senior. No departamento de TI, júnior, médio e sênior, ele já está cheio de significado, no qual, entre outras coisas, a experiência de trabalho é investida. , . A, B C — . « » .

— .

, . , , , , .

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

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

Estojos

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

E isso é tudo! 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

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

, HR, , -, , -, , , -, HR - . HR , , .

• , .

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

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .