Как оценивал работу?

Оценка работы в IT-проектах: системный подход

Оценка работы — критически важная функция IT Project Manager, которую я строю на сочетании количественных метрик, качественных индикаторов и непрерывной обратной связи. Вот мой многоуровневый подход:

1. Количественные метрики (Hard Metrics)

Ключевые показатели эффективности (KPI) для оценки прогресса и результата:

• Соблюдение графика: Измеряю отклонение от baseline плана с помощью Earned Value Management (EVM).

  # Пример расчета базовых метрик EVM
  Planned_Value (PV) = 500  # Плановый объем работ на текущую дату
  Earned_Value (EV) = 450   # Фактически выполненный объем работ
  Actual_Cost (AC) = 550    # Фактически понесенные затраты
  
  Schedule_Performance_Index (SPI) = EV / PV  # SPI = 0.9 (отставание на 10%)
  Cost_Performance_Index (CPI) = EV / AC      # CPI = 0.82 (перерасход бюджета)
  

• Соответствие бюджету: Отслеживаю CPI (Cost Performance Index), прогнозирую EAC (Estimate at Completion).
• Качество продукта:

    *   **Плотность дефектов** (defects per story point / KLOC).
    *   **Скорость закрытия багов** (bug closure rate).
    *   **Процент успешных прогонов тестов** (test pass rate).

• Производительность команды (в Agile): Анализирую Velocity (не как цель, а как тренд), CFD (Cumulative Flow Diagram) для выявления узких мест.

2. Качественные и процессные индикаторы (Soft & Process Metrics)

Цифры без контекста — ловушка. Поэтому я дополняю их оценкой процессов:

• Соблюдение процессов: Регулярность и качество проведения ежедневных стендапов, ретроспектив, демо, полнота артефактов (технический долг, документация).
• Работа команды: Оцениваю уровень collaboration, психологическую безопасность, вовлеченность, самостоятельность в решении проблем. Индикаторы — активность на встречах, инициативность, качество дискуссий.
• Удовлетворенность стейкхолдеров: Провожу регулярные NPS-опросы или structured feedback sessions с заказчиком и ключевыми пользователями.
• Соответствие бизнес-целям (Business Value): Даже идеально выполненная техническая задача без достижения бизнес-результата — неудача. Оцениваю через цели и ключевые результаты (OKRs) проекта.

3. Инструменты и методы регулярной оценки

• Еженедельные отчеты: Стандартизированный дашборд с красными/желтыми/зелеными индикаторами (RAG status) по ключевым параметрам.
• Спринтные обзоры и ретроспективы (в Agile): Оценка не только что сделали, но и как.
• Персональные встречи 1:1: Индивидуальная обратная связь с членами команды, обсуждение их вклада, сложностей и роста.
• Gate Reviews на ключевых этапах (в каскадной модели): Формальная проверка выполнения exit criteria перед переходом к следующей фазе.

4. Философия и ключевые принципы

1. Оценка ради улучшения, а не наказания. Данные — основа для корректирующих и предупреждающих действий (Change Requests, адаптация процессов).
2. Прозрачность и объективность. Все метрики и критерии известны команде заранее. Оценка ведется на основе фактов, а не субъективных впечатлений.
3. Баланс между результатом и процессом. Можно «выжать» спринт, сорвав срок, но сжечь команду. Это проигрышная стратегия в долгосрочной перспективе.
4. Контекст важнее слепого следования цифрам. Падение velocity может быть связано с рефакторингом legacy-кода, что является стратегически правильным решением.
5. Оценка проекта vs. Оценка людей. Оценка работы проекта (срока, бюджета, scope) — моя прямая ответственность. Оценка личного вклада разработчиков (performance review) проводится совместно с техническим лидом и HR, где мои данные — один из важных входных параметров.

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