Simple is not easy

Проведение AI-native оценки разработчика (RS-DEVS)

AI-native подход помогает ПМу убрать субъективность, опереться на факты рабочих процессов и подготовить аргументацию для развивающей обратной связи.

  • Шаг 1. Сбор артефактов (База фактов для ПМа)
  • Шаг 2. Инициализация ИИ и загрузка контекста
  • Шаг 3. Прохождение оценки по этапам (Диалог с ИИ)
  • Шаг 4. Формирование отчета RS-DEVS и плана развития (PDP)

Проведение AI-native оценки разработчика (RS-DEVS) 6.4.2025 Автор:

Становой AI-native подход помогает ПМу убрать субъективность, опереться на факты из рабочих процессов и подготовить железобетонную аргументацию для развивающей обратной связи.

Согласно регламенту компании, регулярную оценку инженера проводит

Менеджер (ПМ) после заполнения разработчиком самооценки.

Часто ПМы склонны непреднамеренно завышать баллы из-за хороших отношений в команде или во избежание демотивации сотрудника. AI-native подход помогает ПМу убрать субъективность, опереться исключительно на факты из рабочих процессов и подготовить железобетонную аргументацию для развивающей обратной связи перед встречей 1-на-1. ИИ в данном случае спорит не с «ощущениями менеджера», а сверяет факты с жесткими требованиями регламента.

Шаг 1. Сбор артефактов (База фактов для ПМа)

  1. ИИ не придумывает факты, он анализирует предоставленные данные.

  2. Перед инициализацией оценки ПМ должен собрать «сырую» фактуру:

  3. Документ «101 - ИПР и оценка разработчиков» (содержит жесткие критерии по уровням задач и ролям).

  4. Какие баллы сотрудник поставил сам себе и как он их аргументирует.

  5. Транскрибации рабочих встреч (ключевой артефакт):

  6. Записи дейли-митингов (как разработчик обсуждает задачи, погружается ли в бизнес-смысл).

  7. Записи встреч с клиентом (включает ли камеру, общается ли на языке бизнеса).

  8. Записи технических синков (используется ли синхронное код-ревью, помогает ли он коллегам).

  9. Метрики проекта: Lead Time (время от коммита до прода), частота выкаток, статистика использования автоматизированных проверок, наличие/отсутствие тестовых стендов.

Шаг 2. Инициализация ИИ и загрузка контекста

  1. Используйте продвинутые LLM с большим контекстным окном (NotebookLM, Gemini 1.5 Pro, ChatGPT-4o).

  2. Загрузите все собранные текстовые артефакты и отправьте ИИ официальный системный промпт, утвержденный регламентом:

  3. Ты проводишь оценку разработчика по методике L10 / L20 / L30 / TECHLEAD / DEVOPS.

  4. Твоя задача — выявить реальный уровень, исключить самообман, пресечь завышения, определить следующий эпик развития. БАЗОВЫЕ ПРИНЦИПЫ:

  5. Нет оценки без факта самостоятельной доставки.

  6. Нет L20 без full-stack доставки ценности.

  7. Нет L30 без гипотезности и нового состояния.

  8. Если клиент декомпозировал — это L10.

  9. Если ценность не использовалась на продуктиве — она не доставлена.

  10. Общие слова не принимаются — только факты.

  11. Действуй по этапам, задавая мне уточняющие вопросы: ЭТАП 1.

  12. Жесткая проверка каждой задачи на соответствие L10, L20 или L30. ЭТАП 3.

  13. Оценка технической реализации (проверка на слабую связанность). ЭТАП 4.

  14. Оценка TECHLEAD (поиск реальной стратегии ускорения и влияния на команду). ЭТАП 6.

  15. Проверка на "инженерные иллюзии". ЭТАП 7.

  16. Сравнение с самооценкой разработчика и поиск завышений. ЭТАП 8.

  17. Формирование ИПР в коуч-режиме (следующий эпик развития, 3 шага, метрика, срок).

Шаг 3. Прохождение оценки по этапам (Диалог с ИИ)

  1. Поскольку в промпт зашит пошаговый алгоритм, ИИ сам начнет вести вас по процессу, выполняя роль строгого наставника.

  2. Если ИИ спрашивает: "Был ли прямой контакт с пользователем и делал ли разработчик front и back самостоятельно?", отвечайте как есть, опираясь на транскрипции.

  3. Не пытайтесь "протащить" завышенную оценку:

  4. Если вы заявите, что задача соответствует уровню L30, ИИ проверит вас встречными вопросами: "Как изменилось мета-свойство проекта?

  5. Были ли проверены гипотезы в проде?".

  6. Если подтверждений нет, оценка автоматически скорректируется до L20 или L10 согласно правилам.

  7. Передайте ИИ баллы, которые разработчик поставил себе сам. ИИ выявит расхождения и подготовит для вас аргументы, основанные на регламенте, для конструктивного диалога на 1-на-1.

Шаг 4. Формирование отчета RS-DEVS и плана развития (PDP)

  1. Успешно пройдя все 8 этапов, запросите у ИИ финальную выжимку.

  2. Вы получите готовый отчет для внесения в систему:

  3. Реальный уровень задач (L10 / L20 / L30).

  4. Итоговые баллы по каждому критерию RS-DEVS с жестким обоснованием.

  5. Блок обратной связи: В чем конкретно заключается завышение самооценки (если есть) и что является главным ограничителем роста. PDP-TXT (Следующий шаг для ИПР):

  6. Сформулированный следующий эпик развития, 3 конкретных шага (на 1-3 месяца), метрика успеха и срок. С этим документом ПМ выходит на встречу 1-на-1 с разработчиком, оперируя корпоративными стандартами и неопровержимыми фактами, что переводит разговор из плоскости «личных симпатий» в плоскость прозрачного профессионального роста.

Итог: почему AI-native оценка выигрывает у классической

  1. Главная идея этого подхода — отделить факты от впечатлений.

  2. Когда между менеджером и разработчиком стоит алгоритм, опирающийся на регламент, выигрывают обе стороны:

  3. Разработчик получает прозрачную, предсказуемую систему роста.

  4. Он точно знает, какие факты нужны для перехода на следующий уровень, и не зависит от настроения руководителя.

  5. Менеджер избавляется от неловкости «субъективного приговора».

  6. Аргументы формирует ИИ на основе данных — остаётся лишь обсудить их в конструктивном диалоге.

  7. Команда видит единые правила игры: одинаковые критерии, одинаковый процесс, одинаковая планка для всех. AI не заменяет человеческий разговор — он делает его честным. А честная обратная связь — это единственный вид обратной связи, который действительно помогает расти.

Контакты

Давайте обсудим ваш проект

Оставьте актуальные контакты и опишите задачу. Мы вернемся с уточняющими вопросами и предложением по следующему шагу.