Справочные материалы:
- Базовая матрица компетенций: [внутренняя ссылка скрыта]
- Матрица для руководителей команд: [внутренняя ссылка скрыта]
- Пример матрицы от внешнего профессионального сообщества: [ссылка/источник скрыт]
- Репозиторий с шаблонами матриц по ролям и технологиям: [ссылка скрыта]
- Отдельная матрица навыков для backend-инженера: [ссылка скрыта]

# Критерии уровней инженеров разработки

## IC1 (L1, Junior-, Начинающий инженер)

### Зона ответственности
Включается в работу над небольшими фрагментами продукта под постоянным сопровождением.  
Постоянная "своя область" ещё не закреплена — фокус на освоении кода и правил команды.  
Берёт отдельные подзадачи и отвечает за их доведение до согласованного результата вместе с наставником.  

### Результат и поставка
Ключевая цель на уровне L1 — быстро учиться и безопасно встроиться в цикл разработки.  
Выполняет небольшие изменения с низким риском, где путь решения заранее понятен или подсказан.  
Как правило, получает задачу с готовым разбиением на шаги и примерами похожих реализаций.  
В процессе регулярно сверяется с ментором и командой, чтобы не "уехать" в неверном направлении.  

### Техническая сложность
Работает с задачами, где требования и ожидаемый результат описаны максимально конкретно.  
Оперирует в пределах знакомых компонентов, используя готовые примеры и документацию.  
Зависимости обычно заранее известны, а недостающие детали легко уточняются у команды.  
Если возникает неизвестность — поднимает руку и спрашивает, а не пытается угадать.  

### Взаимодействие и лидерство
Пока не "ведёт" — учится корректной коммуникации и ответственности за обещания.  
Оперативно сообщает статус, задаёт уточняющие вопросы, проговаривает блокеры.  
Не закрывается в одиночном отладочном марафоне: своевременно просит поддержку.  
Формирует привычку к прозрачности: что делаю, что мешает, когда будет результат.  

### Развитие и улучшения
Следует договорённым процессам и осваивает инструменты команды без самодеятельности.  
Собирает базовую инженерную гигиену: оформление PR, проверки, тесты, чтение логов.  
Начинает понимать контекст продукта и то, "зачем" вообще делается конкретная задача.  
Совместно с лидом/ментором ведёт простой план роста и регулярно сверяет прогресс.  

### Дополнительные критерии
Не требуются: достаточно демонстрировать способность учиться и надёжно выполнять поручения под сопровождением.

---

## IC2 (L2, Junior, Младший инженер)

### Зона ответственности
Ведёт небольшой участок работы более самостоятельно, хотя поддержка всё ещё доступна.  
Появляется ограниченная зона ответственности — часть сервиса/модуля или небольшой поток задач.  
Умеет планировать выполнение в рамках спринта/итерации и держать договорённости.  

### Результат и поставка
Стабильно закрывает типовые задачи быстрее и увереннее, чем на L1.  
Часть задач доводит до продакшена без постоянных "чекпоинтов" с наставником.  
Умеет находить аналоги, повторять шаблон и корректно адаптировать его под новый кейс.  
Если что-то неясно — формулирует конкретные вопросы и быстро снимает неопределённость.  

### Техническая сложность
Решает задачи с чёткими требованиями и умеренным количеством "скрытых" нюансов.  
В состоянии самостоятельно найти недостающую информацию в документации или кодовой базе.  
Понимает базовые архитектурные решения своего сервиса и не ломает их по незнанию.  
Распознаёт типовые причины ошибок и умеет провести первичную диагностику.  

### Взаимодействие и лидерство
В коммуникации становится увереннее: проактивно синхронизируется по прогрессу.  
Раньше поднимает риски, если видит, что сроки/объём уплывают.  
Умеет объяснить коллегам, что сделал и почему, и как это проверить.  
Начинает участвовать в обсуждениях решений, задаёт вопросы по существу.  

### Развитие и улучшения
Понимает "как у нас принято" и следует этому без постоянных напоминаний.  
Постепенно наращивает профессиональную базу: ревью, тестирование, сборка/релиз.  
Воспринимает обратную связь как инструмент и показывает видимый прогресс по ней.  
Регулярно обновляет план развития с лидом и фиксирует конкретные навыки на квартал.  

### Дополнительные критерии
Внешняя активность не обязательна. Плюсом будет участие во внутренних обменах опытом и обсуждениях.

---

## IC3 (L3, Junior+, Уверенный младший инженер)

### Зона ответственности
Закрепляется за набором компонентов/модулей и отвечает за их эволюцию.  
Работает параллельно по нескольким связанным задачам, удерживая общий контекст.  
Участвует в разработке решений, влияющих на качество части продукта, а не только "вот этот PR".  

