Интерн, Джуниор, Мидл, Сеньор, Тимлидер, Проджект-менеджер
Хочу высказать свое мнение об этих названиях, потому что на просторах Интернета слишком много неоднозначных трактовок.
Прежде всего, почему данную классификацию я рассматриваю как «статусы», а не «грейды»? Потому что грейды относятся к группировке в конкретной компании по степени значимости для компании групп должностей (как следует из определения), а статус - более общее понятие, и его можно применить не только к компании, но и к отрасли, в нашем рассматриваемом случае ИТ.
Грейдинг (англ. grading) — группировка должностей по определённым основаниям (определение «веса», классификация) с целью построения системы мотивации. Суть грейдинга — в сопоставлении внутренней значимости должностей для организации (внутренняя ценность) с ценностью этой работы на рынке (внешняя ценность). (Википедия)
Статус - ...С упрощённой точки зрения статус объекта или субъекта — это его состояние либо позиция, ранг в любой иерархии, структуре, системе, времени и ином. ... Статус, в социуме — положение, занимаемое индивидом или социальной группой в обществе или отдельной подсистеме общества.
(Википедия)
В случае с грейдами, их применение обосновано в профильных ИТ компаниях, где подавляющее число специалистов, сотрудников занимаются разработкой или связанными с этим процессами. Разделение на группы-грейды удобно для создания систем мотивации, каждый грейд имеет определенную схему. Но это не в полной мере соотносится с ролью специалиста в конкретном проекте, И как только начинают применять подобную схему грейдинга в небольших компаниях или в непрофильных компаниях с присутствием в поддержке бизнеса ИТ специалистов, классификация начинает принимать несколько иной смысл.
Вот к примеру, что нашел в Интернете, одно из пояснений уровней классификации:
Junior — это младший специалист, который работает под присмотром более опытных коллег;
Middle — это разработчик, который умеет проводить ревью кода и контролировать работу джунов;
Senior — специалист высокого уровня, умеющий решать сложные задачи и проектировать архитектуру программы.
Это мое описание обозначенных статусов специалистов ИТ:
Интерн (Intern) – полон теоретических знаний, но совершенно не понимает как с ними работать в условиях неопределенности. У него нет опыта, поэтому пытается использовать первое, что пришло в голову для решения задач и проблем. Метод проб и ошибок не перешел еще в стадию экспериментов, для него любая задача – эксперимент.
Неплохо работает по протоколу/сценарию, и чем подробнее и проще сценарий, тем лучше справляется. Устные задания плохо воспринимает и долго переваривает, задавая большое количество глупых и тупых на первый взгляд вопросов, потому что у него нет еще логики шагов для решения поставленной задачи, он даже не понимает с какой стороны к ней подходить. Поэтому задачи должны быть по возможности максимально короткие, не требующие разнородных знаний и связей между различными логическими схемами/системами. Наличие наставника или куратора обязательно. Только под чутким руководством может показать какую-то эффективность. В противном случае задачи будет выполнять долго и криво. Допуск к критически важным системам только под непосредственным присмотром наставника.
Джуниор (Junior) – прошел стадию Интерна, либо путем обучения на пет-проектах, сам пилил и грыз находя решения, хоть и не всегда эффективные, или помогал кому-то с рутинными, несложными и второстепенными задачами. Может решать самостоятельно несложные задачи, находить под них решения. Чаще всего любит внедрять чужие, найденные на просторах Интернета, решения в свой код. Но адаптировать под существующую задачу, скорректировать работу чужого кода, если он не в полной мере отвечает запросу уже не может или испытывает серьезные трудности. Везде старается использовать типовые свои наработки, применяет их к месту и не к месту, как только появляется такая возможность. В связи с тем, что наработок еще мало, то код имеет обычно много повторений одинаковых по типу конструкций языка. Способен самостоятельно создать/отработать несложный законченный проект в рамках своих познаний, то есть, если не смотреть на внутренности – это будет уже рабочий продукт. К задачам стоит подпускать, либо после серьезного обсуждения способов решения, убедившись, что это решение знакомо Джуну и он понимает как будет действовать, либо после небольшого обучения на работающем примере, с указанием сделать также. Требует серьезного подхода к подготовке задания, поэтому затраты на работу с Джуном не всегда оправданы, стоимость времени потраченного на постановку задачи более опытными (и дорогостоящими) разработчиками может превышать стоимость экономии от использования недорогого труда Джуна.
Мидл (Middle)– кругозор наработок уже достаточно велик, есть понимание как реализовываются типовые задачи, причем несколькими способами. Обычно не задает кучи вопросов после качественной постановки задачи, а просто принимает к работе. Затраты времени на постановку задачи Мидлу самые минимальные, если и задает вопросы, то по делу. Способен самостоятельно создать законченный проект средней сложности. Знаком или попробовал выполнять какие-то задачи реализуемые смежниками (сисадминами, тестировщиками, пользователями и т.д.), поэтому учитывает в разработке и их возможности, претензии, хотелки, пожелания. В рамках своего рабочего проекта способен закрыть практически любые вопросы, но при переходе на новый может испытывать трудности, которые фактически понижают его эффективность и возможности до Джуна.
Сеньор (Senior) – имеет опыт реализации нескольких разнородных крупных проектов, в различном статусе. Понимает какие сложности вызывает применение тех или иных инструментов в реализации. Задает определенный подход в разработке проекта, как по стилистике кода, так и по процессу его создания. То есть Сеньор – это стандарт, которого должны придерживаться все остальные разработчики в команде. Плохой это стандарт или хороший, не столь принципиально, основное это то, что есть лицо, которое формирует/определяет стандарт, отслеживает и контролирует, а при нарушении наказывает. Поэтому выбор каких-либо инструментов применяемых в проекте, особенно сторонних, обязательно согласовывается с Сеньором, потому что в конечном итоге от его выбора зависит соответствие конечного продукта заказу.
Тимлид (TeamLeader) - раздает задачи, пинки и подзатыльники. Отслеживает результаты выполнения, текущую операционку, назначает совещания и участвует в них для понимания ситуации, перспектив и решения проблемных, возникающих в процессе работы вопросов. То есть фактически – это координатор команды, все вопросы должны концентрироваться у него и через него распространяться/распределяться в команде посредством указаний, формулировки задач, оптимизации и регулирования операционной деятельности.
Кто-то может сказать, что аналогом этого человека на стройке является прораб, где-то его сравнивают с бригадиром. Но это не столь важно, основное что надо понимать – этот человек по своим обязанностям управляет командой.
Проджект (Project Manager) – управляет проектом на стратегическом уровне, но имеет возможность вмешиваться в процессы на других уровнях, если того требует ситуация. То есть это тот человек, который своей головой (или чем-то еще) отвечает за проект. Основная задача, выполнить проект в заданных условиях. С его стороны должно производиться обеспечение проекта требуемыми ресурсами (специалисты, оборудование, финансирование и пр.). Проджект обычно «сидит» (хотя и не всегда) на выделенном под проект бюджете и отслеживает дедлайны (deadline), чтобы проект не вылез за рамки бюджета. Он также согласовывает все формальности как с заказчиком, так и с исполнителями, при необходимости вносит корректировки в проект и корректирует задачи команде.
На мой взгляд, самая ключевая позиция привязанная к конкретному проекту – Senior. Именно эта позиция задает стандарт в проекте, делает его уникальным. Найти второго такого же Seniora с аналогичным подходом, знаниями и установками – очень нелегкая задача, если вообще выполнимая. Тут наиболее правильное решение сделать опору на Мидла, который работает в проекте длительное время. Он будет поддерживать систему проекта в заданном формате, даже если Senior его покинет. Привлекать нового Seniora взамен ушедшего из проекта – это грозит сменой парадигмы, подходов, стандартов. Конечно, если проект требует переработки со стороны заказчика, то это имеет смысл. И только в том случае, когда такая переработка заявлена, необходимо искать Сеньора подходящего под новые требования.
Все остальные позиции могут быть заменены новыми сотрудниками в менее сложном режиме. Конечно влияние на развитие проекта они оказывают, требуется время на адаптацию к проекту и его условиям, но они менее критично влияют на сам проект, его разработку.
Учитывая, все что было выше изложено, могу сказать, что многие HR специалисты, используя терминологию статусов могут давать соискателям неверные вводные данные по вакансиям.
Например, когда ищут Мидла в проект, который нужно создать с нуля под уникальные требования. В этом случае, подготовки специалиста уровня Мидл на другом проекте, может попросту не хватить – его кругозор недостаточен для формирования стандарта проекта.
Или, тоже ошибка, когда пытаются привлечь нового Сеньора на уже работающий проект, для поддержки и развития. Найти кандидата, соответствующего заданному предыдущим Сеньором стандарту проекта будет максимально сложно, и не факт, что новый кандидат будет готов работать в этом стандарте и не станет его тут же перестраивать под себя, под свое видение, получая недовольство и отторжение от команды разработчиков.
Внимательно используйте терминологию, и будет проще искать подходящих специалистов.
