Многие начинающие PM думают, что основная работа начинается после того, как клиент подписал договор и команда приступила к задачам. На практике всё наоборот. Большая часть проблем появляется именно из-за ошибок на этапе запуска.

Если проект плохо подготовлен на старте, дальше начинаются:

• бесконечные уточнения;
• переносы сроков;
• конфликты;
• дополнительные работы;
• перерасход бюджета;
• недовольство клиента;
• выгорание команды.

Поэтому сильный PM начинает управлять проектом ещё до начала производства работ.

Запуск проекта — это процесс подготовки всех условий для начала работы.

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

• что мы делаем;
• зачем мы это делаем;
• кто это делает;
• когда это должно быть сделано;
• сколько это стоит.

Если хотя бы один из этих вопросов остаётся без ответа — проект находится в зоне риска.

Очень часто происходит так:

Клиент пишет:
— Нам нужен сайт.
PM отвечает:
— Отлично, начинаем.

Через неделю оказывается:

• структура сайта не согласована;
• контент не готов;
• сроки не определены;
• клиент ожидал совсем другой результат.

Именно так начинаются большинство проблемных проектов.

Перед началом работ необходимо проверить пять вещей.

Понятна задача

Это звучит очевидно. Но именно здесь совершается огромное количество ошибок.

PM должен понимать:

• конечный результат;
• цели проекта;
• ограничения;
• ожидания клиента.

Нужно выяснить:

• для кого лендинг;
• какая цель;
• какой продукт;
• какая аудитория;
• какие материалы уже есть;
• какие сроки.

Только после этого появляется реальная задача.

Есть необходимые документы

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

Перед стартом желательно иметь:

• договор;
• приложение к договору;
• техническое задание;
• смету;
• коммерческое предложение;
• NDA (если требуется).

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

Есть материалы от клиента

Очень часто проекты тормозятся не из-за команды, а из-за отсутствия материалов.

Например:
Для сайта нужны:

• тексты;
• фотографии;
• логотип;
• брендбук;
• доступы;
• структура разделов.

Если этого нет — сроки уже под угрозой. Ошибка новичка — начать проект, надеясь получить материалы позже. Через две недели выясняется, что клиент ещё ничего не подготовил, а команда простаивает и сроки срываются.

Есть согласованный бюджет

PM должен понимать:

• сколько стоит проект;
• сколько стоит каждый этап;
• какая маржа;
• какие дополнительные работы оплачиваются отдельно.

Если экономика проекта непонятна, контролировать его невозможно.

Есть согласованные сроки

Kick-off — стартовая встреча проекта. Её задача — синхронизировать всех участников. Очень часто одна такая встреча экономит десятки часов работы в будущем.

Кто должен присутствовать

Минимальный состав:

• PM;
• ключевые специалисты;
• клиент (если необходимо);
• руководитель проекта со стороны клиента.

Что обсуждается на kick-off

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

Объём работ. Обязательно фиксируем:
Что входит в проект.
Что не входит в проект.

Сроки. Разбираем:

• общий срок;
• промежуточные этапы;
• контрольные точки.

Риски. Очень полезно уже на старте задать вопрос: что может помешать проекту?

Например:

• материалы от клиента;
• длительные согласования;
• интеграции;
• подрядчики;
• отпуск специалистов.

Одна из ошибок новичков — думать, что команда автоматически знает, что делать — не знает. Каждому участнику нужно дать контекст.

Каждый специалист должен знать:

• цель проекта;
• клиента;
• ограничения;
• сроки;
• свою зону ответственности.

Например, разработчику недостаточно сказать: « Нужно сделать форму заявки».

Он должен понимать:

• зачем она нужна;
• какие данные собирает;
• что происходит после отправки;
• есть ли интеграция с CRM.

После запуска PM начинает декомпозировать проект, то есть разбивать большую задачу на мелкие. Чем лучше декомпозиция — тем легче управлять проектом.

После появления плана работ формируется календарный график. Очень важное правило: команда оценивает сроки, а PM управляет сроками. Это не одно и то же, оценку всегда даёт исполнитель.

Ошибка новичка — самостоятельно придумывать сроки.

Команда оценивает идеальный сценарий, а PM должен учитывать реальность. В реальности появляются:

• правки;
• согласования;
• болезни;
• форс-мажоры;
• новые вводные.

Поэтому между внутренними и внешними сроками почти всегда есть разница.

Буферы времени

Буфер — запас времени на риски. Новички боятся добавлять буферы, а потом удивляются срывам сроков.

Например, разработка занимает 10 рабочих дней, а PM показывает клиенту 14 рабочих дней.

Эти дополнительные дни позволяют управлять рисками.

После планирования проект переходит в систему управления задачами, например:

• Jira;
• Яндекс Трекер;
• Asana;
• Битрикс24;
• Trello.

Хорошая задача содержит:

• Что нужно сделать — описание результата.
• Контекст — зачем это нужно.
• Материалы — ссылки, документы, макеты.
• Ответственного — кто выполняет работу.
• Срок — когда задача должна быть завершена.
• Критерии готовности — как понять, что работа выполнена.

Перед запуском проекта сильный PM проходит чек-лист.

Запуск проекта — это фундамент всей дальнейшей работы. Сильный PM понимает, что проект начинается не тогда, когда дизайнер открыл Figma или разработчик написал первую строчку кода.

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