Es posible que usted diga: “¿La matriz de competencias? ¿En serio? Lo más probable es que ya haya escuchado algo sobre esta herramienta, e incluso haya llegado a una conclusión por la que no desea usarla. Tal vez simplemente no era antes, o cómo el argumento asesino "sucedió históricamente ...".

De hecho, esta es una herramienta completamente lógica y no nueva que puede ser muy útil. Y puede implementarlo de maneras completamente diferentes, que trataremos de demostrarle en casos prácticos de dos equipos diferentes: soporte técnico y desarrollo. Con base en ellos, usted mismo podrá estimar los costos de mano de obra (pueden ser muy diferentes) y descubrir una forma más adecuada para usted en esta dirección.

Y qué tienen que ver los dragones con eso, lo explicaremos debajo del corte.



Este artículo está basado en el nuestro con Konstantin Kaftan en TeamLead Conf . Konstantin Timlid, Departamento de Soporte Técnico de IPONWEB, y yo soy el escritor técnico del equipo de desarrollo de IPONWEB, dedicado a la gestión del conocimiento.

La historia se basa en casos prácticos de IPONWEB, así que primero conozca un poco a la compañía para que pueda comprender si este material está cerca de usted.

Nuestro departamento de recursos humanos, a pedido de una imagen de marketing genial que contará sobre nuestra esfera, dio esto:


De hecho, IPONWEB está desarrollando plataformas para clientes que se dedican a la publicidad en línea. Estamos trabajando en el modelo de Software como Servicio (o mejor dicho, Plataforma como Servicio). Tenemos muchos componentes: servidor HTTP, algoritmo de predicción, interfaz de usuario, informes. Lógica empresarial para unos 50 proyectos escritos en Lua.

También tenemos el buque insignia BidSwitch, que comenzó como un spin-off. Estamos más interesados ​​en la integración de socios (del lado de la demanda, del lado de la oferta), por lo que tenemos muchos registros. Este es el mismo proyecto, en la misma pila, pero es lo suficientemente grande, tiene detalles y una línea de soporte técnico dedicada, que Konstantin encabeza.

¿Por qué elegimos el nombre "Dragons Live Here"? ¿Qué significa esto? Así que anteriormente en los mapas medievales se designaron lugares donde no se sabe lo que está sucediendo, como Terra Incognita. Hay dos historias sobre esto. El primero es sobre la estructura de las habilidades y destrezas que tiene el equipo, y cuanto más grande es el equipo, más Terra Incognita hay; y hablamos del segundo un poco más tarde.

Como llegamos aqui

Dio la casualidad de que nosotros (Svetlana y Konstantin) no nos superponíamos a menudo en el trabajo, y que habíamos presentado solicitudes sobre esencialmente el mismo tema solo desde el sitio web de la conferencia . Luego decidimos unirnos, nos pareció que sería más interesante para todos.

Perfiles de equipo

Equipo de soporte técnico de Konstantin:

• Personal: 10-12 personas.
• Distancia tímida: corta: todo es visible el uno al otro.
• Un conjunto de habilidades: un conjunto muy diverso de habilidades, competencias, herramientas de trabajo; esto se debe al hecho de que tenemos una forma de extraer nuevas tareas para nosotros de colegas de otros equipos y departamentos.
• Estilo de trabajo: robar tareas de colegas. Esto se hace, en primer lugar, para diluir la rutina de soporte, por lo tanto, no es muy interesante analizar el mismo tipo de solicitudes día tras día. En segundo lugar, para ver quién obtiene qué y para delinear la dirección del desarrollo.

Mi equipo de desarrollo de Lua :

• Personal: 40 personas, pero el número cambia constantemente;
• Distancia con el líder del equipo: lo suficientemente largo debido a los detalles de la estructura de gestión en la empresa (es matriz). Es decir, el líder del equipo no ve a todos los desarrolladores a diario y no sabe exactamente cuáles son sus tareas diarias.
• Conjunto de habilidades: más o menos uniforme. Los desarrolladores escriben lógica de negocios en Lua, pero al mismo tiempo, todos ingresan a la unidad de negocios, es decir en una unión de proyectos, por ejemplo, si venden espacios publicitarios o compran anuncios como anunciantes.
• Estilo de trabajo: tareas específicas, factor de bus. A menudo, el conocimiento se concentra en las cabezas de los individuos, no todo el equipo es intercambiable.

