Junior, Middle, Senior, Lead — в чем разница и куда дальше?
Привет всем! Меня зовут Александр Демура, в IT я работаю с 2004 года, сейчас руковожу центром разработки DataArt в Одессе. В мои непосредственные обязанности входят найм и развитие наших специалистов, поэтому рассуждения на тему «синьорности» сотрудников и качеств, необходимых для той или иной роли, для меня актуальны и привычны.
Позволю себе традиционный дисклеймер — в этой статье изложен мой персональный взгляд. Написанный мной текст не претендует на истину в последней инстанции и вряд ли станет откровением для людей, уже разбирающихся в вопросе. Зато он будет полезен тем, кто только начинает путь в IT или не очень понимает, как и куда развиваться дальше, чувствует себя недооцененным или просто хочет расширить кругозор.
Изначально в DataArt не было формальной градации по уровню квалификации — мы ведь берем в команду человека целиком, со всеми плюсами и минусами, а не просто покупаем на рынке труда требуемую функцию. Если вдуматься, «джуниор», «мидл» или «синьор» — всего лишь штампы. Но такие ярлыки приходится использовать для упрощения картины мира и повышения эффективности коммуникации — они привычны и клиентам, и коллегам.
Это позволяет договориться о наборе ожиданий, предъявляемых к той или иной роли. Но живые люди редко идеально вписываются в удобные рамки, а производительность каждого специалиста в проекте зависит от множества параметров. Поэтому придумать объективную абстрактную метрику крутизны в вакууме практически невозможно.
Например, человек может блестяще проявить себя в одном проекте и вдруг сдуться в другом — чего ожидать от него в третьем? Кто-то может гениально отвечать на сложнейшие технические вопросы, но при этом порождать неподдерживаемый код. Кто-то наоборот — теряется на джуновых вопросах, имея за плечами десяток успешно сданных проектов. Вникать в подобные нюансы, помогать людям использовать свои сильные стороны и компенсировать слабости — одна из задач менеджмента. Общего решения она вроде бы до сих пор не имеет, что делает работу менеджера интересной, хотя подчас непростой.
Интерн
В DataArt есть практикантская программа, куда мы берем людей даже без опыта работы. У них есть три месяца, чтобы под руководством опытного ментора дорасти до уровня «джуниор». Для позиции интерна есть два основных требования:
- Хороший английский.
- Понимание выбранного инструмента и умение им пользоваться.
Требование к знанию английского у нас, на самом деле, общее для всех. DataArt — международная организация, большинство заказчиков находятся в США и Западной Европе, и даже внутренние коммуникации уже все больше на английском. Если человек — грамотный технический специалист, мы поможем ему разговориться и подтянуть язык — для этого есть корпоративные курсы и куча дополнительных инициатив. Но если человек без технического опыта (а интерн — как раз такой) еще и слабо знает английский, ему нужно обладать уникальными качествами, которые перекроют оба этих недостатка.
Про инструмент мысль тоже, мне кажется, простая. Если вы приходите на роль программиста, инструмент для вас — язык программирования со средствами разработки, которыми нужно уметь пользоваться. Если потенциальный интерн хочет разрабатывать на .NET, но не может объяснить, что делает CLR, чем «Equals» отличается от «==» или реализовать простейший алгоритм — шансов у него нет никаких. Приходить с нулевыми знаниями и надеяться, что всему научат на месте, параллельно выплачивая зарплату, бесполезно — слишком большой конкурс. За плечами многих кандидатов профессиональные курсы, они с легкостью отвечают на все теоретические вопросы и даже имеют опыт программирования «для себя». Конечно, таких людей берут в первую очередь.
Junior
Пройдя интернатуру, человек превращается в полноценного джуна. Основное требование к нему — способность самостоятельно выполнять технические задачи. Если в проекте выстроена архитектура, он должен без задержки реализовать очередной кусок типовой логики приложения. Хотя Junior может время от времени ошибаться, не понимать нюансов, обсуждать планы реализации с тимлидом или вместе с ним проверять готовый код.
Для джуна важны следующие качества:
- Желание развиваться и учиться (а на своих ошибках — особенно).
- Энергия и целеустремленность.
- Способность спокойно относиться к критике.
Нужно понимать, что на задачи, которые синьор решит за десять минут, джуну может потребоваться три подхода по часу каждый, а в процессе код придется переписывать полностью, затратив массу дополнительной энергии. Важно не бояться этого и чувствовать баланс: когда поднажать, попробовав решить-таки задачу самостоятельно, а когда, наоборот, перестать биться лбом о стену, сжигая проектное время, и обратиться за помощью. Оправдывать свою недостаточную производительность фразой «я же еще джун» — плохая идея.
Middle
Основное требование к мидл-разработчику — способность самостоятельно выполнять поставленные перед ним задачи. Очень похоже на то, что было написано в предыдущем пункте, правда? Однако есть важный нюанс — здесь отсутствует слово «технические». То есть на новом уровне нужно понимать требования бизнеса и уметь переводить их в технические решения.
Таким образом:
- Мидл-разработчик понимает, что именно делает приложение. Это позволяет глубже понять задачу, а, значит, точнее ее оценить и качественнее реализовать. Если требования не полностью покрывают какой-то сценарий, хороший разработчик обратит на это внимание на этапе планирования. А не когда приложение начнет валиться при любом нестандартном действии пользователя.
- Мидл-разработчик знаком со стандартными шаблонами и решениями при построении приложения в своей области, понимает, зачем они нужны, и умеет их применять. Стандартизация решений имеет большое значение при коллективной разработке кода, т. к. позволяет новому человеку быстрее разобраться, что к чему, и минимизирует количество ошибок. Понимание структуры типового приложения делает задачу его построения с нуля достаточно тривиальной, позволяет рассуждать о принципах правильной реализации и отличать хороший код от плохого.
- Мидл-разработчик понимает, что работает не один. Он умеет взаимодействовать с другими членами команды: может обсудить сложный момент с дизайнером, уточнить у бизнес-аналитика неполные требования или согласовать какое-то важное техническое решение с архитектором проекта (если такой есть) и, конечно, владеет соответствующими инструментами коллективной разработки.
Senior
Синьор — опытный разработчик, повидавший много кода, набивший кучу шишек и сумевший сделать из этого правильные выводы. Основная задача синьора — принимать правильные технологические решения в проекте. «Правильные» — это такие, которые приносят максимальную пользу бизнесу и минимизируют затраты. Хороший синьор не только понимает, что разрабатывает команда, но думает, какие задачи должно решить готовое приложение. Разрабатывая площадку для аукциона, синьор всегда задается вопросом о пиковой нагрузке и старается предусмотреть попытки конкурентной записи в таблицы БД. Он заранее думает об узких местах системы, о возможности ее масштабирования, помнит об уязвимостях и проблемах, вызванных неправильным использованием инструментов.
Такой специалист делает удивительную вещь — решает проблемы еще до того, как они появились. Со стороны это напоминает дар предвидения. А вот если ваш проект живет от пожара до пожара, а вам постоянно приходится выкидывать и переписывать куски кода — это симптомы, что проект получает недостаточно синьорного внимания.
Немного поразмыслив, мы сможем сформулировать ряд особенностей синьор-разработчика:
- Способность решать несколько более сложные задачи, делать это быстрее или лучше, чем средний разработчик, не имеет практически ничего общего с синьорностью. В нашей классификации человек, который это умеет, называется «Strong Middle».
- Звание синьора невозможно получить быстро. Нужно наработать обширный опыт и понять, что отличает хорошо сделанный продукт от тяп-ляп-разработки, как проявляет себя технический долг, сколько стоит рефакторинг, зачем на самом деле нужны паттерны и так ли необходимы бесконечные уровни абстракции. Необходимо самостоятельно принять важные решения и дать им пройти испытание временем, иначе оценить их не получится.
- Синьору необходимы хорошие коммуникативные навыки, потому что он должен не только предложить правильное решение, но и убедить в своей правоте заказчика и команду. Если вы не смогли отстоять хорошее решение и вместо него было принято плохое, винить в этом придется самого себя. Вариант «я же говорил» на уровне Senior уже не работает. С командой то же самое — мало знать, как надо, нужно еще и уметь это доходчиво объяснить. Тогда команда быстро растет и набирается опыта, избегая болезненных ошибок. Авторитарный подход («делайте, как я сказал») зачастую приводит к внутренним конфликтам, и ситуацию на проекте отнюдь не улучшает — нужно стараться этого избегать.
- Синьор не может обойтись без понимания устройства библиотек и фреймворков. Если инструмент разработки для вас — черный ящик, и вы составляете приложение из готовых частей, не зная, что у каждой из них под капотом, продукт всегда будет неустойчивым и непредсказуемым.
Менеджер, который ставит синьора в проект, надеется этим снизить технические риски или хотя бы начать их осознавать. Редко встречаются системы без единой проблемы — технологический перфекционизм, чаще всего, просто нерентабелен для бизнеса. Но уловить момент, когда несколько безобидных костыликов того и гляди превратят систему в лоскутное чудовище Франкенштейна, и вовремя остановить этот процесс — вот для этого, в числе прочего, и нужен синьор.
Что дальше?
Начну с разрушения основного мифа о росте синьоров в менеджеры проектов. Переход в менеджеры — шаг не вверх, а в сторону! Весь опыт, накопленный за долгие годы работы программистом, почти не помогает в новой роли, ведь работать приходится не с кодом, а с людьми и планами.
Само по себе представление, что PM всегда стоит выше разработчиков, что он главнее и больше получает — ошибочно. Например, если требуется сделать высоконагруженное приложение в облаке, а соответствующих специалистов нет — самый лучший менеджер обречен на провал. К тому же, современные гибкие методологии зачастую вообще не предусматривают выделенную позицию менеджера проектов, поэтому лучше рассматривать управление именно как одну из ролей в команде и заниматься тем, что интересно и хорошо получается.
Куда же развиваться синьорам? Многие программисты любят рассуждать о «потолке» — когда внутренний рейт (т.е. деньги, которые вы получаете за заработу) приближается к внешнему (счету, выставленному клиенту) с минимальной маржинальностью. Они считают, что в этом случае дальнейший рост специалиста становится нецелесообразным для работодателя. Однако это не так, есть множество способов и дальше увеличивать свою ценность. Поэтому позицию Senior Developer стоит рассматривать не как карьерное плато, а как плацдарм для дальнейшего развития, например, в одном из следующих направлений:
Технический эксперт
Статус технического эксперта подразумевает глубокое знание отдельной и специфической области. Например, можно быть экспертом в Azure/AWS и знать разнообразные сервисы, которые предоставляют эти платформы. Уметь делать Machine Learning или Computer Vision, знать все про уязвимости в вебе, понимать, как работают криптовалюты или правильно готовить Sharepoint. Такие задачи встречаются не каждый день, но когда появляются, наступает звездный час технических экспертов. Без них подобные проекты были бы просто невозможны, и компания зачастую готова доплачивать за эти уникальные знания.
Индустриальный эксперт
DataArt старается развиваться в определенных доменных областях (путешествия, финансы, здравоохранение и т. п.). В каждом проекте программисты не только приобретают собственно технические знания, но и получают возможность заглянуть в бизнес заказчика, понять, как устроена индустрия, узнать характерные для нее проблемы и решения. Чего стоит построить свою платежную систему вроде PayPal? Зачем нужна система Sabre? Или что такое HIPAA и какие ограничения она накладывает на разработку решений в области здравоохранения в США? Люди, которые обладают подобными знаниями, зачастую формируют костяк проекта и приносят компании и клиенту огромную дополнительную пользу. Поэтому их компенсация (т. е. деньги, которые они получают за работу) может превышать внешний рейт — компании сами готовы доплачивать таким людям сверх счета, выставленного заказчику проекта.
Фронтмен
Умение правильно и хорошо подать себя и компанию, рассказать о сложных технических вещах простыми словами, быстро собрать прототип и показать первые результаты, говорить на одном языке как с топ-менеджерами заказчика, так и с программистами — отличительные качества фронтмена. Таких людей часто зовут на первые звонки и отправляют в первые командировки к клиенту, их задача — быстро разобраться в проблеме, объяснить, каким именно образом мы можем помочь, и наладить взаимодействие с офшорной командой. Комбинация технической крутизны с презентационными навыками позволяет компании получать новые проекты, соответственно, люди, которые ими обладают, ценятся высоко.
Тимлид
Роль тимлида достаточно понятна и традиционна, чтобы я на ней подробно останавливался. Это, по сути, комбинация технически грамотных решений с качественными процессами разработки. Их правильное сочетание означает больше пользы для клиента за те же деньги, меньше шансов для джуна что-то по неопытности испортить, плюс дополнительные плюшки для компании — вроде стандартизации подходов к разработке, снижения порога входа в проект и стимулирования роста специалистов в требуемом направлении.
Архитектор
Некоторые проекты нельзя просто взять, сесть и начать писать. Они могут быть слишком большими или сложными, но в целом архитектор может понадобиться в проекте по тысяче самых разных причин. От архитектора требуется все то же понимание бизнеса клиента, умение анализировать сложные технические системы, а потом доносить это понимание до заказчика и разработчиков. Плюс широкий кругозор в плане имеющихся на рынке платформ и компонент, из которых можно синтезировать решение. Для архитектора «микросервисы», «облако» и т. п. — это не модные тренды, а четко выверенные технологические решения, которые дают строго определенные преимущества и накладывают соответствующие ограничения.
Я перечислил пять возможных ролей только в технической ветке развития, не затрагивая тестировщиков, аналитиков, менеджеров, дизайнеров, маркетологов или продавцов.
Дополнительно: работа без посредников
Я хочу отдельно написать о работе без посредников, которую некоторые воспринимают как Святой Грааль для программиста. Казалось бы, все логично: находим заказчика, предоставляем ему свои услуги напрямую, весь рейт забираем себе — профит! Однако нужно понимать, что, кроме прибылей, на программиста в этом случае падают все сопутствующие риски. Нужно внимательно читать пункт контракта об ответственности сторон, знать законодательную и налоговую базу, придумывать механизм получения денег, действовать, если клиент не заплатил или неожиданно свернул работу.
В IТ-компаниях эти вопросы решают специально обученные люди (продавцы, юристы, бухгалтеры), и даже если заказчик разорился и вышел из бизнеса с сумасшедшими долгами, разработчики, во всяком случае в DataArt, все равно получат деньги в срок и спокойно перейдут в следующий проект. При работе напрямую — каждый оказывается сам за себя. Кроме того, большинство компаний тратят весьма осязаемые бюджеты на привлечение новых клиентов, поэтому прямые отношения с заказчиками, которых нашла компания, запрещены контрактом с той и другой стороны.
По этому поводу можно отдельную статью писать, но не привести мою любимую цитату с «Баша» я просто не могу:
Вы мне напоминаете моего домашнего кота. Он страшно переживает, что не умеет открывать банки с кошачьим кормом. День, когда он научится это делать, и станет независим от хозяина (а он так считает) — будет самым счастливым днём в его жизни. Вот только о том, откуда в квартире берутся банки с кормом, он не задумывается.
На этом мне хочется закончить на сегодня, если есть новые идеи для статей — пишите!