Отзыв на книгу Павла Алферова "Проектное управление: как правильно делать правильные вещи"
Недавно я увидел, что на книжных полках магазина появилась “Проектное управление. Как правильно делать правильные вещи”, автором которой является Павел Алферов. Я посещал курс “Управление проектами”, проводимый Павлом, когда учился по программе MBA. Курс был настолько ярким, что, помня это, я не мог не купить эту книгу.
Недавно я вспоминал, как началось моё практическое знакомство с темой управления проектами, как я стал погружаться в эту тему, изучал PMBoK, а затем и проходил сертификацию PM Expert. Так совпало, что во время написания той заметки, я узнал, что в издательстве МИФ вышла книга “Проектное управление: как правильно делать правильные вещи”. Если быть честным, то разделы с книгами об управлении проектами, это не те места в книжных магазинах, к которым я подхожу в первую очередь. И я скорее пропустил бы книгу с подобным названием. Однако в этом случае всё было иначе. Во время обучения по программе MBA я посетил курс “Управление проектами”, который вёл Павел Алферов - профессор бизнес-практики школы управления “Сколково”, эксперт-практик, внедрявший проектное управление в крупнейших российских компаниях и отвечавший за построение системы управления знаниями в оргкомитете олимпиады в Сочи. А ещё Павел и является автором этой книги. Курс Павла был настолько ярким, что, помня это, я не мог не купить эту книгу.
Мир проектного управления большой. Вряд ли стоит ожидать, что на страницах одной книги получится погрузиться во всё многообразие задач, вызовов и проблем, с которыми приходится сталкиваться руководителю проектов. Тем не менее, прочитав книгу, считаю, что она может быть интересна и полезна и новичку, который получит прививку “хороших манер”, и потрёпанному жизнью участнику ни одного проекта, который словит вьетнамские флешбеки и сможет оглянуться назад и оценить, где он показал себя молодцом, а где можно было бы и поступить иначе.
В целом читалась книга легко. Обилие различных примеров неудачных и провальных проектов, к которым делаются отсылки на протяжения всего повествования - одно из украшений книги. Они не давали заскучать и сами по себе являются отличным инструментом обучения проектному менеджменту: зная неудачи других, начинаешь обращать внимание на то, чему раньше не придавал значения.
Можно книгу и немного покритиковать. Некоторые описанные модели оказались для меня сложными для понимания. Например, раскусить фишку “проектного ромба” я так и не смог. Возможно, и другим читателя это будет сделать не просто.
Не буду вдаваться в пересказ содержания книги, отмечу лишь некоторые инструменты руководителя проекта, которые у меня вызвали больший отклик. Я с ними либо сталкивался или же наоборот не применял их, но вспомнил случаи, когда они бы точно помогли, знал бы я о них ранее.
Фреймворк “Киневин”
В начале пути хорошо взглянуть на карту и компас, чтобы понять, где мы находимся, и определить в каком направлении идти, чтобы добраться туда, куда хочется. Такими картой и компасом может стать фреймворк “Киневин”, разработанный в IBM и позволяющий выбрать наиболее удачный подход к решению проблем. С его помощью мы можем оценить, в каком домене мы сейчас находимся и какой способ управления подходит для текущей ситуации.
Так в “простом” (simple) домене, где связи между причинами и следствиями ясны и предсказуемы, обычно существуют лучшие практики решения проблем подобного класса. Здесь эффективно выстраивать процессное управление, опираясь на процедуры и регламенты.
В случае “упорядоченных сложных” (complicated) систем с причинами и следствиями уже не всё так очевидно. Требуется привлечение экспертов, которые имеют опыт решения подобных задач и могут подсказать хорошие практики. Причём разные эксперты могут предложить разные пути, ведущие к требуемым результатам. Для данного домена модель “Киневин” рекомендует такой алгоритм действия: восприятие -> анализ и экспертиза -> реакция на основе результата экспертизы. В этом домене хорошо подходят практики классического проектного управления: планирование, экспертные оценки, этапность.
Движемся дальше и попадаем в “запутанный” (complex) домен. Здесь связи между причинами и следствиями также не ясны и в целом нет гарантии, что они все в итоге полностью прояснятся. Лучших и хороших практик тут уже нет, но некоторые части системы вполне могут быть похожи на что-то знакомое. Тут алгоритм действия такой: исследование -> восприятие и понимание -> реакция. Работа в этом домене подразумевает эксперименты, agile-практик с итеративным выдвижением гипотез и их проверками как раз то, что тут наиболее подходит.
Хочется ещё посложнее? Переходим в “хаотичный” (chaotic) домен. Тут уже нет никаких правил, связи непонятны. К месту будет процитировать классика: “Страшно, очень страшно, мы не знаем что это такое, если бы мы знали, что это такое, но мы не знаем, что это такое”. Алгоритм действий от создателей фреймворка такой: действие -> восприятие -> реакция.
Завершает модель - пятый домен - “беспорядок”. Коварен он тем, что мы в него можем свалиться из любого другого. И по факту зачастую в нём изначально и находимся, пока не разобрались что вокруг нас происходит. Цель тут простая: побыстрее сообразить где мы и выбраться из беспорядка в соответствующий домен и начать действовать, используя подходящие для этого домена инструменты.
Метод контрольных точек
В начале книги автор затрагивает вопрос отличия практик управления в зависимости от национальных особенностей. В частности рассматривается аспект, как в разных культурах принято работать с инцидентами. Работа с инцидентами важна, так как не устранённый вовремя инцидент может привести к провалу даже самого проработанного проекта. Так, например, отмечается, что для японской модели управления свойственно стремление не допускать инцидентов, для американской - быстрое устранение инцидентов, а русская модель ориентирована на решение кризисных ситуаций, когда уже произошла череда инцидентов и они сами, к сожалению, рассосаться не смогли и всё движется к краю пропасти.
Такое откладывание на потом каких-то проблем в надежде, что авось всё обойдётся, порой приводит к неизбежному авралу на завершающей стадии проекта.
Для того чтобы лучше отслеживать такие проблемы, можно использовать метод контрольных точек. Как отмечает автор, использование контрольных точек позволяет один большой аврал в конце проекта превратить в набор маленьких авральчиков по ходу проекта. Это с одной стороны позволяет держать команду в тонусе на всей дистанции, с другой - быстрее получать обратную связь по ходу проекта.
Что представляют собой эти контрольные точки? По ходу движения по проекту мы ожидаем получать разные результаты, которые приближают нас к достижению целей проекта. Это могут быть как какие-то высокоуровневые результаты, которые интересно отслеживать на уровне высшего руководства организации, так и результаты исполнения задач поменьше, которые отслеживаются на уровне руководителя проектов, и так далее.
Контрольные точки как раз и являются такими, если там можно сказать, КПП, которые мы можем пройти, если только достигли требующихся результатов. Чтобы определить контрольную точку надо ответить на 4 вопроса:
- Какой должен быть результат?
- Кто ответственный за результат?
- Каковы критерии приёмки?
- Когда должен быть получен результат?
Таким образом метод контрольных точек предлагает сместить акцент и контролировать не процесс исполнения проекта, а получение его ключевых результатов.
В целом, можно построить многоуровневый план по контрольным точкам. Высокоуровневые результаты и связанные с ними контрольные точки декомпозируются на нижележащие результаты и контрольные точки и т.д.
Внедрение методики контрольных точек требует выполнения 3 шагов:
- Фиксация контрольных точке, определённых на основе ожидаемых результатов проектов.
- Организация регулярных оценок статуса и рисков контрольных точек людьми, ответственными за конкретные контрольные точки.
- Проведение регулярных собраний, на которых обсуждаются статус проекта и определённых для него контрольных точек.
Автор предлагает для отслеживания статусов приближающихся контрольных точек использовать “светофор”, который должен сигнализировать о том успешно или нет мы движемся к достижению желаемых результатов, связанных с контрольной точкой. Особенно стоит отслеживать и бороться с ситуациями, когда из совещания к совещанию по какой-то контрольной точке все время был статус “зелёный”, “зелёный”, “зелёный”, то есть “движемся в срок, результаты будут”, а потом в момент прохода контрольной точки статус меняется на “красный”, который сообщает, что получение результата под угрозой.
Пентабазис
Последним упомянутым инструментом будет набор вопросов, ответы на которые автор предлагает получить перед началом проекта:
- Зачем и для кого мы делаем проект?
- Что мы хотим получить (продукты и эффекты)?
- Как мы ходим достичь результата?
- Кто будет достигать результата?
- Чем мы будем пользоваться для достижения результата?
Вопросы кажутся очевидными. Но всегда ли мы их задаём? Нам кажется, что всё и так просто, и потом получаем проблемы, который могли бы увидеть и предотвратить заранее. Может быть проект, вообще и не стоило начинать.
В качестве заключения
На сайте Павла Алфёрова есть отдельный раздел, посвящённый этой книге - https://alferov.expert/pm_book_mif. Загляните на него, там есть множество поясняющих схем и чек-листов для руководителей проектов. Быть может вы найдёте там то, чего вам не хватало.
