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

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

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

Часть 1

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

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

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

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

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

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

Схема 1.

Оценка кандидатов - требования​ logros.tech​
Оценка кандидатов - требования​ logros.tech​

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

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

Сехма 2.

Внутренняя оценка сотрудников - схема​ logros.tech
Внутренняя оценка сотрудников - схема​ logros.tech

А за уходом следует дорогостоящая замена сотрудника. И мы возвращаемся к Схеме №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:

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

Схема 3.

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

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

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

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

Схема 4.

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

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

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

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

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

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

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

22
2 комментария

Спасибо за статью. Об описанной проблеме думаю уже давно - очевидно что хайринг в IT секторе сейчас дико неэффективен.

Из-за раздутых требований в вакансиях (навязанных техническим персоналом, не совсем осознающим их влияние на экономику проектов), компании ищут специалистов месяцами. А то и годами.

Специалисты же как правило, перед каждым новым интервью, в режиме ошпаренного кота учат очередные незнакомые для них buzzwords (а они есть практически всегда, независимо от уровня человека).

Итого это все просто не работает - ибо технологий слишком много, а кол-во людей, точно попадающих в нужные вам системы координат все меньше и меньше.

Понятно что надо формализовывать hard skills, но в таком виде это не спасет ситуацию.

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

Поэтому я считаю что главный фактор в оценке человека - понять стоит ли trade-off на его "вкатывание" в проект (изучение им архитектуры/технологий/специфики бизнеса) времени поиска вами более подходящего кандидата.

А списки hard skills, наоборот, должны быть максимально простыми - есть взять ваш пример, с большой долей вероятностью там можно выкинуть до 80%. Hard skill на Solr, например, в реальном мире нужен в одном проекте на миллион.

2
Ответить

Уважаемый, Marketmaker! Огромное спасибо за Ваш комментарий. Согласны с каждым словом. В том числе с последним абзацем. Именно об этом мы хотели писать нашу следующую статью - как из 100% хотелок "с дерева" сделать 20% "минимально достаточных" адекватных для проекта. 

Кажется, есть точки соприкосновения. Мы бы очень хотели с Вами связаться и продолжить диалог. Напишите, пожалуйста, мне по адресу: yaroslavna@logros.tech  

Ответить