После Ивана познакомился с когортным анализом , он ненавидел любые сентиментальные показатели.
Но ирония заключалась в том, что больше ничего руководство не знало и знать категорически не хотело.
Пришлось переступить через себя и тупо пойти навстречу «просьбам» начальника, чтобы не заслужить репутацию плохого человека, не подчиняющегося указаниям мудрецов.
Иногда это даже давало очень интересные результаты.
Об одном таком случае сейчас пойдет речь.
Однажды менеджер попросил Ивана разобраться, почему конверсия проходящих стенд команд постоянно падает на протяжении 3 недель: 
Надо сказать, что в отделе Ивана было много команд, несколько десятков, каждый день они делали сотни сборок своих дистрибутивов и тестировали их на стендах.
Конверсия рассчитывалась как отношение количества сборок, созданных командами за неделю, к количеству сборок, прошедших целевой стенд. Одним из главных недостатков сладких метрик является то, что по ним невозможно ничего определить.
Коэффициент конверсии, который использовал менеджер Ивана, оказался типичным слащавым показателем.
Конверсия падала, но было совершенно непонятно, почему.
Естественно, всем командам было объявлено предупреждение с требованием во что бы то ни стало улучшить работу трибун.
Для этого очень быстро была составлена еще одна слащавая метрика со списком «плохих парней»: 
Под каждым столбцом на картинке собственно написаны названия команд.
Команды взвыли и принялись изо всех сил бороться с новой постигшей их бедой.
Устав гоняться за командой, менеджер обратился к Ивану, чтобы разобраться в причинах падения конверсии.
И вот что из этого получилось.
Понять суть метрик
Необходимо понимать метрики.Хотя бы понять, как они рассчитываются.
Тогда можно копнуть глубже и разобраться.
Вот что сделал Иван: Конверсия = Созданные сборки / Сборки, прошедшие через стенд
Разобравшись в формуле, Иван первым делом отобразил на графике две составляющие конверсии: 
Сразу стало очевидно, что количество создаваемых сборок практически не изменилось, но в то же время количество сборок, прошедших стенд, уменьшилось, причем оно начало снижаться именно в тот момент, когда конверсия начала снижаться.
Конверсия изменилась из-за того, что увеличилась разница между количеством созданных сборок и количеством прошедших стенд, а так как конверсия является результатом деления одного на другое, то по мере увеличения разницы значение конверсии синхронно изменяется (уменьшается).
Разница между значениями на графике — темная линия.
Те.
Увеличение разницы между красными и синими полосками на графике указывало на автоматическое снижение конверсии.
Подумайте о результатах
Иван понимал, что полученных данных еще недостаточно, чтобы определить причину.Предыдущий опыт работы с метриками натолкнул его на одну важную идею: нужно добраться до корня, истинной причины любой проблемы.
Причиной любых изменений в преобразовании DevOps на самом деле являются.
люди.
Разработчики и девопсеры команд. Именно к ним в конечном итоге Иван и хотел попасть.
Посмотрев на растущую разницу между создаваемыми и прошедшими стенд сборками, он задался вопросом: почему это происходит и кто является «генератором» сборок, не дошедших до стенда? Книга «Дао Тойоты», которую я прочитал, дала мне подсказку: мне нужно посмотреть на «оставшиеся запасы» или «незавершенную работу».
Поскольку сборки проходили через несколько стендов и могли там оставаться, Иван решил посчитать не только сборки одного стенда, а посмотреть на истинный «реальный остаток», т.е.
посчитать, сколько сборок вообще не использовалось ни на одном стенде и осталось как мертвый груз: 
Темная линия показывает количество остатков, желтая линия показывает количество сборок, прошедших целевой стенд, учтенных в первоначальном графике конверсии.
Не надо было даже гадать.
Очевидное синхронное движение двух линий было подтверждено расчетом корреляции: 
Оказалось, что чем больше остатков сборок осталось, тем ниже желаемая конверсия.
Найдите первопричину
Определить, кто создает балансы, не составило труда по простой таблице:
В левом столбце указано название команды.
Выделенный столбец — это количество балансов, созданных этой командой в течение недели.
Лидеры ТОП-2 вышли сразу и Иван моментально побежал к ним разбираться.
Причина, естественно, оказалась банальной: команды просто начали новый цикл разработки и, создавая функционал, начали делать сборки для проверки его корректности.
Основной недостаток сладких метрик
На самом деле изменение конверсии оказалось тесно связано с цикличностью процесса разработки и не представляло собой ничего фатального или плохого.
На графике конверсий показаны три волны (цикла) развития.
Это естественный процесс, который должен идти таким путем.
И команды, спорившие с менеджером, были абсолютно правы: при нынешнем процессе разработки, используемом в компании, повышение конверсии было бы не только «непонятным» действием, но могло бы полностью разрушить процесс и привести к существенным задержкам в доставке ПО.
В этом главный недостаток слащавых метрик — они превращают положительные моменты в отрицательные и вместо того, чтобы прояснить ситуацию, только запутывают и ухудшают ее.
выводы
В целом опыт Ивану был интересен, поэтому он даже с некоторым удовольствием подготовил презентацию для руководства, в которой объяснил, что используемая метрика не подходит для управления отделом, вводит в заблуждение и может вызвать большие проблемы.Вот и все.
Если вам был интересен опыт Ивана, он будет вам очень благодарен за отзыв.
Кстати, Иван теперь хочет применить себя и свои знания в вдохновляющем и зажигательном проекте, поэтому интересные предложения принимает в личном сообщении.
Теги: #DevOps #метрики #конверсия #анализ #разработка #менеджмент #сладко #сборки #дистрибуции #стенды #команды #причины #причины #it-инфраструктура #Визуализация данных #Управление разработкой #Управление продуктом #DevOps
-
Монголия
19 Oct, 24 -
Использует Ли Blogger Хранилище Picasa?
19 Oct, 24 -
Javafx Изнутри
19 Oct, 24 -
Пенрин Сейчас В Продаже
19 Oct, 24 -
Хабразум Подскажите...
19 Oct, 24
