Comments 6
Канбаааан! Две чачи этому джигиту!
Спасибо за статью, но простите вам стоит перечитать еще раз «Цель», после нее «Цель 2», «Критическая цепь», потом «Выбор» и наконец «Проект Феникс».
Если говорить конкретно по статье то вот после этих слов:
Да, типов тасок у вас может быть не так много, например, штук 5, но это означает, что у вас 5 РАЗНЫХ узких мест, и для оптимизации их потребуются совершенно разные подходы.
Можно было прекратить читать, вы в корне не верно поняли принцип ТОС. А после того как вы канбан противопоставили ТОС…
А есть ли выход, если ТОС не применим? Есть, конечно! Надо переходить на …. «Канбан»
Совсем грустно стало, по этому поводу снова советую «Проект Феникс»
Спасибо за статью, но простите вам стоит перечитать еще раз «Цель», после нее «Цель 2», «Критическая цепь», потом «Выбор» и наконец «Проект Феникс».
Цель знаю практически наизусть. Цель 2, Критическая цепь - помню хорошо. Выбор - прочитал... Проект Феникс - весьма слабая книга, ну очень. На момент когда писалась, это было да. Но в 2023 нет. Кстати она не про разработку а про обеспечение. Как говорится бледная тень итила.
Можно было прекратить читать, вы в корне не верно поняли принцип ТОС. А после того как вы канбан противопоставили ТОС…
Окей, в чем тогда заключается принцип ТОС?
Еще. Я не противопоставил канбан ТОС, я в статье говорю, что у ТОС есть ограничения и она слабо подходит для задач связанных с умственным трудом. Точно так же большинство ККШ бесполезны в ИТ, слишком большие вариации. И мыслительные инструменты ТОС то же весьма тяжелы, разрешение тучи я видел всего два раза и сотен попыток с ней поработать.
Совсем грустно стало, по этому поводу снова советую «Проект Феникс»
Проект Феникс, о чем книга:
Мысли
Мы постоянно путаем Людей и Чем они занимаются
Мне следует играть по правилам с тех пор, как я стал тем самым человеком, который их устанавливает.
Усовершенствование, осуществляемое где-то, кроме бутылочного горлышка это иллюзия.
Пути
I. Бороться с дефектами рабочего процесса.
Налаживать взаимодействие производственных участков
Направлять ход работы
Задать темп в зависимости от ограничения.
Вся организация должна достигать своих целей, а не только ее часть…
II. Создание быстрой обратной связи.
Нужно стремиться к однонаправленному течение, которое увеличивает отдачу и минимизирует вариативность системы.
III. Улучшение ежедневной работы даже важнее чем выполнение ее.
Мы постоянно работаем с системой,
Мы закрепляем полезные привычки и занимаемся совершенствованием чего-либо.
Мы должны постоянно давить на систему с целью избавиться от тех недостатков, которые в ней есть. Четыре типа работы
Бизнес-проекты
Внутренние проекты IT-сопровождения
Изменения
Незапланированная работа (антиработа)
Невыплаченный технический долг. Приведет к тому, что все, что в итоге будет сделано.Это только незапланированная работа
Текстовое представление майнд карты по книге.
Спасибо за развернутый ответ, рад видеть автора готового отстаивать свою точку зрения, а не сливаться. Тут, к сожалению, таких много. Итак: По поводу принципа ТОС - согласно ТОС узкое место всегда ОДНО, это хорошо раскрывается в «Критическая цепь», но вы пишете «5 разных типов задач, 5 разных воркфлоу = 5 разных узких мест» Если вашу логику перенести на производство тогда 5 разных выпускаемых продуктов имеют 5 узких мест, а номенклатура завода может насчитывать тысячи наименований производимой продукции, согласно вашей логике ТОС в принципе неприменим нигде, но практика показывает обратное.
Если вернуться к нашему примеру то у вас пропущен первый этап, поиск узкого места в рамках ВСЕЙ системы, вместо этого вы ищете его в локальных процессах. Конечно после этого все сыпется.
Далее «Проект Феникс» в сравнении с Целью конечно же слабее, так как это всего лишь частный случай применения принципов ТОС в разработке и эксплуатации (Development , Operations- DevOps) т.е там описывается общий подход к процессу работы всей системы включающий все этапы работы, а не только сопровождения/обеспечения как Вы утверждаете. Суть как раз в этом надо рассматривать всю систему в целом все этапы и только тогда можно найти настоящее бутылочное горлышко .
Хотя как говаривал Питер Друкер и мы с вами это тоже видим на практике - «обычно бутылочное горлышко сверху бутылки» ;)
Итак: По поводу принципа ТОС - согласно ТОС узкое место всегда ОДНО, это хорошо раскрывается в «Критическая цепь», но вы пишете «5 разных типов задач, 5 разных воркфлоу = 5 разных узких мест» Если вашу логику перенести на производство тогда 5 разных выпускаемых продуктов имеют 5 узких мест, а номенклатура завода может насчитывать тысячи наименований производимой продукции, согласно вашей логике ТОС в принципе неприменим нигде, но практика показывает обратное.
«Критическая цепь» это книга по управлению проектами, где описано что есть критический путь и как можно его застраховать через введение буферов.
Но мы сейчас чуть о другом.
Напомню, алгоритм определения узкого звена по Голдрату:
В книге перечисляются пять основных этапов теории ограничений:
Определите. Определите узкое место системы.
Эксплуатируйте. Используйте это узкое место, повышая его пропускную способность за счет изменения процессов, процедур обслуживания оборудования, обучения, политик и т.д.
Подчиненный: Подчиняет пропускную способность всех других рабочих центров этому рабочему центру.
Улучшайте. Инвестируйте в этот рабочий центр, чтобы увеличить его пропускную способность - добавьте оборудования, рабочей силы и т.д.
Инерция. Начните процесс заново на линии, чтобы определить новое узкое место.
Так, ровно то что вы описали и происходит в цели. Напоминаю, что в зависимости от заказов у них узкое звено болталось по всему заводу. То на работе, то на печке, то ...
Потому, что они были ВЫНУЖДЕНЫ ПЕРЕНАСТРАИВАТЬ ОБРУДОВАНИЕ ПОД ВЫПУСК КАЖДОГО НОВОГО ЗАКАЗА. И каждый раз применяли ТОС для поиска узкого звена. И да заказы можно формировать в пачки, что бы уменьшить время на переналадку оборудования.
В разработке ПО КАЖДАЯ задача по своей сути это другой, совершенно другой заказ. Он требует под себя другую тех карту и можно сказать перенастройку оборудования.
Если вернуться к нашему примеру то у вас пропущен первый этап, поиск узкого места в рамках ВСЕЙ системы, вместо этого вы ищете его в локальных процессах. Конечно после этого все сыпется.
Поговорим про ВСЮ систему.
У Голдрата кстати, то же не вся система рассмотрена в цели. Если бы там была вся система, и они разместили ограничение на рынке(Сателитная программа)! То они бы заказы брали только те для которых прибыль максимальна, а время на производство минимально. То бишь оборудование не требовало бы перенастройки и это уже похоже на конвейр...
Фактически в ИТ мы имеем систему состоящую из двух частей. Дискавери и Деливери. В дискавери происходит селекция идей, их проработка и осознание их ценностей. Грубо говоря на вход приходя тысячи идей и большинство из них идут в мусор. Из них остаются, пускай десятки и вот они доходят до деливери части. В статье описана ТОЛЬКО деливери часть и начинается она как раз с бэклога идей.
Напомню, мы же говорим про СИСТЕМУ целиком, про сквозной процесс поставки ценности. Это означает, что мы протаскиваем запрос клиента до финиша и мы четко понимаем, что как стыкуются то что хотел клиент с тем, что мы поставили. Если это так. То у нас высокий уровень зрелости, 3 уровень по КММ. К этому уровню мы уже отстроили деливери, мы точно его понимаем и в идеале у нас есть простые модели. Так что прекрасно знаем где у нас узкое звено в деливери. Более того мы его можем предсказать через мат. модели. И можем максимально его использовать.
То что я писал, относится к уровню ниже 3, где мы еще разбираемся с тем как мы ценность поставляем и как попадаем в ожидания. В статье описан простой рабочий механизм понимания как работает ваше деливери.
Далее «Проект Феникс» в сравнении с Целью конечно же слабее, так как это всего лишь частный случай применения принципов ТОС в разработке и эксплуатации (Development , Operations- DevOps) т.е там описывается общий подход к процессу работы всей системы включающий все этапы работы, а не только сопровождения/обеспечения как Вы утверждаете. Суть как раз в этом надо рассматривать всю систему в целом все этапы и только тогда можно найти настоящее бутылочное горлышко .
Эх, не читали что я написал про феникс. Штош... в Фениксе НЕ РАССМАТРИВАЕТСЯ ВСЯ СИСТЕМА, там нет принятия решения о том, что берется в работу, а что нет. Там ни слова нет про требования и про анализ. Там не ничего про проработку идей.. Так что там только деливери. Причем не про всю его часть, а так начиная с разработки...
PS.Кстати феникс и кейс XIT очень похожи в чем то.
PPS. Все что есть в фениксе описано, хорошо было известно в ИТ компаниях и использовалось, все это было описано и итиле и в исо и в симсонах, куда уж без них
Оптимизация процесса поставки ценности, с чего стоит начать