📌 Записывайтесь на тренинг “Основы Канбан-систем” ☞ scrumtrek.ru/product/34/osnovi-kanban-sistem-base-ksd/ Чтобы лучше понять, как управлять потоком задач и прогнозировать сроки их реализации с достоверностью 80-90% 🤝
Скажите про Otask менеджер что то слышали? Вроде Русская разработка ,недавно его обнаружила может кто что знает? канбан, список задач, команду даже добавлять можно!
Идея про необходимость расшивания узких мест - понятна, тут вопросов нет. Но на 5-й минуте вы говорите "узкое место переместится куда-то дальше по потоку и в целом мы работать быстрее не будем". Вот эта мысль непонятна. Даже на вашей схеме видно, что добавив в систему новых людей система перешла со скорости 2 на скорость 4, т.е. увеличила свою скорость в 2 (!!) раза. И это, имхо, хороший показатель. Ускорение произошло не самым эффективным, туповатым образом (больше людей, больше связей, найм, обучение, все верно). НО! Ускорение работы все равно произошло и это частый метод для решения вопросов в современных организациях - например в строительстве. Не успеваем доделать 5 этажей - призываем еще 5 гастарбайтеров и они больше/быстрее кладут кирпичи. Подчеркну еще раз - я только "за"" оптимизацию и уже использовал мысль из вашего видео для расшивания узкого места с фронтами перед дедлайном крупного проекта. Но мысль на 5-й минуте звучит неубедительно. Или я что-то не понимаю - буду благодарен за пояснения.
Как я говорил в одном из видео, рабочий процесс похож на трубу переменного диаметра. Если один участок представляет собой узкое место , и мы резко, кратно увеличили его пропускную способность добавив туда много новых людей, то этот участок начнет работать СИЛЬНО БЫСТРЕЕ. Но последующие за ним участки быстрее работать не станут. Они будут работать с такой же пропускной способностью как и раньше. А на них с кратно бОльшей производительностью начнут вывалится работы с предыдущего этапа. Например - раньше с этапа узкого места приходило 2 задачи в неделю, а после того, как мы добавили туда людей - начало приходить 10 задач в неделю! А пропускная способность этапа после узкого места - 5 задач в неделю. И она не изменилась. Очевидно, что мы получим новое узкое место, где постоянно будет перегруз. Общая пропускная способность end-to-end рабочего процесса при этом изменится незначительно. И Lead Time тоже не сильно ускорится. То есть мы сделали локальную оптимизацию самым тупым (и дорогим) способам, но в целом, всему рабочему процессу может даже поплохеть. Канбан-метод фокусируется на ускорении ВСЕГО end-to-end рабочего процесса, а не отдельных его этапов.
📌 Записывайтесь на тренинг “Основы Канбан-систем” ☞ scrumtrek.ru/product/34/osnovi-kanban-sistem-base-ksd/
Чтобы лучше понять, как управлять потоком задач и прогнозировать сроки их реализации с достоверностью 80-90% 🤝
Василий респект.
Классно, а особенно, в изложении простота, кристально чистая трактовка сущности.👍😘
Спасибо, Vugar!
Спасибо. Полезно, понятно.
Рад что вам понравилось!
Скажите про Otask менеджер что то слышали? Вроде Русская разработка ,недавно его обнаружила может кто что знает? канбан, список задач, команду даже добавлять можно!
Здравствуйте. Не приходилось с ним работать.
Идея про необходимость расшивания узких мест - понятна, тут вопросов нет.
Но на 5-й минуте вы говорите "узкое место переместится куда-то дальше по потоку и в целом мы работать быстрее не будем". Вот эта мысль непонятна. Даже на вашей схеме видно, что добавив в систему новых людей система перешла со скорости 2 на скорость 4, т.е. увеличила свою скорость в 2 (!!) раза. И это, имхо, хороший показатель. Ускорение произошло не самым эффективным, туповатым образом (больше людей, больше связей, найм, обучение, все верно). НО! Ускорение работы все равно произошло и это частый метод для решения вопросов в современных организациях - например в строительстве. Не успеваем доделать 5 этажей - призываем еще 5 гастарбайтеров и они больше/быстрее кладут кирпичи.
Подчеркну еще раз - я только "за"" оптимизацию и уже использовал мысль из вашего видео для расшивания узкого места с фронтами перед дедлайном крупного проекта. Но мысль на 5-й минуте звучит неубедительно. Или я что-то не понимаю - буду благодарен за пояснения.
Как я говорил в одном из видео, рабочий процесс похож на трубу переменного диаметра. Если один участок представляет собой узкое место , и мы резко, кратно увеличили его пропускную способность добавив туда много новых людей, то этот участок начнет работать СИЛЬНО БЫСТРЕЕ. Но последующие за ним участки быстрее работать не станут. Они будут работать с такой же пропускной способностью как и раньше. А на них с кратно бОльшей производительностью начнут вывалится работы с предыдущего этапа. Например - раньше с этапа узкого места приходило 2 задачи в неделю, а после того, как мы добавили туда людей - начало приходить 10 задач в неделю! А пропускная способность этапа после узкого места - 5 задач в неделю. И она не изменилась. Очевидно, что мы получим новое узкое место, где постоянно будет перегруз.
Общая пропускная способность end-to-end рабочего процесса при этом изменится незначительно. И Lead Time тоже не сильно ускорится. То есть мы сделали локальную оптимизацию самым тупым (и дорогим) способам, но в целом, всему рабочему процессу может даже поплохеть. Канбан-метод фокусируется на ускорении ВСЕГО end-to-end рабочего процесса, а не отдельных его этапов.