# Грейды разработчиков: уровни L10, L20 и L30

Canonical: https://www.kt-team.ru/hr/razrabotchiki

Source: https://www.kt-team.ru/hr/razrabotchiki

Как в KT.Team устроены уровни инженера L10, L20 и L30, бейджики DEVOPS и TECHLEAD, как проходит оценка и что поднимает или снижает грейд.

## Коротко

- Уровень инженера — это уровень неопределённости, который ему доверяют: L10 — известны «что» и «как», L20 — ценность целиком, L30 — новое состояние бизнес-процесса.

- Уровень не зависит ни от объёма задачи, ни от того, сколько строк кода написано руками.

- Минимально достаточное состояние — L20 и DEVOPS на 4 балла. На выход в него даётся до шести месяцев.

- TECHLEAD и DEVOPS — отдельные ветки развития, а не обязательная ступень после L30.

- Оценку ставят дважды: сначала инженер сам, затем менеджер. Расхождение разбирают на тет-а-тете.

- Оценка даёт расчётный ориентир оклада. Если он ниже фактического, оклад не понижают.

- **3–7 человек** — оптимальный размер команды для средней системы по данным QSM — на этом и построена вся шкала

- **до 6 месяцев** — срок, за который инженер выходит на минимально достаточное состояние L20 + DEVOPS

- **≤ 1 месяц** — целевое время до реального использования (TTU) — им меряется доставленная ценность

## Кто такой инженер в KT.Team

Конечный продукт разработчика — самостоятельно доставленная ценность, которой пользуется живой человек в бизнесе клиента. Не закрытая задача, не влитая ветка и не выложенный релиз, а работающий функционал, по которому уже получена обратная связь от конкретных пользователей на продуктиве.

Отсюда следует всё остальное. Инженер берёт ответственность от идеи до использования, поэтому ему нужен прямой контакт с бизнес-пользователем. Он формулирует результат на языке бизнеса, поэтому его оценивают по сдвигу в процессе, а не по объёму написанного. Он закрывает ценность целиком как full-stack инженер, поэтому в оценке нет отдельных шкал для фронтенда и бэкенда.

ИИ здесь базовый инструмент, а не бонус. Инженер не пишет то, что может написать машина, использует агентную разработку и подключает ИИ-аналитиков и ИИ-критиков к ежедневной проверке требований и реализации. Оценка это учитывает: она не привязана к объёму ручного кода.

## Что входит в зону ответственности инженера

- Понимать, зачем делается работа, и мыслить workflow, а не набором тикетов.

- Доводить ценность до продуктива и до фактического использования пользователями.

- Разговаривать с бизнес-пользователем напрямую и как можно чаще.

- Закрывать ценность целиком, включая развёртывание своего сервиса.

- Держать слабую связанность: каждая ценность изменяема независимо от соседних.

- Минимизировать размер партии изменений и выкладывать результат регулярно.

- Использовать ИИ-агентов в проектировании, реализации и проверке.

- Сохранять знания команды: фиксировать решения и контекст общения с клиентом.

## Как устроена лестница уровней

L10, L20 и L30 различаются не объёмом работы, а тем, сколько неопределённости остаётся на стороне инженера. DEVOPS и TECHLEAD растут параллельно и не заменяют друг друга.

## L10 — задача без неопределённости

На уровне L10 не стоит вопрос «как это должно работать» и очевидно, что нужно бизнесу. Клиент описывает не только «что» сделать, но и «как» — либо задача настолько прозрачна, что описывать «как» не требуется. В таком взаимодействии команда работает руками, а инженер применяет только технические навыки.

Объём здесь ни при чём. Вёрстка большого раздела по готовым макетам вместе с данными — это L10, сколько бы недель она ни заняла. Повторение уже сделанной интеграции с другими данными — тоже L10, потому что неопределённость снята предыдущим разом.

Техническое качество при этом обязательно. Джуниор, который делает задачу технически неаккуратно, высокой оценки по L10 не получает.

## Примеры задач L10

- Страница по макету вместе с данными — любого объёма.

- Работа по техническому заданию с минимальными отклонениями от него.

- CRUD данных, настроек или форма сбора данных.

- Интеграция, повторяющая уже реализованный поток с другой системой того же класса.

- Исправление ошибки в уже созданной ценности.

- Обучение пользователя готовому функционалу.

## L20 — ценность целиком

L20 — это бизнес-ценность среднего размера, в которой неопределённость почти отсутствует: смысл сущностей понятен, модель данных в целом ясна, а удобство легко проверить, прокликав результат внутри команды. Клиент формулирует, что нужно получить, но не разбирает задачу на технические шаги.

