Грейды, продолжаем: критерии

С чего начать разработку грейдов? Неплохо решить, какими критериями вы будете описывать уровни. Есть как минимум два подхода:

Первый — детальный, через матрицу компетенций

Четкое описание требований к знаниям, навыкам и поведению на каждом уровне.

Детализированный чек-лист, который можно пройти по пунктам. Хорош, если вы стабильно хотите развивать определенный скиллсет, и он не меняется.

Второй — широкий, через масштаб и влияние

Гибкий вариант без детализации, акцент на масштабе задач (простые/сложные), автономность (под присмотром / самостоятельно), зону влияния (team → org → industry).

Пример: Google, Meta. У них нет классической матрицы компетенций. Уровни описываются через масштаб & влияние. Если вы не хотите упарываться в узкие строго сформулированные компетенции, то это ваш вариант.

Подход хорош там, где инженеры работают над сложными задачами в быстро меняющейся среде и жесткие рамки здесь только бы мешали.

И вместо тысячи слов — сравните сами

1. Грейды по компетенциям (CircleCI):
Детально описаны ожидания в Writing code, testing, debugging, observability, understanding code, software architecture, security, work breakdown (см. их матрицу).

2. Грейды через влияние и масштаб (Google):
Начальный уровень инженера, фокус на обучении и выполнении задач под руководством старших коллег. Написание качественного кода, исправление ошибок, освоение внутренних инструментов и процессов, выполнение задач средней сложности. Реализация небольшой функции.

Делитесь, ребята, как у вас:

🦄 — грейдов нет
👍 — через четкие компетенции
🔥 — через влияние и масштаб