Коротко
- Грейд связывает наблюдения о работе с ожиданиями конкретной компании.
- Расчётная рекомендация, предложение руководителя и итоговый уровень — разные результаты оценки.
- Расхождения нужно разбирать по примерам работы, а причины решения — сохранять.
- Отсутствие бюджета на повышение не означает недостатка компетенций сотрудника.
Что можно оценить по наблюдениям, где начинается человеческое суждение и кто отвечает за итоговый уровень.
Представим собирательную сцену. Сорок минут обсуждения на тему «тянет ли он на сеньора». В комнате пять человек, у каждого своё определение сеньора, но вслух его никто не произносит. Решает тот, кто говорит увереннее. Через месяц инженер получает в другой компании оффер на позицию мидла — не разучившись за месяц ничему.
Напрашивается решение: нужна объективная система грейдов. Появляется матрица на сто двадцать пунктов, баллы, пороги. Но если ожидания так и не согласовали, следующий спор будет уже о том, ставить человеку 3,5 или 4 по «системному мышлению».
Моя позиция: измерения могут быть входом в решение о грейде. Но выбор критериев, их веса и границы уровней остаются договорённостью компании. Формула может последовательно применять эти правила; она не делает их единственно правильными.
«Договорённость» не значит «произвол». Хорошее решение опирается на проверяемые наблюдения и позволяет понять, как из них получили вывод. Плохое прячет спорные предпосылки за итоговой цифрой.
Мы делаем платформу оценки компетенций. Начинали с предположения, что грейд можно посчитать. В результате пришлось хранить три значения: расчётную рекомендацию, предложение руководителя и итоговый уровень. Это не доказательство невозможности измерять компетенции. Это практический способ разделить данные, их интерпретацию и кадровое решение.
На каждой стадии фиксируется свой результат. Оценка по критериям, обсуждение уровня и назначение не должны подменять друг друга.
Что именно мы называем грейдом
Универсальной шкалы сеньорности у компаний нет. Но из этого не следует, что сравнивать работу разработчиков невозможно. Можно определить критерии, собрать примеры и проверить, насколько согласованно разные люди их оценивают. Вопрос в том, какие выводы такая оценка позволяет делать.
Грейд связывает возможности человека с ожиданиями конкретной организации. Одной команде нужен инженер, который надёжно развивает монолит. Другой — специалист, который согласует изменения платформы с десятком потребителей. Техническая глубина, автономность и координация будут иметь разный вес.
Поэтому смена компании может изменить присвоенный уровень при тех же навыках. Это говорит о различиях требований и доступных свидетельств, а не обязательно об ошибке одной из сторон. Грейд из резюме полезен как отправная точка; дальше всё равно нужно выяснять, что человек делал и за что отвечал.
Есть и организационная сторона: уровни связаны с ролями, вилками вознаграждения и бюджетом. Здесь особенно важно разделить два вывода: «человек показывает нужные результаты» и «компания готова оформить повышение». Если денег нет, это не новое свидетельство о компетенциях сотрудника.
Для дальнейшего разговора я разделю три стадии: измерение, суждение и решение. Под измерением здесь понимаю сбор наблюдений и оценку по заранее описанным критериям, с ограничениями этой оценки.
Измерение: наблюдаемое поведение вместо прилагательных
«Глубокое понимание баз данных» оставляет слишком много пространства для толкования. Полезнее описать, что человек должен уметь показать:
- читает план запроса и объясняет, почему индекс не применился;
- различает гипотезы о блокировке и неудачном плане выполнения, предлагает способ проверки;
- перед изменением оценивает риски и готовит способ проверить результат и откатиться.
Даже здесь мало отметить «делает / не делает». Нужно учитывать сложность задачи, помощь коллег и качество объяснения. Сам факт, что человек открыл план запроса, ещё не подтверждает компетенцию. Но теперь есть предмет разговора: конкретная работа и основания для вывода.
Возьмём учебный пример, к которому будем возвращаться. Backend-разработчица Ирина претендует на следующий уровень. В её команде от этого уровня ожидают самостоятельного решения проблем производительности и согласования изменений со смежниками.
В одном проекте Ирина нашла причину медленного запроса, сравнила варианты и провела изменение с проверкой результата. В другом руководитель подключился к согласованию слишком поздно замеченной зависимости. Оба эпизода нужны для оценки. Один не отменяет другой.
| Компетенция | Наблюдаемый индикатор | Свидетельство и вопрос к оценке |
|---|---|---|
| Диагностика производительности | Проверяет гипотезу по плану запроса и данным, объясняет выбор решения | План до и после, описание проверки. Какую часть сделала самостоятельно? |
| Управление рисками изменения | Заранее определяет проверку результата и условия отката | План изменения. Кто предложил проверки и помог оценить риски? |
| Работа с зависимостями | Выявляет затронутые команды и согласует действия до внедрения | Переписка и план работ. Когда обнаружили зависимость и кто организовал согласование? |
Учебный пример для одной роли. Это основа обсуждения, а не универсальный чек-лист сеньора.
Практический тест формулировки: смогут ли двое коллег оценить одну и ту же работу и объяснить свои ответы через конкретные свидетельства? Если нет, сначала стоит уточнить критерий.
При этом согласие оценивающих ещё не гарантирует, что выбранный критерий отражает нужное качество работы. Можно одинаково аккуратно считать то, что мало связано с ожиданиями роли. Поэтому нужно проверять и согласованность оценок, и полезность самих требований.
С баллами нужна такая же осторожность. Без оценки надёжности шкалы мы не знаем, значима ли разница между 3,6 и 3,8. Десятичный знак сам по себе точности не добавляет.
Разброс оценок — повод для диагностики. Люди могли по-разному понять пункт, видеть разные проекты или наблюдать сотрудника в разные периоды. В случае Ирины коллега из первого проекта и руководитель второго вполне могут дать разные оценки самостоятельности. Сначала нужно сопоставить эпизоды, а уже потом решать, что менять в формулировке или выводах.
Большая матрица эту работу не заменяет. Наш рабочий ориентир — пять–семь ключевых компетенций на роль с конкретными индикаторами внутри. Это рекомендация из практики, а не универсальный предел. Важнее, чтобы оценивающие могли содержательно пройти каждый пункт и привести примеры.
Пример интерфейса на роли менеджера по обучению: компетенции, минимальные баллы и веса. Это настройки конкретной модели, а не универсальные требования к разработчику. Инженерный пример с наблюдаемыми индикаторами приведён в таблице выше.
Откуда брать наблюдения
Практическим заданием можно проверить, как человек объясняет план запроса или разбирает инцидент. Но разовая проверка мало говорит о том, насколько устойчиво он действует так в работе. Для этого нужны рабочие материалы и наблюдения окружения.
В нашей системе названия 180/270/360 обозначают наборы участников: сотрудник и руководитель; они же плюс коллеги либо подчинённые; все перечисленные группы. Для процесса важнее явно назвать отвечающих, чем опираться только на привычный ярлык.
Анкету полезно собирать из индикаторов текущего или следующего уровня. Вопрос «оцените лидерство от 1 до 5» вернёт нас к спору о прилагательных. Вопрос о том, как человек выявлял зависимости и согласовывал действия, позволяет попросить пример. Нужен и ответ «не наблюдал»: отсутствие свидетельства нельзя автоматически превращать в низкую оценку.
У Ирины стоит спросить коллег из обоих проектов. Если выбрать только участников удачного, картина будет неполной. Состав респондентов должен быть понятен сотруднику и руководителю; приглашать стоит тех, кто действительно видел нужную работу.
Редакцию требований нужно фиксировать на момент запуска цикла. Иначе ответы до и после изменения вопроса окажутся в одном отчёте, хотя относятся к разным критериям. Правила видимости ответов и условия анонимности тоже следует объяснять заранее.
Средний балл по всем группам может скрыть главное. Руководитель, коллеги и подчинённые наблюдают разные стороны работы. Расхождения между ними нужно разбирать, а не автоматически превращать в единое число для назначения грейда.
В интерфейсе выбирают процесс оценки. Состав участников и правила сбора обратной связи нужно определить до запуска цикла.
Суждение: как перейти от наблюдений к уровню
Допустим, наблюдения собраны. Теперь возникает соблазн: «средний балл 4,5 и выше — сеньор».
Такое правило может быть понятным и воспроизводимым. Но порог всё равно выбран людьми. Нужно объяснить, почему он такой, что допускается компенсировать высокими баллами и какие требования обязательны независимо от среднего.
Есть и риск подгонки: сотрудники начинают собирать удобные пункты, а руководители — подтягивать оценки под желаемое повышение. Это не неизбежный результат любого порога, но причина проверять, как правило влияет на поведение.
Мы разделяем три значения:
- Расчётная рекомендация — результат применения выбранной версии правил к оценкам. В ней уже есть договорённость о критериях и порогах.
- Предложение руководителя — вывод с учётом рабочего контекста и дополнительных свидетельств.
- Итоговый уровень — результат обсуждения, который затем передаётся на оформление.
Исходные данные сохраняются снимком. Если итог отличается от рекомендации, остаётся объяснение: какие сведения повлияли на решение. Иначе через год будет виден результат, а основания исчезнут.
Но кворум сам по себе не защищает от самого громкого участника. Поэтому оценки и примеры стоит собрать независимо до встречи. На обсуждении — сопоставлять свидетельства с требованиями, фиксировать существенные разногласия и называть ответственного за вывод. Сотруднику нужна возможность увидеть основания и оспорить фактическую ошибку, с понятным порядком пересмотра.
Вернёмся к Ирине. Расчётная рекомендация может указывать на следующий уровень, а руководитель — сомневаться из-за проекта со смежниками. Полезный вопрос: что именно ожидалось от неё в этом проекте? Были ли у неё полномочия, доступ к нужным людям и информация о зависимости?
Если ожидание было ясным и возможность действовать была, эпизод может показывать зону развития. Если координацию изначально забрал руководитель, отсутствие самостоятельного результата ещё не доказывает, что Ирина на него неспособна. Тогда нужно договориться о следующей задаче, полномочиях и сроке повторного обсуждения. Доступ к работе следующего уровня — тоже часть ответственности компании.
Решение: что именно компания фиксирует
После обсуждения остаётся оформить назначение: уровень, дату начала действия, основание и ответственного. Для временного назначения нужен и срок. Расчётная рекомендация сама по себе кадровые данные менять не должна.
Если в случае Ирины требования следующего уровня признаны выполненными, но повышение задерживается из-за бюджета, это следует записать отдельно. Формулировка «пока не доросла» подменит организационное ограничение оценкой человека и отправит её собирать доказательства, которые уже есть.
Ожидания также стоит связать с полномочиями и условиями. Если уровень требует координации нескольких команд, компания должна обеспечить возможность такой работы. Если требует наставничества — учитывать время на него в загрузке.
На время согласования полезно фиксировать требования и маршрут принятия решения. Если их необходимо изменить, изменение должно быть явным для участников, с объяснением последствий для уже поданной заявки.
Есть и техническая деталь: название грейда в карточке сотрудника и история назначений могут расходиться. Это не обязательное устройство любой системы, но если у вас существуют оба источника, нужно заранее определить их приоритет.
В списке команды уровень показан рядом с должностью. Сам экран не показывает основания назначения: для них нужна отдельная история решений.
Пример правила: действующее назначение имеет приоритет; справочное название используется с пометкой об источнике; неоднозначность требует уточнения.
Без этого отчёт и процесс повышения могут показывать разные уровни одного человека. Система должна сохранять источник значения и выносить конфликт на уточнение, а не молча выбирать правдоподобный вариант.
Наконец, новый титул вместо прибавки тоже требует честности. Если ожидания не изменились, а уровень выдали ради удержания, смысл грейда размывается. Следующим сотрудникам будет трудно объяснить, почему от них для того же названия требуют другую работу.
Что с этим делать в понедельник
- Разделите оценку, обсуждение и назначение. У каждого этапа должны быть понятный результат и ответственный. Это не обязательно три отдельные встречи.
- Опишите требования через работу. Для каждого критерия укажите, какие примеры помогут его оценить и как учитывать помощь коллег.
- Оставьте посильную матрицу. Число пунктов должно позволять разбирать свидетельства, а не только проставлять баллы.
- Собирайте наблюдения независимо. Включайте людей из разных релевантных проектов и разрешайте ответ «не наблюдал».
- Разбирайте расхождения. Проверяйте формулировки, условия работы и доступные оценивающим сведения.
- Сохраняйте версии и основания. Требования, расчётная рекомендация и объяснение итогового решения должны оставаться доступны для пересмотра.
- Разведите компетенции и бюджет. Если повышение задерживается, называйте действительную причину. Договоритесь, кто и когда вернётся к решению.
- Обеспечьте возможность роста. Следующий уровень требует подходящих задач, полномочий и понятной процедуры оспаривания ошибок оценки.
Платформа может хранить свидетельства, применять согласованные правила и помогать обнаруживать расхождения. Качество решения зависит и от того, насколько обоснованны критерии и как участники разбирают спорные случаи.
Грейд фиксирует договорённость: какую работу компания ожидает, какую ответственность и полномочия даёт, какие условия предлагает. Наблюдения позволяют эту договорённость обосновать. Проблема начинается, когда за итоговой цифрой перестают быть видны правила и люди, принявшие решение.
Мне кажется, полезнее спрашивать не только «почему у меня такой балл», но и «какие свидетельства привели к этому выводу, что от меня ожидается дальше и кто отвечает за условия, в которых я смогу это показать».
Частые вопросы
Почему грейды разработчика различаются в разных компаниях?
Компании предъявляют разные требования к автономности, технической глубине и координации работы. Поэтому один и тот же опыт может соответствовать разным уровням в разных организациях.
Можно ли назначать грейд по среднему баллу оценки?
Средний балл может дать расчётную рекомендацию по согласованным правилам. Итоговое решение требует проверки рабочих примеров, контекста и обязательных требований уровня.
Что делать, если оценки коллег расходятся?
Сопоставить конкретные эпизоды работы, периоды наблюдения и понимание критериев. Расхождение может указывать как на неясную формулировку, так и на разное поведение в разных условиях.
Как отделить оценку компетенций от решения о повышении?
Отдельно зафиксировать соответствие требованиям уровня и готовность компании оформить повышение. Если препятствие связано с бюджетом, это нужно назвать прямо, а не объяснять недостатком компетенций.