Se necesitan descripciones de comandos para dejar en claro cómo difieren nuestras implementaciones de matrices. Intentaremos describir cómo los diferentes equipos se dirigieron a esto, lo que sucedió al final, porque las estructuras del equipo, el mensaje, los objetivos, los factores desencadenantes y los resultados finales fueron algo diferentes.

Objetivos y disparadores

En el equipo de soporte técnico:

• ¿Quién hace qué? Era necesario saber cuándo todo se volvió demasiado y dejó de encajar en mi cabeza, quién estaba haciendo qué, quién sabía qué y a qué nivel.
• ¿Qué especialistas faltan? Como resultado, quién falta para completar las tareas, quién necesita capacitación.
• ¿Qué competencias son comunes y necesarias para todos? Lo principal es comprender en la etapa de selección lo que es común y obligatorio, lo que debe escribirse para RR. HH. En el perfil del candidato ideal.

En el equipo de desarrollo, los objetivos y los desencadenantes fueron ligeramente diferentes. El incentivo inicial fue precisamente la gestión del conocimiento, porque, como ya se mencionó, tenemos un negocio muy específico: Ad Tech. La probabilidad de que alguien venga con conocimiento ya hecho es bastante baja, y al mismo tiempo, para un desarrollador, el conocimiento de los detalles del negocio es muy importante.

En Dev Team fue necesario:

• Acelera la incorporación de principiantes . La inclusión a largo plazo de desarrolladores en el proyecto es un gran dolor. La incorporación tardó unos seis meses, es decir, más que un período de prueba, lo que significa que capacitaremos al desarrollador por nuestra cuenta.
• Comprender la estructura del conocimiento, evaluar las brechas en el conocimiento , encontrar puntos blancos, esbozar un plan de capacitación, esbozar caminos de crecimiento individuales.
• Debido a la estructura matricial, es necesario distribuir de manera más uniforme a los desarrolladores entre las unidades de negocio y las tareas, y no ofender a nadie. Es decir, no envíe a todas las personas mayores a una unidad de negocios.

También había un objetivo secundario: hacer que el proceso de revisión del desempeño sea más transparente, comprensible, para formular objetivos en un solo sistema de coordenadas.

Revisión de desempeño

La evaluación del desempeño es el estándar de nuestra compañía. Una vez cada N meses, se lleva a cabo una revisión de desempeño con cada empleado en presencia del empleado, el líder de su equipo, utilizando un RRHH o un notario público como árbitro. En la evaluación del desempeño, examinamos qué hizo el empleado con respecto a las tareas establecidas, qué no tuvo éxito, si no tuvo éxito, por qué, qué más nos gustaría lograr, qué podemos ofrecer. Después de eso, se establecen nuevas metas y objetivos, se establece la próxima fecha límite.

En el equipo de soporte, este período es bastante corto, ya que no hay proyectos grandes y prolongados, esto es 3, máximo 4 meses. El equipo de desarrollo tiene ciclos de revisión semestrales. Anteriormente, los plazos eran más largos, simplemente porque los desarrolladores pueden delinear mejor un mapa de ruta. En algunos otros equipos de desarrollo, por ejemplo, la revisión de rendimiento de front-end también ocurre cada 3-4 meses. Quizás el intervalo no tiene nada que ver con el desarrollo o el apoyo del equipo, pero sucedió con nosotros.

¿Por qué necesitas una matriz de competencias?

Hace un año, nuestra empresa atravesó un período de crecimiento intensivo, había más personas, más herramientas, más tareas, más. En un momento, quedó claro que sin los documentos correctos es difícil entender lo que estaba sucediendo. Y encontramos una solución a cómo sistematizar la información: sobre tareas; herramientas y habilidades; empleados

