Как бардак в требованиях лишает нас лучших программистов и что с этим делать
Тема оценки программистов одна из самых болезненных и обсуждаемых в ИТ-пространстве. Как оценивать? Как определять критерии? Что принимать за 100%? Как минимумом заданий оценить максимум навыков? Какие вообще навыки есть?
Часть 1
Тема оценки программистов одна из самых болезненных и обсуждаемых в ИТ-пространстве. Как оценивать? Как определять критерии? Что принимать за 100%? Как минимумом заданий оценить максимум навыков? Какие вообще навыки есть?
C этими вопросами мы ежедневно сталкиваемся в Logros.tech при работе с клиентами. Чтобы собрать онлайн-тест на платформе для компании, мы обязательно запрашиваем требования: будь это вакансия и отбор кандидатов или требования к штатной позиции программиста для внутренней оценки.
Пересмотрев сотни требований, поговорив с руководителями разработки, проектов и HR-ами, мы выявили корень многих бед. И нашли истоки:
- затяжных кровавых поисков программистов на перегретом рынке вместо решения крутых бизнес-задач
- появления “котов в мешке” (по проф.уровню) в компании даже после нескольких технических собеседований… и их сюрпризы по результатам работы
- скрытых и открытых конфликтов с разработчиками из-за туманной, субъективной оценки их руководителями, отток в поисках правды
Одна из первопричин:
Требования к кандидатам и сотрудникам не структурированы и слабо формализованы изначально!
Схема 1.
Итак, обобщенными и неструктурированными требованиями трудно гибко оперировать в зависимости от ситуации в компании, на рынке, в проекте.
Рассмотрим ситуацию с оценкой уже работающих сотрудников в компании. В отличие от подбора кандидата в конкретный проект, без структурирования требований на уровне разработки в целом невозможно создать никаких систем.
Сехма 2.
А за уходом следует дорогостоящая замена сотрудника. И мы возвращаемся к Схеме №1. Так осуществляется круговорот неструктурированных требований от кандидатов к сотрудникам и обратно.
“У нас же есть перечень требований!” нам говорят.
А вот что мы видим ежедневно:
Знания, Hard skills, технологии и инструменты, методологии, параметры опыта, Soft skills и “горящие глаза” - вот неполный список разнородных сущностей через запятую. Получается жесткий и пестрый перечень, не поддающийся анализу и оптимизации в случае возникновении проблем при подборе.
Команды хотят получить с рынка как можно более квалифицированного, знающего специфику специалиста, способного быстро включиться в работу. А получаются затяжной поиск, переработки, распухающие от задач бэклоги и мрачнеющие в ожидании клиенты.
“Что делать?”
Грамотно формулировать и структурировать требования к вакансиям и доносить их до сотрудников. При этом учитывать:
- Необходимую Seniority специалистов
- Технологический стек, инструменты и инженерные практики, используемые на проекте
- Что считать базовыми (обязательными), а что - “дополнительными” Hard Skills для специалистов выбранного уровня
- Соотношение задач, для выполнения которых необходим определенный 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
- как сформулировать оптимальные для быстрого подбора и комплементарные для команды требования к кандидату.
Авторы: Ярославна Медведева и Денис Первушин
Спасибо за статью. Об описанной проблеме думаю уже давно - очевидно что хайринг в IT секторе сейчас дико неэффективен.
Из-за раздутых требований в вакансиях (навязанных техническим персоналом, не совсем осознающим их влияние на экономику проектов), компании ищут специалистов месяцами. А то и годами.
Специалисты же как правило, перед каждым новым интервью, в режиме ошпаренного кота учат очередные незнакомые для них buzzwords (а они есть практически всегда, независимо от уровня человека).
Итого это все просто не работает - ибо технологий слишком много, а кол-во людей, точно попадающих в нужные вам системы координат все меньше и меньше.
Понятно что надо формализовывать hard skills, но в таком виде это не спасет ситуацию.
Как разработчик, я понимаю что большинство фреймворков, концепций и отд. инструментов могут быть крайне быстро изучены "на месте". Нет в них никакого hard skill. А часто они вообще не имеют никакого значения, т.к. проект работает со сложной предметной областью - и способность разобраться именно в ней перевесит любые технические слова.
Поэтому я считаю что главный фактор в оценке человека - понять стоит ли trade-off на его "вкатывание" в проект (изучение им архитектуры/технологий/специфики бизнеса) времени поиска вами более подходящего кандидата.
А списки hard skills, наоборот, должны быть максимально простыми - есть взять ваш пример, с большой долей вероятностью там можно выкинуть до 80%. Hard skill на Solr, например, в реальном мире нужен в одном проекте на миллион.
Уважаемый, Marketmaker! Огромное спасибо за Ваш комментарий. Согласны с каждым словом. В том числе с последним абзацем. Именно об этом мы хотели писать нашу следующую статью - как из 100% хотелок "с дерева" сделать 20% "минимально достаточных" адекватных для проекта.
Кажется, есть точки соприкосновения. Мы бы очень хотели с Вами связаться и продолжить диалог. Напишите, пожалуйста, мне по адресу: yaroslavna@logros.tech