Грейды разработчиков KT.Team: L10, L20, L30 и ИПР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шкала выросла не из вкусовых предпочтений, а из нескольких устойчивых результатов:

• DORA и Accelerate
• Google SRE
• уравнение Патнэма и кривая Нордена-Рэлея
• Domain-Driven Design
• принципы бережливого производства

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

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

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

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

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