ГЛАВА 27

Схема-рамка «РИМ-III. Миниморум». 20 шагов реализации проекта

Все должно быть изложено так просто, как только возможно, но не проще.

Альберт Эйнштейн

Итак, мы подошли к практической части — конкретным шагам, которые связывают все воедино. Все, что я писал раньше, универсально и может быть применено вне той рамки, что я буду предлагать дальше. Вы можете использовать контрольные точки, «Описание проекта», «Сводный план» в своих проектах как рабочие инструменты. Или применять Пентабазис и цепочку решения проблемы как рабочие мыслительные модели. Но вам все равно придется как-то собирать под себя систему управления проектом.

Хочу предложить вам делать это не с нуля, а на основе схемы-рамки «РИМ-III. Миниморум». Это мой способ соединить элементы системы управления — кубики лего. Я много лет собирал и обобщал свой опыт, опыт студентов, которых учил, компаний, которые консультировал. Все это превратилось в пять национальных особенностей, о которых я рассказывал в , и в набор типовых рисков. В 2019 году для журнала Harvard Business Review я написал статью «Девять рисков, которые могут погубить все ваши проекты». С тех пор прошло уже много времени, и я расширил список до двенадцати типовых угроз проекту. Вот они:

1. Пентабазис. Нет ясного ответа, ЗАЧЕМ нужен проект.
2. Пентабазис. Нет ясного ответа, ЧТО будет результатом проекта.
3. Пентабазис. Нет ясного ответа, КАК выполнять проект.
4. ЛПР. Принятие решений ЗАТЯГИВАЕТСЯ руководством.
5. ЛПР. Ключевые решения по проекту часто и неуправляемо МЕНЯЮТСЯ.
6. Пользователи. НЕПОНИМАНИЕ и НЕЖЕЛАНИЕ использовать продукт.
7. Интересанты. Принятие решений блокируется КОНФЛИКТАМИ.
8. Команда. Неясно, КТО и ЧТО должен сделать (не распределена ответственность).
9. Команда. Ключевые участники НЕ МОГУТ выполнять задачи проекта (не компетентны).
10. Команда. Ключевые участники НЕ ХОТЯТ выполнять задачи проекта (не мотивированы).
11. Команда. Ключевые участники НЕ ИМЕЮТ ВРЕМЕНИ, чтобы выполнять задачи проекта (заняты).
12. Остальное. Установленные обязательства и ограничения по срокам, бюджету, результатам НЕИСПОЛНИМЫ.

Конечно, список не исчерпывающий. И под каждый вид проектов есть свои наборы типовых часто встречающихся рисков. У меня в личной базе знаний таких подборок десятка полтора. Но эти двенадцать могут стать базой, от которой стоит отталкиваться.

Соответственно, опираясь на «Модель швейцарского сыра», я собрал конструкцию из 4 ролей, 11 инструментов, 20 шагов и механизмов, а также 10 контрольных точек, скрепляющих все это вместе. Это целый пласт «листов сыра» — минимальный набор действий и инструментов, которые создают базовый костяк вашего проекта.

Это и есть РИМ-III. Миниморум. Схема-рамка, которая позволяет успешно реализовывать проекты с учетом национальных особенностей. Миниморум опирается на модели, которые я описывал выше: кроме пяти национальных особенностей и «Модели швейцарского сыра», это модели «Цепочка решения проблемы», «Пентабазис» и «Круг проектного мышления» и скрепляющий их все «Проектный ромб». Итак, попробуем свести все, что я рассказывал выше, в единую схему реализации проекта. Четыре роли в миниморуме те же, что требует ГОСТ: Куратор, Заказчик, Руководитель (Лидер) проекта, команда. Их мы уже разбирали. Начнем с инструментов. Напоминаю круг проектного мышления (рис. 27.1).

Нам нужны инструменты для управления каждым из аспектов (если в вашем проекте будут дополнительные аспекты, то и для управления ими тоже нужно будет подобрать соответствующие инструменты).

Ниже приведена таблица (табл. 27.1), где в левой колонке обозначены аспекты, которыми нам нужно управлять; в средней — инструменты, которые включены в миниморум; а в правой — возможные альтернативы им.

