Как бардак в требованиях лишает нас лучших программистов и что с этим делать

Тема оценки программистов одна из самых болезненных и обсуждаемых в ИТ-пространстве. Как оценивать? Как определять критерии? Что принимать за 100%? Как минимумом заданий оценить максимум навыков? Какие вообще навыки есть?

Тема оценки программистов одна из самых болезненных и обсуждаемых в ИТ-пространстве. Как оценивать? Как определять критерии? Что принимать за 100%? Как минимумом заданий оценить максимум навыков? Какие вообще навыки есть?

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

Пересмотрев сотни требований, поговорив с руководителями разработки, проектов и HR-ами, мы выявили корень многих бед. И нашли истоки:

• затяжных кровавых поисков программистов на перегретом рынке вместо решения крутых бизнес-задач
• появления “котов в мешке” (по проф.уровню) в компании даже после нескольких технических собеседований… и их сюрпризы по результатам работы
  
• скрытых и открытых конфликтов с разработчиками из-за туманной, субъективной оценки их руководителями, отток в поисках правды
  

Одна из первопричин:

Требования к кандидатам и сотрудникам не структурированы и слабо формализованы изначально!

Схема 1.

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

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

Сехма 2.

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

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

А вот что мы видим ежедневно:

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

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

“Что делать?”

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

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

Подходов к распределению требований по уровням Seniority много. Мы предлагаем наиболее классическую градацию Hard skills по уровням.

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

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

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

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

И другие бонусы от четкой структуры Hard Skills:

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

Схема 3.

Перейти на полную версию классификации.

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

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

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

Схема 4.

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

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

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

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

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

Авторы: Ярославна Медведева и Денис Первушин

#разработка #ИТ #IT #оценка #требования #HardSkills#программисты #технологии