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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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