Оценку L20 получает только тот, кто исполняет ценность целиком. Если ценность делается связкой «фронтендер плюс бэкендер», L20 не получает ни один из них: ответственность размыта, появляется лишняя точка синхронизации, а инженер начинает оптимизировать контракт с коллегой вместо результата для пользователя. Поэтому L20 — всегда full-stack.

На этом уровне инженер уже не столько пишет код, сколько проектирует workflow, автоматизирует процессы разработки и опирается на ИИ-агентов. Анализ бизнес-требований проходит через ИИ-аналитика, а результат сверяется с пользователем маленькими инкрементами, ежедневно.

## Примеры задач L20

- Бизнес-ценность «внутренние счета» — выставление счетов между подразделениями.

- Первая интеграция потока данных между двумя системами, сформулированная как результат для пользователя.

- Регистрация и авторизация пользователя через SSO.

- «Мы тратим много денег на SMS-авторизацию, решите эту проблему» — вариантов решения немного, гипотезы не нужны.

- Ускорение сервиса, когда неочевидно, что именно ускорять.

## L30 — эпик и новое состояние процесса

Эпик — это значимое новое состояние сквозного бизнес-процесса или всего проекта. Набор ценностей внутри эпика даёт проекту новое мета-свойство, а не сумму отдельных функций. Такое состояние можно описать на языке лица, принимающего решение, и в идеале реализовать командой за две-четыре недели.

Главное отличие L30 от L20 — гипотезное мышление. Мы не знаем наверняка, приведёт ли задуманный состав ценностей к нужному состоянию; каждая ценность внутри эпика — предположение, которое проверяется на реальных пользователях. Простое правило: если заранее можно точно описать, что сделать и как проверить, это L20 или L10. Если можно описать только желаемое новое состояние, а путь к нему открывается по ходу, это L30.

Важно различать делегированный и удержанный уровень. Клиент может передать состояние целиком, но если команда не формулирует сценарии, тест-кейсы и критерии готовности сама, а клиент вынужден работать за аналитика или тестировщика, L30 не удержан. В оценке это фиксируется прямо: L30 делегирован, удержание L20.

## Примеры эпиков L30

- «Наш отдел логистики тонет в накладных, сделайте что-нибудь» — состав ценностей формулируем сами.

- Выделение крупного функционала из сильно связанного монолита в самостоятельные сервисы.

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

- Перевод всех цифровых каналов магазина на централизованное управление контентом со сроком публикации не более суток.

- Встроенное соответствие строительным нормам в процессе проектирования, чтобы ошибки ловились на ранних стадиях.

- Сквозной процесс управления сделками у девелопера — от онлайн-бронирования до оформления договора.

## L10, L20 и L30 при одном взгляде

| Критерий | L10 — задача | L20 — ценность | L30 — эпик |
| --- | --- | --- | --- |
| Единица результата | Выполненная постановка | Одна бизнес-ценность | Новое состояние процесса |
| Что заказывает бизнес | «Сделайте так, как описано» | «Сделайте функционал X» | «У нас есть такая проблема, решите её» |
| Неопределённость в бизнесе | Отсутствует | Отсутствует | Все ценности внутри — гипотезы |
| Кто говорит с пользователем | Обычно менеджер | Часто достаточно менеджера | Нужен прямой контакт команды с бизнес-пользователем |
| Слабая связанность | Не определяет оценку | Важна, ошибки локальны | Критична: без неё эпик становится монолитом |
| Лидирование команды | Не требуется | Не требуется | Требуется: кто что делает внутри эпика |
| Маркер доверия | «Делай что сказано» | «Дал ценность — сделал, но я рядом» | «Дал эпик — я не управляю реализацией» |

## Повторяемая задача снижает свой уровень

Когда в проекте появляется задача, похожая на уже решённую, её уровень падает: неопределённости в ней больше нет. Была интеграция с одним банком на L20 — вторая такая же интеграция считается L10. Для L30 это менее характерно, для L20 встречается регулярно. Правило неприятное, но оно защищает от инфляции оценок.

## DEVOPS и TECHLEAD — отдельные ветки

- **DEVOPS** — Отвечает на вопрос, можно ли обойтись без отдельного инженера инфраструктуры в зоне ответственности разработчика. От «разворачиваю локальный стенд» до «управляю инфраструктурой как кодом». Четвёрка здесь — базовый инженерный стандарт, а не достижение. Быстрее всего уровень набирается в паре с тем, у кого эта компетенция уже есть.

- **TECHLEAD** — Складывается из технической экспертизы и лидерства: благодаря техлиду можно быть спокойным за качество реализации всего проекта и за рост команды. Оценивается двумя вопросами — качество проекта и рост команды. Ветка необязательная: обязательной траектории «инженер → техлид» в KT.Team нет.

## Что значит каждый балл

