Обсуждение

Есть много дорогих проприетарных надстроек-солверов для решения в ограничениях построенных поверх прологов (в том числе и открытых версий прологов). Поэтому скорее всего никто и не вставляет в массовый продукт.

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

Читаю ваш блог в ЖЖ, а в Facebook как-то не завёл ещё аккаунта, поэтому пишу сюда свой кейс, вдруг вам на что сгодится: У нас в компании послали учиться менеджеров на модуль "Управление проектами по ТОС" как только он появился в России (тогда это было от имени Goldratt's school) в далёком 2009-м году. Послали топ-менеджеров разработки не просто так, а воодушевлённые результатами от посещения нашими производственниками модуля "ТОС в управлении производством" (затраты на обучение отбили месяца за три, а уж про текущее состояние и вовсе говорить нечего - кстати, будете в Нске в апреле - заходите в гости, мы там рядом с тем местом, куда вас пригласили :)). На текущий момент инструменты ТОС у разработчиков используется только для решения сложных управленческих кейсов (например, "туча" прекрасна на все времена :)), а для управления собственно проектами - нет. На сегодняшний день нам кажется, что ограничение оказалось не в софте (продукт lynx (a-dato.com) по мнению всей команды разрабов оказался достаточен и (!!!) проще, чем MS Project (я был в шоке, если честно)), а в "неполноте нашей корпоративной "культуры" (коротко говоря, чтобы выполнить проект софт для управления проекта не является ключевым фактором, ограничения в чём-то другом). С 2009-го года у нас потихоньку из отдела программистов на всю разработку проросли Agile-подходы, в результате чего Канбан-доска стала в какой-то момент центральным местом встреч и дискуссий. В конце этого года, как мне представляется, мы достигнем потолка в росте эффективности, если будем продолжать использовать текущие управленческие инструменты из Agile. А дальше, пока что, представляется перспективным подход TameTheFlow, но как и куда у нас вырастет понимание к концу года пока можно только гадать :). Книжка с описанием подхода (на Амазоне первая ссылка в поиске Tame The Flow на бумажную версию, pdf продаётся на kobo.com) официально вышла в январе этого года (до этого пару лет была доступна только в электронном виде), ничего сверхъестественного в подходе нет, просто описание метода использования ТОС для канбан-доски, но первые главы про программирование в Борланде 90-х (откуда, собственно, все Agile-методики и выросли), просто прекрасны. За всю свою карьеру я не видел кейса с успешным внедрением ТОС в управление проектами разработки в России (да и за рубежом кейсы от realization.com про HP не выглядят сверхвдохновляющими (но это, скорее, из-за того, что на всех докладах менеджеров из HP сквозило, как мне показалось, отсутствие поддержки топ-менеджмента)). Кейсы по управлению проектами в более детерминированных средах (например, в строительстве) регулярно мелькают на конференциях http://www.tocpractice.com/ru

Да, ваш кейс хорош. Интересное мнение высказал в фейсбуке Андрей Степенко, его гипотеза была похожей на вашу: дело не в софте, а в трудностях масштабирования культуры разработки с маленькой команды на всех сотрудников -- в этом дохнет и TOC, и обычный MS Project с любой методологией, остаётся только всё "на коленке". В строительстве, конечно, всё по-другому, но там рулит госрегулирование, а не крутые методологии. Про Tame the Flow -- хорошая мысль и про него сказать специально. Я даже не думал, что есть команды, которые уже от скрама переметнулись к канбану и прошили его насквозь так, что захотелось идти дальше ))) Меня, кстати, удивляет: сами разработчики канбана для разработки чётко указывали, что они отталкивались именно от работ Голдратта. А сейчас канбан для разработки представляют эдаким винегретом всяких разных идей, так что обращение к TOC из него выглядит чуть ли не новацией! Главную идею мою вы чётко подтвердили: в этой предметной области управления проектами-задачами-делами идут довольно глубокие подвижки, и они вылезают от программистов в железные и социотехнические проекты, в левой части V-диаграммы. Так что каждую пару лет нужно смотреть, что происходит: мода на XP быстро поменялась на моду на SCRUM, она поменялась на канбан, а спецы по проектному управлению в этот момент застыли в своём антиквариате и практически не меняются (кроме, пожалуй, P2M).

У Голдратта практика управления буфером в проекте схожа с практикой управления буфером на производстве тем, что фиксируются причины отставаний, классифицируются и принимаются меры. В строительных проектах чаще после фиксации причин ищут виноватых и принимают меры;) У ребят из AVA ERP есть модуль управления проектами и есть опыт продажи крупным компаниям. Собственники заинтересованы в виду приобретаемой выгоды, но часто отказываются от внедрения, потому что то, что есть работает более менее предсказуемо, а софт можно применить после изменения практик управления. Вы как-то описывали пример про однолетний опыт, повторенный 20 раз — в строительной отрасли так. Софт ни при чем, инертность отрасли играет большую роль.

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

