Лоуренс Лич. «Вовремя и в рамках бюджета», изданно в любимой Альпине. Книга посвящена применению и внедрению теории ограничений (TOC) в проектной деятельности по PMBoK. Полезна будет всем, кто профессионально занимается проектной деятельностью. А также тем, кто занимается ей, но не знает об этом. Для оных сообщаю: проект по PMBoK– это проектная работа , характеризующаяся большой непредсказуемостью (не конвейерное производство) и строго заданными бюджетом, сроками и составом работ.
Теория ограничений (описана в книге Цель Голдратта) – это набор практик и логических инструментов для нахождения ограничения в системе (бутылочного горлышка, слабого звена) и устранения его, либо оптимизации системы для максимально эффективного использования слабого звена с целью повышения производительности всей системы. Главный постулат: все составляющие системы не должны работать на 100%, если есть слабое звено. Все процессы должны быть подчинены тому, чтобы слабое звено работало на 100%.
В книге Лича рассматривается применение и внедрение концепций и инструментов теории ограничения для обеспечения выполнения проекта вовремя и в рамках бюджета.
Применимость и полезность
Даже если в вашей организации нет проектного управления и о PMBoK даже не слышали, то данная книга поможет осмыслить некоторые важные аспекты жизненного цикла проекта, понять основные причины отставания проектов по срокам и выхода за пределы бюджета.
Впрочем, внедрение планирование сроков исходя из 50% вероятности их соблюдения, а также внедрение буферов, представляется мне трудноосуществимым даже в рамках организации со зрелым управлением проектами. Но я верю, что это возможно и работает. Автор же внедрял :)
Интересно ли было читать? Сложно?
Читать было очень интересно. Размышления автора о причинах провалов проектов и как они соотносятся с законом Паркинсона при планировании задач. Как работают буферы и как их можно использовать для мониторинга состояния проекта. Разделение причин вариабельности проекта на среднестатистические, которые не стоит трогать, и из ряда вон выходящие, на которые стоит реагировать – достаточно свежая идея. Здесь к месту вспоминаются карты Шухарта. Книга сдобрена приличной пачкой ссылок на литературу, которая тоже нередко вызывает интерес.
Местами книгу сложновато читать, если очень слабое понимание законов статистики. Приходилось доверять автору на слово :)
Нужны заметки на полях или годится аудиоформат?
Однозначно эта книга не для аудио формата. Есть таблицы, есть графики, а главное, есть много мест, которые хочется выделить или выписать. Следствие чему конспект в конце поста.
Совет для читающих
Не принимайтесь за эту книгу не прочитав Цель Голдратта. А еще лучше прочитать следующий набор книг:
- Т. ДеМарко. Deadline
- Э. Голдратт. Цель
- Э. Голдратт. Дело не в везении (Цель 2)
- Л.Лич.
Вся книга одним предложением
Главная проблема проекта находится в системе управления, поэтому в срок и в рамках бюджета завершаются проекты только по двум причинам: они планировались с использованием метода критической цепи (не пути), либо кому-то просто очень повезло.
Конспект
Проект - это система. И все главные проблемы не в конкретной задаче, не в исполнителе или плане. А в связях между элементами системы, взаимосвязи.
Мой любимый вывод в книге: многие менеджеры были бы счастливы, если бы их проект имел отклонение от плана около 1 %. На практике отклонения гораздо больше. Из чего можно сделать вывод, что детализация плана проекта до операций продолжительностью меньше 1% от продолжительности проекта никак не поможет сдать проект в срок.
Есть два типа одной большой ошибки:
- вмешательство в систему с целью противостоять событиям, которые находятся в пределах статистической нормы работы системы.
- игнорирование изменений, которые выходят за пределы статистической нормы.
{slider title="Мысли по моим делам #1" open="false" class="icon"}
Мысль: нарисовать процесс от возникновения списка фич до релиза и продажи. Нарисовать систему и изучить ее на предмет слабых звеньев. Понять, как это звено усилить и что будет, если оно перестанет быть слабым.
Кстати, скорости релиза и своевременности релиза сильно мешает длительность тестирования. Если перевести на кластер и автоматизировать, то все будет супер. Можно релизить несколько раз в год. Сейчас это максимум два раза в год.
Мысль: надо нарисовать последовательность расчетного проекта. От постановки задачи до результата. И описать все НЯ в ходе проекта. Одно из НЯ: даже если мы уже решали похожую задачу, то не факт что решим сейчас. Нет базы знаний по прошлым проектам и их описание почти всегда неточное.
{/sliders}
По мнению автора, главная причина провала проекта: система управления проектом воздействует не на критическое звено. Если произошел успех проекта, значит случайно воздействовали на слабое звено.
Критическая цепь - это самый длинный путь после выравнивания ресурсов на диаграмме проекта, построенной методом критического пути.
«Программное обеспечение по проектному менеджменту выявляет критический путь, логически соединяя операции и высчитывая самую длинную цепочку работ. При этом предполагается, что ограничений по ресурсам нет. Затем менеджер проекта добавляет информацию о доступности ресурсов. Программы распределяют ресурсы, используя различные схемы, но обычно в первую очередь — на операции, находящиеся на критическом пути (то есть те, где самый минимальный временной резерв), потом на те, что занимают следующее место по длительности (со следующим наименьшим резервом). Люди, изучавшие вопрос распределения ресурсов, знают, что таким образом не всегда получается оптимальный график.»
«Одно из обязательных условий — закончить проект в соответствии с графиком. А чтобы выполнять проекты по графику, нужно, чтобы по графику шли все операции, находящиеся на критическом пути. Чтобы все операции критического пути выполнялись в срок, необходимо при планировании каждой «закладываться» на непредвиденное.»
Без мотивации на досрочное завершение, этапы проекта не могут быть завершены досрочно. Работа займет все время, что на нее выделено (закон Паркинсона). А если сверхурочные оплачиваются, то будет тенденция к затягиванию работ, чтобы получить сверхурочные.
Основные конфликты проектной работы, проводящие к срыву сроков, которые выделил Лич:
- Учитывать риски и делать запас при плановом vs сделать проект максимально кортом.
- Выполнить досрочно vs получить обвинения в плохом планировании и еще более ужатые сроки в будущем. + синдром студента, когда все делают в последний момент и от этого даже если кто-то сделал раньше, то следующий, кто должен принять дело, будет еще занят.
- При раннем старте нужно начать сразу все, что можно начать. В результате получается многозадачность и увеличение сроков. Брать vs не брать
Корневой конфликт: Выполнить проект вовремя, демонстрируя личный успех vs удовлетворить желание заказчика и взять больше обязательств и проектов на меньшие сроки и ресурсы.
"Для эффективного применения ССРМ в отдельном проекте крайне необходимо добиться следующих изменений привычного стиля работы:
-
руководство должно способствовать тому, чтобы при оценке операций давались средние величины, и не требовать от исполнителей завершения работ в точно обозначенные сроки;
-
руководство должно дать исполнителям возможность в конкретный момент времени заниматься только одним заданием;
-
исполнители должны сосредотачивать усилия на одной операции и передавать результаты на следующий этап, как только работа завершена;
-
чтобы решить, над чем дальше работать, каждый должен использовать план проекта и отчеты по буферу."
Слишком детальное разделение проекта на задачи даст рост потерь на редактирование плана и снизит контроль за ситуацией.
Если проект содержит операцию по уточнению содержания проекта (например, этап диагностики), то эта операция должна оказаться как можно раньше в проекте.
Бесконечная очередь: Если пропускная способность равна скорости наполнения стека, то очередь будет расти до бесконечности. Вероятность роста очереди высока вплоть до 30% превышения пропускной способности над скоростью наполнения.
Работа инженера в рамках метода критической цепи – это работа в режиме эстафеты: получил задач, сделай как можно скорее и отдай как можно скорее следующем. Для этого нужна очередь задач для каждого исполнителя.
{slider title="Мысли по моим делам #2" open="false" class="icon"}
проблема у меняя в том, что несколько моих ресурсов периодически простаивают. При этом я не готов курировать их проекты с утра до ночи, но при этом сам как-то не очень доверяю, считая проекты очень ответственными. Сделать можно так: пусть они сами целиком и полностью отвечают за свои проекты. Хватит жмотничать! А также нужно создать целый стек задач для них или стек общих задач в редмайн.
{/sliders}
Очередность задач должна определяться так: чем меньше остался буфер в цепи или проекте, тем раньше задача должна выполняться.
Если закладывать на каждую задачу какой-то запас, то сумма этих запасов будет существенно больше, чем величина буфера, правильно посчитанная (например, как квадратный корень суммы квадратов по задачам). Или как половина от продолжительности всех задач.
Ресурсный буфер: оповещение специалиста о том, что через столько-то дней надо будет скорее всего начать работы над задачей из критической цепи. Вообще, оповещению специалистов нужно уделить особое внимание.
Часто в конце проектов нужно слить много цепей в последние участки критической цепи. Из-за этого часто последние этапы проекта имеют самые большие опоздания. Т.к. опоздание лишь одной цепи, вливающейся в критическую, дает гарантированное опоздание проекта. А чем больше цепей, тем выше вероятность опоздания.
Вот почему необходим буфер на слияние для каждой цепи перед слитием с критической цепью.
Все буферы -это еще и инструмент контроля и анализа ситуации. Очень классной показалась вот такая диаграмма расходования буфера с тремя зонами (красная, желтая и зеленая). В зеленой зоне не нужно ничего предпринимать. В желтой зоне нужно планировать контрмеры. В красной зоне нужно применять запланированные меры.
Преждевременная реакция на отклонение может привести к расшатыванию процесса. Нужно убедиться, что отклонение не вызвано среднестатистической вариабелностью процесса.
Автор предлагает бороться с законом Паркинсона путем задания продолжительности операции с 50% вероятностью выполнения. Т.е. такая продолжительность будет существенно короче, чем обычная оценка. Забавно, что это входит в сильное противоречие с тем, о чем писал ДеМарко в своем Deadline, когда описывал неразумность задания агрессивно коротких сроков. Впрочем, Лич призывает приучить сотрудников к мысли, что это не обязательные сроки. Только не говорит, как это сделать и как это может работать :)
Вот что он говорит о борьбе с законом Паркинсона:
«агрессивные сроки (длительность работ, вполовину меньшая первоначальной оценочной), отсутствие точных дат начала и окончания, регулярные оповещения о том, сколько времени осталось на выполнение операции.»
А еще Лич против раннего старта операций, т.к. в этом случае сотрудник не считает задачу не из критической цепи срочной и растягивает удовольствие до последнего и опасного момента.
Выписал заинтересовавшую меня статью: Ireland, Lewis R. Quality Management for Projects and Programs, Upper Darby, PA: PMI, 1991.
Для крупных проектов нельзя сразу от ИСР перейти к графику (последовательности), слишком много промежуточных шагов. Поэтому можно использовать промежуточная шаг: диаграмма контрольных точек. Некие крупные события или результаты.
Мысль: ИСР можно повторить в структуре каталогов при хранении файлов по результатам проекта.
Составляя структуру расходов важно записывать из каких соображений делались расчеты, из чего состоят общие суммы. Тогда можно будет в случае изменений в проекте быстро понять, какая часть расходов остается, какая меняется.
{slider title="Мысли по моим делам #3" open="false" class="icon"}
Идея: создав опенсорс проект по мониторингу или планированию, можно существенно повысить свою видимость для профессионального мира. В частности у меня давно вертится идея доброго прибамбаса для redmine про мониторинг, дашборды, мир и любовь.
{/slider}