# Оценка разработчика и ПМа: L10-L60, workflow и ИИ

Canonical: https://www.kt-team.ru/blog/developer-pm-assessment-ai-native-workflow

Source: https://www.kt-team.ru/blog/developer-pm-assessment-ai-native-workflow

_08.07.2026 · KT.Team_

Мы оцениваем не строки кода и не занятость, а уровень ответственности, который человек или команда реально удержали в проекте.

L10 - работа по готовому ТЗ. В AI-native разработке этот уровень дешевеет быстрее всего, потому что ИИ уже хорошо закрывает предсказуемые технические операции.

L20 - самостоятельная доставка бизнес-ценности до продуктивного использования. Без end-to-end ответственности это остается набором технических задач.

L30 - workflow или эпик: новое состояние бизнес-процесса, которое нельзя заранее разложить в полный список функций без гипотез и обратной связи.

ПМ растет не как диспетчер задач, а как человек, который повышает доверие клиента, сокращает TTU, убирает потери и выводит проект к L40-L60.

## Почему код перестал быть главным активом

Классическая оценка разработчика часто смотрела на стек, стаж, скорость закрытия задач и субъективную сеньорность. В AI-native среде эти признаки быстро теряют вес.

Исследование Microsoft/GitHub по Copilot показало ускорение выполнения контролируемой задачи на 55,8%. Anthropic в Economic Index по разработке описывает coding-agent сессии как заметно автоматизируемый класс работы. DORA при этом дает важное ограничение: AI повышает индивидуальную продуктивность, flow и удовлетворенность, но без инженерных основ может ухудшать стабильность и throughput поставки.

Вывод для оценки простой: ИИ ускоряет руки, но не отвечает за систему. Если ценность человека - писать куски кода по чужому ТЗ, ИИ действительно выглядит угрозой. Если ценность человека - держать workflow, проектировать слабую связанность, ставить задачи агентам, проверять гипотезы и доводить результат до использования, ИИ становится рычагом.

## Шкала L10-L60

Уровень не равен размеру задачи. Большая, но заранее описанная работа остается L10. Небольшой, но неопределенный workflow может быть выше.

L10 - нам доверяют руки. Клиент или ПМ уже описал, что делать и часто как делать. Это макеты, CRUD, повторная интеграция, багфикс, работа по подробному ТЗ.

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

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

L40 - нам доверяют цель проекта. Мы сами формулируем L30-эпики и можем корректировать цель по фактам использования.

L50 - мы сами предлагаем проект из тактической нужды клиента.

L60 - мы сами предлагаем проект из стратегии клиента.

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

## Как мы оцениваем разработчика

Разработчик в KT.Team - не кодер, который закрывает таски. Это инженер, который самостоятельно доставляет бизнес-ценность через изменение workflow, использует AI как базовый инструмент, общается с конечным пользователем и отвечает за результат на продуктиве.

Минимально достаточное состояние по регламенту - L20-инженер на 4 балла и DEVOPS на 4 балла. Если человек ниже, ИПР должен показывать понятный путь к этому уровню максимум за 6 месяцев.

L20 требует end-to-end ответственности. Если ценность делится на фронт и бэк так, что никто не держит ее целиком, это еще не зрелая доставка ценности.

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

Оси оценки инженера: L10, L20, L30, DEVOPS, TECHLEAD и AI-native способ работы. TECHLEAD - это не обязательная следующая ступень, а отдельная ветка: спокойствие за качество реализации проекта и рост команды.

## Как мы оцениваем проектного менеджера

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

Главная метрика ПМа - состояние проекта. PROJECT-LEVEL показывает уровень доверия L10-L60. MARGIN-CURRENT показывает финансовую управляемость. TTU показывает, как быстро ценность начинает использоваться целевой аудиторией. PROMISE показывает попадание в обещания по сроку, бюджету и цели.

TEAM-MENTORING, MENTOR и LEADERSHIP показывают, растет ли команда и устраняет ли ПМ неэффективность до кризиса. RELATIONS и SALES показывают, является ли KT.Team формальным подрядчиком или доверительным партнером, который развивает новые проекты.

## Почему это выгодно разработчику и ПМу

Разработчику эта система дает прозрачность. Важны факты доставленной ценности, а не впечатление руководителя. ИИ перестает быть угрозой и становится рычагом для перехода от кода к workflow. Есть инженерная траектория без обязательного ухода в менеджмент: L20, L30, DEVOPS, TECHLEAD.

ПМу эта система возвращает более сильную роль. ПМ перестает быть диспетчером задач и растет в сторону доверия, цели проекта и отношений с клиентом. Меньше микроменеджмента разработки - больше времени на L40-L60, маржинальность, продажи и структурные риски.

## Что здесь общего с Amazon

Мы не нашли официальной Amazon-статьи, где вводится шкала L10-L60 в нашем смысле. Это шкала KT.Team. Но публичные материалы Amazon хорошо объясняют, почему такая шкала появилась.

В статье AWS The New Unit of Software Delivery: The Workflow Марк Шварц пишет, что с agentic AI единицей разработки становится workflow: сквозной процесс с бизнес-целью, который можно специфицировать, доставлять, тестировать и улучшать как единое целое. Это почти прямое описание нашего L30: workflow как единица результата, а не экран, API или user story.

Amazon two-pizza teams строятся вокруг малых автономных команд и single-threaded ownership. Публичное описание AWS подчеркивает, что такие команды владеют полным customer experience и жизненным циклом продукта или сервиса. Это близко к нашему требованию end-to-end ответственности: L20 для ценности, L30 для workflow.

Свежий текст Вернера Фогельса 2026 года про возвращение к two-pizza culture показывает ту же логику уже в AI-продуктовой команде: малая команда, автономия, использование собственного продукта с первого дня и правило ownership.

## Что делать уже сейчас

1. Определить реальный уровень: клиент дал L30 или команда действительно удержала L30 фактами?
2. Считать TTU не от релиза, а до момента, когда целевая аудитория начала пользоваться ценностью в боевом процессе.
3. Убирать посредников: лишние передачи между бизнесом, ПМом, аналитиком, разработкой, QA и эксплуатацией.
4. Давать ИИ проектный контекст: решения, переписки, критерии готовности, обратную связь и факты использования.
5. Растить следующий уровень: для разработчика - от ценности к workflow, для ПМа - от задач к доверию и цели проекта.

## Вывод

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

Именно это мы оцениваем.

## Источники

- AWS - The New Unit of Software Delivery: The Workflow: https://aws.amazon.com/blogs/enterprise-strategy/the-new-unit-of-software-delivery-the-workflow/
- AWS Executive Insights - Amazon's Two Pizza Teams: https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
- AWS Executive Insights - Product Management at Amazon: https://aws.amazon.com/executive-insights/content/product-management-at-amazon/
- Werner Vogels - A return to two-pizza culture: https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html
- DORA - Accelerate State of DevOps Report 2024: https://dora.dev/research/2024/dora-report/
- DORA - Software delivery performance metrics: https://dora.dev/guides/dora-metrics/
- Microsoft Research - The Impact of AI on Developer Productivity: https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/
- Anthropic - AI's impact on software development: https://www.anthropic.com/research/impact-software-development