Управление проектами: планирование

Менеджер управляет проектами – а этого никак нельзя сделать, если нет никакого понимания, когда что должно произойти по ходу выполнения проекта. Для того, чтобы понимание было, мы занимаемся планированием – тема сегодняшней статьи.

Представь себе, что тебе нужно построить тот же дом. Представь, что каким-то образом ты пропустил этап “планирование” и сразу начал строить. И вот ты берешь кирпичи, кладешь их друг на друга, потом понимаешь, что не рассчитал по финансам, и эту стройку закончить не можешь. Берешь кредит, продолжаешь строительство. Докладываешь кирпичные стены, кладешь сверху шифер и вдруг оказывается, что без фундамента эта тема долго не простоит (вообще не простоит, на самом деле). Ты ломаешь все, делаешь фундамент, кладешь кирпичи, крышу, а тут вдруг (внезапно!) оказывается, что до ближайших коммуникаций тридцать километров по прямой, и строить здесь дом бессмысленно вовсе. Ну или хотел ты шестикомнатный таунхаус, а получил одноэтажный барак. Можно, конечно, рассказать коллегам, что у тебя там был эджайл и все по плану, но не было там никакого плана. Планирование – та фича, которая должна помочь избежать подобных неожиданностей. Чем четче план – тем меньше шансов, что что-то пойдет не так. Идеально не будет никогда, но с планом жить станет проще.

Планирование – один из основных процессов в управлении проектами. По важности он чуть ли не важнее реализации проекта. Стоит этот процесс сразу за “инициализацией”, когда кто-то кому-то сказал: “проекту быть!”. На деле, та же инициализация тоже планируется, но в меньших масштабах. При планировании проекта мы должны понять, что от нас требуется, когда, что у нас к этому есть, как это влияет на что-то еще и когда мы это сможем вытащить. Планирование – наше все. К планированию относится и управление рисками, о нем я тоже однажды расскажу подробнее – в самом “управлении рисками” есть свой пунктик “планирование”.

Тема применима не только к управлению проектами – она применима даже к собственной жизни. Вот то, как ты расписываешь бюджет на месяц – планирование. То, как ты в гугл-календаре расставляешь даты отпусков – планирование. Когда ты выезжаешь на работу из Подольска к Садовому – тоже планирование (когда выехать, как проехать, на чем ехать). Есть такие люди, которые вот вообще ничего не планируют и летят туда, куда их пнут. Я про них рассказывать не буду, и вы меня не просите.

Есть мнение, что неправильному планированию обязаны 80-90% провалов проектов (по срокам или содержанию, как минимум). Чтобы такого у вас (и у меня) не случалось, в этом блоке поговорим про макро-планирование, когда предмет планирования – целый проект. Я обещал углубиться в предмет с позиции практической – здесь будет с позиции практической. Все через призму менеджера проектов креативного агентства.

При планировании проектов у нас есть несколько основных групп планирования:

• Планирование проектных задач
• Планирование расписания проекта
• Планирование команды проекта
• Управление рисками

Ниже разберем каждый пункт отдельно. Помимо управления рисками – об этом напишу отдельно – сейчас это будут вкрапления в первые три пункта.

Главный документ в жизни проекта креативного агентства – техническое задание. В техническом задании мы расписываем общий набор того, что ожидаем на выходе. Еще технические задания подписывают и показывают потом заказчику в случае чего – мол, смотри, твоих требований в нем не имеется, потому изволь. Технические задания, кстати, пишутся до согласования стоимости проекта – стоимость потом напрямую зависит от содержания техзадания.

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

Я пишу технические задания только на функциональные вещи. Раздел такой-то, содержание такое-то, внутри происходит это-то. Увы, NDA, и ничего показать не могу, а писать отдельно под статью – не запланировано. Техническое задание должно быть структурировано, написано простым языком, избегать двусмысленностей – как мануал здесь можно брать статью о деловой переписке, правила те же.

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