¿Por qué necesitas todo esto? Aprenderá sobre nuestros casos prácticos, pero puede tener una pregunta razonable: ¿cómo entender que la necesito?

Si tiene problemas similares a los que hemos indicado anteriormente, es decir, no comprende el conjunto completo de tareas de sus desarrolladores, demasiado tiempo presenta nuevos empleados y otros problemas que ya se han mencionado, entonces probablemente necesite esto.

Por donde empezar

Por dónde empezar lo diremos con nuestro ejemplo.

En el equipo de soporte técnico, nosotros: identificamos las tareas en las que estamos involucrados; tareas descompuestas en manipulaciones separadas; descubrió qué herramientas debe saber un empleado para trabajar en un sector en particular.

A continuación se muestra un ejemplo ligeramente simplificado.


El equipo tiene empleados Batman, Joker, Flash e Ivanov, y tareas estándar:

• diagnóstico general de tráfico;
• diagnóstico de tráfico de negocios;
• monitoreo de despliegue;
• probando la integración de nuevos socios, tanto DSP como SSP, tanto compradores como vendedores.

De las herramientas que tenemos:

• uSIicer le permite obtener números comerciales muy detallados;
• Graphite proporciona datos de estado del sistema en tiempo real;
• Google BigQuery (BQ): nuestros registros viven allí;
• Grafana, que le permite agregar métricas de Graphite, es conveniente poner alertas si es necesario;
• Ajustes ul en la interfaz de administración, que le permiten cambiar los parámetros de tráfico para un socio particular, par comercial, centro de datos, etc.

Luego descubrimos quién sabe qué y en qué medida.


2 - un experto que puede enseñar; 1 - significa que una persona sabe más o menos; celdas vacías en su lugar, para no ofender a nadie.

Resumimos en una tabla:


Las herramientas que no son necesarias en una tarea determinada se resaltan en gris. Por ejemplo, para el diagnóstico general, no necesitamos saber BQ y Grafana. El resultado fue una imagen bastante interesante.

Nezhdanchiki (Soporte)

Surgieron varias personas inesperadas que ayudaron a comprender:

• ¿Cuál de los colegas qué habilidades se deben extraer para atraerlos a nuevas tareas? (Indicar la dirección del desarrollo);
• ¿Dónde pueden surgir problemas en caso de pérdida del empleado?
• ¿Qué tan adecuado es el salario del empleado para su grupo de tareas?
• ¿Qué tan bien está formado y capacitado el equipo?

Nos detendremos en cada uno de los puntos más adelante.

Volvamos a la mesa.



Formalmente, Batman está ocupado con diagnósticos generales. La tabla muestra que el Joker, si es necesario, lo reemplazará bien, dado el hecho de que todavía es un experto en IU, ¿por qué no? Es decir, Batman es reemplazable aquí.

El bromista generalmente está bien hecho: es inteligente en casi todas partes, excepto quizás desplegar monitoreo, pero esto se puede enseñar.



Es bien sabido que el Joker pasa su tiempo libre de manera algo excéntrica y puede quedarse sin trabajo en cualquier momento. ¿Qué pasará entonces? Entonces todo será triste con el diagnóstico de tráfico de negocios.

¡No solo eso, no tenemos un experto en BQ! Es decir, es urgente levantar a alguien, entrenar. Por ejemplo, puedes enseñar Batman BQ e Ivanov - Graphite.



Incluso con un sistema de evaluación tan simplificado, puede obtener una cierta cantidad para cada uno de los empleados a fin de comprender cuán competente y versado es. Estas estimaciones arrojaron otra inesperada.

Otras dos cosas interesantes son la cantidad total del equipo y su puntaje promedio. Estrictamente hablando, estas cifras por sí solas no son particularmente interesantes: la dinámica de sus cambios de mes a mes es interesante. Si por alguna razón el total comenzó a caer, lo más probable es que alguien se fuera y viniera un empleado débil: un problema con la configuración, debe comunicarse con Recursos Humanos. Si el promedio comenzó a caer, significa que algo está mal con el entrenamiento: el líder del equipo y solo el líder del equipo tienen la culpa.

