В начале декабря американский инженер и создатель методологии экстремального программирования Кент Бек (Kent Beck) в своем Facebook опубликовал интересную заметку, в которой рассказал, как, по его мнению, следует «назначать цену» конкретному программисту. Мы подготовили адаптированный перевод материала, а также поговорили с представителями российских ИТ-компаний.

В чем проблема

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

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

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

• Созданная ценность. Если программист приносит компании ценности на $1 млн, значит его зарплату можно сравнить с этим миллионом долларов. Понятие ценности сложно использовать само по себе. К примеру, если из команды уволить не самых хороших людей, то ее общая ценность увеличивается, в то время как цена для компании снижается.
• Стоимость возможностей. Что лучше для компании, нанять программиста на желаемую им зарплату или заплатить за что-то еще? Если сделать работу этого ведущего программиста и принести компании тот же самый $1 млн могут два junior-разработчика, то он не должен получать больше, чем две их зарплаты.
• Рыночная стоимость. Насколько сильно отличается сумма зарплаты, которую хочет получать программист, от того, что ему могут предложить другие компании? Что будет, если он найдет работу, которая ему понравится больше?
• Цена замены. Сколько компании будет стоить поиск кого-то, кто сможет сделать «ту же работу»?
• Сопоставление с другими. Сколько платят людям «как он»?
• Потребности. Программист также сравнивает предложенную зарплату с тем, сколько он тратит на еду, жизнь, образование детей и прочее.

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

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

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

Заключение

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

• Разумная цена — это не одно число, а диапазон.
• Для людей, оценивающих одну и ту же сумму с разных точек зрения, она может казаться, как совершенно неприемлемо высокой, так и смехотворно низкой.
• Если и компании и программисту сделка кажется удачной, то цена является наиболее справедливой.
• Если диапазон желаемой зарплаты с точки зрения компании и программиста вообще не пересекаются, стоит сделать шаг назад и еще раз обсудить, на основе каких метрик производится оценка каждым из участников переговоров.

Мы решили спросить у представителей российских ИТ-компаний (в том числе, у руководителя нашего проекта) и HR-специалистов, какие подходы можно использовать к определению уровня зарплаты программиста, а также для оценки возможного размера его премии.

Виталий Грицай, руководитель 1cloud.ru

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

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

---

Aviasales, пресс-служба

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

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

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

---

Елена Журавлева, сооснователь HumanFactorLabs и DaData.ru

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

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

Например, с количеством багов (исправил 10 багов — получи 1000 рублей). В багтрекере вместо десяти багов быстро возникнет сто и даже двести. Или с количеством строчек кода (написал 1000 строчек — держи 100 рублей).

Разработчики быстро и талантливо научатся раздувать код в 10 или даже 100 раз.

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

В итоге мы приняли решение не мучать себя и разработчиков. Мы берем к себе только крутых и даем им зарплату ощутимо выше рынка. Если рынок растет — повышаем зарплату. Если не растет — тоже повышаем, хотя бы раз в год. Если ошиблись с уровнем крутизны разработчика — расстаемся с ним.

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

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

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

---

Сергей Дмитриченко, основатель ИТ-рекрутингового агентства GMS и поисковой системы для рекрутеров AmazingHiring

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

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

Для оценки разработчиков хорошо работает двухуровневое тестирование:

— Быстрый скрининговый тест на старте, который позволяет базово оценить навыки кандидата. Здесь можно использовать как самостоятельно разработанные задания, так и взять готовые, например, certification.mail.ru. Они отлично подходят для решения этой задачи.

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

Есть еще несколько моментов, на которые стоит обратить внимание:

— общая эрудированность, желание и умение разбираться в новых областях, использовать современные технологии;

— участие в проектах с открытым кодом и высокая репутация на профессиональных сайтах вроде Github, Stackoverflow, Kaggle;

— опыт выступления на профессиональных конференциях и митапах.

---

А какой подход к определению справедливой зарплаты разработчика кажется наиболее эффективным вам? Делитесь мнениями в комментариях!