Оценка успешности

Упоминание показателей эффективности работы обычно имеет негативный эмоциональный окрас. Было время, когда простое упоминание этого термина вызывало в памяти образ надзирателя с секундомером, заносящего в блокнот результаты производительности. Давно уже было высказано утверждение: если вы не можете что-то измерить, оно не может быть улучшено – но убедить в этом большинство людей почти невозможно. Суть в том, что показатели эффективности всегда были инструментом руководителей для того, чтобы выжать как можно больше из сотрудников.

Гибкая революция в реализации метрик показателей эффективности и тут перевернула все с ног на голову. Любые характеристики принадлежат команде и используются ими для выполнения работы. Из-за этого сдвига акцентов показатели эффективности лучше воспринимаются, поскольку команды могут теперь посмотреть, как именно идет работа. Без этих характеристик гибкие подходы – особенно Скрам и Канбан – не смогут функционировать должным образом.

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

Блистательное определение

Основные принципы 1–2-3 для определения метрик показателей эффективности:

• определите важнейшие процессы или требования заказчика;

• определите специфический, измеримый результат работы;

• установите цели, по которым можно измерить результаты.

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

Если команда управляет всеми метриками, это говорит о том, что они намного надежнее и имеют большое значение для компании. Это особенно заметно при измерении скорости работы (характеристика Agile-команды), где команда рассчитывает свою скорость выпуска продукта и использует эту информацию для прогнозирования работы в заданных временных ограничениях. Такой прогноз намного надежнее, потому что он основан на прошлом опыте. Члены команды довольны выбранными задачами, потому что они не навязаны им, а бизнесмены заранее имеют представление о том, что они получат за свои деньги.

Поскольку гибкие подходы сосредоточены на бизнес-ценности, показатели всегда должны быть понятными для заинтересованных сторон. Процесс расчета выполняется для команды, и значение скорости будет разниться, однако конечный результат вполне точен. Это субъективное значение может быть использовано для вычисления того, что именно и через какое время может быть выпущено. Например, «Agile-команда A реализует функции A, B и C через X недель». Заказчик точно знает, чем занята команда в этот период времени и на что именно уходят его денежки.

Блистательный пример

Краткое пособие по использованию скорости работы команды в Agile.

• Согласуйте шкалу от одного до пяти для измерения масштабов работы (например, 1 = незначительная, 5 = большая).

• Оцените по этой шкале все задачи, которые должна выполнить команда в определенный временной промежуток (например, две недели).

• Сосчитайте общее количество баллов реализованных задач (скорость работы команды).

• Определите минимальные и максимальные значения, чтобы определить предельные значения скорости для команды.

• Исключите самое большое и самое маленькое значение и высчитайте среднее значение для оставшихся (общее количество баллов реализованных задач, поделенное на общее количество временных промежутков).

• Планируйте выполнение будущих задач на основе средней скорости. Повторяйте до тех пор, пока запланированное и фактическое значения скоростей не будут совпадать.

Вы можете использовать это значение для прогнозирования выполнения задач.

Двоякая польза отчетов

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

И здесь гибкие подходы все меняют. Представителям заказчика не нужно постоянно спрашивать о прогрессе, потому что они полностью вовлечены в процесс. Вместо того чтобы тратить время на отслеживание хода работы, бизнес может сосредоточиться на более важных вещах. Время тратится на более полезную деятельность.

Даже если люди, непосредственно вовлеченные в разработку, точно знают, как обстоят дела, все равно необходимо доносить информацию и до оставшейся части компании. Например, использование статусов по цветам светофора (RAG: Red, Amber, Green. Красный, желтый, зеленый) резко отличает Agile от традиционных методов управления, в которых людям, не участвующим в проекте, используемые метрики обычно непонятны. От Agile-команды ожидается, что она будет представлять плоды своих трудов в формате бизнес-ценности, по которому можно будет сделать прогноз о будущей производительности.

Блистательное определение

Доклады о ходе работы обычно используют систему цветов светофора или «RAG-статус» как визуальный сигнал для суммирования производительности для всех заинтересованных лиц:

Красный – серьезные проблемы, блокирующие дальнейшую разработку.

Желтый, или янтарный, – препятствия, которые могут быть устранены.

Зеленый – все в порядке.

Гибкие отчеты по проекту – это регулярные новости, обновляющиеся каждые несколько недель. Они полностью сосредоточены на том, что было выпущено или что скоро планируется выпустить, – настоящие новости, которые понятны организации и в которых нет места отговоркам и попыткам что-то скрыть.

Блистательный пример

Полезным инструментом для отслеживания прогресса является диаграмма сжигания задач. Она показывает прогресс выполнения проекта в наиболее распространенном варианте в виде двух линий на графике:

• общая работа – суммарная оценка сложности проекта – в динамике;

• выполненные задачи – в динамике.

Она очень отличается от диаграммы сгорания задач. График показывает общую работу по проекту (обычно в условных баллах) в сравнении с выполненной работой в течение определенного периода времени. Это визуальное отображение прогресса работы над проектом, отслеживающее выпуск продукта и оставшуюся работу.

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

Рис. 7.1. Блистательная диаграмма сжигания задач

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