Удобно писать технические задания в Google Docs, расставляя важные вещи заголовками – все чисто и аккуратно. Можно делиться ссылкой с заинтересованными лицами – они сразу напишут комментариев. Чем четче в техническом задании прописано, как что должно работать – тем меньше проблем возникнет при передаче проектных задач исполнителям. Менеджер налаживает процессы, а случаи, когда исполнитель уточняет у него каждый шаг, мало похоже на процесс. Автор знает о чем говорит, потому что автор, как человек самоуверенный, периодически может пропускать куски в техническом задании – может от ограничений во времени, а может потому что ленив.

Иногда вместо технического задания используется карта проекта – иерархическая структура. Под тип паука, в центре которого – название проекта, а из него исходят остальные задачи, соблюдая вложенность. Такое “техническое задание” сильно ускоряет оценку проекта, но снижает точность оценки – и времени, и содержания.

После того, как у нас есть техническое задание и понимание содержания проекта, задачи передаются в работу. Разумеется, после подписания задания клиентом.

Здесь у нас планирование работ для передачи исполнителем + планирование сроков исполнения задач. Кто-то верно заметил, что управление проектами – разделение большого пласта на поменьше и попытка всунуть их в какие-то сроки. Примерно так все и есть: на куски мы пилим проект, чтобы было проще контролировать выполнение и расставлять их на таймлайне.

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

Методов пилки задач несколько:

• Сделать каждый пункт и подпункт технического задания отдельной задачей, по иерархии.
• Использовать сложные темы, типа PERT, и по итогу раздавать задачи исполнителям.

В несложных проектах наш друг – расстановка задач по иерархии. В диджитале сложные проекты случаются редко, потому запоминай. Графически такие планирование выливается в в иерархическую структуру работ – ИСР (или WBS). Иерархическая структура работ – один в один “карта проекта” (она же – ментальная карта или “майндмап”), только направлена в одну сторону. Можно иметь ее параллельно техническому заданию, хуже не станет.

PERT (его еще называют “сетевой график”) примерно в тысячу раз сложнее иерархического планирования, он нужен для сложных проектов – в них PERT поможет не допускать рисков, когда что-то сделано не вовремя. Этот метод планирования определяет последовательность решения задач – что следует до, что после. PERT также используется при оценки времени выполнения задач – интересной фишкой в нем является выставление трех сроков каждой задаче – оптимистическое время выполнения, пессимистическое время решение и наиболее вероятное. На основании этих трех оценок вычисляется наиболее вероятное время. Там ниже говорим про планирование времени, поймете почему это интересно и важно.

Критический путь (и метод критического пути) фича именно PERT. Я не использую сетевые графики в работе, но вот критический путь прям в душу запал. Суть его в том, что он определяет самую долгую последовательность задач – тех, которые нельзя подвинуть или избежать. Критический путь определяет минимальное время завершения проекта.

Итого, проект, в котором достаточно иерархической структуры при планировании задач, может выглядеть так:

• нарисовать главную страницу сайта
• нарисовать контентную страницу
• нарисовать продуктовую страницу
• сверстать главную страницу сайта
• сверстать контентную страницу
• сверстать продуктовую

Удобно при “водопаде”, о котором рассказывал в предыдущей статье. Плюс, такой проект гораздо проще в планировании времени – все понятно при взгляде сверху. Сетевой график используется, когда задач тысяча, и половина из них между собой связана – когда задача, которая должна быть выполнена после этапа Х зависит от задачи Y, не связанной с задачами A, B и C, которые в графике первые. PERT – такой эджайл при планировании, только что результат проекта точно определен, иначе не надо было бы вам этих графиков.

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

Это тоже расписание проекта – у него может быть меньшая, по сравнению с сетевым графиком, детализация, но даже такая форма отображения таймлайна проекта лучше, чем никакая. Диаграмма Гантта собирается в экселе, на коленке за 5 минут.

