- PVSM.RU - https://www.pvsm.ru -
В начале декабря американский инженер и создатель методологии экстремального программирования [2] Кент Бек (Kent Beck) в своем Facebook опубликовал интересную заметку [3], в которой рассказал, как, по его мнению, следует «назначать цену» конкретному программисту. Мы подготовили адаптированный перевод материала, а также поговорили с представителями российских ИТ-компаний.
Не существует четко обозначенных правил, описывающих процесс оценивания программиста с точки зрения финансов. Чтобы как-то продвинуться в этом вопросе, для начала нужно понять, с какой стороны такая оценка может быть выработана. Здесь есть три варианта:
При этом, нельзя понять, высока или нет определенная сумма, если не сравнить ее с чем-нибудь. Вот с чем зарплату программиста можно сопоставить:
При этом важно понимать, что иногда желаемая программистом зарплата может ему самому казаться слишком высокой, однако итоговая сумма формируется несколькими факторами, среди которых представление конкретного сотрудника о том, сколько ему бы хватило денег, не является главным.
Например, в ходе обсуждения материала Бека на ресурсе Hacker News пользователь под ником lemevi отметил [4], что будучи разработчиком в американских стартапах, часто совсем не видел результата своего труда в привязке к продажам и общей ценности для компании, поскольку не все разрабатываемые им продукты в конечном итоге вообще запускались для пользователей.
«Не знаю, почему люди платят мне так много, но я рад этому, потому что могу заниматься тем, что я люблю — программированием, а не выпуском продуктов. В итоге я имею редкую возможность жить по стандартам исчезающего ныне среднего класса».
Как считает Бек, конечная оценка того, высока или нет итоговая сумма будет зависеть от того, с какой стороны на нее посмотреть. Перечисленные выше метрики нельзя применить для получения четкого результата. Но вот, что можно сказать об оценке зарплат программистов:
Мы решили спросить у представителей российских ИТ-компаний (в том числе, у руководителя нашего проекта) и HR-специалистов, какие подходы можно использовать к определению уровня зарплаты программиста, а также для оценки возможного размера его премии.
Виталий Грицай, руководитель 1cloud.ru
Мы используем некоторые способы оценки возможной зарплаты программистов, описанные Кентом Беком. Нам нужны очень сильные разработчики, поэтому, как правило, мы назначаем зарплату выше рынка (а значит, мы его мониторим). Но хорошие деньги даются не просто так, а тем людям, которые могут принести компании пользу, повысив уровень наших продуктов.
Уже после найма мы также оцениваем еще и качество выполняемой программистом работы, а также его инициативность — если человек предлагает новые идеи и способен их реализовать, то это следует всячески поощрять, в том числе и финансово.
Программисты в Aviasales работают в составе продуктовых групп, успех отдельного программиста в первую очередь зависит от успеха группы и уже затем от того сколько и какого кода написал программист.
Идеальный программист успевает прочесть новости ИТ-мира до работы, на работе успевает реализовать несколько тикетов (да, мы используем Agile), помочь коллегам по команде в реализации их тикетов, а вечером рассказывает коллегам из других продуктовых групп об инструментах и практиках, помогающих поддерживать адскую продуктивность в его команде.
Именно такие программисты регулярно получают высший грейд и максимальный бонус.
10 лет тому назад, когда мы основали свою компанию, мне очень хотелось научиться измерять эффективность разработчиков и связать их зарплату с результатами работы. Это очень сладкая цель и для бизнесмена, который хочет наиболее эффективно инвестировать, и для хороших разработчиков, которые хотят обоснованно за свою высокую компетенцию получать выше среднего по рынку.
Но, поскольку я сама была разработчиком, то знала, что подходы с метриками не работают.
Например, с количеством багов (исправил 10 багов — получи 1000 рублей). В багтрекере вместо десяти багов быстро возникнет сто и даже двести. Или с количеством строчек кода (написал 1000 строчек — держи 100 рублей).
Разработчики быстро и талантливо научатся раздувать код в 10 или даже 100 раз.
Как только вы пытаетесь платить разработчику на основании какой-то метрики, он, как талантливый инженер, почти сразу же находит способ ее взломать. И вместо того, чтобы делать проект, менеджер будет придумывать все новые и новые KPI, а разработчик будет придумывать, как им соответствовать. И они будут забавляться этой игрой бесконечно, вместо того, чтобы писать код и делать лучше продукт.
В итоге мы приняли решение не мучать себя и разработчиков. Мы берем к себе только крутых и даем им зарплату ощутимо выше рынка. Если рынок растет — повышаем зарплату. Если не растет — тоже повышаем, хотя бы раз в год. Если ошиблись с уровнем крутизны разработчика — расстаемся с ним.
У нас продуктовая разработка, поэтому для нас это оправдано. На ввод человека в продукт тратится до полугода времени, поэтому нам выгодно удерживать очень хороших разработчиков. А разница в производительности труда на сложных задачах у очень хорошего и просто хорошего специалиста может отличаться более чем в десять раз.
Но такой подход оправдан не всегда. Например, в аутсорсинге или заказной разработке рентабельность определяется разницей между ценой часа работы, которую оплачивает заказчик, и его себестоимостью, состоящей из зарплаты, офиса и других накладных расходов.
При этом и цены и зарплаты определяются открытым рынком, который близок к рынку совершенной конкуренции. Поэтому им выгодней брать стажеров и доучивать их под себя. В таком случае можно повышать зарплату на основании расширения круга обязанностей (например, переход из разработчика в тимлиды) или после очередного достижения (провел крутейший рефакторинг, который снизил скорость исправления ошибки в продукте с 16 до 2 часов).
Ответить на вопрос «сколько платить» не сложно: нужно понимать текущую рыночную компенсацию специалистов с аналогичным опытом. Для того, чтобы ее определить, необходимо проанализировать зарплатные ожидания подходящих кандидатов, а также уметь оценивать специалистов, пришедших на интервью. Обычно проблемы бывают со вторым — объективной оценкой.
По опыту могу сказать, что для оценки кандидатов лучше всего подходит структурированное интервью — заранее составленный набор вопросов с понятной шкалой оценки ответов на них. Использование одинаковых вопросов при общении с разными кандидатами дает общую систему координат для анализа результатов.
Для оценки разработчиков хорошо работает двухуровневое тестирование:
— Быстрый скрининговый тест на старте, который позволяет базово оценить навыки кандидата. Здесь можно использовать как самостоятельно разработанные задания, так и взять готовые, например, certification.mail.ru. Они отлично подходят для решения этой задачи.
— И основной этап — расширенное тестирование, когда кандидату предлагается решить задачу или серию задач близких к тем, которыми будет необходимо заниматься на этой позиции. Такие тестирования обычно занимают 4-6-8 часов, но дают хорошее понимание, подходят ли человек и компания друг другу. Здесь также важно, чтобы все кандидаты решали одинаковые задачи.
Есть еще несколько моментов, на которые стоит обратить внимание:
— общая эрудированность, желание и умение разбираться в новых областях, использовать современные технологии;
— участие в проектах с открытым кодом и высокая репутация на профессиональных сайтах вроде Github, Stackoverflow, Kaggle;
— опыт выступления на профессиональных конференциях и митапах.
Автор: 1cloud.ru
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-personalom/105768
Ссылки в тексте:
[1] Image: http://megamozg.ru/company/1cloud/blog/22582/
[2] экстремального программирования: https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
[3] заметку: https://www.facebook.com/notes/kent-beck/pricing-programmers/1062181727148024
[4] отметил: https://news.ycombinator.com/user?id=lemevi
[5] Источник: http://megamozg.ru/post/22582/
Нажмите здесь для печати.