in devops ~ read.
Анти-паттерны DevOps#3. Таблицы "половозрелости"

Анти-паттерны DevOps#3. Таблицы "половозрелости"

В предыдущих частях (раз и два) мы рассмотрели проблемы, связанные с процессами и людьми. Поняли, почему человек-devops далёк от супермена и что developers и operations совсем не то, чем кажутся на первый взгляд. В этой статье мы рассмотрим проблему измерения успешности наших действий по "внедрению" DevOps-а в организации. В голове при этом давайте сразу держать, что слово "внедрение" я не зря написал в кавычках. Погнали.

Условия задачи. В организации ООО "Рога и копыта" есть N независимых продуктовых команд. Пусть они что-то там пилят, и не важно на каком языке, и по каким внутренним процессам. Очевидно, что у нас будут передовики производства, и будут остающие. Более того несколько умных людей вполне могут выделить некоторые этапы процесса, по котором артефакты ползут к разной степени довольности пользователям продукта. Поэтому одним из возможных, и применяемых на практике средств, могут быть таблицы, в которых каждая строчка представляет собой некоторую команду, а каждый столбец некоторый этап в разработке или доставке ПО.

После составления таблицы, очень быстро можно раскрасить её ячейки, где красным цветом будет, скажем отсутствие чего-то, либо это что-то работает на ручном приводе. Например, если ПО ставится руками админов по вордовым документам в команде А, то она получит красный цвет в соответствующем столбце. А зеленый цвет команда получит тогда, когда будет реализована автоматическая вкатка артефактов в бой.

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

Во-первых, если поставить озеленение таблицы в качестве KPI-ев или других целей, то мы получим в конце года зеленую, как трава на американской лужайке, таблицу. Но что будет реально сделано под каждым из зелёных прямоугольников? Зачем делать что-то правильно и хорошо, если можно накостылять абы как, лишь бы ячейка стала зеленой? Вполне может оказаться, что никакого DevOps-а на самом деле не появилось, а появилась ещё одна группа людей, которые озеленяют? Вся проблема в том, что цвет ячейки довольно субъективная, и хуже того, качественная оценка.

Во-вторых, даже после озеленения ничего не понятно, а как это всё повлияло на бизнес, продукт в целом, довольство пользователей, и даже на банальное времени доставки ПО. Не сделали ли мы что-то, что интересно только с технической точки зрения? Куда двигаться, и надо ли, дальше?

Поэтому такие таблицы "половозрелости" команд не стоит использовать как индикатор успешности "внедрения" DevOps-а. Как, собственно, и любые другие метрики, которые нацелены на технические детали разработки или сопровождения, которые не учитывают ценность для бизнеса.

Тогда как мерять? Какие метрики брать?

Возьмите показатели, которые напрямую влияют на бизнес. Lead time, или количество внедрений в единицу времени. Они помогут понять, насколько то, что мы делаем ускоряет доставку ценности клиенту.

Добавьте что-то, что будет характеризовать качество. Например, количество дефектов в бою или оставшийся за период time budget. Это не позволит сделать систему однобокой, без качественной обратной связи.

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

Выбирайте правильные метрики, но не забывайте, что метрики это всего лишь метрики.

comments powered by Disqus