Таблица 27.1. Миниморум: общая схема

Ас­пект	Ин­ст­ру­мент РИМ-III. Ми­ни­мо­рум	Аль­тер­на­ти­ва
Ба­зо­вые ас­пек­ты
ЗА­ЧЕМ? Про­бле­ма	Опи­са­ние про­ек­та	При­каз о за­пус­ке про­ек­та Кон­цеп­ция про­ек­та Пас­порт про­ек­та Мо­дель эф­фек­тов
ЧТО? Це­ли, ре­зуль­та­ты, эф­фек­ты
КАК? Стра­те­гия про­ек­та
КТО и ЧЕМ? Участ­ни­ки и ре­сур­сы		Ре­сур­с­ный план
Клю­че­вые фор­маль­ные ас­пек­ты
Обя­за­тельст­ва	Про­то­ко­лы встреч (не­обя­за­тель­но фор­маль­ные)	Ре­естр обя­за­тельств
Со­дер­жа­ние	Ме­ха­низм фик­са­ции тре­бо­ва­ний к про­дук­ту про­ек­та. Ме­ха­низм про­вер­ки и при­ем­ки ре­зуль­та­тов. Таск-ме­нед­жер (IT-сис­те­ма для за­дач, до­ку­мен­тов, рис­ков и от­кры­тых во­про­сов)	Тех­ни­чес­кое за­да­ние Ре­естр тре­бо­ва­ний Бэк­лог про­дук­та
Сро­ки	Таск-ме­нед­жер	Ка­лен­дар­ный план
За­тра­ты	Раз­дел в Свод­ном пла­не	От­дель­ный бюд­жет про­ек­та
Рис­ки	Про­гно­зи­ро­ва­ние кон­троль­ных то­чек по свод­но­му пла­ну Таск-ме­нед­жер	Ре­естр рис­ков Мат­ри­ца рис­ков Лист от­кры­тых во­про­сов (ЛОВ)
Об­щие для всех фор­маль­ных ас­пек­тов	Ме­ха­низм пла­ни­ро­ва­ния Cводный план с кон­троль­ны­ми точ­ка­ми
Клю­че­вые че­ло­ве­чес­кие ас­пек­ты
ЛПР. Ку­ра­тор	Ре­гу­ляр­ные (еже­ме­сяч­ные) встре­чи с Ку­ра­то­ром От­че­ты по про­ек­ту	План встреч
ЛПР. За­каз­чик	Ре­гу­ляр­ные встре­чи с За­каз­чи­ком От­че­ты по про­ек­ту	План встреч
Поль­зо­ва­те­ли и ин­те­ре­сан­ты	Мат­ри­ца стейк­хол­де­ров Раз­дел в Свод­ном пла­не	План ком­му­ни­ка­ций
Ко­ман­да	Раз­дел в свод­ном пла­не Пра­ви­ла мо­ти­ва­ции ко­ман­ды Стар­то­вое со­ве­ща­ние Пра­ви­ла вза­и­мо­дейст­вия ко­ман­ды Еже­не­дель­ные встре­чи ко­ман­ды Об­щая груп­па в мес­сенд­же­ре Таск-ме­нед­жер	При­каз со спис­ком ко­ман­ды Мат­ри­ца рас­пре­де­ле­ния от­вет­ст­вен­нос­ти Ре­сур­с­ный план

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

Если вы не знаете, какие инструменты вам подойдут, рекомендую посмотреть «Базу рабочих инструментов и знаний проектного управления» (БРИЗ). Мы создали ее совместно с известным экспертом в области проектного управления Андреем Малаховым. БРИЗ содержит описание разных моделей и методов, инструментов и фреймворков.

Выбор инструментов во многом зависит от того, какие установки, подходы, теории и концепции разделяете вы и те, кто принимает решения на проекте. А еще — от установленных ограничений, уровня неопределенности и многих других факторов.

