Vitaly Salakhmir
385
Блоги

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

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

Поделиться

В избранное

В избранном

Планирование

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

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

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

Планирование задач

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

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

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

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

Планирование проектных задач

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

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

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

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

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

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

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

Планирование расписания проекта

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

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

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

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

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

Иерархическая структура работ.

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

График PERT.

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

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

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

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

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

Диаграмма Гантта.

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

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

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

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

Планирование команды проекта

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

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

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

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

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

Резюме

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

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

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

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

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

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

{ "author_name": "Vitaly Salakhmir", "author_type": "self", "tags": [], "comments": 7, "likes": 8, "favorites": 21, "is_advertisement": false, "section_name": "blog", "id": "39931", "is_wide": "" }
{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]