Как-то не получилось у меня отдельно рассказать про планирование сроков проекта, расскажу вкратце и внутри блока “планирование расписания”. Сроки выполнения проекта вычисляются людьми, которые будут делать задачи внутри проекта – каждый в рамках своей зоны ответственности. Обычно это выглядит как указать пальцем в небо, и практика показывает, что палец подходит любой – даже вот твой. Планирование сроков выполнения проекта – всегда предсказание: можно угадать, а можно не угадать. Что с этим делать, я не знаю – обещал рассказать про риски, вот оно.

На планирование работы команды ( = выполнения проекта), работающей для внешнего заказчика влияют не только задачи внутри проекта – влияют задачи из параллельных проектов (ибо такого, чтобы кто-то сидел и ждал именно своего проекта, просто не бывает). Если используется PERT – сроки будут плюс-минус релевантными, ибо берется три пальца в небо и после небольшого вычисления выявляется наиболее вероятный палец. На тех проектах, где полезен PERT, вряд ли бывают конфликты между проектами, а те пальцы куда опытнее, чем мой. Быть может этот блок дополнит следующая статья, про микроменеджмент – там будет немного про управление временем.

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

Планирование команды проекта должно начинаться примерно на этапе инициализации. Чаще всего на этапе планирования задач уже есть кто-то, кто после будет работать с проектом. Например, люди, готовые поделиться экспертным мнением, чтобы ты, менеджер, потом не зафакапил чего-нибудь.

Где-то на Западе менеджер может скрупулезно выбирать членов команды под проект. Выяснять, насколько тот или иной человек подходит под проект, какие у него взаимоотношения с другими членами команды и почему у исполнителя может возникнуть нежелание работать. Для проектов он их как бы нанимает – изнутри компании, или из вне (рекрутинг или фрилансеры). Когда ты станешь менеджером, ты их тоже будешь нанимать. Только что выбора тебе особого не дадут – вот, есть человек, подключай. Это тебе скажет руководитель направления (или тимлид), в котором работает твой коллега.

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

Планирование команды проекта (и отдельных ее членов) нужно делать заранее – никогда в нормальной жизни ты не встретишь ситуации, чтобы кто-то тебе понадобился, и вот сразу он, сидит, ждет когда ты его забрифуешь. Запрашивать ресурсы исполнителей нужно хотя бы за пару недель до – чтобы исполнитель тоже смог спланировать свою работу. Закончить ее например, или передать.

В этот блок отлично подошел бы текст про передачу задач исполнителям, но в Алматы уже вечер, а мне завтра на работу пилить, чтобы собрать для вас контент “с полей”. Добавил себе в задачи тему, поговорим о ней, когда коснемся работы с людьми в проекте.

Итого, мануал.

• Пишем техническое задание
• Планируем сроки и задачи – когда что будет и что за чем следует
• Собираем команду
• ???
• PROFIT!

Риски на каждом этапе.

• Написать некорректное или неполное техническое задание
• Неправильно запланировать последовательность или содержание задач
• С исполнителями – какие угодно риски. От конфликта между проектами, до человеческого фактора

Это статья про планирование небольших проектов. Она для совсем начинающих менеджеров проектов и сочувствующих. В следующей серии планирую (sic!) рассказать про планирование личного времени и задач – про микроменеджмент. Перед следующей статьей предлагаю прочитать (или перечитать) статью про управление задачами в таск-менеджере.

Читателям: комментарии это здорово. В комментариях можно выражать свои пожелания, критиковать и поправлять – если достаточно экспертизы или есть свое мнение (тм). Минусовать и плюсовать тоже можно, если что не так – но от оценок никакого толка – лучше в комментариях написать, почему так, а не эдак. Приветствуются и комментарии от тех, кто работает с менеджерами со стороны, как исполнитель или заказчик – вы расскажете, как оно там выглядит, а мы с проджектами эту тему перетрем и сделаем вашу жизнь комфортнее.