Кто есть кто: Java Developer о грейдах в разработке
Уже несколько лет IT-сфера переживает настоящий бум. Причины, думаю, довольно понятны. Вполне логично, что на этой волне, как грибы после дождя, стали возникать разного рода курсы по обучению разработке на разных языках и развитию навыков IT-специалиста, обещающие сделать за три месяца из вас полноценного программиста. С другой стороны, работодатели, на мой взгляд, стали щепетильнее относиться к выбору того или иного кандидата, т.к. хлынувшая волна «специалистов», готовая горы свернуть за хорошие деньги, зачастую обещает больше проблем и головной боли, чем качественный результат.
В вакансиях часто указывается конкретный требуемый уровень профессиональных навыков разработчика, тестировщика, аналитика и так далее. Чаще всего мы можем видеть такие термины как Junior, Middle, Senior, FullStack и некоторые другие. Попробуем разобраться, в чем же смысл первых трех понятий как самых часто встречающихся в вакансиях и резюме. Оценку и осмысление проведем с точки зрения опытного разработчика, проектного менеджера и тимлида.
Junior/Джуниор
Junior — как понятно из перевода, это нечто сродни новичку, человеку, который только начал работать на реальном коммерческом проекте и вообще в IT. Но как правильно квалифицировать его уровень навыков? Кого действительно считать джуном? Давайте разберемся.
Человек, впервые пришедший в разработку, которая приносит «живые деньги», обязан начать делать продукт здесь и сейчас. Никакой работодатель, даже самый лояльный, не будет доволен, если вместо решения задач человек будет заниматься самообразованием. Именно поэтому многие компании практикуют для джунов испытательный срок, в течение которого человек обязан проявить себя как специалист: показать свои навыки и доказать свою необходимость на конкретном рабочем месте.
Секрет уровня разработчика и кроется в его навыках, hard- и soft-скиллах. Грейд Junior, на мой взгляд, можно присвоить специалисту, у которого есть самые базовые принципы, минимально достаточные, чтобы выполнять простые задачи вроде исправления багов, рефакторинга кода, добавления некритичного функционала, которые можно легко протестировать. Если таких умений у человека нет, то о каких грейдах мы можем говорить?
Если отталкиваться от видения джуна тимлидом (руководителем команды разработки), то это разработчик, которому можно поручить написать интеграционные тесты, исправить баги или добавить несложный функционал, который не вносит существенных изменений в общую логику. Тимлид следит за тем, как джун пишет код, насколько грамотно он придерживается общепринятых концепций на проекте, принципов чистого кода и SOLID. Обязательно рефакторит за ним, запрещает самостоятельно сливать в общую ветку разработки — это гарантирует, что джун не смержит заранее неисправный код или код, отличающийся от требований.
С точки зрения проектного менеджера, джун — это лицо не самостоятельное. Задачи получает строго от своего тимлида и редко контактирует с непосредственным ПМ. Джун не принимает участия в архитектурных обсуждениях и целиком полагается на решения, вынесенные на совещаниях.
Для остальных коллег — разработчиков и тестировщиков — более важны soft-скилы джуна, нежели его профильные навыки. Нельзя недооценивать софты, поскольку они прямо влияют на адаптацию джуна и его скорейшее вливание в общий процесс разработки. Тут я выделю навыки общения внутри команды, стрессоустойчивость, желание обучаться и помогать другим.
Интересный момент. Если мы будем сравнивать двух новеньких — джуна и миддла, то поначалу оба покажутся примерно одного уровня, потому что не будут способны сразу приступить к сложным задачам. Однако миддл в силу своего опыта гораздо быстрее вольется в работу и сможет гарантировать качественный код, в то время как джун будет продолжать писать слабый код и совершать ошибки.
Middle/Миддл
Как правило, миддлы — это люди с опытом в соответствующей сфере от 3 лет и больше. У них есть опыт и экспертиза в различных технологиях и программных продуктах, они хорошо понимают эффективность того или иного решения или применения необходимого шаблона проектирования.
По мнению проектных менеджеров, миддл вполне способен самостоятельно декомпозировать в случае необходимости задачу на подзадачи, провести их оценку и приступить к выполнению. Специалист такого уровня намного быстрее вливается в общий процесс разработки и начинает быстрее выполнять порученные задачи. ПМ может обсудить с миддлом интересующие нюансы реализации или уточнить у него эффективность предлагаемого подхода.
Тимлид ожидает от миддла качественного выполнения задач, где будут грамотно подобраны необходимые решения, выбраны нужные шаблоны проектирования, код будет покрыт unit- и интеграционными тестами, и, что немаловажно, бизнес-требования будут реализованы в полном объеме. Код такого разработчика должен легко поддерживаться в будущем, быть гибким в расширении и наиболее полно соответствовать принципам чистого кода и SOLID.
Другие коллеги могут ожидать от такого разработчика, помимо выполненных в срок задач, определенной помощи по другим вопросам, т.к. он обладает необходимыми компетенциями и экспертизой. В ряде случаев миддл может выступать наставником (ментором) для джунов, хоть это больше прерогатива сеньоров. Я бы сказал, что миддл — это такая крепкая рабочая лошадка, на которой висит значительная часть будничной рутины.
Senior/Сеньор
Условно, сеньор — это разработчик, находящийся в IT более 8 лет. Суждение довольно оценочное и может разниться, но «в среднем по больнице» примерно совпадает. Кто такие сеньоры? И какая роль им в основном отводится в разработке?
Для начала стоит отметить, что сеньорами становятся гораздо меньше разработчиков, чем могло бы, в силу различных причин. Одна из самых частых — выгорание. Многим надоедает однообразие, на первый план выходят другие интересы. Люди ищут себя в других направлениях, например, в тестировании или в управлении командой. Еще немаловажный фактор — люди не хотят брать на себя больше ответственности. Разработчика устраивает его уровень, и он не стремится еще больше углубляться в определенные детали.
Senior — это история про ответственность. Разработчик такого грейда, как правило, занимается более глобальными вопросами, состоит в архитектурных комитетах, принимает участие в решениях уровня глобальных бизнес-процессов разработки и т.д. Часто это тимлид, так как уровень компетенций позволяет ему быстро и эффективно решать задачи управления разработкой в отдельно взятом модуле или комплексе модулей. Как руководитель команды разработки он способен грамотно оценивать задачи уровня эпиков и истории, декомпозировать последние на задачи и подзадачи для миддлов и джунов, следить за соблюдением архитектурных нюансов модуля. В роли тимлида сеньор отвечает за сроки выполнения задач, выпуск очередного релиза спринта и, если нет инженера DevOps, за деплой на продакшен.
Руководителю проекта часто достаточно поставить общую задачу по реализации того или иного требования заказчика, и Senior самостоятельно принимает решение об оптимальном способе реализации с минимальными временными затратами.
С точки зрения других разработчиков и тестировщиков, Senior — это ревьюер кода, дающий аппрув на выставленный запрос слияния, либо источник информации о требованиях и особенностях поставленных задач.
Заключение?
Не существует универсальных способов четкого разделения на джуна, миддла и сеньора. Все мысли выше — оценочное суждение, зависящее от степени сложности проводимой разработки в том или ином проекте. Однако всегда возможно оценить разработчика по минимально необходимым критериям, включающим важные soft- и hard-скиллы, необходимые на конкретном проекте, и дать заключение.
Кроме того, нужно понять, что не существует универсального способа стать миддлом или сеньором за определенный срок, пройдя какие-либо курсы. Постоянно совершенствуясь и приобретая опыт, разработчик может самостоятельно оценивать свои навыки и сказать, каким критериям он точно соответствует на сегодняшний день. В сети существует множество тестов и заданий, условно разделенных на уровни Junior/Middle/Senior, в которых можно себя испытать. Конечно, всё условно, так как в одних условиях опыта может быть достаточно, а в других его придется дополнительно приобретать и совершенствовать себя.
В любом случае, независимо от уровня развития разработчика, человек должен любить то, чем он занимается, и постоянно совершенствоваться, так как это единственный способ повысить качество выполнения поставленных задач.