Программист с почти 15-летним стажем на условиях анонимности написал для dev.by колонку о том, что зарплата разработчика не очень зависит от того, какую пользу он приносит бизнесу, — правильно ли это?
Зарплата разработчика не очень зависит от того, какую пользу он приносит бизнесу. И это, на мой взгляд, большая проблема в белорусском (и не только) ИТ.
У представителей целого ряда профессий зарплаты отличаются в разы — в зависимости от крутости и качества. Возьмём продажников: в основном они зарабатывают за счёт процентов, сколько напродавали — столько заработали. Какой у них опыт «в годах», мало кого волнует: принёс продажи — молодец, не принёс — не молодец. Или вот менее интеллектуальная профессия: сантехник из ЖЭСа, который приходит через две недели после вызова пьяненьким, или сантехник-ипэшник с полным сервисом — две большие разницы. Один получает 200 баксов, второй пару тысяч. Разница в 5-10 раз. Хотя казалось бы — работа руками.
Ну а у программиста, которого тоже можно отнести к пролетариям, только работающим головой, разница — хорошо если в полтора раза. Пока разработчик не достигнет стеклянного потолка, рост может быть очень быстрым, но затем останавливается практически полностью. Ты можешь пахать тимлидом и получать условные 3 штуки, пахать сеньором спокойненько и получать те же 3 штуки, можешь дурака валять, ждать, пока уволят, — и получать 3 штуки. Из лично моего опыта: как бы я хорошо ни работал — или плохо, как бы ни вовлекался в проект и ни брал кучу ответственности (или вообще не брал), я получал ровно одну и ту же цифру. Что ещё более удивительно, она оказалась даже чуть больше в том случае, где я брал на себя мало и валял дурака. Как разработчик лично я преодолеть зарплатный потолок не смог.
Да, поднять зарплату на 200-500 можно, но о разнице в 2-4 раза между полезным разработчиком и неполезным на белорусском рынке вообще не идёт. Грубый средневзвешенный потолок — 4 штуки. Кто-то получает до 5, отдельные единицы до 6. Это уже супергерои, они умрут через год от истощения, потому что взяли на себя слишком много. Если честно, для достижения этой цифры намного проще переквалифицироваться в кого-то и начать новую карьеру.
На зарплату обычно влияют два фактора: стаж в разработке (он задаёт вилку) и умение себя продать.
А как быть, например, с понятием «правильная идея»? Правильная идея может сэкономить месяцы работы. Тогда со стороны бизнеса получается, что один чей-то совет ускорил разработку проекта на 20 процентов за счёт избежания проблем. Такой вклад абсолютно незаметен и прячется за кучей информации и проблем любого проекта. Разработчик никак не мотивирован глубоко понимать проект и генерить «правильные идеи».
Работу программиста оценить нельзя?
Возможно, её причина в следующем: принято считать, что работу программиста измерить нельзя. В бородатые времена её пробовали оценивать по количеству строк кода. По понятным причинам, это очень плохой критерий. После ряда бесплодных попыток устаканилось мнение, что оценить объективно нельзя. Вроде как есть дифференциация по шкале «джуниор — мидл — сеньор — тимлид», но она своя в каждой компании и даже в каждом проекте. И тоже размытая.
У меня противоречивые чувства на этот счёт: руководя программистами, хорошо вижу, как работает один и как другой. Да, вопрос «кто из них более ценен?» никак нельзя решить, используя формальные критерии: каждый проект отличен от других. Правда, в проекте всегда есть один или несколько человек, которые видят то, что делает разработчик, — менеджер, тимлид, архитектор или опытный разработчик, опытный тестировщик. Выходит, эти люди могут оценивать работу разработчика? Да, могут. Всегда ли они объективны, можно ли считать их мнение формальным критерием? Не всегда. Человеческий фактор сведёт все попытки оценить вклад разработчика к нулю.
Замкнутый круг: работу разработчика оценить нельзя, поэтому всем платим примерно одинаково. Тяжело разбираться, кто больше или меньше сделал, кто умнее и чей совет самый крутой, кому премию, а кого уволить за то, что он никогда не смотрит вне своей задачи и делает строго по постановке.
В итоге всё плохо и грустно: все разработчики получают примерно одинаково.
Отягчающий фактор: разработчики не любят общаться и никому не показывают код.
Может, стоило бы оценивать именно качество кода?
Ситуация отягощается тем, что разработчики не очень любят показывать свои решения другим разработчикам: не понимают зачем и боятся критики. Программист лучше покажет что-то неприличное из штанов, чем свой код — это ещё более интимная вещь. Даже на митапах реальный код проектов увидеть невозможно, только специально сделанные примеры. Дело не в NDA — что там с того кода можно реально разобрать! — дело именно в этом страхе.
В чужой код вникать тоже не хотят: мой код, который я сейчас пишу, лучший, остальной код (включая мой старый) г...но. Чем разобраться в чужой концепции, лучше запилить свою — практически всё разработчики делают с полного нуля, каждый раз это штучная продукция.
И оказывается, что каждый разработчик в своей скорлупке. Он редко опирается в своём развитии на других разработчиков. Особенно это касается людей с опытом: мидлы на сеньоров опираться могут, а сеньоры на сеньоров — нет. Во всяком случае, я такого не встречал. Разработчик совершенствуется с помощью чтения книг и других безличных способов, устраняя опасность показать код другим.
Если разработчики начнут общаться более тесно (как сантехники) то будет происходить более цельная передача опыта и критериев оценки.
Пока же как оценивать код — непонятно.
Может, бизнесу это выгодно?
По сути, бизнес и нивелирует риски за счёт средней зарплаты: можно работать очень сильно и получать за это среднюю зарплату, это бизнесу выгодно, а можно работать слабо, но работать и не быть уволенным, и это бизнесу невыгодно. Знаков отличия по результатам труда не выдаётся, нет желания кому-то повысить зарплату просто потому, что он хорошо работает.
Что делать?
Непонятно. Это действительно проблема. У меня были сценарии, что можно этому противопоставить.
1. Формализовать в рамках компании и проекта рейты разработчиков.
Не «он молодец, давай сеньором назовём, а то уйдёт», а «он умеет вот это и вот это».
Если эти понятия в рамках проекта будут формализованы, то разработчик сможет сказать: вот я это уже знаю, давайте следующий лейбл и следующий уровень зарплаты. Мотивация разработчиков оставаться в рамках компании повышается. Они видят, куда расти и как рост конвертируется в деньги. Они учатся и знают, что изучать: не просто «иди-ка получай опыт», а конкретику. Они понимают, что решение принимает не менеджер и тимлид, исходя из личной симпатии, а есть простые, честные и прозрачные правила.
Когда непонятно, сколько лет опыта (и какого) требуется, чтобы получить следующее повышение, неизвестность вызывает тревогу и чувство несправедливости. Сама по себе прозрачность даёт огромный результат в удержании сотрудников.
2. Мотивировать разработчиков к общению и широкому пониманию проекта.
Сейчас мотивация разработчика в том, чтобы делать свою задачу. Зачем ему смотреть шире, если никто не платит ему за идеи и широкие взгляды? Разработчик думает: слушайте, я же разработчик, чего я буду вникать в эти ваши детали, вы мне задачу поставьте. Наниматель думает: господи, я этим парням яйцеголовым столько плачу, мне нужно, чтобы они сидели и молча пилили, а не болтали, вот ты менеджер, я тебе плачу в два раза меньше, ты и болтай. В итоге менеджер общается за пятерых, кодера заваливают переделками, а заказчик думает: куда я попал? Ситуация поддерживает сама себя. Кривовато сделали — но зато вроде бы сделали и заказчик слегка доволен. Про такую ситуацию много карикатур, некоторым больше 30 лет. «Заказчик — идиот, разработчики — дебилы, не понимают, что ему надо», а они общаются через целую иерархию людей, который каждый на своём уровне искажают информацию. В чёрной цепочке аутсорса искажения могут приобретать самые причудливые формы, как в королевстве кривых зеркал.
На самом деле в конечном счёте никто не доволен.
Решение тупо и банально: больше понимать о проекте. Если разработчик будет мотивирован глубоко понимать проект в целом, всем станет легче. Как ни удивительно, это работает не только в продукте, но и в аутсорсе и на фрилансе.
А понимания можно застигнуть только за счёт общения.
Скрам делает огромный шаг в этом направлении, заставляя разработчиков общаться и иметь общие ценности. Все эти митинги, планирование существуют, чтобы увеличить количество общения и перевести его в качество. Когда можно высказывать новые идеи, задавать дурацкие вопросы.
Непонятно, как общение приведёт к росту зарплаты разработчика?
В этой открытости всем членам команды понятно, кто чего стоит в проекте. Кто делает таски, а кто занимается улучшениями и пониманием.
Как мне кажется, большая открытость позволит более опытным разработчикам получать большую зарплату за больший вклад в проект, и ни у кого не будет сомнений в справедливости такого подхода. Видя, что их вклад адекватно оценивается, разработчики будут стремиться увеличивать его.
Кому-то достаточно находиться в своей роли — но и им хорошо: у них есть такая возможность, и такие люди тоже нужны.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.