Комментарии 25
Класс! Даже как-то не задумывался никогда про такой научный подход к управлению. Очень и очень интересно и познавательно.

Спасибо.
Действительно очень интересно, есть о чём поразмыслить, вдруг пригодится когда-нибудь. Плюс несколько книжек записал себе в список на прочтение. Спасибо автору!

Можете еще разъяснить, я наверное где-то пропустил, описанное больше подходит для управления потоками I-типа? А какой подход лучше подойдёт для проектов Ж-типа?
Таичи Оно (Öno Taiichi) не понимал, почему его система работает.

Мощный троллинг тойотоводов.
«командир взвода не может отдать приказ напрямую солдату» — опасен и скользок путь метафор. Мысль очень правильная, но вы избрали слишком мелкий масштаб для иллюстрации — командир взвода (как и руководитель любого другого подразделения из 30-40 человек) знает (и жарит) каждого подчинённого лично. Описанным вами способом работают подразделения из сотен и более человек, где нет личного контакта.

Я на своей шкуре ощущаю всю порочность такого подхода — в любой момент может ворваться руководитель отдела и надавать заданий минуя непосредственного руководителя подразделения. Это делает мне нервы и привносит хаос, содомию и разрушения в процесс разработки.
Как раз об этом и говорит автор — не стоит так делать.
Этот мессадж я как раз уловил, осталось только донести его до руководителя ) Спустя три кружки кофе я и сам уже точно не уверен, что именно хотел сказать в тот момент.
«Есть подозрение, что Ж-тип это более правильное название Т-типа, просто американцам не повезло с алфавитом. ;-)» — есть подозрение, что вы смешали все в кучу. что мешает разделить эти потоки? сначала пустить А, потом пустить Т.
Во всем тексте прослеживается желание делать из 5000деталей автомобиль за 81 час. Не кажется ли Вам, что создание модулей и последующая их компановка в готовые изделия намного эффективнее? И не надо будет использовать Ж и О потоки. Разделите авто на 10-20 модулей (готовых продуктов, которые можно реализовывать конкурентам) и сборочные линии этих модулей. Это касается и ИТ сферы.
Статья интересная, спасибо!
Сергей, крутая статья, хорошо, что наконец оформил свои наработки.

Я хочу обратить твоё внимание на то, что ты путаешь производство (manufacturing) и разработку (development). В it в основном происходит разработка. Разработка характеризуется достаточно высокой неопределённостью относительно качества принимаемых решений и рисками переделки. Причём эти риски неизбежны и являются самой сутью процесса, в отличие от производства.

Критику применения теории ограничений и канбана для разработки и новые подходы читай в Product Development Flow Дональда Райнерштэна: www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009
Я написал ее в декабре.
А в феврале-марте выдвинул гипотезу, что канбан в IT просто неприменим. Эту гипотезу я уже тестирую: testing-club.ru/2012/04/meet/, но статьи еще не написал.

И я оформил лишь часть своих наработок. Причем достаточно малую.
Я хочу ещё отметить, что во многих случаях разработка замешана с сопровождением систем, когда кроме простых доработок, нужно ещё и инциденты устранять и пользователей консультировать. При этом в «цех» валится большое число «заказов» принципиально разного размера и управлять этим хозяйством надо именно как Ж-тип производства (с большой буквы Ж)
Напишите книгу. Я серьезно, статья увлекает сверх всякой меры.
Пока не получается совмещать семью и книгу. Но хочется.
Очень познавательно. Действительно большинство известных мне мелких и средний фирм «отстают на 99 лет». Единственное, что всегда смущает, это притягивание «за уши» разработки к производству. Хотелось бы экскурс в управление сложными но успешными проектами. Вроде Firefox, например.
Кстати, одно очень существенное упрощение во всех этих выкладках. При разработке задача может ходить много раз по всех производственной цепочке в обоих направлениях. Создаваемая этими движениями работа может быть больше чем работа в «прямом» направлении, что полностью рушит аналогию с производством.
Очень много матана и ссылок на другие книги. Книги могли бы описать в литературе внизу, по мере прочтения они довольно раздражают.

Также хотелось бы больше примеров из реального опыта в IT — и лучше было бы разделить статью на 10 маленьких статей с примерами, чем вывернуть гору матана на читателей, которые не знают кто 50% из этих людей.

Но ваш интеллект и чувство юмора, а также восторг от происходящего в истории заслуживают уважения!
Ткните пальцем в матан. Все на пальцах объясняется без формул.
Я условно называю матаном вещи, которые после первичного прочтения нужно прочитать ещё 4-5 раз, чтобы въехать в их смысл. В худших случаях нужно не просто прочитать текст несколько раз, но ещё и ознакомиться с другим материалом, чтобы понять мысль.

Исключение — дифуры и физика твёрдого тела, где невозможно сформулировать эти вещи проще. Также я люблю такие вещи называть Кантом и Гегелем, т.к. у философов всегда довольно простые мысли разводняются на тома сложного текста.
Крайне познавательная статья. С кучей полезных ссылок. Огромное вам спасибо. Статья попала прямо в точку. Я как раз сейчас пытаюсь оптимизировать процессы, которыми руковожу. А вы подсказали мне пару идей.
Любая система управления должна соответствовать менталитету тех, кем она будет управлять. Канбан менталитету японцев соответствует, но в Германии он будет неэффективен.

Если руководитель пытается насадить чуждую систему управления, не адоптировав ее к собственной ситуации, он — вредитель, поскольку система не сработает.

Задачи эффективного производства в условиях российской действительно давно и эффективно решались — см. работы Косыгина в части организации именно работы, а не целой экономической системы.
Если рассматривать изложенные принципы в более крупном масштабе, то это по сути переход от экономики максимального дохода к экономике максимальной устойчивости и управляемости. Думаю что с такой расстановкой приоритетов и кризисов не было бы.

За примеры отдельное спасибо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.