Минимальное планирование Вступление переводчика – Георгия Лейбовича Читая книгу четы Каспари (Caspari, Caspari) «Management Dynamics: Merging Constraints Accounting to Drive Improvement», я наткнулся на ссылку на эту дискуссию и подумал, что она перекликается с затронутой нами недавно темой стратегии. Дискуссия велась на одном из первых (а может и первом) дискуссионных сайтов по ТОС. Около года назад я уже приводил ссылку на архивы этого сайта. Некоторые из дискуссий читал, другие оставил на потом. Эту почему-то пропустил. В дискуссиях участвовали многие крупные или ставшие крупными специалисты ТОС. Надо принять во внимание, что это 1996 год, многое было потом подробно рассмотрено (например, управление в многопроектной среде). Так как недавно прислал перевод про дерево СиТ, а эта дискуссия показалась «в струе», то привожу и её. Текст в стилистике форума, не старался слишком менять и причёсывать. Старался переводить максимально близко к тексту. Позволил себе только несколько замечаний в скобках [x], проясняющих текст, и несколько жирных выделений текста, не удержался. Ну и пару примечаний, но это уже вне основного текста.
96-10-24 elyakim@netvision.net.il (Eli S) Почему так много менеджеров не действуют по схеме Прогнозируем – Планируем – Исполняем? И вместо этого вынуждены бороться с препятствиями. Некоторым [людям] могут нравиться действия и волнения, связанные с усилиями по преодолению препятствий. Я не думаю, что это относится к большинству менеджеров. Планирование определённо требует времени, особенно при наличии проектов, и оно, как прокомментировал Tony Rizzo, может выглядеть необязательной задержкой. Однако, я смею сказать, что если бы ценность планирования была действительно очевидна, то значительное количество менеджеров продолжало бы тратить время на планирование. Мой основной аргумент следующий: слишком многие менеджеры не видят реальной ценности планирования. Я предполагаю, что планирование слишком часто не давало результата (не реализовывалось). Каков смысл планирования вперёд во времени, если окружающая нас неопределённость, включая наши ошибки и неспособность предвидеть определённые события, вынуждают нас отклоняться от исходного плана – ВСЁ ВРЕМЯ! Позвольте мне определить, что я подразумеваю под «планированием»: Планирование состоит в принятии ряда решений, касающихся будущих действий до совершения этих действий. Этот конфликт легко изобразить в виде облака:
А. Цель: поддерживать отличную работу*
Требования [необходимые условия – прим. ГЛ]: В. Гарантирование того, что все необходимые действия будут выполнены в нужной последовательности и во-время. C: Обеспечение подходящей реакции на неожиданные изменения и динамические ситуации.
Предпосылки для выполнения указанных требований следующие: D: Планируем все действия [для выполнения В]. D': Не планируем, полагаемся на вашу способность решать и действовать на месте [для выполнения С].
Внутри процедур DBR, а именно, TOC методологии планирования действий на производстве – лежит «вводная»* к вышеуказанному конфликту. Эта вводная следующая: «Планируй только то, что реально должен». Обычно выгодно принимать решение в самую последнюю минуту – при этом у вас есть данные, наилучшие из возможных [самые свежие]. Существует две категории связанных с планированием решений, которые я должен принять заранее:
Это значит, что результативное планирование основывается на минимальных решениях, остваясь достаточно гибким для реакции на изменения и Мёрфи (случайности). Нужно принять только такие решения, которые должны быть предприняты заранее. В DBR планирование сфокусировано только на трёх вопросах:
Что НЕ включено – это расписания не-ограничений. Этот тип решений лучше принимать на месте. Эти решения не слишком сложны, так как у вас есть избыток мощности для покрытия большинства «суб-оптимальных» решений. Вообще говоря, это наиболее радикальная идея DBR. Я думаю, что более радикальная, чем понятие узкого места. Когда расписание составлено, оно, по-видимому, шокирует тех, кто ожидает получить очень детальное расписание для всех рабочих центров. Принцип МИНИМАЛЬНОГО ПЛАНИРОВАНИЯ является более общим, чем DBR для производства. У меня есть впечатление, что в проджект-менеджменте сложилось представление, что или вы планируете проект в деталях и имеете сложности с еженедельной корректировкой, или имеете самый общий взгляд на него и начинаете работу без фиксированного плана с риском отставаний и завышения стоимости. Этот конфликт следует разрешить, определив какие решения действительно нужно принять в самом начале процесса – и что оставить для принятия по ходу дела. В этом случае управление неопределённостью означает поддержание защитного механизма (буферов) для защиты надлежащего выполнения минимального планирования. Чрезмерно подробный план следует рассматривать таким же злом, как избыток запасов. DBR показало это для производства. Слишком детальное бюджетирование, распределяющее точный бюджет по каждой статье, вредно аналогичным образом
96-10-25 YaegerDA.CE.USAFA@usafa.af.mil (CIV Daniel A. Yaeger, 472-4101) Eli, замечательный пост!!! Я давно подозревал, что ценность планирования не в плане, а в том, чему мы в его процессе научились. Однако, я никогда в полной мере не понимал причин, почему это так, и вы их вполне ясно изложили. Если кто-то имеет соображения по поводу «принципа МИНИМАЛЬНОГО ПЛАНИРОВАНИЯ», я буду рад прочитать их. Буду благодарен за ссылки, если они существуют.
96-10-25 rizzo@hogpa.ho.att.com (Anthony R Rizzo) Я тоже получил удовольствие, читая мысли Eli по поводу планирования. Я также приветствую идею планировать необходимое и не планировать не необходимое. Но я чувствую настоятельную потребность показать отрицательную ветвь, связанную с «принципом МИНИМАЛЬНОГО ПЛАНИРОВАНИЯ». Во-первых, я хочу провести различия между планированием и составлением расписания. Хочу уточнить: планирование включает составление расписания. Но оно также включает определение того, что должно быть сделано и в какой именно последовательности это должно быть сделано. После того, как у нас это есть, возможно составить расписание, минимальное или какое-то другое. В своей статье Eli S. поделился наблюдением, что попытка планировать всё в мельчайших деталях является пустой затеей. Эли, имеешь ли ты в виду план или расписание? По-моему, это не одно и то же. Поэтому, я прошу от тебя некоторых пояснений. Теперь относительно отрицательной ветви... В моём окружении (Исследования и Разработка, R&D), уровни неопределённости, с которыми мы сталкиваемся при попытках построения планов проектов, по меньшей мере на два порядка величины больше, чем те, с которыми мы сталкиваемся на производстве. Фактически всегда существует огромная неопределённость в оценке продолжительности выполнения работы. Часто неопределённость даже в том, каковы задачи. Ответ многих инженеров и менеджеров проекта на эту огромную неопределённость в том, чтобы ПЛАНИРОВАТЬ МИНИМАЛЬНО или вообще не планировать. Такой подход к планированию даёт нежелательные результаты. Я видел исключения из правила. По крайней мере один менеджер пректа, с которым я работал, взял за правило иметь, перед началом выполнения проекта, наилучший план, который он и его команда могли составить. Однажды, когда я был в его команде, мы создали план и расписание, имевшие только 10-дневный буфер при длительности проекта в 8 месяцев. Это был настоящий R&D проект, в котором искали и нашли новые знания. Проект был признан успешным и завершился за две недели до срока, достигнув цели. Это не был проект «критической цепи», так как я ещё ничего не знал о ТОС. Моя отрицательная ветвь состоит в следующем: многие из тех, кто сейчас считает неизбежную неопределённость во всех аспектах R&D планирования извинением полного отказа от планирования, будут использовать принцип минимального планирования как дополнительное оправдание для отказа от большей части усилий по планированию, которые могли бы принести пользу. Я не могу привести имеющиеся в моём распоряжении сравнительные данные, так как это приватная информация. Но могу сказать лишь следующее. Совместные усилия по наилучшему планированию проекта до его начала могут дать изумительный положительный результат даже без ТОС-парадигмы. Ещё раз, под планированием я понимаю попытки определить, что нужно сделать и в какой последовательности. Это полностью совпадает с соображениями Эли Шрагенхейма по поводу планирования (или составления расписания) только того, на что должно быть составлено расписание. Наибольшим препятствием для большинства людей при попытке составления плана проекта является то, что они не могут разобраться, что нужно сделать. Они испытывают большие трудности в достижении достаточности в их планах. Часто они не могут определить необходимости. В результате, многие из них прилагают максимальные усилия, чтобы вообще избежать планирования. К сожалению, это приводит к плачевным результатам. В организации, возможности которой подгоняются под потребности проекта, очень важно, чтобы поступление заданий не превышало возможности организации выполнять их. Мы, ТОС-еры, знаем, что это реализуется, как ограничение поступления заданий до темпа, в котором может работать ограничение. Планы проектов, которые не охватывают целое, вызывают избыточное количество поступающей в систему работы. Проектные планы, которые в целом неполны, приводят к тому, что в систему входит незамеченным большое количество избыточных заданий. Эти незамеченные задания создают WIP. Они засоряют, душат R&D систему столь же эффективно, сколь и физические WIP душат завод. Но не всё потеряно. У нас, к счастью, есть мощные средства, с помощью которых мы можем создавать планы проектов. И мы можем использовать нашу ТОС-парадигму составления расписаний для получения ещё большего эффекта.
96-10-25 elyakim@netvision.net.il (Eli S) Я думаю, Tony Rizzo и я согласны относительно того, что в рамки плана нужно включить только те решения, которые действительно нужны в конкретных временных границах. Тони говорит: "Но план и расписание не одно и то же. В то время, как расписание может меняться по ходу дела (can be all over the map), план меняется редко". Я думаю, что расписание это определённый тип плана. Бюджет – ещё один тип. Есть и другие типы. Когда Тони говорит: «план меняется редко», он имеет в виду такой тип плана, который мы оба считаем необходимым. Мне кажется, что слишком многие считают, что чем больше деталей в плане, тем лучше. Эти детальные планы почти никогда не остаются неизменным. По моему мнению, причина неудачи большинства планов в том, что в них пытаются достичь слишком многого и включить слишком много действий, которым нет обоснования на этой стадии [планирования]. Когда план включает вещи, которые могут легко меняться в будущем (я называю это неопределённостью), его неспособность исполняться становится очевидной, и тогда люди говорят: «мы вам говорили, что невозможно планировать что-то подобное». Ошибочным является понимание того, что следует планировать и что – нет. Для исключения отрицательной ветви Тони, а именно, вероятности, что люди используют термин МИНИМАЛЬНОЕ ПЛАНИРОВАНИЕ для отказа от планирования действительно важных вещей, я предлагаю создать формат для планирования проекта. Возможно нескольких форматов, подходящих для управления проектами в различных условиях. Формат должен включать решения, которые нужно принимать – и ясно устанавливать, какой вид решений оставлять для последующего рассмотрения. Другими словами, план должен позволять максимальную гибкость, которую можно поддерживать без угрозы цели проекта. Я полагаю, что Тони имеет в виду именно такой формат – для R&D условий, с которыми он имеет дело. Я не уверен, что его коллеги интерпретируют термин «план проекта» так же, как Тони. Применение формата к плану проекта совместно с логическими основаниями этого формата (почему эти решения необходимы, а другие лучше оставить для последующего рассмотрения) может помочь выполнить планирование. Если беда в том, что некоторые люди не способны выполнять планирование правильным образом, то или их нужно обучать это делать, или на этих должностях нужны другие люди. Когда у вас есть подходящий формат/процедуры, всё это становится реализуемым. Формат для планирования проектов должен быть связан с временными рамками. Определённые вещи, относящиеся к конечному результату проекта, должны быть специфицированы с самого начала. Это несомненно. Также, это относится к основным промежуточным точкам и их основным результатам. Для начального периода нужно специфицировать больше деталей. Последующие задачи должны быть специфицированы только в том случае, когда вскоре должны быть сделаны закупки. Уровень детализации для более поздних действий нужен только для того, чтобы проверить степень выполнимости и общей оценки затрат и основных потребностей в ресурсах. Это также означает, что усилия по планированию продолжаются на протяжении всего проекта. Это не то же самое, что «обновление плана». Вы добавляете к плану детали текущего периода. Нелепо видеть очень детальный Pert (Pert-chart, Program Evaluation and Review Technique) для 5-летнего проекта. Эти аргументы также влияют и на метод критической цепи (МКЦ).Я думаю, что МКЦ особенно справедлив для мультипроектов. Однако, мы должны осознать, что не можем предсказать реальную потребность в ресурсах далеко вперёд. Основная логика ТОС заставляет меня утверждать, что в мульти-проектной среде совсем немного ресурсов окажутся подвержены вероятности спора за них. Эти ресурсы – ограничение мощности этого мульти-проекта. С некоторой изощрённостью мы можем управлять проектами с 3-4 критическими ресурсами. Кстати, у этих ресурсов должна быть некоторая защитная мощность, в противном случае общее время прохождения не удовлетворит потребителя. Остальная часть должна иметь много большую избыточную мощность, чтобы спор за ресурс вызывал самое незначительное отставание. Горизонт для такого мульти-проектного проектирования по методу критической цепи планирования должен быть достаточно коротким, чтобы большую часть времени быть справедливым. Эту миссию можно рассматривать реальной только в задачах с 3-4 критическими ресурсами. Несомненно, в сфере разработки софта существует ошибочная концепция детального планирования. Во многих случаях реален и противоположный подход – не планировать – что столь же ошибочно. Хороший план – это план, близко совпадающий с исполнением. Когда это не так, что-то неверно. Я предлагаю начать рассмотрение случаев сверх-детализации и, следовательно, излишних усилий по планированию.
96-10-25 75104.3564@CompuServe.COM (Rob Newbold)
Для меня цель любого плана проекта состоит в том, чтобы развить и сообщить понимание проекта. Когда вы стараетесь передать понимание, которого у вас нет, вы сообщаете ошибочное понимание, и это плохо. Чтобы прийти к нужному уровню детализации плана вы должны прояснить с самого начала цели плана и проекта. Даже этот важный этап часто пропускается. Я думаю, что предсказание примерных потребных ресурсов часто достаточно важно, и не только "valid most of the time." Вам нужно предвидеть их для оценки продолжительности проекта. Они вам определённо нужны, если вы хотите быть уверены в том, что совсем немногие ресурсы могут оказаться предметом спора. Главное в том, чтобы помнить не только то, что вы действительно знаете, но и то, чего не знаете. Многим это не всегда удаётся. Защитная мощность является ещё одним интересным предметом проектной среды. Я видел множество мест, в которых менеджмент старается загрузить ключевых людей на 100%, считая при этом, что у них ещё найдётся время на собрания и комиссии. Если они рассчитывают на 60-80 часовую неделю, то тогда да, до некоторых пор. Я согласен, что хорошо иметь политику компании, согласно которой никто не должен загружаться на 100 % задачами высокой приоритетности. Для этого не требуется большого сдвига парадигмы – всегда есть множество работ не самой высокой важности, которые нужно выполнить.
96-10-26 LaHir@aol.com Существовал принцип, использовавшийся при разработке социотехнических систем, называвшийся принципом «определения минимума необходимых подробностей», который близок принципу минимального планирования Эли. Я согласен с Эли, что самым важным вкладом DBR или TOC в этот вопрос является то, что вы должны планировать только с учётом ограничения. Но это не всегда так просто. Возможно, мы должны проводить различие между планированием в первую очередь и во-вторую. Множество раз отдельные люди и организации обращались к планированию (как противоположности расписания) действий, когда a) они должны ещё определить свою цель, b) ограничение изменилось не потому, что переместилось, а скорее потому, что изменилась система как таковая, отношения, управлявшие тем, когда и почему часть системы является ограничением, меняются или требуют изменения. Это похоже на классичиские различия между «риском» и «неопределённостью». Первое, связанное с законом Мёрфи, минимизируется применением DBR. Для последнего нет распределения вероятности, которе может заранее быть известно. Однако оказывется, что планирование в условиях неопределённости, в противоположность риску, очень затруднительно. В действительности, хорошая методика для этого не разработана (например, прогноз, планирование сценариев, разработка прототипов и т.д.), так что не известно, как это делать.
96-10-26 anders.claesson@mailbox.swipnet.se (Anders Claesson) Во первых, я хочу поблагодарить Эли Ш., который написал:
Я согласен, сейчас я участвую в попытках перефокусировки большой программы разработки продукции. Один из аспектов – использовать МИНИМАЛЬНОЕ ПЛАНИРОВАНИЕ (но раньше я не знал такого названия). Одна из реакций на это, с которой мы постоянно сталкиваемся, указана выше.
Чрезмерно подробный план следует рассматривать таким же злом, как избыток запасов. DBR показало это для производства. Слишком детальное бюджетирование, распределяющее точный бюджет по каждой статье, вредно аналогичным образом Я согласен и думаю, что с нами именно это и случилось. Полагаю, что именно это явилось основным движителем наших усилий по перефокусировке и использованию минимального планирования. Связь с процессом бюджетирования внове для меня, но кажется очень интересной мыслью. Также спасибо Тони Риццо, давшему дополнительное описание того, что есть мой мир (R&D). Тони написал:
Я опять согласен относительно возможной отрицательной ветви. Однако, с моей точки зрения, критическим вопросом является проработка того, ЧТО и В КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ должно быть сделано. Также, нужно включить некоторые механизмы, отвечающие за неопределённость. По-видимому, так и было в приведённом Тони примере успешного планирования и выполнения проекта. Из этого я понимаю, что это планирование было результатом КОМАНДНЫХ УСИЛИЙ, что включало достаточно способности и опыта заранее разобраться в существенных этапах того проекта. Я считаю, что для этого было рассмотрено множество неопределённостей и некоторые из них снижены и приняты во внимание при планировании. Я считаю, что ключ здесь в том, чтобы разобраться в балансе между ЧТО планировать заранее и что оставить для последующего локального «планирования». По-моему, вы не можете приравнивать ОТСУТСТВИЕ ПЛАНИРОВАНИЯ (или ленивое планирование, lazy planning) к МИНИМАЛЬНОМУ ПЛАНИРОВАНИЮ, хотя последнее должно быть проверено на способность давать ожидаемые результаты.. Ещё Rob Newbold внёс несколько глубоких комментариев:
Мне это кажется замечательным способом получения разумного баланса в плане.
Вероятно, это очень важный вопрос, который надо иметь в виду. Но как это учесть в плане? Этот разговор помог мне двояко:
Моей настоящей задачей будет разобраться, как планировать и выполнять план в условиях протяжённости проекта более 3 лет, в котором много (более 50) параллельных тем, которые нужно синхронизировать для получения конечных результатов.
96-10-28 lleach@srv.net (Larry Leach)
Проверка ясности (Clarity reservation)?*
Ваш взгляд на ограниченное количество ограничений хорош и интересен. Нам следует обдумать это несколько глубже; и понять, что с этим делать. С считаю, что в действительности всё дело в том, какое обязательство перед вами у того, кто питает ресурс и как оно выполняется. Метод AGI* включает в расписании три буфера:
Буферы ресурсов критической цепи не являются «реальными» временными буферами. То есть, они не увеличивают продолжительность работы критической цепи. Они являются обязательством немедленно по запросу обеспечивать ресурс и использовать его на полную мощность на протяжении срока потребности в нём. Эти буферы – «готовность обеспечить» договорённость. В некоторых случаях нужно за это заплатить, что является нормальным. Одной из перемен, внесённых управлением проектами по методу критической цепи, является управление по длительности, а не по некоторым промежуточным опорным датам. Как ещё мы можем выгодно воспользоваться тем, что некоторые действия выполнены за более короткий, чем предполагалось, срок? Вам, также, нужен денежный буфер. Наподобие буфера завершения критической цепи, мы должны выделить его из оценок индивидуальных действий, чтобы воспользоваться преимуществом снижения вариабельности суммы переменных.
Это цель. Есть и другие. Такие, как получение одобрения проекта, определение долговременных ресурсов, и т.д. Я думаю, что предсказание примерных потребных ресурсов часто достаточно важно, и не только "valid most of the time." Вам нужно предвидеть их для оценки продолжительности проекта. Они вам определённо нужны, если вы хотите быть уверены в том, что совсем немногие ресурсы могут оказаться предметом спора. Главное в том, чтобы помнить не только то, что вы действительно знаете, но и то, чего не знаете. Многим людям это не всегда удаётся. Как мы можем оценить затраты по проекту без предположения о надобности в ресурсах? Как может какой-либо менеджер утвердить проект без знания затрат? Откуда вы знаете затраты без ресурсов?
Как раз по этому поводу афоризм знаменитого Дилберта (Dilbert, известный юмористический персонаж Скотта Адамса). «Кэти, согласно политике нашей компании ты обязана пойти в отпуск. – Но я работаю на вас по приоритетным проектам семь дней в неделю круглый год». Кто-нибудь хочет разрешить это облако?
96-10-31 rizzo@hogpa.ho.att.com (Anthony R Rizzo)
(A) поддерживать семейную гармонию и семейный доход. (B) делать то, что хорошо для компании.. (D) не брать отпуск (C) делать то, что хорошо для меня и моей семьи. (D') взять отпуск Я видел примеры дилбертовской политики. После нескольких испытаний такой глупой политикой большинство людей разрешают этот конфликт в сторону взятия отпуска. Они осознают, что допущение (A-B), что их уволят за выполнение того, что им говорят делать, ложно.
|
