«За несколько лет мы собрали команду из 110 разработчиков». Как мотивировать IT-шников без системы грейдов

Почему мы не используем грейды 

Грейдирование (от английского grade – класс, звание) предполагает деление специалистов компании на классы по уровню квалификации. В одних компаниях используются только основные уровни – junior, middle, senior, в других – могут применяться еще и промежуточные, например, junior+ и middle+. Для каждого уровня устанавливаются свои требования по опыту и навыкам и назначается фиксированный размер зарплаты. 

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

При таком подходе старшим разработчиком обычно называют самого крутого программиста в команде, и это ничего не говорит о его настоящем уровне. Не исключено, что при попытке устроиться в другое место с более сложными проектами он не пройдет даже на позицию «джуниора». 

Нельзя сказать, что грейдирование совсем не имеет смысла. Оно вполне подойдет компании, которая развивает собственный IT-продукт силами внутренней команды. Но если говорить о заказной разработке, где команда работает над сторонними продуктами и имеет дело с большим стеком технологий, то ей при определении зарплат программистов нельзя ориентироваться на абстрактные звания и жестко фиксированные суммы.

Вот, например, как это происходит у нас. Мы работаем по модели предоставления разработчиков заказчику (аутсорсинг), поэтому для нас логично определять уровень и вознаграждение специалиста в зависимости от рыночной стоимости его работы. Она, в свою очередь, зависит от двух вещей:

• сложности решаемых задач,
• востребованности технологий. 

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

Такой подход помогает «привязать» зарплату разработчика не к статичным званиям, а к изменчивым реалиям рынка. 

Зачем ориентироваться на рынок 

Для чего компании, разрабатывающей IT-продукты на заказ, учитывать рыночные факторы при определении зарплат программистов? 

1. Во-первых, это обеспечивает корреляцию между тем, сколько компания получает от клиентов и сколько она платит своим разработчикам. Стоимость решения тех или иных задач в IT постоянно меняется: одни технологии устаревают, другие, наоборот, становятся актуальными и востребованными.
2. Во-вторых, привязка зарплаты программистов к стоимости задач позволяет учесть востребованность их навыков. Неважно, какой у программиста послужной список и звание, на его зарплате обязательно отразится, сколько денег он приносит компании.

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

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

1. Оклад, он же «несгораемая сумма», – это гарантия стабильного заработка разработчика. 
2. Переменная часть, которая считается по затраченным часам и зависит от сложности проекта. Она отражает связь между зарплатой конкретного разработчика и рыночной стоимостью его работы. 
3. Премия, которая выплачивается раз в квартал и зависит от общей прибыли компании. 

Каждая часть в этом списке выполняет свою роль в мотивации сотрудников. Оклад дает им ощущение стабильности, переменная часть является стимулом работать больше «здесь и сейчас», а премия мотивирует вкладываться в работу команды: обучать коллег, читать курсы, предлагать полезные решения. 

Также переменная часть, которая считается по затраченным часам, – это возможность для сотрудников регулировать свою нагрузку. Хочешь получать зарплату выше – работаешь больше, хочешь посвящать больше времени семье или спорту – работаешь меньше. 

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

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

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

Как набирать программистов без грейдов

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

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

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

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

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

Заметив проблему, мы прямо сообщали таким сотрудникам, что вынуждены перевести их на более низкую зарплату по объективным причинам. Чаще всего люди после этого увольнялись. Лишь в одном случае человек согласился с нашим решением, начал интенсивно работать и смог вернуть свою прежнюю зарплату через полгода. 

Как достичь максимума в найме ИТ-специалистов?

Подведем итог. Какие особенности возникают в работе IT-компании без «джуниоров» и «сениоров», где зарплата специалиста зависит не от условного звания, а от рыночных показателей? 

1. Динамическая система мотивации делает вопрос вознаграждения более прозрачным. Каждый разработчик понимает, от чего зависит его зарплата – от сложности задачи и стоимости проекта. В коллективе больше не возникает вопросов из серии «Я работаю год, а Вася – полгода, почему он получает больше?» 
2. Разработчикам требуется постоянно развиваться, чтобы не потерять в зарплате. Соответственно, компания должна обеспечить им возможность мигрировать в актуальные технологии.
3. Руководству компании (директору или HR-отделу) нужно следить за технологическими трендами, чтобы вовремя рекомендовать специалистам обновлять и расширять свои навыки.
4. Отсутствие грейдов усложняет процесс найма сотрудников, но делает его более эффективным. Чтобы не ошибиться при оценке кандидата, нужно тщательно подбирать вопросы и задания для собеседования. Зато такой подход повышает шансы найти действительно хороших специалистов и отсекает тех, кто просто гонится за высокой ЗП. 
5. Отсутствие привычной системы с четкими грейдами привлекает более свободолюбивых, мыслящих и увлеченных людей. Им не по себе от перспективы годами писать на одном и том же языке и получать за это одну и ту же зарплату. Они хотят развиваться, решать интересные задачи и получать деньги не за «выслугу лет», а за реальные достижения.

Чего здесь больше – плюсов или минусов? Каждая компания решает этот вопрос сама. Мы выбрали для себя систему без грейдов и в течение нескольких лет собрали в команде 110 отличных разработчиков. 

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

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

Фото в тексте и на обложке: Unsplash