Система грейдов как инструмент развития мобильных разработчиков
Я Нелля Кебирова — Android Tech Lead Kolesa Group. Я и моя коллега Вера Чернобиль — менеджер по обучению и развитию — расскажем вам про систему грейдирования в нашей компании. Я поделюсь процессами — про то, кто и какие шаги предпринимает для того, чтобы поднять себе грейд. Вера Чернобиль расскажет про развитие — про то, как грейдовая система прокачивает разработчиков и побуждает к карьерному росту.
Для начала определимся с терминами. Грейд — это уровень: junior, middle, senior. А грейдовая система — совокупность определенных hard- и soft skills для построения системы мотивации и роста сотрудников.
В этой статье вы узнаете про:
• Историю
• Задачи
• Наш путь (пошагово)
История
Еще в 2017 году у нас в команде Android было 5 человек, в команде iOS тоже 5, плюс несколько стажеров. Здесь можно было обойтись без грейдовой системы, потому что каждый читал код друг друга на ревью и было понятно, у кого какие плюсы и минусы. Но команда растет: сейчас у нас 21 Android-разработчик, и примерно столько же iOS-разработчиков. Ребята в командах прокачивают свои скиллы, растут. Появилась необходимость систематизировать все технические и софтовые требования к ребятам и создать систему, которая позволит сотрудникам понимать, как они могут поднять свой уровень.
Задачи и шаги
- Иметь пошаговую инструкцию
Чтобы у новых и старых сотрудников было четкое представление, с чего начать и что делать, чтобы поднять свой грейд. То есть создать гайдлайн с описанием всего процесса.
- Открытость/Прозрачность
Чтобы вся информация была открытой для всей компании, не только для мобильной команды. Чтобы каждый мог взглянуть на систему грейдов и понять, за что люди получают грейд и зарплату.
- Объективная оценка
Избавиться от субъективизма, когда один человек принимает решения и раздает грейды. Грейдовая система не должна зависеть от знаний и опыта одного человека. Даже если это руководитель, тимлид, техлид или кто-то еще.
Субъективизм распространяется и на собеседования. Кандидаты будут оцениваться по-разному, потому что нет стандарта в том, кого считать мидлом, а кого джуном. Как итог, у нас будут разношерстные сотрудники. И может появиться дисбаланс в заработной плате.
- Стандартизация
Для избавления от субъективности нужна стандартизация. Стандартизация подхода к разработке в техническом плане необходима, чтобы между разработчиками не было разлада. И в плане soft skills, чтобы сотрудники соответствовали ценностям компании.
- Комфорт
Важно, чтобы людям было комфортно с грейдовой системой, которая бы мотивировала расти и развиваться внутри нашей компании.
Кстати, про даты пересмотров: у нас есть объявленные месяца, когда разработчик может подавать себя на пересмотр: январь, апрель, июль, октябрь.
- Поднять грейд можно 1 раз в полгода
- Можно подняться сразу на 2 уровня
Шаги
1. Технический план
Кандидат нуждается в векторе технического развития. Суть этого этапа — узнать о планах разработчика, что ему интересно, что бы он хотел попробовать, над какими задачами поработать и т.д. Это все обсуждается с техлидом.
В плане технических навыков нам недостаточно только практических умений, мы смотрим и на теоретические знания. Для понимания, как человек пишет и какие у него проблемы, просмотра кода на ревью нам недостаточно.
Поэтому мы придумали свою матрицу навыков. Она помогает сопоставить технические знания и навыки с уровнем грейда. Оформлена она у нас в обычной Excel-табличке. Там 5 листов. Первые 4 листа это разделы: Computer Science, платформенные вещи, memory management, language.
К каждому разделу есть более конкретные темы. А для каждой темы (например, паттерны и архитектура) есть еще более конкретизированные требования. Эти требования делятся на уровни от 1 до 5. С каждым уровнем повышается сложность и глубина знаний. Последний лист — это таблица соответствий знаний и навыков с конкретным уровнем.
Computer Science
Более подробно с нашей таблицей грейдов вы можете ознакомиться по ссылке.
На каждого сотрудника заводится персональный файл, который содержит в себе 2 листа:
- навыки
- план развития
Также смотрим на soft skills и на ценность, которую сотрудник приносит команде и компании. Тут в работу вступает уже тимлид команды.
Шаги
2. Soft skills
Изначально у нас были софты общего назначения, которые легко нагуглить: базовые коммуникативные навыки, self-менеджмент и т.д.
Но потом у нас появилась картина и ценности компании. Так к нам пришло четкое понимание, какой человек нам подходит, а какой нет. Кстати, по поводу ценности soft skills, наш Team Lead Android-разработчик Ильяс Касым написал статью о том, насколько софты влияют на карьеру разработчика и дал общие рекомендации по их развитию.
Ценности компании:
Эти ценности написаны исключительно под себя, под компанию. Под эти ценности у нас сформирована своя матрица навыков, которая служит больше для информативной роли — здесь нет оценок и персональных таблиц. Матрица навыков нужна для того, чтобы человек понимал, какие есть ценности, на что надо сделать упор, какие вообще качества необходимо прокачивать.
Одна из ценностей Kolesa Group — развитие. В среднем, прокачаться с уровня Junior 1 до Middle 1 ребята могут за 6–9 месяцев. Middle- и senior-специалисты продвигаются в грейдах уже медленнее, и это оправданно: требования к каждому следующему уровню усложняются, требуют больше времени на прокачку. Появляется задача делиться знаниями, менторить джунов, глубже погружаться в бизнес. С уровня middle ребята поднимают грейд в среднем за 1–1,5 года.
Прозрачная система грейдов в каждом отделе помогает сотрудникам видеть свои перспективы и выстраивать объективный и понятный индивидуальный план развития. Грейды есть во всех технических командах Kolesa Group: backend-, frontend-, iOS-, Android-разработка, web- и mobile-QA, Data-аналитики, Machine Learning-инженеры, и у Product-менеджеров.
Тимлиды в командах отвечают за знакомство всех сотрудников с грейдовой системой, и помогают в составлении плана развития. Грейд присуждается сотруднику, когда его hard skills и soft skills полностью ему соответствуют.
Шаги
3. Подготовка
После того, как кандидат получил весь план, пожелания и предложения, он начинает подготовку. Подготовка состоит из двух частей:
1) Работа над soft skills
Это работа над собой, результаты которой должен увидеть тимлид и команда. Например, если у человека была проблема с декомпозицией задач, то ему дают большую монолитную задачу и ждут решения декомпозиции. Если есть проблема с коммуникациями, ему дают задачу, где требуется тесное сотрудничество с другой командой.
2) Изучение тем из матрицы навыков
Работа над soft skills всегда связана с повседневными задачи, а темы из матрицы технавыков — нет. Поэтому от компании мы даем возможность читать и изучать что-то новое в рабочее время. Но стоит понимать, что прежде всего сам кандидат заинтересован в своем росте, и мы приветствуем подготовку во внерабочее время.
Шаги
4. Сдача
После подготовки наступает этап сдачи технических навыков.
1. Формат личных встреч
В таком формате кандидат рассказывает техлиду обо всем, что изучил. Здесь желательно присутствие тимлида или второго техлида, чтобы избежать субъективной оценки. Но это не экзамен, скорее диалог. Потому, что если человек чего-то не знает, его не заваливают, а напротив стараются вывести на правильный ответ наводящими вопросами.
2. Формат парных встреч
Первый вариант бывает достаточно стрессовым для некоторых кандидатов, поэтому мы добавили формат парных встреч. Формат такой же, как и в виде личных встреч, только подготовка и сдача идет в паре — так психологически проще.
3. Провести внутреннюю лекцию с презентацией
Мы проводим офлайн/онлайн-лекции с записью в Zoom. Плюс мы делаем запись и сохраняем все лекции на корпоративном диске, чтобы они были доступны и новым сотрудникам. Зачастую людям страшно не столько выступать, сколько отвечать на вопросы. И поэтому подготовка к выбранной теме идет доскональная. Это самый действенный способ подготовиться к какой-либо теме.
4. Написать статью в Notion
Самый легкий вариант. Мы оформляем статьи в Notion через наш корпоративный аккаунт. И сейчас в процессе создания своей базы знаний по своей матрице навыков.
5. Участие в митапах/конференциях
И фаворит по уровню стресса — это участие во внешних митапах и конференциях :)
В итоге у нас есть 5 вариантов сдачи, и 2 самых популярных — личные встречи и внутренние лекции.
Шаги
5. Performance review
Performance review (оценка продуктивности) — метод оценки труда за определенный отрезок времени. Опросы 180 или 360.
Что это нам дает:
- Отображение сильных и слабых сторон кандидата
- Обратную связь
- Помогает поставить цели на будущее
Оценивают претендента на грейд только те, с кем он тесно работал за последний квартал. Обязательные люди в оценке:
- Руководитель отдела
- Product-менеджер
- SEM (Software Engineering Manager)
- TeamLead, TechLead
- QA-инженер
- Разработчики из команды
Разработчикам обязательно оставляют фидбек QA-инженеры, которые тестируют их код, и наоборот. К фидбеку команды присоединяются и другие разработчики, если они вместе работали.
Все фидбеки мы собираем анонимно. Тот, кто дает фидбек, выбирает из предложенных опций свое отношение к претенденту на грейд. Соответственно, в зависимости от отношения к грейдируемому, вопросы немного различаются. Тиммейты больше оценивают командные скиллы, насколько комфортно работать вместе, дедлайновость, ответственность, вовлеченность, насколько претендент развивается и делится знаниями с командой.
А менеджеры, лиды, руководители дают фидбек по этим критериям уже больше со стороны бизнеса. Также у менеджеров появляется критерий «самостоятельность-зависимость» в обратной связи грейдируемому.
Руководитель, тимлид и техлид заранее готовят списки людей, кто хочет грейдироваться. В эти списки мы вписываем человека, его грейд, и всех людей, кто должен его оценить.
Потом за 1–2 недели менеджер по обучению и развитию пишет в личку всем, кто должен оставить фидбек с ссылкой на форму и дедлайнами, что нужно дать обратную связь по кандидату.
В форме оставить фидбек претенденту можно по 4-балльной шкале, соглашаясь или не соглашаясь с определенным утверждением. Вариант ответа «не могу ответить» исключается. Эта опция была необходима, чтобы не происходили перекосы, когда человек не может оценить какой-то скилл и вынужден выбирать вариант рандомно.
Помимо закрытых вопросов есть и открытые, где можно в свободной форме оставить комменты по каждому скиллу. Открытые вопросы помогают нам глубже понимать причины, по которым могла быть поставлена та или иная оценка. Зачастую, открытые вопросы даже более информативны, и они используются для обсуждения в дальнейшем с претендентом. Так мы исключаем непрозрачность. Если у сотрудника возникает вопрос «Что такое 3 за дедлайновость? Почему?» мы можем всегда обратиться к развернутым фидбекам.
Результаты собираются ручками в Excel-файле.
Шаги
Встреча по итогам
И завершающий этап — это обсуждение итогов с лидами, руководителем, HR-директором и CTO.
Основная идея финального этапа в том, что тимлид представляет кандидатуру претендента на грейд. Показывает «комиссии» проекты, которые кандидат успешно выполнил, фидбеки от команд и руководителей, графики предыдущих оценок и обозначает прогресс.
Также финальный этап отражает беспристрастную оценку кандидатов, так как тим- и техлиды могут «толкать» своих кандидатов, а HR-директор и CTO смотрят на вещи объективнее.
Присутствующие на обсуждении могут задать дополнительные вопросы. В целом, в 99% случаев одобряют всех претендентов, так как к этому этапу вся картина по ним уже предельно ясна.
Вам, наверное, может показаться, что все это overhead. Что грейдовая система требует слишком много шагов, действий и затрачиваемого времени. Но так кажется только поначалу. Когда вливаешься в процесс и проходишь через это много раз, все становится очень простым и интуитивно понятным.
Итог
5 составляющих помогли нам внедрить систему грейдов:
1. Пошаговая инструкция
Весь процесс описан в статье в Confluence и включен в онбординг для новичков. Благодаря инструкции у сотрудников — и новых, и старых — нет неопределенности в росте, каждый понимает, что и как ему делать.
2. Прозрачность
Все требуемые hard- и soft skills открыты для всех сотрудников.
3. Объективная оценка
Избавились от субъективной оценки. Определились с с критериями и метриками.
4. Стандартизация
Распространили этот подход на всю мобильную команду. Раздел Computer Science и System Design у нас единый, что позволяет нам меняться — лиды iOS-команды могут слушать Android-команду, и наоборот.
5. Комфорт
Сдача технических навыков — щекотливая тема, потому что большинство не горят желанием что-то учить и сдавать. Поэтому мы придумываем альтернативные варианты сдачи, создаем собственную базу знаний. Мы за то, чтобы людям было проще готовиться и интересно работать.
После введения системы грейдов людям стало легче расти. Плюс стало проще отслеживать рост ребят.
