Оставьте заявку на пилотное тестирование
Заполните форму, и наш консультант свяжется с Вами для организации пилотного тестирования
Ваша должность
Как нечеткие требования лишают нас программистов и что с этим делать?
16.06.2019
Тема оценки программистов одна из самых болезненных и обсуждаемых в ИТ-пространстве. Как оценивать? Как определять критерии? Что принимать за 100%? Как минимумом заданий оценить максимум навыков? Какие вообще навыки есть?

C этими вопросами мы ежедневно сталкиваемся в Logros.tech при работе с клиентами. Чтобы собрать онлайн-тест на платформе для компании, мы обязательно запрашиваем требования: будь это вакансия и отбор кандидатов или требования к штатной позиции программиста для внутренней оценки.

Пересмотрев сотни требований, поговорив с руководителями разработки, проектов и HR-ами, мы выявили корень многих бед. И нашли истоки:
  • затяжных кровавых поисков программистов на перегретом рынке вместо решения крутых бизнес-задач
  • появления "котов в мешке" (по проф.уровню) в компании даже после нескольких технических собеседований… и их сюрпризы по результатам работы
  • скрытых и открытых конфликтов с разработчиками из-за туманной, субъективной оценки их руководителями, отток в поисках правды
Одна из первопричин:
Требования к кандидатам и сотрудникам не структурированы и слабо формализованы изначально!

Как это связано?
Итак, обобщенными и неструктурированными требованиями трудно гибко оперировать в зависимости от ситуации в компании, на рынке, в проекте

Рассмотрим ситуацию с оценкой уже работающих сотрудников в компании. В отличие от ситуации подбора кандидата в конкретный проект, без структурирования требований на уровне разработки в целом невозможно создать никаких систем.

А за уходом следует дорогостоящая замена сотрудника. И мы возвращаемся к Схеме №1. Так осуществляется круговорот неструктурированных требований от кандидатов к сотрудникам и обратно.

"У нас же есть перечень требований!" нам говорят.


А вот что мы видим ежедневно:
Знания, Hard skills, технологии и инструменты, методологии, параметры опыта, Soft skills и "горящие глаза" - вот неполный список разнородных сущностей через запятую. Получается жесткий и пестрый перечень, не поддающийся анализу и оптимизации в случае возникновении проблем при подборе.

Команды хотят получить с рынка как можно более квалифицированного, знающего специфику специалиста, способного быстро включиться в работу. А получаются затяжной поиск, переработки, распухающие от задач бэклоги и мрачнеющие в ожидании клиенты.

"Что делать?"

Грамотно формулировать и структурировать требования к вакансиям и доносить их до сотрудников. При этом учитывать:

  1. Необходимую seniority специалистов
  2. Технологический стек, инструменты и инженерные практики, используемые на проекте
  3. Что считать базовыми (обязательными), а что - "дополнительными" Hard Skills для специалистов выбранного уровня
  4. Соотношение задач, для выполнения которых необходим определенный skillset, и количества seniority специалистов в команде, необходимых для выполнения этих задач.

1. Seniority


Подходов к распределению требований по уровням Seniority много. Мы предлагаем наиболее классическую градацию по Hard skills:
Соотносите требования с таблицей, чтобы не завышать и занижать их. Также важно придерживаться единой градации в компании в целом. Притча во языцех: "Middle по Паше" и "Middle по Саше", когда руководители в 2-ух отделах компании по-разному определяют содержание уровня. Что, конечно, смущает умы охочих до справедливости программистов.

2. Технологический стек, инструменты и инженерные практики

Ключевой момент определения требований к специалисту - формализация набора технологий, инструментов и инженерных практик, использующихся на проекте.

Чтобы не "утонуть" в технологическом многообразии, нужно четко представлять себе структуру Hard Skills, которая позволит решить три задачи:

  • выделить технологии, инструменты и практики, необходимые для проекта
  • разделить их на базовые (необходимо знать всем участникам проекта), и "дополнительные" (владение ими необходимо для команды в целом, но не обязательно для каждого участника проекта)
  • определить оптимальное количество специалистов требуемого уровня seniority, владеющих конкретными Hard skills

И другие бонусы от четкой структуры Hard skills:
  • легче сделать критерии оценки и проверять соответствие им у кандидатов. Это и фундамент для внутренней системы оценки программистов в компании
  • вы яснее даете понять кандидату, чего вы от него хотите. Поверьте, на рынке труда это случается нечасто. "Бардак" в требованиях отпугивает прежде всего квалифицированных кандидатов.

Мы сделали свою древовидную классификацию Hard skills.

На верхних уровнях - ветвях указаны категории, группы и подгруппы (количество уровней вложенности групп может меняться от категории к категории). "Листья" - концепции, технологии, инструменты и практики.

Таблица 2. Классификация Нard Skills
Классификация не претендует на всеохватность и универсальность, но отражает сам принцип структурирования Hard Skills.

Для примера - набор требований для проекта по разработке enterprise-системы с использованием микросервисной архитектуры, Java-технологий на бэкэнде и React на фронтенде.

В команде нам нужны как backend, так и фронтэнд разработчики – для этого выделим Hard skills, специфичные для каждого из этих двух типов специалистов, а общие категории – архитектуру и инженерные практики – приведем как общий блок. Для упрощения "свернем" дерево категорий и групп в первый столбец (см. Таблицу 3).

Таблица 3. Hard Skills для проекта
В процессе работы вы постоянно можете добавлять свои категории, группы и технологии в Таблицу классификаций. Используйте ее в качестве основы для формирования требований для ваших собственных проектов с учетом их специфики.

Итак, мы разобрали как неструктурированные и слабо формализованные требования снижают на нашу способность быстро привлекать сотрудников в компанию и удерживать дорогостоящий персонал.

Мы показали как распределяются требования по уровням Seniority и как классифицируются Hard skills. Надеемся, использование этих инструментов поможет вам структурировать skillset для ваших проектов и команд.

А в следующей статье мы расскажем о формировании требований:

  • как определять базовые (обязательные) и дополнительные Hard-skills
  • как соотнести их с уровнями Seniority
  • как сформулировать оптимальные для быстрого подбора и комплементарные для команды требования к кандидату

Понравилась статья? Поделитесь и обсудите с коллегами в социальных сетях!
Made on
Tilda