### Результат и поставка
Берёт типовые задачи "от постановки до выката" и доводит их без сопровождения шаг‑в‑шаг.  
Регулярно выпускает изменения в продакшн, понимая критерии готовности и риски.  
Учитывает последствия для пользователей и соседних систем, а не только локальную логику.  
Начинает видеть влияние своей части на метрики качества (ошибки, стабильность, скорость).  

### Техническая сложность
Берёт задачи со средним уровнем абстракции и умеренной неопределённостью.  
Самостоятельно выявляет часть зависимостей и согласует их с владельцами смежных компонентов.  
Знает, как соседние сервисы связаны между собой, и не боится аккуратно "выйти за границу" модуля.  
Думает о нефункциональных аспектах: наблюдаемость, отказоустойчивость, тестируемость.  

### Взаимодействие и лидерство
Предлагает варианты решения, а не только фиксирует проблемы.  
Активно участвует в технических дискуссиях и аргументирует выбор.  
Поддерживает новичков: отвечает на вопросы, делится шаблонами и подходами.  
Спокойно принимает ревью и умеет превращать замечания в улучшения, а не в обиду.  

### Развитие и улучшения
Уверенно ориентируется в процессах команды и понимает их причины.  
Инициирует небольшие улучшения: автоматизация, упрощение пайплайна, улучшение документации.  
Корректирует план развития вместе с лидом, фокусируясь на "следующем рывке".  
Закрепляет навыки через практику, а не только через чтение.  

### Дополнительные критерии
Обязательных нет. Плюсом будут внутренние доклады, документация, шэринг практик внутри команды.

---

# Пример хорошо описанной задачи для повышения уровня

По внутреннему руководству "как оформлять достижения и инициативы".

## Scope

#### Описание
Ситуация:  
В нескольких командах возникла потребность автоматически проверять "чувствительные" запросы пользователей (изменение реквизитов/лимитов/параметров), чтобы снизить риск ошибок и ручных разбирательств. Общего решения не существовало: каждая команда делала по‑своему, качество и критерии отличались.

#### Итоги работы
1. Собрал варианты подходов: как это решают в отрасли и внутри других команд (паттерны, типовые риски, метрики).  
2. Предложил сделать "проверку рискованных запросов как сервис": оформил решение в виде ADR/RFC и прототипа для проверки гипотез.  
3. Сформировал небольшую проектную группу, распределил роли и взял на себя техническую координацию.  
4. За несколько месяцев довели первую версию до пилота и подключили несколько потребителей.  
5. Подготовил документацию: как подключаться, какие есть правила, как дебажить и где смотреть метрики.  
6. Настроил сбор базовых метрик (доля отклонений, типы причин, влияние на поддержку/ручные проверки).  
7. После пилота на общем обсуждении приняли решение масштабировать сервис на другие команды, которым нужна проверка запросов.  
8. Итоги пилота (в обезличенном виде):
   1. появились единые метрики и понятный процесс обработки "спорных" запросов,
   2. сформирован переиспользуемый сервис с набором правил/сигналов,
   3. поделился опытом на внутреннем техническом митапе,
   4. количество ручных разбирательств снизилось в несколько раз,
   5. число подключённых команд выросло до "нескольких десятков" за последующие итерации.

#### Кто участвовал в реализации
Инициировал проблему, собрал и повёл работу. Команда была кросс‑функциональной (разработка, тестирование, аналитика/данные, частичная фронтенд‑поддержка).

## Impact

#### Описание задачи
Ситуация:
Текущая архитектура ключевого сервиса перестала соответствовать требованиям: новые фичи внедрялись слишком долго, сильная связность порождала регрессии, производительность "лечилась" точечно и неустойчиво. Без системной переработки архитектуры улучшить ситуацию было невозможно.

#### Итоги работы
1. Провёл диагностику: собрал список проблем, измерил влияние, зафиксировал текущий дизайн на нескольких уровнях (контекст → компоненты → потоки данных).  
2. Изучил подходы к архитектурному моделированию и критерии выбора стратегий миграции без остановки бизнеса.  
3. Подготовил и провёл через согласование ADR/RFC/PoC. Ключевые решения (в обобщённом виде):
   1. переход от "центрального управляющего компонента" к распределённому управлению процессом (событийный подход),
   2. разделение модели чтения и записи для ускорения критичных запросов,
   3. разведение оперативного контура и аналитического контура по потокам данных,
   4. переопределение границ модулей и контрактов между ними,
   5. план миграции по этапам с измеримыми контрольными точками.
4. Вёл технаправление: следил за качеством решений и темпом внедрения, координировал изменения между компонентами.  
5. Снял повторный срез метрик и сравнил "до/после". Результаты (в публично безопасных формулировках):
   1. скорость разработки выросла примерно вдвое на типовых изменениях,
   2. число регрессий на релиз заметно снизилось,
   3. время тестирования сохранилось на прежнем уровне (за счёт лучшей наблюдаемости и стабильности),
   4. p85 задержки уменьшился в несколько раз,
   5. система стала лучше масштабироваться по нагрузке (появился предсказуемый рост при добавлении реплик),
   6. общая надёжность выросла: снизилось количество инцидентов и "пожаров".

