Идея о разделении программистов на джунов, мидлов и сеньоров, как мне кажется, появилась вместе с появлением самих программистов. Не удивительно, ведь такова человеческая натура. Нас с детства учат ранжировать людей. Нам ставят оценки в школе, награждают грамотами, вывешивают на доски почёта и так далее. Неудивительно, что во взрослой жизни мы тоже начинаем ранжировать других людей.
Интуиция подсказывает нам, что те, кто только пришёл в профессию, ещё зелены и малоопытны, а те, кто уже давно работает, крутые спецы. Это утверждение, конечно же, верно не на 100%. Я встречал людей, которые давно в индустрии, но так и не выросли до крутых спецов.
А если посмотреть с другой стороны? Одинаковую ли прибыль принесёт сложная оптимизация медленно работающего скрипта, которую в состоянии сделать только крутой спец или небольшое улучшение в интерфейсе, которое может сделать джун? В реальности может быть верно и то и другое. Так кого же с точки зрения бизнеса больше ценить? Это очень сложный вопрос. Может быть, даже один из самых сложных.
Ниже я попробую описать некоторые способы ранжирования программистов в компаниях, с которыми приходилось встречаться, а также способы назначения их на должности.
Способы ранжирования
Джун, мидл, сеньор. Тут всё просто. Есть 3 должности: джун (младший программист), мидл (программист) и сеньор (ведущий/главный/старший программист). Почему 3? Вопрос открытый. Имхо, это самое интуитивно понятное разделение. Люди очень часто используют градацию "плохо", "средне", "хорошо" или "младший", "средний", "старший". Возможно, простота и интуитивная понятность сделали такую градацию популярной.
Более тонкая градация, может включать в себя промежуточные стадии между джуном, мидлом и сеньором. Таких стадий может быть множество. Я встречал градацию с плюсами: "джун+", "мидл++", или просто с указанием грейда "программист грейд N" (от англ. "grade" - ранг).
Некоторые компании вообще имеют одну должность - сеньор. Они избавлены от ранжирования. Им не нужно строить сложные системы повышения внутри компании.
Далее поговорим о способах назначения.
Назначаем по субъективному мнению руководителя
Назначение происходит по каким-то субъективным критериям руководителя. Он может опираться на что угодно: от недавно хорошо и вовремя сделанной задачи до личных хороших (или плохих) отношений.
Плюсы такой системы:
- Простота использования: не нужно придумывать каких-то механизмов оценки
- Нет привязки ко времени - повысить можно хоть когда
Минусы такой системы:
- Очевидная несправедливость: почему-то повысили Васю, хотя я тоже сделал важную задачу
- Подвержена когнитивным искажениям: вывод о повышении может быть сделан на основании одной хорошей задачи, хотя 9 других были выполнены не так хорошо
- Личные отношения с руководителем могут стать причиной повышения (не повышения)
- Зависимость от руководителя. Если твой босс продвигает сотрудников по службе чаще и активнее, чем его коллега, то тебе повезло. Хотя другие программисты могут выполнять такую же важную работу, как и ты, но не получать повышения
- Сотруднику не всегда понятны критерии повышения
Руководствуемся KPI при повышении
Та же градация, но повышение происходит на основании "ключевых показателей эффективности".
Плюсы такой системы:
- Слегка уменьшается роль руководителя (хотя и не всегда)
- Сотруднику становится более понятным критерий, по которому оценивают его работу
Минусы:
- Объективные KPI нелегко придумать (порой даже невозможно)
- Люди начинают работать на выполнение только своего KPI, начинается нездоровая конкуренция, рушится командная работа
- Выполнение KPI можно подделать
- Всё ещё есть влияние личных отношений с руководителем
По стажу в компании
Повышение происходит за время, отработанное в компании. Например, чтобы стать мидлом, нужно проработать 1 год. Чтобы стать сеньором, нужно проработать 3 года и т.д.
Плюсы такой системы:
- Личные отношения с руководителем уже играют меньшую роль в повышении
- Вполне ясно, когда ты получишь следующую должность
- Нет никакой системы оценки, нет KPI
- Относительное равенство в команде, нет вредной конкуренции, сосредоточенность на целях отличных от выполнения KPI
Минусы:
- Непонятно как набирать в компанию крутых спецов, ведь они ещё не имеют стажа в этой компании и поэтому не могут занять высокие позиции
- Может пройти много времени, пока ты достигнешь высокой позиции, хотя в другой системе ты мог бы сделать это быстрее
- Не ясно как устанавливать сроки после которых происходит повышение. Для роста с джуна на мидла нужен год? И, может, два? Или полгода?
Внутренние собеседования
Повышение происходит после прохождения внутреннего собеседования. На собеседовании оцениваются знания (как на входном собеседовании в компанию) и, возможно, личные качества, но не учитывается выполнение тобой задач, KPI, выполненные проекты и т.д.
Плюсы:
- Руководитель практически не влияет на повышение
- Нет привязки ко времени - когда ты готов, ты проходишь собеседование
- Более чёткое понимание того, что нужно сделать для повышения
Минусы:
- Любое собеседование (пусть даже внутреннее) - стресс
- Сотрудник может сосредоточиться только на своём личном росте, а не на общих целях компании
- Личные отношения с собеседующим могут повлиять на результат
Повышение за выполнение плана
Повышение происходит после выполнения каких-либо задач, какого-то плана, заранее составленного руководителем (или кем-то ещё). Иногда это называется "индивидуальный план развития".
Плюсы:
- Чёткий план что нужно сделать
- Можно примерно спрогнозировать когда ты получишь повышение
Минусы:
- Зависимость от плана. Планы очень часто меняются. Поэтому нет уверенности, что он будет выполнен
- Может случиться так, что временно не будет задач, на которых можно расти
- Не у всех руководителей есть заинтересованность в росте сотрудников, они могут затягивать составление плана и твой рост
- Определённое неравенство, ведь планы всегда будут разными, а потому будут отличаться и скиллы программистов
Кое-какие выводы
Различных вариантов систем для ранжирования сотрудников много. У них есть свои плюсы и минусы. Каждая может быть полезна для одной компании равно как и вредна для другой. Здесь приведён далеко не полный список всех плюсов и минусов. Уверен, вы с легкостью придумаете ещё как минимум парочку для каждой из них.
Не следует копировать уже готовые решения. Прежде, чем что-то внедрять у себя, подумайте. Взвесьте все плюсы и минусы. Проведите эксперимент на небольшой группе. Составьте чёткие критерии успешности и не успешности внедрения. Не пытайтесь надеяться на интуицию, это может привести к совершенно неожиданному результату.
Мир ещё не придумал идеальной системы. Велика вероятность, что её не существует. Такие дела :)
Альтернатива
Альтернативой может являться отсутствие ранжирования. Например, иметь в штате просто программистов. Без всяких приставок типа "младший" или "старший".
Если у вас есть опыт работы в таких "плоских" структурах, пожалуйста, поделитесь им в комментариях.