Согласен, что в чем-то это две альтернативные стратегии.
Но с другой стороны, мне кажется, что поиски "идеальной второй половинки, которая во всем меня понимает и поддерживает" или "банды таких же ушибленных" могут быть тщетны. Люди сложные, так еще и меняются со временем.
Однако успех продажи идеи не гарантирован, зависит от коллектива - в каких-то случаях не получится ничего поменять.
Егор Бугаенко за свои несколько книг с 2016 года получил около $100 000. Вроде тиражи у Бугаенко по-меньше. Издавать книги на Amazon может быть выгоднее, чем на O'Reilly) «Я ЗДЕСЬ БОСС» | В офисе Егор Бугаенко
Чтобы внедрить найденное решение необходимо пройти по всем слоям сопротивления. То есть как минимум:
1. Отсечь негативные ветви (см Дерево будущей реальности) 2. Выявить препятствия и найти промежуточные цели для преодоления препятствий (см. Дерево перехода aka "prerequisite tree")
Насчет выявить препятствия – мне кажется, что «мыслительные процессы теории ограничений» вряд ли бы нам помогли. На старте я не предполагал, что могут возникнуть препятствия вроде «разработчикам не интересно ускорить поставку кода на прод». И когда столкнулся, не знал, что делать.
Я сомневаюсь, что моих способностей и алгоритмов «мыслительных процессов теории ограничений» хватило бы, чтобы предсказать подобное препятствие и придумать решение, даже если бы я затратил много времени на анализ.
А вот чтение книг на тему теории изменений помогло научиться думать об этом) Книги Джон Коттер «Впереди перемен», Питер Сенге «Танец перемен» дали какое-то объяснение неудачной попытки улучшения: успешные изменения проходят через несколько конкретных этапов, пропуск любого из них увеличивает вероятность торможения/отката изменений. В нашем случае мы пропустили примерно 5 шагов из 8 (по классификации Коттера).
Итого: две гипотезы почему застряли).1) до бизнеса не донесли реальную ценность и оценку сложности реализации2) боль для разработки от этого мала, как следствие задачу положили не в "тот" бэклог).
Согласен с вашими гипотезами.
Недавно нашел их в книге Джона Коттера "Впереди перемен" в перефразированном виде: "отсутствие видения, учитывающего долгосрочные интересы всех участников (работников, руководителей, акционеров…)», «отсутствие ощущения необходимости перемен».
С точки зрения автора успешные изменения фирм последовательно проходят через 8 шагов, пропуск любого шага повышает вероятность остановки или отката изменений. В случае данной статьи мы пропустили около 5 шагов)))) Возможно, напишу еще статью хабре, рассмотрев нашу неудачу с точки зрения Джона Коттера)
Как ваша проблема соотноситься с метриками ТОС? Окей, ваш релизный цикл стал 15 дней? Денег больше заработали? Да? А если нет, то и начинать не надо, это уже потери.
Согласен, что желательно иметь более-менее точное представление о финансовой выгоде при внедрении изменений.
Для нашего случая мы не делали расчет. Есть лишь несколько предположений, основанных на здравом смысле:
"чем быстрее делаем релиз, тем быстрее можем исправить баг"
"если мы допустили ошибку в коде, то мы узнаем об этом лишь в момент релиза. И хотелось бы узнавать об ошибках пораньше"
Не корректно искали узкое место, ТОС работает со всей цепочкой поставки ценности. А у вас только хвост: dev -> e2e тесты -> ожидание установки на прод -> обновление сервисовё1 на проде. Так, что то что вы делали может быть субоптимизацией.
Вы правы, что необходимо захватывать весь поток создания ценности. Но мы не пытались увеличить доход/уменьшить накладные расходы/уменьшить связанный капитал компании. У нас была примитивная эгоистическая цель - сделать работу программиста "удобнее и приятнее": получать обратную связь на работу раньше, чем через 10 дней.
И ТОС нужен был как способ увеличить вероятность того, что мы придем к этой цели, а не проведем несколько спринтов ускоряя неподходящие участки конвейера.
почему если в очереди несколько релизов одного и того же сервиса их нельзя схлопнуть в один.
Схлопывать релизы нежелательно, так как это усложнит поиск причины бага(если баг возникнет).
Это некая UI обёртка на дженкинсом и нексусом? А почему для ваших целей не подходит самописный дженкинс плагин?
Отличная статья) можно было бы ещё добавить в список аналогичную веру в devops, continious delivery...
Интересный тезис про эволюцию и "грабли" для читателей книг по канбан)
Не знал, что дядюшка Боб был редактором журнала о программировании)
Мне кажется, что если мотивация согласуется с моралью и интересам компании, то
почему бы не попробовать)
Например:
интерес к новой библиотеке, разработке через тестирование, парному программированию
уменьшить количество багов, митингов и ручных действий
увеличить прибыль
забота о пользователях
забота о тестировщиках, аналитиках, админах, программистах
Согласен, что в чем-то это две альтернативные стратегии.
Но с другой стороны, мне кажется, что поиски "идеальной второй половинки, которая во всем меня понимает и поддерживает" или "банды таких же ушибленных" могут быть тщетны. Люди сложные, так еще и меняются со временем.
Однако успех продажи идеи не гарантирован, зависит от коллектива - в каких-то случаях не получится ничего поменять.
Нужен какой-то баланс подходов)
Интересная статья) напоминает немного книги про "системное мышление"(Медоуз/Сенге/О'Коннор)
Всего: 108 079 экземпляров, роялти $477 916
Егор Бугаенко за свои несколько книг с 2016 года получил около $100 000. Вроде тиражи у Бугаенко по-меньше. Издавать книги на Amazon может быть выгоднее, чем на O'Reilly)
«Я ЗДЕСЬ БОСС» | В офисе Егор Бугаенко
Спасибо за комментарий!
Насчет выявить препятствия – мне кажется, что «мыслительные процессы теории ограничений» вряд ли бы нам помогли. На старте я не предполагал, что могут возникнуть препятствия вроде «разработчикам не интересно ускорить поставку кода на прод». И когда столкнулся, не знал, что делать.
Я сомневаюсь, что моих способностей и алгоритмов «мыслительных процессов теории ограничений» хватило бы, чтобы предсказать подобное препятствие и придумать решение, даже если бы я затратил много времени на анализ.
А вот чтение книг на тему теории изменений помогло научиться думать об этом)
Книги Джон Коттер «Впереди перемен», Питер Сенге «Танец перемен» дали какое-то объяснение неудачной попытки улучшения: успешные изменения проходят через несколько конкретных этапов, пропуск любого из них увеличивает вероятность торможения/отката изменений. В нашем случае мы пропустили примерно 5 шагов из 8 (по классификации Коттера).
Спасибо за ссылку и гипотезы!
Согласен с вашими гипотезами.
Недавно нашел их в книге Джона Коттера "Впереди перемен" в перефразированном виде: "отсутствие видения, учитывающего долгосрочные интересы всех участников (работников, руководителей, акционеров…)», «отсутствие ощущения необходимости перемен».
С точки зрения автора успешные изменения фирм последовательно проходят через 8 шагов, пропуск любого шага повышает вероятность остановки или отката изменений. В случае данной статьи мы пропустили около 5 шагов))))
Возможно, напишу еще статью хабре, рассмотрев нашу неудачу с точки зрения Джона Коттера)
Спасибо за ваш комментарий!
Согласен, что желательно иметь более-менее точное представление о финансовой выгоде при внедрении изменений.
Для нашего случая мы не делали расчет. Есть лишь несколько предположений, основанных на здравом смысле:
"чем быстрее делаем релиз, тем быстрее можем исправить баг"
"если мы допустили ошибку в коде, то мы узнаем об этом лишь в момент релиза. И хотелось бы узнавать об ошибках пораньше"
Вы правы, что необходимо захватывать весь поток создания ценности. Но мы не пытались увеличить доход/уменьшить накладные расходы/уменьшить связанный капитал компании. У нас была примитивная эгоистическая цель - сделать работу программиста "удобнее и приятнее": получать обратную связь на работу раньше, чем через 10 дней.
И ТОС нужен был как способ увеличить вероятность того, что мы придем к этой цели, а не проведем несколько спринтов ускоряя неподходящие участки конвейера.
Схлопывать релизы нежелательно, так как это усложнит поиск причины бага(если баг возникнет).