#### Кто участвовал в реализации
Был основным драйвером проектирования и реализации; привлекал команду и смежников по зонам ответственности.

## Technical Complexity

#### Описание задачи
Реализовать согласование состояния в распределённом хранилище "критичных числовых значений" (например, лимиты/балансы), где важны корректность, отказоустойчивость и предсказуемые задержки.

#### Итоги работы
По итогам исследования (зафиксировано в RFC) выяснилось, что стандартные решения в "чистом виде" не закрывают часть нефункциональных требований. Был выбран базовый известный алгоритмический подход и адаптирован под ограничения нашей среды.

Что было сделано:
- Сравнил несколько подходов к консенсусу/репликации, описал компромиссы и риски в документе.  
- Адаптировал выбранный алгоритм под целевые требования и проверил идею на прототипе.  
- Провёл формальную проверку модели (спецификация + модель‑чек) для ключевых инвариантов корректности.  
- Собрал MVP и бенчмарки, сравнил с предыдущим решением, описал результаты и ограничения.  
- Оформил реализацию как библиотеку: документация, комментарии, интеграция логов/метрик, рекомендации по эксплуатации.

#### Кто участвовал в реализации
Работу выполнил самостоятельно: от исследования до реализации и оформления артефактов.

## Leadership

#### Описание задачи
Ситуация:
Процесс управления задачами был фрагментирован: статусы не отражали реальность, оценки и фактические трудозатраты не фиксировались, часть работ делалась "мимо трекера". Метрики команды не собирались, обмен опытом между командами отсутствовал.

#### Итоги работы
1. Собрал и сравнил несколько подходов к организации разработки (kanban/scrum/hybrid, метрики потока, практики ретро/планирования).  
2. Организовал серию совместных сессий со стейкхолдерами (лиды, менеджеры, представители команд), выявили болевые точки и варианты решения.  
3. Подготовил и раскатал новый процесс в командах. Основные изменения (обобщённо):
   1. регулярный refinement и ретроспективы,
   2. единый набор метрик потока и качества,
   3. понятный workflow задач и правила переходов,
   4. стандартизированные типы задач (фича/дефект/долг/инцидент),
   5. регулярный межкомандный синк по зависимостям.
4. Собрал обратную связь, итеративно поправил процесс и зафиксировал финальные правила.  
5. Выступил "чемпионом" внедрения: помогал командам освоить практики и не скатиться обратно в хаос.  
6. Эффект (в обезличенном виде):
   1. пропускная способность выросла примерно в 1.5 раза,
   2. появились базовые метрики для улучшений, а не "ощущения",
   3. снизилось напряжение в командах и уменьшилась текучесть.

#### Кто участвовал в реализации
Собрал рабочую группу из лидов и менеджеров, проводил презентации и поддерживал внедрение в нескольких командах.

# Improvement

#### Описание
Ситуация:
Инженерные практики и инструменты сильно отличались между командами: разные подходы к качеству, разные шаблоны, отсутствие общих библиотек и стандартов. Это усиливало изоляцию, замедляло поставку и затрудняло обмен знаниями.

#### Итоги работы
1. Собрал лучшие практики и обновления в инструментах/подходах, релевантные нашему стеку и масштабу.  
2. Оформил инициативу и прошёл согласования (ADR/RFC/PoC). Ключевые шаги (в обобщённом виде):
   1. усиление практик качества (например, property-based/мутационные проверки там, где это даёт эффект),
   2. "shift-left" тестирование: проверять раньше и дешевле,
   3. регулярные сессии совместной разработки (pair/mob) для выравнивания подходов,
   4. стандарты и гайды для типовых инженерных практик,
   5. библиотека общих компонентов/утилит,
   6. программа внутреннего наставничества.
3. Стал проводником изменений: помогал командам внедрять практики и адаптировать их под реальность.  
4. Запустил регулярные практические сессии (разборы кейсов, совместная разработка, ревью подходов).  
5. Взял поддержку библиотеки общих компонентов: релизы, качество, совместимость, документация.  
6. Наставлял коллег по техническим темам и помогал выстраивать индивидуальные траектории роста.  
7. Подготовил публично‑безопасный доклад о том, как меняли подход к качеству (без внутренних деталей).  
8. Итоги (в обезличенном виде):
   1. заметно сократилось количество "acceptance" дефектов на типовых задачах,
   2. покрытие тестами и наблюдаемость выросли,
   3. онбординг новых инженеров сократился с "нескольких недель" до "примерно одной".

#### Кто участвовал в реализации
Инициировал и оформлял инициативу, готовил артефакты для продвижения идеи, менторил и поддерживал внедрение; привлекал участников из нескольких команд.
