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