| Балл | Уровень задач (на примере L10) | DEVOPS |
| --- | --- | --- |
| 1 | Поручить нельзя ничего. | Максимум — развернуть локальный тестовый стенд. |
| 2 | В реализации будут технические огрехи, нужно сопровождение. | Исправляет любые проблемы при разворачивании локального стенда. |
| 3 | Задачу можно дать, она будет сделана при некотором контроле сроков и требований. | Диагностирует и чинит известные проблемы на продуктиве, помогает внешнему инженеру инфраструктуры. |
| 4 | Дал задачу и забыл, но есть неидеальности по срокам или требованиям. | Решает почти все инфраструктурные задачи, внешний инженер команде почти не нужен. |
| 5 | Дал задачу и забыл. | Управляет инфраструктурой как кодом; ресурсы и ошибки под контролем. |

## Как читать эту шкалу

Вопросы задаются в пятибалльной шкале Ликерта: на каждое утверждение отвечают мерой согласия, от «точно не согласен» до «точно согласен». Если уровень оценить нельзя, его оставляют пустым — например, у единственного разработчика на проекте не бывает оценки TECHLEAD, потому что нет команды, в которой можно быть лидером.

Действует правило округления вниз: «почти четыре» означает три. Четвёрка появляется тогда, когда это точно четвёрка. Оптимистичная оценка кажется доброй, но лишает инженера честной картины и времени на рост, а команду — понимания того, как здесь принято работать.

Если инженер не делает задачи определённого уровня целиком, оценку по этому уровню ему не ставят. Это ограничение проекта, а не приговор человеку.

## Как проходит оценка и составление ИПР

- **Подготовка:** Самооценка инженера (по каждому уровню и бейджику); Оценка менеджера (независимо, до встречи)

- **Тет-а-тет:** Разбор каждого балла (почему не ниже и не выше); Сверка расхождений (самооценка против оценки менеджера)

- **Ориентир:** Расчётный оклад (сумма веса уровней); Сравнение с фактическим (вниз не понижает)

- **План:** ИПР (инженер формулирует сам); Следующий шаг (одно ключевое изменение)

- **Сверка:** Возврат через месяц (что изменилось и как это видно)

Первую оценку менеджер проводит вместе с наставником: без этого оценки получаются нерепрезентативными.

## Как оценка связана с деньгами

Из баллов складывается расчётный ориентир оклада. Каждый уровень и бейджик имеет свой вес: балл ниже четырёх в ориентир не входит, четвёрка засчитывается наполовину, пятёрка — полностью, промежуточные значения считаются пропорционально. Сумма и есть ориентир.

Это индикатор, а не автоматический пересчёт зарплаты. Если инженер получает больше расчётного ориентира, оклад не понижают. Расхождение вниз чаще говорит не о человеке, а о проекте: там, где клиент доверяет только задачи L10, оценить можно лишь технические навыки, и работать с этим должен менеджер вместе с клиентом, а не инженер.

Обратное расхождение — сигнал к разговору о повышении, которое обычно происходит не одним шагом, а в течение нескольких месяцев, чтобы прошёл ещё один цикл оценки. Небольшая разница между фактическим окладом и ориентиром пересмотра не требует.

## Что двигает уровень

**Поднимает**

- Задачи, где инженер сам формулирует сценарии, критерии готовности и проверки.

- Прямой диалог с бизнес-пользователем и быстрая обратная связь с продуктива.

- Слабая связанность: изменение живёт в одном сервисе и разворачивается отдельно.

- Парное программирование и ментальное программирование до первой строчки кода.

- Full-stack: ценность закрывается целиком, без передачи по цепочке.

- Настроенная ИИ-разработка: правила, критики требований, автоматические проверки.

**Снижает**

- Повторение уже решённой задачи — неопределённость в ней снята.

- Ценность, собранная связкой фронтендера и бэкендера: целиком её не сделал никто.

- Клиент вынужден быть аналитиком или тестировщиком вместо команды.

- Работа, которая не доходит до продуктива и до реальных пользователей.

- Сильная связанность: изменение требует правок в нескольких сервисах.

- Фокус на экранах, API и сроках без связи с тем, что изменится в бизнесе.

## Почему шкала устроена именно так

Шкала выросла не из вкусовых предпочтений, а из нескольких устойчивых результатов: DORA и Accelerate, Google SRE, уравнение Патнэма и кривая Нордена-Рэлея, Domain-Driven Design и принципы бережливого производства.

Кривая Нордена-Рэлея описывает, как распределяется усилие на проекте, и показывает, что у срока есть физический минимум. Любая дополнительная роль в цепочке добавляет коммуникационные связи: кривая растягивается, срок растёт, а объём работ остаётся прежним. Уравнение Патнэма добавляет к этому нелинейность: попытка компенсировать организационную сложность людьми и фазами делает запуск непропорционально дороже. По данным QSM оптимум команды для средней системы — три-семь человек.