Es importante que en este caso sea una herramienta de liderazgo de equipo que no se muestra a los empleados, porque las evaluaciones son subjetivas.

Equipo de desarrollo

Todo es un poco más democrático en Dev Team, o tal vez simplemente complicamos nuestra tarea. La lista de habilidades en el equipo de desarrollo es mayor, aunque la uniformidad de las tareas es probablemente mayor.

Recopilamos consejos de 4 desarrolladores experimentados (incluido el líder del equipo y el especialista en gestión del conocimiento), intercambiamos ideas y analizamos tareas y habilidades. Simplemente caminamos paso a paso y de acuerdo con nuestros sentimientos personales, pero varias personas analizaron las tareas, las expusieron según sus habilidades y formaron una lista.

Al principio era una lista, luego se estructuraba en habilidades más universales, que incluían codificación y habilidades comerciales por separado, porque para nuestros desarrolladores esta es una parte importante. Y de esta lista de habilidades que ya formaron la matriz.

La primera iteración de la matriz no incluía las llamadas habilidades blandas, es decir, lo que no se puede llamar habilidades duras. Esto es algo relacionado con el trabajo diario, e incluso parte de las habilidades críticas, que incluyen: planificación; comunicación con el equipo; la capacidad de gestionar el proceso de desarrollo en minigrupos o solo; capacidad de formular requisitos, por ejemplo, durante una revisión de código.

No incluimos de inmediato todas estas habilidades, porque no entendíamos cómo evaluarlas con precisión.

En la segunda iteración, ingresaron al sistema de evaluación:

• descomposición de tareas y todo lo relacionado con ella;
• Documentación y código autodocumentado
• la capacidad de comunicarse con el gerente del proyecto, es decir, entender lo que está diciendo y plantear las preguntas necesarias a su vez;
• la capacidad de formular correctamente comentarios sobre revisiones de código, etc.

Por cierto, sobre habilidades blandas en apoyo. El hecho es que las habilidades blandas en el equipo de desarrollo requieren una evaluación por separado. Sin embargo, se requieren cualidades personales que solo son deseables para el desarrollador para el equipo de soporte. Si se contrató a una persona, ya la tiene por defecto.

En el desarrollo, abandonamos el concepto mismo de "habilidades blandas" y lo llamamos habilidades universales. No incluyen, por ejemplo, el conocimiento del idioma inglés o el hecho de que no enfurezca a su equipo; esto no es así, porque está más cerca de las habilidades blandas, describe el carácter de una persona. Evaluamos las habilidades en algún lugar al borde, y por lo tanto se nos ocurrió ese nombre: habilidades universales .

Cuando la lista de habilidades estaba lista, las evaluamos mediante una encuesta continua. Realizamos un examen real en el que algunas de las preguntas sugirieron una respuesta definitiva, y algunas discutieron situaciones de trabajo: "¿Qué debo hacer si alguien retrasa o no hace algo?", "¿Cómo implementaría esta o aquella funcionalidad en el proyecto?" . Esto nos ayudó mucho, porque esta parte de las preguntas me permitió hablar con una gran cantidad de desarrolladores.

Luego calificamos a los desarrolladores en una escala de 1 a 3 para cada habilidad.

Esas habilidades que no pudimos evaluar con la ayuda de la encuesta inicial, las evaluamos con la ayuda de compañeros, es decir, se les pidió que evaluaran a sus colegas. En ese momento, no teníamos ningún líder de grupo, de lo contrario podrían haberlo hecho.

Esta matriz se parece a esto.



Por supuesto, no fue posible ajustar todo en la imagen, por lo que algunas cosas, por ejemplo, las correlaciones y el perfil de los desarrolladores no están claros aquí. Pero aun así, puede evaluar más o menos lo que sucede y ver qué tan claro es y qué puede medir.

Los colores son consistentes con el grado. Se dedujeron las mismas métricas que en el equipo de soporte: promedio total y diverso en habilidades.

