Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Что происходит с теорией ограничений в проектном управлении

В порядке подготовки ко "Дню смычки менеджеров и инженеров" (http://techinvestlab.ru/379665) довольно долго сегодня обсуждал в FB-комьюнити управления проектами тему судеб теории ограничений в классическом управлении проектами (https://www.facebook.com/groups/msproject/permalink/815111638524365/). Надеялся на какие-то новости -- но зря надеялся. Вот несколько выводов:

1. Мода на теорию ограничений в проектном управлении в её оригинальном виде прошла. Но в современном отечественном софте (новом TurboPlanner, Spider) какие-то элементы голдратовщины реализованы (выравнивание ресурсов по критической цепи, похожие буфера против рисков). В принципе, есть и западный софт, но он весьма эзотеричен (http://ailev.livejournal.com/1102626.html).

Моя гипотеза тут такова, что отсутствие нормального свободного софта существенно повлияло на ситуацию. Для любой методологии управления проектами (отличной от PMI PMBoK) нужна поддерживающая её софтина. С софтиной же для TOC проблемы, есть замкнутый круг: мал рынок, софт никто не пишет, а пока софт не написан, то мал рынок.

2. То, что пик моды на "каноническое учение" TOC прошёл, вовсе не означает конец банкета. Многие идеи растащены по разным другим быстро набирающим популярность методологиям (то, что Голдратт сам многое откуда-то натаскал и его роль популяризаторская, мы оставим за рамками рассмотрения. Мы тут не о приоритетах, и не о прошлом). Так, идеи TOC в сочетании с lean и agile плодотворно взошли в kanban для разработки, http://en.wikipedia.org/wiki/Kanban_%28development%29. Поглядите на сначала падение интереса к kanban (для производства), а потом возрождение этого интереса (похоже, что это связано с kanban в разработке) -- http://www.google.com/trends/explore#q=%2Fm%2F01cyx0%2C%20kanban&cmpt=q&tz=

3. Но по факту это означает, что классические технологии управления проектами в их опоре на нормирование всё больше и больше используют в правой части V-диаграммы (воплощение системы), а в левой части (определение системы) бурно расцветают case management, issue tracking (ведение дел, управление задачами, управление процессом разработки -- нет даже слова "проект"!) с разнообразным софтом для методологий типа того же kanban-для-разработки. Да, там проблемы с масштабируемостью, но и они потихоньку решаются. В любом случае, инженеры тяготеют к issue tracker и учёту голдратовщины, а неинженерные менеджеры к программе управления проектами и неучёту голдратовщины. В проекте же можно обычно обнаружить обе программы и сопутствующую ругань по поводу того, какая из них главней для целей планирования работ и отслеживания выполнения планов. При этом ситуация существенно различается в зависимости от отрасли (у программистов, машиностроителей, строителей всё будет разное) и стадии жизненного цикла, плюс ещё сильно влияет размер проекта.

4. Но все эти методики едины в одном: мультитаскинг нужно удавливать! Сто слегка надкушенных задач хуже одной целиком выполненной! Софт этот мультитаскинг не слишком помогает контролировать, это вопрос больше к дисциплине работы. Так что методология всё одно первичней. Но без простого и удобного софта методология может не получить шанса быть попробованной в реальном проекте.

Кстати, для маленьких софтовых проектов kanban инструментов уже много: погуглите kanban software, сразу выскочит десяток софтинок (ну, или гляньте сюда: http://www.quora.com/Whats-the-best-Kanban-software). Только вопрос: что делать для не очень маленьких проектов, в том числе машиностроительных или строительных? Ответ: тяжело вздыхать и сдаваться классическим управленцам проектами, они ведь тоже потихоньку двигаются. Хотя и очень потихоньку.
* * *
Чего никак не ожидал в том комьюнити управления проектами, так это высокого накала политических страстей. Чуть ли не Наше Управление проектами против Западного (американо-европейского) Развала Проектов при примате Советской Науки (и заодно практики, и заодно софта -- в том числе Наших Надстроек к Мелкомягким). Как-то даже было неудобно говорить, что происхождение методологии ничего не говорит о её полезности или вредности, а ссылка на слишком древние источники заставляет подозревать застой.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 23 comments