Какой шикарный кейс! Спасибо большое! Это, кстати, вполне в духе Essence: "проект" разваливается на много-много отслеживаемых "альф", каждая из которых не совсем проект в смысле проектного управления, но нечто, проходящее состояния. Продажи тут вполне подходят. А дальше многие рассуждения проектного управления в части планирования и контроля выполнения вполне тут применимы. Пример другой такой альфы -- это выбор поставщика и контрактация с подрядчиком. Всё то же самое, что в примере по вашей ссылке, будет тут вполне применимо.

Я как-то разговаривал с девелопером и показывал ему Essence с подАльфами и изменением их состояний. Ему очень понравилась идея с чеклистами. Выбор поставщика у них начинается теперь с куда большим перечнем требований чем раньше. Правда они не рассматривали это как проект. До внедрения CCPM куда полезней простая системная медитация.

Анатолий Игоревич, обратите внимание, что часто CCPM буксует из-за того, что не важно на каком уровне полномочий находиться "идейный вдохновитель" перемен, ему рано или поздно придется "уговаривать" других участников проекта к контроинтуитивным действиям;) Голдратт советовал четко понимать свою роль в проектах и прежде чем переключать фокус с завершения каждой задачи в срок на завершение проекта в срок, необходимо обратить внимание на скорость завершения задач. Часто с ТОС знакомятся менеджеры и они изменения начинают не со своего поля контроля, а с длительными совещаниями с коллегами. Проходит время, с ним если и соглашаются, то ничего дальше не делают. Пусть сфокусируются на собственной скорости завершения задач, а для убеждения потом можно почитать Л. Лича "Вовремя и в рамках бюджета".

Да, я понимаю, что последовательность освоения TOC (в варианте CCPM или TameFlow или ещё каком) отнюдь не та, что изложение в какой-то книжке. например, в Hannan, Michael; Müller, Wolfram; Robinson, Hilbert "The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean" предлагают последовательность такую: 1. Project Staggering 2. Project Buffering 3. Portfolio Buffer Balancing 4. Project Selection Using Effective ROI 5. Eliminating Task-level Commitments 6. Single-tasking 7. Ultimate Scrum 8. Showing all Buffers as Time-Based 9. Lean Process VSAs Хотя книжка и про портфолио, и это понятный сдвиг акцента -- но не скорость завершения первым делом идёт, а недопуск новых зада в WIP. Но это важнейший аспект: "как попасть из точки бардака в точку укрощённого потока, через какие микропроекты и в какой последовательности".

У меня чуть модифицированная системная медитация вообще в основе всего, я с неё начинаю любые беседы. Ибо если ты не знаешь, с какой системой работаешь, никакие методы работы тебе не помогут! Архитектура не-пойми-чего это не архитектура, критическая цепь работ по не-пойми-чему вообще неисповедима.

"Перестань делать лишнее и со временем станешь делать только необходимое";) Ссылка дельная, благодарю.

Старый вариант годился только в случаях, когда собеседник очень хотел разобраться, пришлось адаптировать и добавлять вводные вопросы. Вот моя версия. Поделитесь своей актуальной версией?

Главное изменение у меня для сегодняшнего варианта -- это включение в неё использующей системы. Без неё ни потребностей, ни приёмки.

Она доступна только в виде краткого плана, а не нарратива -- и сейчас в виде слайда к "Дню смычки менеджеров и инженеров", пока это только клиентам.

Та, которая потом воспользуется целевой системой?

Да, надсистема к целевой системе (системы в операционном окружении обычно тоже её подсистемы).

Забавная история случилась с насосом из примера в описании СМ: в Ростове построили "небоскреб" на 30 этажей, в котором небожители из пентхаусов набирают ванну час, душевые кабинки вообще не работают из-за слабого напора;) Никто так и не узнает, кто проморгал требования в этом проекте.

Требования вполне могли там быть (более того, наверняка были -- есть же всякие ГОСТы на водоснабжение). Но они могли не быть учтёнными ни в проекте, ни в воплощении системы.

Наткнулся сегодня случайно на статью с видео, в которой главный спорщик из фейсбука признается, что он о Голдратте узнал от планировщиков из Газпрома. В его речи используется критический путь, и на риск дефицита ресурса он предлагает заложить 100% буфер времени. В Spider реализован механизм критической цепи, но поклонники ССРМ его не жалуют, так как в программе цепь меняется, что по незнанию вводит в заблуждение проектную команду.