Prestemos atención a Dev8. De la tabla resulta que esto es como si el primer candidato para el despido. Pero, en primer lugar, tiene conocimientos específicos en uno de los puestos, por lo que lo necesitamos. Pero lo más importante, esta tabla no es una herramienta de disparo . También contaré sobre esto, no lo empezamos todo por el bien.

Habilidades promedio: este es el trabajo, cuyos resultados deben formarse un plan sobre cómo apretar la habilidad. Es decir, si los desarrolladores no saben algo, este no es su problema. Esto significa que no les dimos suficiente información y, en general, el conocimiento de algunas de las habilidades generalmente no es suficiente en la empresa. Debe escribir documentación o hacer algún tipo de patio de recreo para que puedan practicar, o comprar algún tipo de curso externo para que puedan aprender, realizar una sesión de intercambio de conocimientos, enviarlos a aprender unos de otros, trabajar juntos por un tiempo, incluir a la persona en otro proyecto. Puede haber diferentes opciones para compartir conocimientos. La conclusión es que primero debe celebrar un evento, y solo luego hablar sobre la dinámica.

Es importante tener en cuenta que, dado que nuestra empresa tiene una estructura matricial, no todos los desarrolladores necesitan algunas habilidades. Los recibirán cuando completen la tarea asociada con esta habilidad. De lo contrario, no tiene sentido, especialmente si la habilidad no está incluida en la lista crítica. Por ejemplo, en alguna parte de los proyectos no hay uPredict, esta no es una habilidad crítica. En general, este enfoque nos ayudó a formular qué habilidades son clave y cuáles no, y qué puede alcanzar un especialista cuando tiene una tarea tan práctica.

Otro punto importante sobre la calificación. Inicialmente cometimos un error, lo que provocó más de lo que podría ser la resistencia del equipo: no verbalizamos el valor de las calificaciones 1, 2 y 3. Estaban en nuestras cabezas a nivel de intuición, pero no pudimos responder por qué un desarrollador obtuvo 1, y el segundo - 2. Los desarrolladores compartieron los resultados de la propagación entre sí y esto provocó conflictos. A diferencia del grupo de soporte, informamos calificaciones personales a pedido, pero no extraños.

Debe definir claramente y transmitir esto a todos, por ejemplo, que en conocimiento de Lua el puntaje es:

• 1 - significa que el desarrollador conoce todos los operadores básicos, sabe cómo trabajar con estructuras de datos y escribir clases de funciones;
• 2 - sabe cómo organizar el código en bibliotecas, trabaja constantemente con ellas durante todo el proyecto y sabe qué son las metatablas;
• 3: conoce los detalles de la empresa y los proyectos, por ejemplo, cuáles son las corutinas (los detalles de cómo funciona nuestro servidor con Lua), cómo funciona el código C ++ con el código Lua, qué restricciones impone, cómo se interpreta, el código compilado, cómo funciona nuestro compilador JIT.

Entonces puedes descomponer cada habilidad, porque en algún lugar del nivel de intuición ya la tienes.

Nota para uno mismo:

• Verbalice el sistema de calificación, incluso si no muestra a nadie.
• En las primeras etapas, intente incluir desarrolladores experimentados. Usted sabe quién puede tener la mayor resistencia, inclúyalos de inmediato en el trabajo. Elimine todas las objeciones por adelantado, como se hace en las ventas.

Cómo implementar

Cuando la matriz primaria estaba lista, en el equipo de desarrollo le asignamos métricas . Básicamente, fue el porcentaje de calificaciones máximas de habilidades, lo que le permite poner una calificación al desarrollador.

Además de las evaluaciones de habilidades individuales, necesitábamos calificar a los desarrolladores. Tuvimos grados A, B y C, algo así como junior, middle, senior. En TI junior, middle, senior, ya está demasiado lleno de significado, en el que, entre otras cosas, se invierte experiencia laboral. , . A, B C — . « » .

— .

, . , , , , .

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

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

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

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

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

. , - : « ? ?».

, , , — , , , . .

Casos

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

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

¡Y eso es todo! 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 .

, ( , , , , ) ( ).

. , , , . .