С базовыми аспектами все просто, здесь основной инструмент — описание проекта. Именно в нем фиксируются ответы на все вопросы. Альтернативой ему станут документы, которые мы разбирали в : Концепция проекта, Паспорт проекта, Модель эффектов и так далее. Также можно использовать приказ о запуске проекта, в котором фиксируется информация по аспектам.

Для всех ключевых формальных аспектов общими будут механизм планирования и его главный результат — сводный план с контрольными точками. Именно он объединяет все аспекты: фиксирует наши обязательства, содержание и сроки в виде контрольных точек, а также затраты.

Для обязательств важный инструмент — протоколы встреч. Необязательно делать их в формальном виде. Этот документ может носить более неформальное название — «Итоги встречи». Во всем мире принято называть его follow-up: после встречи некоторые краткие итоги (что обсуждали, что решили) рассылаются по почте всем заинтересованным. Готовится письмо формата: «Коллеги, фиксирую договоренности по итогам встречи… Пожалуйста, проверьте, все ли правильно вспомнил…»

Для очень формализованных историй это может быть отдельный реестр требований / обязательств. Я рассказывал выше, как в Оргкомитете «Сочи-2014» мы насчитали свыше трех тысяч разных обязательств. Чем более формально ваше окружение, тем больше внимания уделите этому аспекту. В сводный план обязательно нужно внести контрольные точки по разработке официальных документов.

Для содержания основные инструменты — механизм фиксации требований к продукту проекта и механизм проверки и приемки результатов — мы разбирали их в . Альтернативой им может стать тривиальное техническое задание — без особых изысканий: взяли и написали все требования к результатам.

Также важный инструмент для работы с содержанием — IT-система для задач, документов, рисков и открытых вопросов. Сейчас есть много таких IT-систем, обычно их называют таск-менеджерами. На сайте книги (см. ) есть обзор таск-менеджеров — выберите тот из них, который вам подходит. А можно и просто в табличке на сетевом диске вести. Но вести нужно обязательно!

В таск-менеджер попадают все задачи, которые должна выполнить команда: как предметные (по созданию продукта проекта), так и управленческие. Например, при запуске механизма, причем любого — сбора требований, изменений и так далее, — его шаги попадают в таск-менеджер. Действия разных этапов — анализ опыта аналогичных проектов, вариантов реализации и так далее — должны попасть в таск-менеджер. Провели регулярную встречу рабочей группы, зафиксировали новые задачи? Они тоже должны попасть в таск-менеджер. Все работы команды на ближайшую перспективу — тоже.

Помните притчу о камнях и песке в банке? Сводный план фиксирует «камни», а таск-менеджер — «песок», чтобы его тоже не потерять. По песчинкам мы приходим к большим камням.

Также в таск-менеджере ведется лист открытых вопросов (ЛОВ) — это фактически бортовой журнал проекта. Знаете, на кораблях есть такие? Моряки все в них фиксируют: «Прошли мыс Гаттерас — впереди рифы. Настроение команды бодрое».

Его также называют реестром инцидентов, реестром проблем. В него заносится все, что непонятно в проекте, что требует внимания и проработки. Учитывая, что риски — это будущие проблемы, а проблемы — реализовавшиеся риски, можно считать, что ЛОВ — в том числе и инструмент для работы с рисками. Его можно вести как отдельный файл, но в принципе все таск-менеджеры позволяют работать с вопросами (англ. issues, issue log).

Все таск-менеджеры дают возможность хранить документы проекта.

Для сроков базой становятся все тот же сводный план и система для списка задач и открытых вопросов. Альтернативой может быть календарный план проекта. Если вы решите все задачи («песок») отражать в календарном плане, то это тоже возможно, хотя и трудоемко. О программах для создания календарного плана (модели проекта) я говорил в . Это более сложный в работе инструмент, однако он удобен, если у вас есть много связей между задачами и имеются в команде специальная роль и специальный человек для работы с планом — планировщик.

Для затрат есть раздел в сводном плане. Но можно приготовить и отдельный документ — бюджет проекта. Вообще, тема работы с затратами очень плотно регулируется финансовыми подразделениями организаций, и, скорее всего, вам сообщат, какие финансовые документы нужно готовить в проекте. Универсальных историй здесь практически нет, у каждой организации свои правила.