DORA даёт эмпирическое подтверждение из современных команд и выделяет два ключевых архитектурных фактора: слабую связанность и свободу команды выбирать инструменты. Поэтому в оценке технологические детали почти не участвуют — кроме слабой связанности, которая определяет, насколько дёшево система переживает изменения.

## Кривая Нордена-Рэлея

Интенсивность усилий распределяется колоколом. Каждая дополнительная роль добавляет коммуникационные связи: кривая растягивается, объём работ остаётся тем же, а проект заканчивается позже.

## Слабая связанность — это способность локализовать изменение

Слабая связанность не про стиль написания кода и не про соблюдение SOLID. Это способность системы удержать изменение в одном месте. Сильная связанность даёт медленные изменения, длинные проверки и сложные релизы, а значит растянутое время до реального использования.

Проверяем это измеримо, а не на словах. Основной метод — анализ совместных изменений файлов: раз в месяц смотрим историю репозитория и ищем модули, которые регулярно меняются вместе. Устойчивое совместное изменение означает скрытую зависимость, даже если формально всё разложено по интерфейсам.

Если инженер объясняет слабую связанность только через интерфейсы, внедрение зависимостей и SOLID — это признак поверхностного понимания. Разговор должен идти о локализации изменений, скрытых зависимостях и связанности на уровне workflow.

## Признаки того, что связанность сильная

- Общая база данных для разных контекстов: одну таблицу меняют несколько сервисов.

- Сервис напрямую вызывает внутренние методы другого сервиса.

- Интерфейс знает детали модели на бэкенде.

- Микросервисы выстроены в синхронную цепочку вызовов.

- Модуль нельзя удалить, развернуть или протестировать отдельно.

- Время от коммита до продуктива больше трёх суток.

- Одно изменение затрагивает больше тридцати файлов или несколько сервисов.

- Команда боится рефакторинга.

## Что мы считаем доставленным

- Ценность

- Продуктив в тот же день

- Реальные пользователи

- Обратная связь

- Изменение в бизнесе

## Частые вопросы

Обязательно ли становиться техлидом?

Нет. Обязательной траектории «инженер → техлид» в KT.Team не существует. Единая официальная траектория строится по уровню самостоятельности и ответственности за результат — L10, L20, L30. TECHLEAD — отдельная ветка для тех, кто хочет влиять на качество и рост всей команды.

Как меня будут оценивать, если значительную часть кода пишет ИИ?

Оценка не привязана к объёму ручного кода. Смотрим на доставленную ценность, самостоятельность, архитектурные решения, слабую связанность системы, скорость получения обратной связи и качество коммуникации. ИИ — инструмент усиления, и не использовать его сегодня означает терять время.

Почему L20 только full-stack?

Если инженер отвечает только за свою половину ценности, появляется контракт с другим разработчиком, лишняя синхронизация и размытая ответственность. Ценность в этом случае не сделал целиком никто, поэтому L20 не получает ни один из участников связки.

Что делать, если я готов к задачам L30, но на проекте таких задач нет?

Оценка зафиксирует разрыв между уровнем инженера и уровнем ответственности проекта. Для инженера это не имеет негативных последствий: расчётный оклад — индикатор, а отсутствие задач L30 характеризует проект. Это сигнал команде и менеджеру развивать отношения с клиентом.

Какой у меня уровень, если обычно я делаю задачи L10, но иногда мне поручают L20?

Если доверить можно любую задачу L20 — значит L20. Если только некоторые — значит L10. То же правило работает для пары L30 и L20.

Не превращается ли инженер в конфигуратора из-за ИИ?

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

Кто даёт обратную связь и можно ли с ней спорить?

Обратную связь даёт заказчик работы инженера и наставник по процессу. Первую оценку менеджер проводит под контролем наставника, а запись тет-а-тета отдаёт на супервизию. Разговор всегда заканчивается вопросом, насколько эта обратная связь справедлива; если ответ отрицательный, назначается отдельная встреча с наставником.

## Источники

- DORA — DevOps Research and Assessment: https://dora.dev/

- QSM — Quantitative Software Management, оценка размера команды и сроков: https://www.qsm.com/

- Nicole Forsgren, Jez Humble, Gene Kim. Accelerate: https://itrevolution.com/product/accelerate/

- AWS Enterprise Strategy. The New Unit of Software Delivery: The Workflow, 25.11.2025: https://aws.amazon.com/blogs/enterprise-strategy/the-new-unit-of-software-delivery-the-workflow/

- Adam Tornhill. Software Design X-Rays — метод анализа совместных изменений: https://pragprog.com/titles/atevol/software-design-x-rays/

- Agile Manifesto: https://agilemanifesto.org/