В феврале прошла конференция TeamLead Conf 2020 — одно из последних отраслевых мероприятий в офлайне до пандемии. В рамках ближайшей недели в блоге Skillbox мы разберем лучшие доклады спикеров. Сегодня — самое полезное из выступления Галины Головановой из Тинькофф-банка.
Материал полезен руководителям, которые хотят повысить эффективность команды, анализировать конкретные показатели каждого сотрудника и предотвратить замыкание знаний внутри команд.
Как оценивать результаты и прогресс сотрудников
Когда в вашей команде чуть больше 10 сотрудников, довольно легко оценивать прогресс каждого из ребят и намечать пути их развития. Однако если в команде 40 человек в 3 городах, становится сложнее общаться с каждым разработчиком и следить за качеством выполнения задач. На ум приходит привлекать кураторов на местах, но это порождает свои сложности. У кураторов разный технический уровень, требования и подходы, это не позволяет добиваться объективной и однозначной оценки сотрудников.
Ситуация осложняется, если ваша компания переходит на матричную структуру управления — когда каждый разработчик закрепляется за полностью укомплектованной бизнес-командой и делает задачи только для своего бизнес-направления. Этот подход значительно повышает скорость поставки задач, однако есть риск замыкания экспертизы внутри таких мини-команд. Помимо этого, в командах периодически расширяется технологический стек. Если раньше инструментарий для всех задач одинаковый, и разработчики универсальны и взаимозаменяемы, то со временем появляются новые виды задач, которые требуют освоения новых инструментов. И очень важно замотивировать ребят изучать новые технологии, при этом объективно оценивая их прогресс в каждом из направлений.
Как карта компетенций помогает оценивать качество работы сотрудников
Чтобы решить проблему оценки качества работы, нужно составить набор компетенций, по которым собираетесь оценивать своих сотрудников. Берите те технологии, которые используете – SQL, Python и так далее – и собирайте всю ту экспертизу, которая накопилась в команде.
Следующий шаг — подробно расписать каждую компетенцию и выделить четкие критерии оценки для каждой из них: то есть что нужно знать сотруднику, чтобы получить ту или иную оценку.
Как вариант, выделить четыре уровня: от нуля до трех:
- 0 — сотрудник не имеет знаний в конкретной предметной области;
- 1 — может выполнять простые задачи (junior);
- 2 — может выполнять большинство задач (middle);
- 3 — выполняет любую задачу, применяя знания в предметной области (senior).
Когда все компетенции расписаны, попросите сотрудников оценить себя по шкале от нуля до трех, а кураторов — проверить оценки.
Спустя несколько месяцев матрица этих оценок меняется, ведь сотрудники осваивают новые навыки, требования в проекте меняются, в команду приходят новые люди. С каждым обновлением нужно проставлять новые оценки и анализировать изменения, это достаточно делать раз в полгода.
Матрица нужна, в первую очередь, для того чтобы принимать решения о повышении сотрудника. Конечно, нужно смотреть не только на нее: важно еще то, какие задачи сотрудник делает, как он их делает (на скорость, на качество), на то, какой вклад в общую культуру разработки он вносит, на то, проводит ли он review, как он это делает. В результате вы получаете полную картину эффективности сотрудников, а самим сотрудникам становится предельно понятно, что именно нужно делать, чтобы получить повышение.
Замыкание знаний внутри команды
Бывает, что после распределения сотрудников со временем появляется проблема замыкания знаний: участники одной команды знают всё, а другой — почти ничего. Чтобы такого не происходило, нужно посмотреть на матрицу и проанализировать средние оценки по каждому навыку. Если один из навыков плохо развит у всех участников, может возникнуть проблема. В офисе вопрос замыкания знаний решается просто: сотрудник общается с коллегами и набирается опыта, но если разработчики живут в разных городах, все становится чуть сложнее.
В этом случае руководителю нужно построить график, который покажет средний уровень владения навыками в каждом из городов, где находятся сотрудники. Предположим, график показал, что сотрудники из Ростова в среднем владеют javascript-фреймворками на 50% лучше остальных. Тогда менее опытные ростовские сотрудники имеют возможность быстро прокачаться в работе с фреймворками, а у остальных такой возможности нет.
Если есть такой перекос в навыках по городам, то нужно переформировать команды таким образом, чтобы специалисты, например, из Ростова, попали в одну бизнес-команду со специалистами из других городов. Потихоньку ребята из других городов повысят навыки владения js-фреймворками и вскоре сами смогут обучать младших коллег.
Матрица помогает грамотно распределить сотрудников по проектам, сделать onboarding более структурированным и проанализировать движение знаний внутри команды. Она способствует поддержанию документации в актуальном состоянии и мотивирует на изучение чего-то нового. И главное — она показывает сотрудникам путь развития. Ребята понимают, что нужно сделать для повышения, и работают более эффективно.