Показатели эффективности работы

Все показатели зелёные, а проблемы остались. Как так?

Сотрудник укладывается в сроки, потому что регулярно работает по вечерам. Персональная метрика в норме, премия сохранена. Только планирование лучше не стало, а переработки теперь ещё и скрыты. Получилось измеримое неизвестное.

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

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

Проектируем механизм

“Нужно точнее оценивать задачи” – понятное пожелание. Но в основе изменения должна быть гипотеза с чёткой формулировкой: если – то – потому что.

Согласитесь, что это слабая гипотеза: “Если установить лимит на Estimate Time, то планирование станет точней, потому что сотрудники начнут делать декомпозицию задач, лучше продумывая детали реализации”. Лимит может подтолкнуть к размышлениям, но скорей научит дробить задачи для прохождения формальной проверки. Неопределённость при этом останется.

Другой вариант: “Если декомпозицию начинать делать с уровня бизнес-анализа, то планирование станет точней, потому что задачи на разработку станут дозированными и понятными”. Здесь начинаем раньше разбирать бизнес-проблему на небольшие сценарии с понятным результатом и критериями приёмки. При сопоставимой загрузке команды ожидаем уменьшения разброса времени выполнения сценариев и колебаний их количества за спринт. А точность прогноза проверяем, сравнивая предполагаемую длительность с фактической.

Команде “разброс времени” поможет находить причины задержек и улучшать декомпозицию. Руководству “колебания количества принятых сценариев” покажут, какой объём работы команда способна предсказуемо поставлять.

Вторая гипотеза тоже может не подтвердиться! Но мы понимаем, что меняем, почему ожидаем эффект, когда и по каким показателям увидим результат или пересмотрим решение.

Контролируем корректность

Если разработка ускорилась, но подготовка задач стала занимать вдвое больше времени, смотрим на весь путь поставки: должен быть конвейер, а не водопад. Если количество сценариев за спринт возросло вместе с количеством багов; или потому, что спринты стали не по 2, а по 3 недели.

Любой целевой метрике нужны контр-метрики – противовесы, которые помогают увидеть перекос.

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

Изменения распространяются не сразу. Требуется время на перестройку связей и принятие новых правил. Один удачный спринт ещё не показывает, что результат можно получать регулярно без авралов.

Подводим итоги

Для работы с метриками эффективности выделяем несколько правил:

• Каждая метрика сопровождается гипотезой. Что и для чего меняем, какого эффекта ожидаем и почему.
• Каждая метрика сопровождается контр-метриками. Чтобы видеть аномалии и цену результата.
• Для каждой метрики определяем: текущий уровень (как точку отсчёта), целевое значение (как желаемый результат), период ожидания эффекта и период фиксации (сколько времени уровень должен удерживаться, чтобы мы считали его достигнутым, а не единичным всплеском).

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

---

Для закрепления темы предлагаю посмотреть мультфильм. :)

// Выражаю благодарность Руслану Сафину как идейному вдохновителю для этого поста.