Вопрос - ради чего мы все собрались на конкретном проекте? Есть два ответа: романтический и прагматический. Романтический - поставлять клиенту бизнес-ценность, чтобы клиент мог удовлетворить свои потребности. Прагматический - чтобы работодатель заработал больше денег, это бизнес, ничего личного.
Команда разработки влияет на способность зарабатывать деньги довольно-таки косвенно, добавление новой фичи в продукт это не производство и продажа отдельного физического продукта или партии, посчитать выручку и прибыль от действий команды разработки довольно сложно. Но тем не менее, есть некоторые эвристики, позволяющие оценить влияние ИТ-команд на финансовые показатели работы организации в целом.
Тут уместно вспомнить про Николь Форсгрен и latent construct of performance,
ссылка на видео Мартина Фаулера: https://youtu.be/Avs70dZ3Vlk?t=127, где он
рассказывает, что это такое. Выяснилось, что
Метрики DevOps и их влияние на результаты организации оказывают
влияние на финансовые показатели организации, в частности, на доходность
активов.
Две из трех метрик в совокупности описывают скорость работы команды. А поскольку это в том числе и скорость получения обратной связи, то нужно всячески эту скорость увеличивать, потому что Быстрая обратная связь - универсальное преимущество.
Такое ощущение, что этим должен заниматься операционный менеджер, см. Что такое операционный менеджмент, Основные проектные роли и виды труда. Есть несколько разных подходов к повышению эффективности работы, я когда-то давно ознакомился в общих чертах (на уровне чтения цикла бизнес-романов “Цель”) с теорией ограничений Голдратта. Смысл ее заключается в том, что для повышения прибыли нужно увеличивать Выработку, уменьшая Запасы и сокращая Операционные расходы.
- Выработка - количество историй, попавших на прод за период.
- Запасы - количество историй, одновременно находящихся в работе.
- Операционные расходы - общее количество времени, затраченное на разработку истории.
Видно, что это простое правило сильно коррелирует с выводами DevOps. Если представить, что мы одновременно работаем только над одной историей, то операционные расходы будут определять время между релизами, а частота релизов и выработка совпадут. В общем и целом, подобную корреляцию можно рассматривать как подтверждение значимости выбранных показателей. Исходя из этого можно сформулировать основную цель операционного менеджера в команде разработки:
Увеличивать количество историй, проходящих цикл разработки ПО за период, уменьшая количество зависших в цикле и сокращая время на прохождение цикла. Это должно привести к повышению частоты релизов, снижению среднего времени между релизами, а при условии сокращения времени на восстановление после сбоев позволит повысить операционные показатели организации в целом.
Голдратт явно утверждает, что основные показатели должны применяться для анализа процесса в целом, а не отдельного его участка. Мне кажется, что это следствие еще одного постулата теории ограничений - “любые изменения вне узкого места иллюзорны”. То есть, нет смысла применять оптимизации к отдельному шагу большого процесса до тех пор, пока мы точно не уверены в том, что именно этот шаг и является ограничением для всей системы в целом. Показатели Голдратта явно это учитывают, и метрики DevOps, очевидно, тоже, поскольку сконцентрированы на деплоях как конечной точке процесса разработки в целом.
Выглядит так, что четырех метрик DevOps, дополненных метриками Голдратта, должно хватить для понимания того, в правильном ли направлении движется команда.
По ходу этих размышлений подумал еще и о назначении любых метрик в целом. Я исхожу из предположения, что метрики - это инструмент проверки гипотез. То есть, мы вносим изменения и смотрим, как поменялись метрики. Мониторинг - это немного другая история, там мы видим, что поменялись метрики и в любом случае затеваем дополнительное расследование, потому что ни одна метрика не скажет нам точную причину своего изменения. И даже комплект метрик не даст полную картину. Или даст, но слишком дорого, так мне кажется.
То есть, я вижу выбор между двумя вариантами:
- постоянно спрашивать себя: “Что мы можем сделать, чтобы улучшить метрику Х?” и проводить эксперименты;
- в случае ухудшения метрик задаваться вопросом: “Почему метрика Х ухудшилась?” и проводить расследования.
Первый вариант кажется мне проактивным поведением, направленным на предотвращение проблем до того, как они появятся. Второй - реактивный, когда мы чешемся тогда, когда уже болит. И если выбирать, куда направить ограниченные ресурсы, то я бы лучше упирался в проактивный подход, к которому отлично подходят четыре метрики DevOps. Их всего четыре, но они очень комплексные. А реактивный подход может потребовать сбора куда большего числа более частных и, возможно, более сложных в получении метрик, плюс все равно доп.расследования.