К сожалению, ваш подход к изменениям рушит индустрию и только прививает ненависть к всем видам Technical/Product Management.
У вас ничего не получилось, потому ваши свистелки не решали корень проблемы и не меняли сам процесс управления продуктом внутри компании.
Надеюсь, что в следующий раз, вы всё-таки сможете грамотно коммуницировать со "старичкам" и прислушиваться к их мнению, чтобы понять действительные проблемы в системы и научиться изменять её снизу вверх.
Дизайн Канбана - это оптимизация ПОТОКА внутри процесса. А не сам процесс /методология управления проектами.
Вы технически не можете уничтожить процесс и заменить его рядом потоков. Даже если в вашей голове картина мира сложилась таким образом - процесс на самом деле никуда не исчез.
«Мы работаем по Канбану». Это тоже некорректно - Канбан используется для обёртки существующего процесса, его можно применить к Scrum, XP, DSDM, Водопаду, и это будет полезно. Но судя по вашей иллюстрации, Chaos Engineering, приукрашенный Канбаном, из вашей системы никуда не делся. От сюда и корень проблем.
Канбан применяют к уже существующему процессу, а не как что-то отдельное.
Эволюция процесса основана на понимании Business Value ваших продуктов, клиентов, культуры внутри компании, ментальных заскоков владельцев и инвесторов. Без глубокого анализа этих составляющих вы не можете построить эффективный процесс улучшающих важнейшие бизнес метрики.
Конечно, статья отражает предыдущий опыт, может подсказать, как не надо делать, если вы внимательно читали) в целом ваш комментарий справедлив, но у меня, как аккредитованного тренера и консультанта по Канбан Методу от Kanban University, есть замечания к некоторым вашим утверждениям. Найду время на днях и прокомментирую подробно
К сожалению, ваш подход к изменениям рушит индустрию и только прививает ненависть к всем видам Technical/Product Management.
У вас ничего не получилось, потому ваши свистелки не решали корень проблемы и не меняли сам процесс управления продуктом внутри компании.
Надеюсь, что в следующий раз, вы всё-таки сможете грамотно коммуницировать со "старичкам" и прислушиваться к их мнению, чтобы понять действительные проблемы в системы и научиться изменять её снизу вверх.
Дизайн Канбана - это оптимизация ПОТОКА внутри процесса. А не сам процесс /методология управления проектами.
Вы технически не можете уничтожить процесс и заменить его рядом потоков. Даже если в вашей голове картина мира сложилась таким образом - процесс на самом деле никуда не исчез.
«Мы работаем по Канбану». Это тоже некорректно - Канбан используется для обёртки существующего процесса, его можно применить к Scrum, XP, DSDM, Водопаду, и это будет полезно. Но судя по вашей иллюстрации, Chaos Engineering, приукрашенный Канбаном, из вашей системы никуда не делся. От сюда и корень проблем.
Канбан применяют к уже существующему процессу, а не как что-то отдельное.
Эволюция процесса основана на понимании Business Value ваших продуктов, клиентов, культуры внутри компании, ментальных заскоков владельцев и инвесторов. Без глубокого анализа этих составляющих вы не можете построить эффективный процесс улучшающих важнейшие бизнес метрики.
Конечно, статья отражает предыдущий опыт, может подсказать, как не надо делать, если вы внимательно читали) в целом ваш комментарий справедлив, но у меня, как аккредитованного тренера и консультанта по Канбан Методу от Kanban University, есть замечания к некоторым вашим утверждениям. Найду время на днях и прокомментирую подробно
Это всё не так.:)
«Иди напиши пару формул [на снегу]» Штирлиц