Для рисков основным инструментом будет в первую очередь прогнозирование будущих статусов контрольных точек, о котором я рассказывал в  (помните три статуса: зеленый, желтый, красный?).

Так вот, если руководитель проекта еженедельно будет ставить статус риска по каждой контрольной точке в сводном плане, то вырисуется весьма наглядная картина. Изучите примеры на рис. 27.3–27.4.

Получается совмещенный план и отчет, по которому видно, где проседает проект, куда нужно направить основное внимание.

Если этот инструмент вам почему-то не подходит, можете использовать более традиционные реестр и (или) матрицу рисков. Их шаблоны тоже есть на сайте книги (см. ).

Для ключевых человеческих аспектов общим для всех будет все тот же сводный план с контрольными точками. Для Куратора и Заказчика дополнительно нужно предусмотреть отчет по статусу проекта и регулярные встречи. Их обязательно нужно проводить. И не когда получится, а регулярно.

Для пользователей и интересантов основными инструментами будут матрица стейкхолдеров и соответствующий раздел в Сводном плане.

Для управления командой инструментов, как видите, больше всего. Кроме многократно уже упомянутых Сводного плана и таск-менеджера, есть еще несколько важных инструментов.

Начнем с простых. Общая группа в мессенджере уже стала непременным атрибутом практически любого проекта. При этом еще лет десять назад этот инструмент был почти неизвестен. Так что здесь сложно загадывать, какие новые телекоммуникационные решения появятся в ближайшие годы, но канал оперативной коммуникации точно будет очень востребован командами.

Далее — еженедельные встречи команды. Звучит как тривиальная мысль — ну конечно, нужно собираться, координироваться. Все понятно. Вот только не собираются… Поэтому я настоятельно рекомендую установить в календаре у всех конкретное время, например 10:00 каждый понедельник, для встречи команды на час. Есть о чем поговорить — час поговорили. Не о чем — поговорили 15 минут: каждый из членов команды сказал, что он делал в предыдущую неделю для проекта, что планирует делать на следующей неделе, какие у него есть проблемы / барьеры. Должно быть такое правило командное — регулярно встречаться.

Кстати, о правилах. Другая важная вещь — правила взаимодействия команды. В английском варианте они называются DOES and DONT’S — ДЕЛАЕМ / НЕ ДЕЛАЕМ. Правила фиксируют, что у нас можно, а чего нельзя. У нас в команде можно ругаться матом? А должны ли быть включены камеры, когда мы по видеосвязи созваниваемся? А когда мы все вместе должны присутствовать? Древние римляне говорили: “Ubi homines sunt modi sunt” («Где люди, там правила»). Без установленных правил работы команда не может быть эффективной.

Еще один важный инструмент — правила мотивации команды. На эту тему написано очень много книг и статей. Но все сводится к тому, что команда должна быть четко мотивирована на получение результатов. Каждый ее член должен знать, что ему светит, если будут получены необходимые результаты, и что его ждет, если эти результаты получены не будут.

Следующий инструмент — стартовое совещание (его еще называют установочным совещанием, или kick-off). Необходимо всех ключевых участников проекта собрать в одной комнате (или на видеоконференции) и попросить Куратора объяснить, насколько важен проект для организации. А потом показать ваше описание проекта — ознакомить всех с целями, основными этапами и распределением ролей. После этого никто не сможет сказать, что был не в курсе. При выборе формата встречи отталкивайтесь от масштаба вашего проекта и его сложности. В каком формате пройдет совещание — не так важно. Хоть в театрализованном. Помните историю с глобусом? Когда генеральный директор вышел перед залом и обещал, что лучшие поедут на любую точку на глобусе вместе с семьей? Так что не пренебрегайте стартовым совещанием. Особенно если оно, как в этом примере, совмещено с системой мотивации.

Выше — минимальный набор шагов, которые необходимы для реализации проекта (рис. 27.5).

Разберем их в следующей главе на нашем сквозном примере — открытии филиала компании «Кварк».

Краткого резюме в этой главе не будет, ведь она сама и есть краткое резюме всей книги.

Отправить