Комментарии 13
Автору респект!
Побольше бы таких статей:)
В ТОС есть три метрики: скорость генерации дохода, накладные расходы и связанный капитал. Все ваши действия должны влиять на них выгодным образом.
Смотрим на вашу проблему:
Проблема: долгий релизный цикл
И, возможно, всех бы устраивал процесс релиза, если бы не занимал в среднем 20 дней. При этом такая длительность не меняется уже в течение года.
Такой срок поставки кода не комфортен – если появился баг, который нужно срочно поправить, то не получится поправить его быстро.
Как ваша проблема соотноситься с метриками ТОС? Окей, ваш релизный цикл стал 15 дней? Денег больше заработали? Да? А если нет, то и начинать не надо, это уже потери.
Не корректно искали узкое место, ТОС работает со всей цепочкой поставки ценности. А у вас только хвост: dev -> e2e тесты -> ожидание установки на прод -> обновление сервисовё1 на проде. Так, что то что вы делали может быть субоптимизацией.
На пошатать: 20 из 26 релизов содержат изменения этого сервиса. Вопрос, почему если в очереди несколько релизов одного и того же сервиса их нельзя схлопнуть в один.
Спасибо за ваш комментарий!
Как ваша проблема соотноситься с метриками ТОС? Окей, ваш релизный цикл стал 15 дней? Денег больше заработали? Да? А если нет, то и начинать не надо, это уже потери.
Согласен, что желательно иметь более-менее точное представление о финансовой выгоде при внедрении изменений.
Для нашего случая мы не делали расчет. Есть лишь несколько предположений, основанных на здравом смысле:
"чем быстрее делаем релиз, тем быстрее можем исправить баг"
"если мы допустили ошибку в коде, то мы узнаем об этом лишь в момент релиза. И хотелось бы узнавать об ошибках пораньше"
Не корректно искали узкое место, ТОС работает со всей цепочкой поставки ценности. А у вас только хвост: dev -> e2e тесты -> ожидание установки на прод -> обновление сервисовё1 на проде. Так, что то что вы делали может быть субоптимизацией.
Вы правы, что необходимо захватывать весь поток создания ценности. Но мы не пытались увеличить доход/уменьшить накладные расходы/уменьшить связанный капитал компании. У нас была примитивная эгоистическая цель - сделать работу программиста "удобнее и приятнее": получать обратную связь на работу раньше, чем через 10 дней.
И ТОС нужен был как способ увеличить вероятность того, что мы придем к этой цели, а не проведем несколько спринтов ускоряя неподходящие участки конвейера.
почему если в очереди несколько релизов одного и того же сервиса их нельзя схлопнуть в один.
Схлопывать релизы нежелательно, так как это усложнит поиск причины бага(если баг возникнет).
Схлопывать релизы нежелательно, так как это усложнит поиск причины бага(если баг возникнет).
Вот это хороший кандидат на проблему! У вас нет простроенного конфигурационного менеджмента, отсюда проблему.
И ТОС нужен был как способ увеличить вероятность того, что мы придем к этой цели, а не проведем несколько спринтов ускоряя неподходящие участки конвейера.
Вы сказали, узкое звено тут, потому что нам нравиться думать что это така, давайте его ускорять. Нуууу окей. Нам нужна обратная связь через 10 дней, ну окей. Толк то от этого всего какой? Выхлоп где?
Для нашего случая мы не делали расчет. Есть лишь несколько предположений, основанных на здравом смысле:
Вот это абсолютно стандартный антипатерн, использовать здравый смысл в айти. То, что гарантированно не работает :) Для айти нужен мат. стат. И спокойный анализ. Слишком большая вариативнось.
Согласен, что желательно иметь более-менее точное представление о финансовой выгоде при внедрении изменений.
Да бог с ним с деньгами, вы даже не определились как узнать, что станет лучше :)
В целом, норм. Просто ТОС штука сложная и сильно не про айти. И одной цели мало, очень желательно все их прочесть. Ну и сателитную программу отсмотреть.
Спасибо, что делитесь применением ТОС! Особенно в IT).
Коллега @Sergey-Titkov верно подметил, что это может быть субоптимизация time-to-market.
Но если это оставить чуть в стороне, и сказать, что ваша идея в этой конкретной реализации корректна, то к проблеме ускорения протаскивания техдолга можно тоже подойти системно).
Внизу ссылка на статью, в которой техдолг упаковывают в бизнес ценность.
Как вариант - добить анализ потерь до начала цепочки, чтобы была полная карта потерь в time-to-market, упаковать в бизнес-ценность, посчитав на языке бизнеса value. Если это value нашли, идем дальше.
Список таких доработок (там может быть еще пара actionitem'ов) упаковываем уже вместе с бэклогом - ценность описана на языке бизнеса же - ускорение поставки ценности на ХХ% с ХХ дней до УУ дней - и будете вы не писать патч на хрустальный сервис, а добиваться ускорения (патч писать придется тоже, но вы не остановитесь на том, что выпустили патч и вы молодцы - команда, взявшая фичу будет должна убедиться в общем ускорении и это в разы важнее выкатки патча - потому что вы еще должны будете переделать правила выкатки релиза и тд).
Если вы используете ICE/RICE/WSJF и тд, то тут же взвешиваете и она сама всплывает где надо. Если сложно менять общие подходы и в бэклоге она будет внизу - то ОК - бизнес решил что это здесь и сейчас не важно. Еще один элемент - управление рисками - если такая штука есть, то можно добавить это как риск и оценить его степень.
Еще момент. Даже в рамках архит.комитета оказалось, что это не так и важно раз за полгода не дошли - следовательно, ценность для разработчиков этого не так велика, им скорее болит распил очередного монолита или как легаси конвейер переделать на кафку). Поэтому разработка не лоббировала снизу эту доработку), там, где у них реально болит - они обязательно будут вспоминать и проталкивать в бэклог.
Итого: две гипотезы почему застряли).
1) до бизнеса не донесли реальную ценность и оценку сложности реализации
2) боль для разработки от этого мала, как следствие задачу положили не в "тот" бэклог).
Можно: вернуться в начало и оценить реальную пользу для бизнеса и тащить, упаковав в бизнес-фичу. Тогда и архит. проработка включится в работу в обычном режиме - не надо будет ждать архит.комитета. архит.комитет (или просто команда) по идее и так уже разложил боль до некоего решения, которое и надо тащить в бэклог.
Техдолг. Все говорят: «невозможно», а я говорю, что буду
https://habr.com/ru/company/oleg-bunin/blog/480636/
Спасибо за ссылку и гипотезы!
Итого: две гипотезы почему застряли).1) до бизнеса не донесли реальную ценность и оценку сложности реализации2) боль для разработки от этого мала, как следствие задачу положили не в "тот" бэклог).
Согласен с вашими гипотезами.
Недавно нашел их в книге Джона Коттера "Впереди перемен" в перефразированном виде: "отсутствие видения, учитывающего долгосрочные интересы всех участников (работников, руководителей, акционеров…)», «отсутствие ощущения необходимости перемен».
С точки зрения автора успешные изменения фирм последовательно проходят через 8 шагов, пропуск любого шага повышает вероятность остановки или отката изменений. В случае данной статьи мы пропустили около 5 шагов))))
Возможно, напишу еще статью хабре, рассмотрев нашу неудачу с точки зрения Джона Коттера)
У них там в ТОС ещё метод критической цепи есть для управления проектами, но как-то мало про это все это слышно, agile больше в моде.
Суть теории ограничений в том, чтобы найти где текущее узкое место системы с точки зрения ее Цели и оптимизировать остальную часть под это узкое место, чтобы использовать его максимально эффективно и по возможности компенсировать недостатки узкого звена за счет доступного запаса других звеньев. Узкое звено выдает себя по переизбытку чего-то перед ним - переизбыток сырья на складе, переизбыток заготовок, переизбыток товара и т.д. Этот переизбыток порождает целую серию негативных явлений, с которыми система вынуждена бороться, тратя ресурсы. У вас по всей видимости переизбыток релизов. Тут надо спросить - а на самом деле их нужно столько? Что запускает начало процесса, который заканчивается релизом и сколько стоит этот процесс? Зачем 4 команды выпускают релизы одновременно? Что включает понятие "ночь", ведь маловероятно, что вы можете обновляться только, когда не светит Солнце, правильная причина скорее всего звучит - обновление возможно, только когда нагрузка на соответствующий сервис минимальна, может там разные промежутки времени для разных сервисов.
Команда не оценила ваше предложение? Возможно система оценки их работы выстроена так, что они не могут не глушить систему релизами. Знаете - идет директор и видит что работник не пилит доски, и такой ах почему не работаешь, в итоге работник пилит доски на разные размеры, но не по заданию отдела сбыта, а на глазок, в итоге часть досок продается, а часть нет и уходит в запасы, которые не факт что продадутся.
А для них это не ценно. И не должно быть ценно. У них свои метрики — кстати говоря, похожие на объем производства каждого узла.
Вот почему проблемы уровня фирмы в книге голдратта стали проблемами каждого сотрудника? Да потому что завод закроют = всех на улицу выбросят. А без этого попытка представить идеи сотрудникам завершилась бы с таким же результатом, как у вас.
Поэтому работайте с владельцем бизнеса. Если ему это действительно не интересно — ок, займитесь чем-нибудь другим.
Оба-на, подскаст со мной! Рад что еще кто-то заинтересовался ТОС.
О шагах:
Если быть более точным, то второй шаг "РЕШИТЬ, как максимизировать работу ограничения" - "Decide how to EXPLOIT the system's constraint(s)." - в словаре TOCICO.
О внедрении:
Пять направляющих шагов простые, НО это это только кажется. Чтобы внедрить найденное решение необходимо пройти по всем слоям сопротивления. То есть как минимум:
1. Отсечь негативные ветви (см Дерево будущей реальности)
2. Выявить препятствия и найти промежуточные цели для преодоления препятствий (см. Дерево перехода aka "prerequisite tree")
О границах применимости:
Из роли разработчика тоже можно менять систему. И для этого у вас есть Ретроспектива спринта. И я уверен, что есть даже кросс-командная Ретроспектива. Ретроспектива - Это основная точка изменений в компании. Это основная точка убеждения в том, что проблема существует. Если "клиент" не принял что "проблема существует", то любые изменения утонут.
О Методе критической цепи для ИТ-проектов
Я уже начинал цикл статей о Методе (читать отсюда https://habr.com/ru/post/462423/ )
Сейчас вышла книга "Управление проектным бизнесом" https://ridero.ru/books/upravlenie_proektnym_biznesom/ о том как скрестить Agile с Методом Критической Цепи так, чтобы это работало. В принципе Метод будет также хорошо работать и для LeSS команд и для управления конфигурацией, потому как планирование с применением "дерева предпосылок" обеспечивает выстраивание всей работы команд и зависимостей.
О метриках ТОС:
Для ИТ-компании связанный капитал и операционные затраты величины постоянные. На Проход внутри ИТ-отдела влияние небольшое, поэтому единственное что остается: "Скорость генерации единиц цели".
В 5 направляющих шагах есть еще 2:
-1 Шаг: Определить границы системы
0 Шаг: Определить цель системы.
Если Цель системы - выкатывать больше изменений в единицу времени - то это хорошая тема для обсуждения. (Но так ли это?)
Для ИТ-компании связанный капитал и операционные затраты величины постоянные.
Для энтерпрайза это не так. Классический пример, у нас все было плохо, и что бы держать канарейку нам нужно 100 серверов. Мы пошли в инфраструктуру как код, и на выходе получили ту же канарейку но с быстрым развертыванием и уже 50 серверов.
Спасибо за комментарий!
Чтобы внедрить найденное решение необходимо пройти по всем слоям сопротивления. То есть как минимум:
1. Отсечь негативные ветви (см Дерево будущей реальности)
2. Выявить препятствия и найти промежуточные цели для преодоления препятствий (см. Дерево перехода aka "prerequisite tree")
Насчет выявить препятствия – мне кажется, что «мыслительные процессы теории ограничений» вряд ли бы нам помогли. На старте я не предполагал, что могут возникнуть препятствия вроде «разработчикам не интересно ускорить поставку кода на прод». И когда столкнулся, не знал, что делать.
Я сомневаюсь, что моих способностей и алгоритмов «мыслительных процессов теории ограничений» хватило бы, чтобы предсказать подобное препятствие и придумать решение, даже если бы я затратил много времени на анализ.
А вот чтение книг на тему теории изменений помогло научиться думать об этом)
Книги Джон Коттер «Впереди перемен», Питер Сенге «Танец перемен» дали какое-то объяснение неудачной попытки улучшения: успешные изменения проходят через несколько конкретных этапов, пропуск любого из них увеличивает вероятность торможения/отката изменений. В нашем случае мы пропустили примерно 5 шагов из 8 (по классификации Коттера).
Возможно я не до конца что-то понимаю в крутой enterprise разработке, но по тому что вы написали напрашивается как минимум одно решение, которое не затрагивает архитектуру вашего основного сервиса - пусть у фиче команд спринты будут заканчиваться в разные дни, тогда очередь не будет возникать или будет возникать, но в намного меньших объёмах. При этом на старте спринта вполне можно предположить будет ли затрагиваться это важный сервис.
Как начать делать непрерывную поставку «снизу»: теория ограничений