В статье директора Практики PM Excellence Валерия Громова, PME, PMP рассказывается о необходимости, целях использования и преимуществах шаблонов в управлении проектами.
Что такое шаблон? Шаблон – типовой календарно-сетевой график, содержащий общую информацию, на основе которой можно разработать календарно-сетевой график для проектов определённого типа.
“Нужны ли вам шаблоны? Не факт. Но в большинстве случаев приходилось иметь дело с ситуациями, когда шаблоны актуальны. Иногда это небольшие проекты с парой десятков строк, иногда - настоящие монстры в несколько тысяч строк, с полным описанием выпуска проектной документации по новому наукоёмкому изделию”.
Читайте полный текст статьи:
"Часто термин «шаблон» несёт негативный смысл. Ох уж эти «шаблонные ответы» – отмазки, «шаблонное мышление» – упрощённое, неоригинальное. Но в Календарно-сетевом планировании шаблоны играют весьма позитивную роль. Постараюсь доказать почему.
Но сначала – определение. Шаблон (он же «рыба») – типовой календарно-сетевой график, содержащий общую информацию, на основе которой можно разработать календарно-сетевой график для проектов определённого типа. Таким образом, теоретически шаблон может содержать практически все типы данных, которые присутствуют в календарно-сетевом графике, кроме факта, базовых планов и контрактных обязательств, общих параметров проекта. Они для каждого проекта уникальны.
Нужны ли Вам шаблоны? Не факт. Бывают виды деятельности, где проекты совсем уникальны и никогда не повторяются. Или проект всего один, и не разбивается на типовые блоки. Тут, конечно, о шаблонах нет и речи. Но в большинстве случаев приходилось иметь дело с ситуациями, когда шаблоны актуальны. Иногда это небольшие проекты с парой десятков строк, например, с описанием процедуры контрактации, иногда настоящие монстры в несколько тысяч строк, с полным описанием выпуска проектной документации по новому наукоёмкому изделию.
Так какие преимущества даёт шаблон?
- Сокращение времени разработки календарно-сетевых графиков. Иногда довольно большое. Как-то раз по просьбе Заказчика даже пришлось сравнивать время разработки планировщиками календарно-сетевых графиков на основе шаблона и «с нуля». Для проектов в две сотни операций шаблон в среднем ускорил разработку с 4-х часов до 20 минут. Это был, конечно, предельный случай, но то, что шаблон облегчает разработку календарно-сетевых графиков в той или иной степени, очевидно.
- Перечень единообразных вех. До чего же иногда поражают способности планировщиков называть по-своему одни и те же события. Казалось бы, например, момент подписания договора очевидно стоит обозначить вехой «договор подписан». Ну нет, накал креативности не знает пределов! Тут тебе и «договор закрыт», и «подпись в договоре есть!», и просто «договор», и много чего ещё. Весь этот зоопарк дико смотрится в отчёте по контрольным точкам для портфеля проектов. В общем, если все важные вехи сформулировать в шаблоне, у ТОПов будет меньше вопросов.
- Единая структура работ. Отлично, если хотя бы структура работ первых уровней имеет типовые названия. Конечно, проекты могут содержать уникальные структуры работ. Но общий принцип организации структуры работ, заложенный в шаблон, например, «Сначала по видам работ, а потом по объектам», здорово поможет.
- Взаимозаменяемость планировщиков. Был недавно случай, когда планировщик прервал разработку календарно-сетевого графика по личным обстоятельствам и с ним не было связи. Мы не знали какие части календарно-сетевого графика разработаны, какие – нет. Проверять оказалось дольше, чем написать заново. Как правило, в грамотно написанном шаблоне хорошо видно, где уже планировщик поработал, а какие части остаются пока типовыми.
Как написать хороший шаблон? Казалось бы, возьми хороший завершённый проект и используй как «рыбу» для новых проектов. Однако не всё так просто.
- Прежде очевидное. Следует убрать из календарно-сетевого графика все следы актуализации – все фактические данные, временные ограничения, прерывания, базовые планы. (Если платформа Project Server и происходит отчётность исполнителей через PWA – убрать чёртовы сведения о владельцах назначений).
- Очистить конкретику проекта – поля уровня проекта, например, с номером договора, очистить крайние сроки для Project.
- Внимательно проверить названия операции и иерархическую структуру работ на наличие в них конкретики прежнего проекта. Однажды пропустил в шаблон задачу «Разработка блока КТ37/09». Потом, через год, был страшный переполох – все искали злосчастный блок КТ37/09, пока не выяснили, что он не должен разрабатываться в данном проекте. Обычно, когда в шаблоне избавляюсь от конкретики, не делаю пропуск, а акцентирую внимание планировщика звездочками – «Разработка блока *******Введите название блока*********». Звёздочки в названиях работ, ресурсов вообще вещь полезная. Если лентяй-планировщик просто взял шаблон, ввёл актуальную дату начала, новое название, и даже не удосужился прочитать содержание, звездочки, или сами выберите какой-нибудь спецсимвол, подскажут Вам, что календарно-сетевой график ещё не готов.
- Заменить обычные ресурсы ролевыми. Никаких конкретных сотрудников в шаблоне, иначе они вечно будут получать новые назначения из всех новых проектов и лишатся воли от немыслимой перегрузки.
- Ломать – не строить. Пользователю шаблона проще удалить пакет работ, если он не требуется в текущем проекте, чем создавать его. Разумеется, тут и меру надо знать, но, на мой взгляд, если есть 20% вероятность, что пакет работ должен быть в проекте, я его оставляю. Правда, с заметкой – «В таких-то обстоятельствах пакет удалить».
- Некоторая избыточность связей. Вопрос неоднозначный. Обычно с избыточными связями приходится бороться. Например, если 3 задачи связаны последовательно, глупо связывать ещё и первую задачу с последней. Это только захламляет календарно-сетевой график и при этом не несёт полезной информации.
Однако, если велика вероятность удаления операции «Закупка недостающих материалов», что в приведённом примере стоит поставить ещё одну связь, между проектированием и сборкой. В этом случае при удалении закупки проект не развалится на два независимых, а лишняя связь сохранит логику. (Пример приведён упрощённый. В реальной практике вместо отдельных операций, как правило, целые пакеты работ). Конечно, тут не стоит переусердствовать. Лично у меня простое правило. Если, проверяя календарно-сетевые графики-планировщиков, которые использовали шаблон, я пару раз нахожу потерю логики из-за удаления лишнего пакета работ, лезу в шаблон и ставлю избыточную связь.
- «Много шаблонов или один общий?». Нередко задают вопрос. У нас несколько типов проектов, немного отличающихся по составу операций. «Что лучше – создать универсальный шаблон или под каждый тип проекта создавать свой?» . Казалось бы, пользователю проще – используй шаблон нужного типа и нет проблем. Однако следует помнить, что при возникновении необходимости изменения части, общей для всех типов проектов, придётся перелопачивать все шаблоны. Практика показывает, что перелопатить все шаблоны удаётся не всегда, некоторые шаблоны остаются неизменёнными, плюс некоторые дающиеся планировщики своих шаблонов наклепают и бардак нарастает, как энтропия во вселенной.
- Шаблон нужно вырастить. Шаблон невозможно сразу хорошо написать. Технология выполнения проекта или его рамки, требования к детализации, ресурсному, финансовому планированию могут измениться. Могут появиться интеграционные модули, или новые отчёты, требующие изменения шаблона. Часто просто возникает идея, как упростить календарно-сетевой график . Так или иначе, шаблон ТОЧНО будет меняться. И этот процесс никак нельзя пускать на самотёк. Если не предусмотрено изменение шаблона, скоро он станет устаревшим и перестанет использоваться. Если всем пользователям дать возможность менять шаблон, его быстро уничтожат или понаделают массу копий. Совет простой. У шаблона обязательно должен быть владелец. (Очень желательно сведения о владельце разместить в шаблоне). Владельцу можно будет задать вопросы по шаблону, направить замечания и предложения по улучшению. В нормативке должна быть предусмотрена процедура модификации шаблона. Например, у пользователя возникла идея добавить в шаблон некий пакет работ. Пользователь отправляет заявку на изменение владельцу шаблона, тот согласует изменение, в случае успеха вносит правки в шаблон, уведомляет об этом пользователей.
- Шаблон должен быть понятен и принят пользователями. Это важный фактор. Как-то раз попросил клиент, которому год назад внедряли информационную систему управления проектами (ИСУП), написать интеграционный модуль. А заодно и посмотреть текущее состояние планирования. Сразу увидел, что шаблоном пользуются не все пользователи. Выяснилось, что один не знал о существовании шаблона, остальные не использовали потому что «там всё запутано», то есть не стали в нём разбираться. Проблему, конечно, можно решить административным приказом – «Всем использовать шаблон», но от этого понимание лучше не станет. Чтобы шаблон был понятен, его обязательно писать вместе с будущими пользователями, вылизывая формулировки названий, логику работ, обсуждать шаблон с максимальным числом пользователей. Помню, для одного проектного института пришлось возиться с шаблоном несколько недель, консультируясь со множеством сотрудников. В конце конов, когда я услышал, что между собой они стали называть шаблон «Наш шаблон», стало понятно, что толк будет. Для тех, кого не затронуло обсуждение шаблона, следует написать пояснительную записку к шаблону. Обычно это небольшой документ, описывающий общую структуру шаблона, его логику, пояснения к отдельным неочевидным элементам, рекомендации – что и где удалять, добавлять при разработке календарно-сетевой модели на основе данного шаблона. Не хочу сказать, что ко всем шаблонам пишу пояснительную записку. Рецепт такой – если шаблон достаточно сложен, чтобы у новичка возникли затруднения или вопросы, излагаю ответы в пояснительной записке.
- «Клавишник» или «Предметник», кто должен написать шаблон? Пусть подрядчик или собственный ИТ-отдел развернул информационную систему управления проектами (ИСУП). Провёл нужные настройки, построил систему аналитической отчётности по эскизам руководства. Можно им же и поручить разработку шаблонов. У такого решения есть минусы. Сотрудник ИТ отдела, и тем более специалист по ИСУП от подрядчика, имеет очень общее представление о предмете планирования. Таких у нас «клавишниками» называют. (Ох и погоняли тряпками меня однажды, за то что закрылки с предкрылки в крыле самолёта перепутал). «Клавишник», даже если честно проработал отраслевые стандарты, ошибок по специфике предмета понаделает. Кроме того, ну кто из нас не побывал в плену профессионального чванства? «Фи», скажут внутренние специалисты, «ну что там хорошего мог написать этот компьютерщик». И будут всеми силами демонстративно игнорировать шаблон. С другой стороны, специалист в предметной области (будем называть предметником) не всегда может написать толковый шаблон. Во-первых, он наверняка сильно занят на проектах, и когда его отвлекут дополнительной работой, не факт, что будет стараться. Во-вторых, предметник недавно научился инструменту и, конечно, продемонстрирует весь арсенал ошибок начинающего планировщика. При этом потратив массу времени и сил. В-третьих. Начинается главное веселье, когда приходит второй предметник и они начинают спорить между собой, как правильно проводить работы. Тут обычно выясняется, что и в ГОСТе написано не так, и в прошлом проекте мы делали неправильно и т.п. Преподаватели, которые на занятии пытались экспромтом, по подсказкам группы, написать реальный кейс, полагаю, хорошо меня понимают. Баталии разыгрываются нешуточные. Вот тут важно не потерять инициативу. Обязательно спорщиков нужно привести к компромиссу, никто не должен уйти обиженным. Помните, шаблон внедрится лишь тогда, когда пользователи начнут про него думать «Наш шаблон». А по сему, идеальным вариантом будет, когда «предметник» и «клавишник» делают шаблон вместе. Ели так не получается, то легче «предметника» научить премудростям составления календарно-сетевых графиков, чем «клавишника» учить тонкостям предмета планирования. По крайней мере, у нас в PMExcellence, как правило, на роль планировщиков берут сотрудников из отраслей (стройка, производство, нефтегаз, энергетика), иногда без опыта работы планировщиком. Потом они попадают ко мне в когти, где учатся планировать во всём что планирует, после чего начинают работу в командах по своей специализации.
- Шаблон не обязан быть похожим на проект. Шаблон – помощник планировщика. Не стесняйтесь писать в заметках полезную информацию для планировщика. Например «Здесь создайте директивные контрольные точки. Откройте договор, внесите все обязательства, которые в нём указаны как отдельные вехи. В названии вех обязательно укажите номера пунктов из договора. Сроки внесите в …». Вполне допустимы гиперссылки на источники информации, нормативные документы, инструкции по разработке календарно-сетевого графика. Если не хочу, чтобы инструкция потом была в календарно-сетевом графике, помещаю её в задачу с названием «***Подсказка. Сотри меня ***».
Вывод. Шаблоны, если они целесообразны для Ваших задач, здорово повышают жизнеспособность и полезность информационной системы управления проектами (ИСУП). Уделите им должное внимание."