Уровни программистов в 2023 году
Денис Гордиенко, генеральный директор Bright Mobile, о градации разработчиков на Junior, Middle и Senior с точки зрения программистов и заказчиков.
Сегодня я хочу затронуть важную как для заказчиков, так и для исполнителей-программистов тему – разделение разработчиков на Junior, Middle, Senior. Рассказываю, в чём суть этой градации и как её воспринимают сами разработчики и конечные заказчики.
В 2023 году мы активно привлекали ребят, т. к. перешли в продуктовый формат ведения разработки и под каждого клиента собираем несколько человек с фултайм загрузкой именно по этому проекту. В связи с этим активно использовали и HH, и FL и kwork. Часто встречались разрабочики, претендующие на Middle+ с опытом в… 1 год. Решил поделиться с сообществом наболевшим и рассказать о своём виденье уровней разработчиков, а вы можете со мной поспорить в комментариях.
Если говорить совсем по-дилетантски, то чем выше уровень, тем разработчик круче, а его зарплата – больше. Junior – это начинающий разработчик, только-только закончивший стажировку, а Senior, как говорили в советское время – ведущий инженер, который тянет всю разработку за собой. Но на самом деле не всё так просто из-за разного восприятия того, что должен делать разработчик того или иного уровня разными командами, самими программистами и конечными заказчиками.
Что думают о градации программистов сами программисты?
У каждого разработчика есть свой собственный жизненный путь: выбирает свой стек, учится на нём разрабатывать, делает пару-тройку тестовых заданий и воспринимает себя джуном, толком ещё ничего не умеющим, но какие-то задачи закрыть способным. То есть программисты считают джуниором начинающего разработчика не с точки зрения бизнес-задач и требований, а с точки зрения навыков во фреймворке или языке программирования.
Когда программист сдаст заказчикам несколько успешных проектов, разберётся с ошибками и проработает в стеке 3-4 года, он уже начинает ощущать себя мидлом – серьёзным разработчиком, готовым закрывать средние задачи, а иногда даже замахиваться на сложные и с большой долей вероятности их выполнить.
Так было 15 лет назад, когда я заканчивал универ. Сейчас же часто встречаются такие резюме, претендующие на Middle:
В качестве сеньора джуны представляют прокаченного гуру, знающего всё о языке/фреймворке от «А» до «Я» и способного решить любую задачу в стеке.
Как градируют программистов основатели?
Здесь ситуация, категорически иная, особенно если речь не о владельцах студий разработки вроде меня, а об основателях проектов, имеющих весьма слабый бэкграунд в IT.
В джуниоре основатель видит дешёвую рабочую силу, которая может закрывать простые задачи и дёшево стоит. При этом работа с джунами для него связана с рисками завала проекта ввиду малой подкованности в программировании и понимании бизнес-процессов. Привет, фриланс.
Второе определяет то, насколько подробно и понятно вы описали задачу в ТЗ. К примеру, если вы расписали ТЗ на три странички, в котором сумбурно расписано, что требуется огромная система с кэшбеком, маркетплейсом и интеграцией с Авито, риск завала существенно увеличится. Если взять корпоративный сайт: заказчик должен подробно описать каждую страницу и (в идеале) связать их технически, т. е. на каком компоненте всё делать. Однако здесь всё зависит от навыков заказчика в разработке, ведении проектов и понимании IT-инфраструктуры.
Чем детальнее вы опишете для джуна его задачу, тем меньше риск завала проекта. Это очевидно, но многие этим пренебрегают. Например, первые две недели ведения продукта в нашей команде — это только формирование всех бизнес-требований, схемы проекта и беклога задач.
С точки зрения основателя, джун не понимает бизнес-требований и выполняет по написанному. Отсюда и возникают расхожие штуки про фриланс, где заказчики находят дешёвых разработчиков, один не понимает, что ему нужно делать, другой – как ему это объяснить, и всё кончается болезнью бабушки и киданием на деньги.
Middle, в понимании основателя, разработчик c неким опытом. А значит, скорее всего, обойдётся классическими бизнес-требованиями. Например, нужен сервис с продавцами, которые должны выкладывать товары, агрегируемые в общий каталог. Получается эдакий товарник аля Ozon, только в узкой тематике. Мидл это понимает: основатель может предоставить ему ТЗ, составленное на основе бизнес-задач, и получает меньшие риски.
Мидл для заказчика – это человек, способный самостоятельно перевести бизнес-требования в технические и, если нужно, правильно задать наводящие вопросы. Реализация проекта средней сложности с мидлом отличается меньшими рисками и большей гарантией результата.
Senior чаще всего привлекается в проект в тех случаях, когда заказчик понимает, что один разработчик с проектом не справится. Это либо какой-то мультистековый проект, в котором есть и веб-версия, и мобильное приложение плюс, к примеру, интеграция с 1С и т. д. Сеньор нанимается как человек, обладающий навыками управления. Здесь проходит корреляция сеньора, тимлида и тех. директора, но сейчас я детально в разницу между ними вдаваться не буду.
С точки зрения заказчика, сеньор – это прокаченный разработчик, способный управлять джунами и мидлами и нести ответственность за их работу.
Его задача – не только воспринять бизнес-процессы, но ещё и передать их коллегам, правильно объяснив, что от них требуется. А затем, получив готовые результаты, собрать воедино так, чтобы всё работало правильно и без ошибок. При наличии багов в модулях сеньор сможет выявить, чей это косяк и, при необходимости, проконсультировать как правильно устранить. Т. е. сеньор – это программист, способный грамотно распределять задачи между младшими разработчиками.
Только 40% разработчиков, после отсева по резюме, смогли в онлайн-режиме реализовать простую задачу на 15 мин. Из оставшихся 60% треть не смогли даже найти в какое место писать код. Рассматривали Middle на зарплату от 150 000р
Как стать сеньором?
Тем джунам и мидлам, которые хотят стать сеньорами, само собой, необходимо детально изучать собственный стек и делать сложные, в том числе нетиповые задачи. Но чтобы стать именно сеньором, а не просто хорошим мидлом, нужно научиться понимать заказчика, в каком косноязычным бы формате он ни предоставлял ТЗ.
Вы должны уметь понимать, анализировать, задавать правильные наводящие вопросы, детализировать, разбираться, предлагать альтернативы и выдавать технически правильный продукт, попадающий в изначальные ожидания клиента. А ещё нужно обладать софт-скиллами, т. е. навыками общения с другими разработчиками и умением ими управлять: правильно выдавать задачи, собирать результаты и тестировать их.
Чаще всего в крупной разработке, где работают сеньоры, в ходу разделение задач по приоритезации, поэтому вы должны обладать пониманием, какие задачи приоритетнее для технического стека, какие нет, и правильно доносить нюансы до основателя, который, естественно, хочет сделать всё и сразу.
Когда ожидания заказчиков и понимание разработчиков совпадают, проект получается качественным. адекватным и без срывов срока. А если разработчик называет себя сеньором, но, по сути, он просто хорошо программирует, он с большей долей вероятности завалит проект просто потому, что не поймёт прикладного характера софта, который реализует.
Нельзя написать Яндекс. Поиск в одиночку – это всегда командная работа, требующая управления не только с точки зрения менеджера или основателя, но и с точки зрения технического стека и распределения задач.
Вместо заключения
На днях случайно попался скрин, хорошо иллюстрирующий то, что сейчас происходит на рынке IT-труда.
10 лет опыта в технологии и зарплата 250 тыс. ($2,500)? Вы там ку-ку что ли совсем?
А за 20 лет дают уже аж целых 350 тыс. руб! Аттракцион невиданной щедрости
ага смешно и горько одновременно :(( забывают, что айтишник ограничен только наличием интернета и вполне способен оценить рынок труда за пределами "стены" :))
Пугает другое.
1. В тексте чуть более, чем полностью отсутствуют БА — это привет "твоя-моя-не-понимай" между бизнес-заказчиками клиента и командой разработки.
2. Командой разработки почему-то управляет Сеньор, а не Дев тим-лид. Как бы тим- и ресурс-менеджмент — это не то же самое, что быть крутым разрабом.
Статья — это типа lessons learned "из опыта работы на проектах с 2-3 FTE", когда делается не так, как надо, а "на сколько у клиента денег хватает"?
Скрин, с которым автор «согласен», показывает абсолютный токсик, потребительское отношение к чужому труду. Посмотрите пожалуйста на календарь (2023), на курс резервных валют, на темпы инфляции в таргетовых странах (полагаю, для автора это Россия + те, откуда много реального импорта), а потом ответьте на вопрос, много ли сотрудники хотят в качестве компенсации своего времени.
TLDR
200 к ₽ — мало.
Даже 300 к. мало - это всего то $3k :(
разработчик, способный управлять
это называется начальник, а не разработчик
разработчик сотрудников )