Я хочу рассказать о нескольких подходах к планированию и о том, почему и когда они не работают. А также — что с этим делать.
Зачем?
Начнем с простого: а зачем вообще планировать? Представим, что есть некая цель, для достижения которой надо в определенном порядке выполнить несколько дел. Простейшим планом будет выстраивание
последовательности действий так, чтобы на заключительном шаге мы достигли бы цели. Собственно, план и служит для того, чтобы обеспечить ее достижение. Точнее, в идеальном мире он именно для этого и
предназначен. В неидеальном — возможны варианты типа «план ради плана» или «план без цели». Об этом поговорим чуть позже, а пока рассмотрим, как правильно составить план, конкретно — сложный план
нетривиального мероприятия (проекта). Потому что «просто план» способен сформировать практически каждый, а вот «победить объем» может оказаться не так просто, как хотелось бы.
С чего начать?
Я считаю, что план имеет смысл составлять «сверху вниз». Для начала определяем точки контроля верхнего уровня. Да, именно точки контроля, а не мероприятия, работы и т. д. Почему? Потому что,
составляя план, надо постоянно помнить, как и кому мы будем сдавать его реализацию. Потому что проект выполняется для того, кто заинтересован в результате, то есть для заказчика. Таким образом, мы
приходим к первому важному выводу: проект должен начинаться с определения заказчика. А если немного подняться «над проектом», то он должен начинаться с определения ролей. Кто есть кто в проекте?
Кто заказчик, кто руководитель, кто спонсор (держатель инвестиций), кто сотрудники? Это всё не просто важно, а очень важно. Особенно если учесть, что в проекте достигается некий результат как
совокупность усилий сотрудников — и основа ролевой модели состоит как раз в том, чтобы расписать не только спонсора-заказчика, но и роли внутри команды. Поверьте, это существенно облегчает жизнь,
причем всем участникам проекта. Появляются четкие границы ответственности, некий водораздел между сотрудниками и функциями. Впрочем, возникает вопрос: а можно ли без этого? Скажу так: жить без
полной ролевой модели в проекте (ну или в деградированной ролевой модели: руководитель, команда проекта и заказчик) в принципе можно. Но сложностей появляется достаточно много. Особенно в ситуации,
когда надо что-то сделать, а все кивают на соседа, указывая, что именно он должен… А он, в свою очередь, тоже кивает на соседа и т. д. Грамотно составленная ролевая модель позволяет если не
свести к нулю подобные конфликты, то заметно сократить их количество. Словом, первый шаг при планировании — сформировать ролевую модель проекта. Кроме определения ответственности, она косвенно
составит основу ресурсного планирования на этапе, когда будем распределять работы и необходимые фонды.
Следующий шаг — создание устава проекта. Это документ, в котором должны быть зафиксированы основные проектные положения. Например, ролевая модель и команда, а также достигнутые цели. Удивительно,
но я часто сталкивался с тем, что на данном этапе в устав попадали непроверяемые, нереалистичные и просто некорректно сформулированные цели. Маленький совет: когда оформляете устав, помните о
«целях по SMART». То есть любая цель должна быть конкретной, достижимой, измеримой, актуальной и имеющей временные границы. Цель в уставе — первая, отправная точка для организации контроля. Еще в
документ включают значимую для проекта информацию, прямо или косвенно отражающуюся на планировании. В частности, это могут быть требования к результату (также сформированные по SMART), к ходу
процесса, критерии достижения целей и/или критерии выполнения проекта, предполагаемые риски и примерные стратегии по работе с ними… Словом, устав, по сути, план очень высокого уровня плюс важные
дополнения, позволяющие его реализовать. Кстати, не следует путать его с заданием на проект. Задание описывает аспекты результата, а устав — подходы к выполнению проекта. Устав — документ «со
стороны бизнеса», а задание — это описание решения (в идеале «до последнего винтика», но я лично таких заданий не встречал… каждый раз приходилось планировать работы по уточнению задания. И не
потому, что оно написано плохо, а потому что в процессе реализации могут внезапно появиться «черные лебеди», то есть ситуации и трудности, которые на старте вообще невозможно предусмотреть).
Как расставить КТ-0 и что это такое?
Вернемся к точкам контроля. Как я уже сказал, планировать имеет смысл по принципу «сверху вниз» и начинать с определений точек контроля верхнего уровня. Они — прямое следствие целей из устава, или,
как вариант, отображение движения к цели. Причем надо иметь в виду, что точки контроля верхнего уровня (КТ-0) — это, прежде всего, конкретные бизнес-результаты, в них должно быть реализовано и
проверено то, что несет конкретные бизнес-выгоды. В КТ-0 не важны и даже вредны технические аспекты. Данные точки отличает то, что в них создается частично законченный продукт, достигается та или
иная цель устава или на крайний случай демонстрируется прогресс выполнения работ в заданном направлении. При планировании КТ-0 будут представлять собой конкретные вехи. Например: «создана базовая
инфраструктура решения» (в уставе должно быть определено, что это такое и что считать проверкой «создана») или «возведен фундамент здания» (опять-таки, «фундамент», очевидно, не просто яма, залитая
бетоном, но и проект фундамента как часть проекта строительства, разрешительная документация и т. д., и все это должно быть отражено в уставе). Разумеется, КТ-0 удобны для заказчика, но мало
пригодны для реальной работы. Поэтому следующий шаг при планировании проекта — определение контрольных точек первого уровня. Я называю их контрольными точками руководителя проекта. По ним делается
вывод о том, насколько проект продвинулся к цели с уровня управления проектом. КТ-1 более мелкие, чем КТ-0, и в общем соответствуют структуре работ по достижению того или иного результата. В
сложных проектах, где есть несколько команд, я часто планирую КТ-1 как точки успеха той или иной команды по достижению цели. На этом же уровне я ввожу понятие «критические КТ», то есть КТ, которые
лежат на критическом пути проекта. В итоге, при таком подходе к планированию, автоматически возникает сфера повышенного контроля (КТ критического пути) и сфера нормального контроля (просто КТ).
Далее — формирование КТ-2, или контрольных точек второго и более низкого уровня. Этот шаг я делаю обычно после того, как провожу декомпозицию работ, потому что подобные точки являются вехами для
руководителей команд исполнителей. В проекте (в зависимости от масштаба) могут быть определены и более мелкие КТ, но о них расскажу позднее.
Почему важны КТ-1?
После того как определены КТ-0 и КТ-1, я обычно формирую структуру работ проекта верхнего уровня. Почему? Да потому что на данном этапе важно определить, какие работы приведут к достижению каких
КТ. А делать это лучше всего укрупненно. Кстати, на этом этапе обычно возникает такой интересный вопрос, как подход к планированию. Поясню на примере. Мы можем планировать по принципу «надо сделать
проект, есть год, но нет жесткой даты» — в таком случае мы планируем «от начала», то есть принимаем дату старта работ в будущем (возможно, недалеком) и составляем план таким образом, чтобы он
совпадал с согласованной датой и длился не более предусмотренного срока. Второй подход — планирование по жестким КТ-0. В данном случае мы планируем фактически исходя из даты окончания и требований
к реализации КТ по принципу «точно в срок». Здесь принципиально следующее: зачастую эти КТ «несдвигаемы» настолько, что приходится договариваться об изменении их содержания, когда понимаешь, что
даже резкое увеличение бюджета и команды не приведет к успеху (помните знаменитое: «девять женщин за месяц ребенка не родят»). Третий случай — когда несколько КТ-0 «жесткие», а несколько могут быть
сдвинуты в ту или иную сторону. Между прочим, такая ситуация встречается достаточно часто. И тут планировать следует по сценарию «выполнить жесткие КТ в срок, а срок остальных — как получится».
Как я говорил, на этом шаге мы укрупненно прописываем структуру работ. Планируя их, важно не упустить ничего (здесь, кстати, кроется так называемая отраслевая специфика РП — менеджер без опыта в
отрасли сможет спланировать проект, но только вместе с сильными специалистами, которые подскажут, что от чего зависит; менеджер же с опытом в отрасли сможет спланировать работы первого уровня без
привлечения экспертов, но это не значит, что впоследствии их не надо верифицировать). Фактически же на этом шаге мы выстраиваем такую структуру работ, которая приведет к достижению целей проекта и
не сдвинет «жесткие» КТ. При планировании крупных проектов данный этап может оказаться довольно сложным в силу взаимосвязанности работ и ресурсных возможностей команды исполнителей. Тут приходится
«быть всем»: и продавцом проекта команде, и менеджером, и человеком-с-палкой, и человеком-с-пряником.
Очередной этап — декомпозиция работ на команды. Его особенность в том, что если работы передаются для декомпозиции в разные команды, то она может быть выполнена очень разного качества. И задача РП
— привести качество декомпозиции к единым стандартам. Принципы очень простые: есть точки контроля РП (КТ-1), относительно которых я хочу знать, как движется проект. Поэтому, планируя точки для РП и
принимая декомпозицию, всегда задаю себе один-единственный вопрос: как я определяю, где мы сейчас находимся? Если декомпозиция работ дает достаточно информации (в частности, КТ-2) для ответа на
этот вопрос, я ее принимаю. Если нет — прошу доработать или сам включаюсь в планирование декомпозиции, поскольку считаю, что планирование — прерогатива РП, а плохой план — первый шаг к провалу по
срокам или по качеству.
Немного про контроль
Тут часто приходится слышать примерно следующее: а давайте введем точки еженедельного (или двухнедельного) контроля и получим общий срез того, как у нас дела. С одной стороны, такой подход
действительно может сработать при условии, что все участники процесса будут абсолютно честны. С другой — если проект большой или затруднены коммуникации, можно спровоцировать ситуацию «на бумаге
одно, в голове другое». Как быть? А очень просто. Вести онлайн-контроль, если позволяет используемая вами информационная система управления проектами, и ежедневно мониторить показатели на предмет
планов и рисков.
Сделаю еще один реверанс «менеджеру из отрасли» — такому специалисту будет проще выявлять риски на ранней стадии. Пример: если работа «Проектирование структуры БД» выполнена на 40%, а через неделю
запуск кодирования логики, при общей длительности проектирования БД в 10 дней и плане в 40% по окончании трех дней с момента старта работы, то, возможно, это зона потенциального риска и требуется
квалифицированное рассмотрение причин отклонений.
Про ресурсы и риски
После того как расписаны и декомпозированы работы, для них проводится распределение ресурсов. Хотя справедливости ради надо сказать, что зачастую в командах декомпозиция происходит сразу в привязке
к ресурсам. Это может быть оправдано или сильно помешать, поскольку за людьми потеряется та или иная работа. Поэтому я стараюсь планировать исходя из работ, и только потом назначать людей.
При ресурсном планировании «в персоналиях» РП надо быть готовым к ситуации, когда «ресурс» заболеет, уйдет в отпуск, в декрет, попадет в больницу… Зачастую можно услышать, что «всё встанет».
Иногда (в случае ключевых разработчиков) так и есть. Для нейтрализации подобного риска имеет смысл еще на этапе планирования обсудить с руководителями команд ситуацию экстренной замены сотрудников.
Это очень помогает. Сколько раз сталкивался с тем, что мне говорят «да нет, он никогда не заболеет» — и внезапный отпуск по семейным обстоятельствам. С точки зрения человека нормально, когда
работодатель уважает своего специалист. С точки зрения проекта пресловутый «план Б» по людям должен быть всегда. Да и по критическим работам было бы очень неплохо иметь представление на случай «а
что, если…» — очень помогает вести реестр рисков, критериев их наступления и планов реагирования. В крайнем случае, при таком подходе будет легче оправдаться за перенос сроков. А в идеальном —
защитить работы по проекту от человеческого фактора.
Возвращаясь к началу, или Вместо заключения
Немного философии, про «план ради плана» или «план без цели». Я встречал такие планы, сделанные с позиции «чтобы было», соответствующего качества. Их основная особенность в том, что они, как
правило, оторваны от реальности, а совпадения с жизнью по большей части или случайны, или представляют собой результат подвига. Увы, как от осины сложно ожидать появления на ней апельсинов, так и
от формального плана — четкого его исполнения (а точнее, хоть какого-то исполнения). Причина в том, что обычно он делается сверху, приурочен к некой дате, не учитывает в первую очередь ресурсных
ограничений, бюджет тоже «немного примерный». В итоге план сам по себе, жизнь сама по себе.
И последнее, о чем нужно сказать в разрезе планирования — о плане в случае гибких методологий. Я работал в крупной организации, где, условно говоря, скрещивали SCRUM и «водопад», и это всё
работало, причем достаточно эффективно. Суть была в том, чтобы расставить КТ-0 и КТ-1, а после спринтами двигаться к ним. Сложность заключалась в том, что при таком планировании, во-первых,
требуется понять скорость работы каждой команды, а во-вторых, назначить КТ-0 для заказчика так, чтобы «если что» не «вывалиться» за его границы. К слову, работая по двухнедельным спринтам и проводя
ревю возможных улучшений, команды смогли выполнить свои обязательства по срокам, хотя и возникали трудности по взаимной координации (результат работы одной команды использовался еще двумя, а еще
одной — тремя остальными). Но это была как раз задача РП — обеспечить синхронность движения к цели нескольких команд. И могу сказать, что в данном случае классическое планирование не работает:
фактический объем приходилось пересобирать каждый спринт.
Об авторе
Александр Башкиров
ИТ эксперт. Высшее техническое образование. Публикуется в ИТ-прессе с 2001 года, с IT Manager сотрудничает с 2009 года. Основные интересующие темы: отношения ИТ и бизнеса, облака, технологии ИТ для бизнеса, управление, проекты, консалтинг, СПО.
