Спасибо за развернутый ответ, рад видеть автора готового отстаивать свою точку зрения, а не сливаться. Тут, к сожалению, таких много. Итак: По поводу принципа ТОС - согласно ТОС узкое место всегда ОДНО, это хорошо раскрывается в «Критическая цепь», но вы пишете «5 разных типов задач, 5 разных воркфлоу = 5 разных узких мест» Если вашу логику перенести на производство тогда 5 разных выпускаемых продуктов имеют 5 узких мест, а номенклатура завода может насчитывать тысячи наименований производимой продукции, согласно вашей логике ТОС в принципе неприменим нигде, но практика показывает обратное.
Если вернуться к нашему примеру то у вас пропущен первый этап, поиск узкого места в рамках ВСЕЙ системы, вместо этого вы ищете его в локальных процессах. Конечно после этого все сыпется.
Далее «Проект Феникс» в сравнении с Целью конечно же слабее, так как это всего лишь частный случай применения принципов ТОС в разработке и эксплуатации (Development , Operations- DevOps) т.е там описывается общий подход к процессу работы всей системы включающий все этапы работы, а не только сопровождения/обеспечения как Вы утверждаете. Суть как раз в этом надо рассматривать всю систему в целом все этапы и только тогда можно найти настоящее бутылочное горлышко .
Хотя как говаривал Питер Друкер и мы с вами это тоже видим на практике - «обычно бутылочное горлышко сверху бутылки» ;)
Спасибо за статью, но простите вам стоит перечитать еще раз «Цель», после нее «Цель 2», «Критическая цепь», потом «Выбор» и наконец «Проект Феникс».
Если говорить конкретно по статье то вот после этих слов:
Да, типов тасок у вас может быть не так много, например, штук 5, но это означает, что у вас 5 РАЗНЫХ узких мест, и для оптимизации их потребуются совершенно разные подходы.
Можно было прекратить читать, вы в корне не верно поняли принцип ТОС. А после того как вы канбан противопоставили ТОС…
А есть ли выход, если ТОС не применим? Есть, конечно! Надо переходить на …. «Канбан»
Совсем грустно стало, по этому поводу снова советую «Проект Феникс»
Судя по статье автор хочет чтобы все понимали термин так как он сам его понимает :) выглядит наивно. Такая же ерунда творится и со всеми другими терминами которые имеют некоторую вольность в интерпретации. Для меня mvp это нечто, что позволит проверить гипотезу. В одном случае это может быть мокап в другом интерактивный прототип в третьем продукт который уже выполняет практически все функции за исключением того, что его слепили дендрофекальным методом с расчетом на то, что это будет переделано нормально, в случае успешного подтверждения гипотезы.
2) Отлично, рассматриваем систему шире, в таком случае какую метрику, по вашему мнению, нужно использовать для определения эффективности и оценки эффекта от изменений?
Если нужно совершить некую работу то затраты энергии на ее совершение будут в сумме одинаковые в независимости от длительности, если не брать во внимание внешние факторы. В то же время если мы в единицу времени выполняем большее количество «работ»(юзер-стори) соотвественно больше тратим энергии в единицу времени, напряженность возрастает. В вашем примере вы добавили ресур (выделеный ревьюер) как следствие напряженность не выросла, а даже упала. Но если количество ресурсов останется неизменным, то как ни крути напряженность вырастет, как следствие стресс и все вытекающие. Я лишь к тому что усердствовать и гнаться за показателями не стоит, а это случается моментально когда начинаешь смотреть графики и тем более ставя их в приоритет не только для себя, но и для команды.
Верно поняли вопрос. И если это все же локальная оптимизация, то какую бы внешнюю метрику Вы бы выбрали для определения эффективности и производительности?
Спасибо за интересную статью! Но возникла пара вопросов. 1) Любое ускорение разработки, не важно как оно достигнуто, увеличивает напряженность труда, почему вы думаете, что ускорение за счет оптимизации ограничений (устранение простоев) будет менее «губительным» в плане выгорания сотрудников чем другие способы улучшения эффективности? И второй вопрос: не кажется ли вам, что попытки измерения и улучшения производительности разработки сами по себе заводят в ловушку погони за локальным оптимумом?
Спасибо за лаконичную и полезную статью. Скажите, а как устроено планирование? Вы планируете несколько версий вперед или только одну? Какой обычно срок выпуска версии?
Спасибо за развернутый ответ, рад видеть автора готового отстаивать свою точку зрения, а не сливаться. Тут, к сожалению, таких много. Итак: По поводу принципа ТОС - согласно ТОС узкое место всегда ОДНО, это хорошо раскрывается в «Критическая цепь», но вы пишете «5 разных типов задач, 5 разных воркфлоу = 5 разных узких мест» Если вашу логику перенести на производство тогда 5 разных выпускаемых продуктов имеют 5 узких мест, а номенклатура завода может насчитывать тысячи наименований производимой продукции, согласно вашей логике ТОС в принципе неприменим нигде, но практика показывает обратное.
Если вернуться к нашему примеру то у вас пропущен первый этап, поиск узкого места в рамках ВСЕЙ системы, вместо этого вы ищете его в локальных процессах. Конечно после этого все сыпется.
Далее «Проект Феникс» в сравнении с Целью конечно же слабее, так как это всего лишь частный случай применения принципов ТОС в разработке и эксплуатации (Development , Operations- DevOps) т.е там описывается общий подход к процессу работы всей системы включающий все этапы работы, а не только сопровождения/обеспечения как Вы утверждаете. Суть как раз в этом надо рассматривать всю систему в целом все этапы и только тогда можно найти настоящее бутылочное горлышко .
Хотя как говаривал Питер Друкер и мы с вами это тоже видим на практике - «обычно бутылочное горлышко сверху бутылки» ;)
Спасибо за статью, но простите вам стоит перечитать еще раз «Цель», после нее «Цель 2», «Критическая цепь», потом «Выбор» и наконец «Проект Феникс».
Если говорить конкретно по статье то вот после этих слов:
Можно было прекратить читать, вы в корне не верно поняли принцип ТОС. А после того как вы канбан противопоставили ТОС…
Совсем грустно стало, по этому поводу снова советую «Проект Феникс»
Судя по статье автор хочет чтобы все понимали термин так как он сам его понимает :) выглядит наивно. Такая же ерунда творится и со всеми другими терминами которые имеют некоторую вольность в интерпретации. Для меня mvp это нечто, что позволит проверить гипотезу. В одном случае это может быть мокап в другом интерактивный прототип в третьем продукт который уже выполняет практически все функции за исключением того, что его слепили дендрофекальным методом с расчетом на то, что это будет переделано нормально, в случае успешного подтверждения гипотезы.
2) Отлично, рассматриваем систему шире, в таком случае какую метрику, по вашему мнению, нужно использовать для определения эффективности и оценки эффекта от изменений?
Если нужно совершить некую работу то затраты энергии на ее совершение будут в сумме одинаковые в независимости от длительности, если не брать во внимание внешние факторы. В то же время если мы в единицу времени выполняем большее количество «работ»(юзер-стори) соотвественно больше тратим энергии в единицу времени, напряженность возрастает. В вашем примере вы добавили ресур (выделеный ревьюер) как следствие напряженность не выросла, а даже упала. Но если количество ресурсов останется неизменным, то как ни крути напряженность вырастет, как следствие стресс и все вытекающие. Я лишь к тому что усердствовать и гнаться за показателями не стоит, а это случается моментально когда начинаешь смотреть графики и тем более ставя их в приоритет не только для себя, но и для команды.
Верно поняли вопрос. И если это все же локальная оптимизация, то какую бы внешнюю метрику Вы бы выбрали для определения эффективности и производительности?
Спасибо за интересную статью! Но возникла пара вопросов. 1) Любое ускорение разработки, не важно как оно достигнуто, увеличивает напряженность труда, почему вы думаете, что ускорение за счет оптимизации ограничений (устранение простоев) будет менее «губительным» в плане выгорания сотрудников чем другие способы улучшения эффективности? И второй вопрос: не кажется ли вам, что попытки измерения и улучшения производительности разработки сами по себе заводят в ловушку погони за локальным оптимумом?
Спасибо за лаконичную и полезную статью. Скажите, а как устроено планирование? Вы планируете несколько версий вперед или только одну? Какой обычно срок выпуска версии?