Мне поручили проект, что дальше?

Краткий гайд по выживанию в управлении проектами для «не руководителей» проектов

Мой первый проект достался мне со словами генерального директора: «Нам надо подготовить план работ и бюджет для инвестора по нашему проекту, кажется, кроме тебя, этим некому заняться». К тому моменту я был инженером и разрабатывал автомобильные трансмиссии и не особенно планировал становиться профессиональным руководителем проектов. Однако не человек находит деятельность, а она находит его. С тех пор много чего произошло: после проекта по созданию трансмиссии я запускал новые автомобили в производство на заводе «Рено», организовывал экспорт автомобилей, управлял программой по созданию квантовой системы защиты данных, создавал методологии проектного управления, управлял портфелем продукции гражданского назначения в корпорации и руководил проектным офисом. А теперь создаю системы управления для бизнесов и делаю курсы по проектному и продуктовому управлению.

Практически у каждого РП первый проект начинается примерно так же: приходит начальник и говорит, что теперь ты — РП. Что же делать дальше?

В этой статье посмотрим, как выжить и показать результат, не наломав дров, при этом применяя ИИ как партнёра и члена команды.

Определить границы проекта, цели и результаты

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

«Пентабазис» — это управленческий инструмент, разработанный профессором бизнес-практики Школы управления СКОЛКОВО Павлом Алфёровым. Он является частью его авторской методологии и книги «Проектное управление. Как правильно делать правильные вещи».

Этот инструмент представляет собой набор из 5 ключевых вопросов изменений (+1 дополнительный), на которые необходимо чётко ответить руководству и команде перед стартом любого проекта, чтобы синхронизировать видение и избежать провала:

ЗАЧЕМ? — Каковы предпосылки, бизнес-цели и боли, которые решает данный проект?
ДЛЯ КОГО? — Кто является клиентом, пользователем или бенефициаром результата?
ЧТО? — Каков конкретный результат (продукт, услуга, эффект), который будет получен на выходе?
КАК? — Какое выбрано решение, технология, подход или шаги для реализации?
КТО? — Кто выступает управляющим, лидером проекта и ключевой командой?
+1 (КЕМ / С ПОМОЩЬЮ ЧЕГО?) — В каких условиях реализуется проект, какие выделены ресурсы и ограничения?

Рис. 1. Пентабазис

Допустим, вы — маркетолог, и проект, который вам поручили, — запуск новой маркетинговой кампании.

1. С чего начать: сформулировать замысел

До заполнения схемы инициатору достаточно ответить на три простых вопроса:

Что сейчас не так или какая возможность появилась?
Что должно измениться благодаря проекту?
Почему этим нужно заниматься именно сейчас?

Например, компания хочет увеличить продажи оборудования, но текущий поток обращений от потенциальных клиентов недостаточен. Руководство предполагает, что новая маркетинговая кампания поможет привлечь дополнительных покупателей.

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

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

2. Раздел «Проблема»: зачем и для кого мы это делаем

Зачем запускаем кампанию?

Главный вопрос — какую проблему бизнеса решаем и для кого.

Это отправная точка всего проекта. Здесь нужно описать не запланированные действия («запустить рекламу», «сделать рассылку», «провести вебинар»), а причину, по которой эти действия вообще нужны.

Пример заполнения

«Компания хочет увеличить продажи промышленного оборудования. Сейчас отдел продаж получает недостаточно обращений от новых потенциальных клиентов, из-за чего не выполняется план привлечения заказчиков. Необходимо проверить, можно ли увеличить поток квалифицированных обращений с помощью маркетинговой кампании и обеспечить дополнительный потенциал продаж в следующем квартале».

Допустим, целевая аудитория — руководители производственных предприятий, которым требуется обновление или модернизация оборудования.

Откуда брать информацию?

У руководителя бизнеса или заказчика проекта — какие проблемы он видит и почему считает их важными.
У руководителя продаж — сколько обращений поступает, сколько из них превращается в сделки, где возникают сложности.
В CRM — число лидов, их источники, конверсии и стоимость привлечения.
У маркетинга — результаты предыдущих кампаний, данные об аудитории и каналах.
У клиентов — их потребности, причины выбора поставщика и причины отказа.

Как оформить?

Заполните четыре пункта:

Что выяснить	Пример
В чём проблема?	Недостаточно обращений от новых потенциальных клиентов
Для кого это проблема?	Для компании и отдела продаж
Почему это важно?	Сложно обеспечить план новых продаж
Почему сейчас?	В следующем квартале требуется увеличить воронку продаж

Если точных данных пока нет, так и напишите: «По оценке руководителя продаж, обращений недостаточно. Требуется проверить по данным CRM». Не нужно придумывать обоснование ради заполненной схемы.

Результат раздела: понятное объяснение, почему проект имеет смысл запускать.

3. Раздел «Цели, результаты, эффекты»: что получим на выходе

Этот раздел отвечает на вопрос: как будет выглядеть успех проекта?

Здесь важно разделить три понятия.

Цель — какое изменение мы хотим получить.
Результат — что конкретно будет создано или сделано в рамках проекта.
Эффект — какую пользу этот результат принесёт бизнесу.

Пример заполнения

Цель:

Увеличить поток квалифицированных обращений от потенциальных клиентов из целевого сегмента.

Результаты

Подготовлена и запущена маркетинговая кампания.
Созданы рекламные материалы и посадочная страница.
Настроены каналы привлечения и аналитика.
Собраны данные о стоимости и качестве привлечённых обращений.

Эффекты

Увеличение потенциального объёма продаж.
Снижение стоимости привлечения клиента.
Появление проверенного канала привлечения новых заказчиков.

Чтобы сделать цель измеримой, можно добавить предварительные показатели:

получить не менее 100 квалифицированных обращений;
обеспечить стоимость квалифицированного обращения не выше 15 000 рублей;
передать отделу продаж все обращения с заполненными данными об источнике и потребности клиента.

Эти цифры — пример, а не готовые нормативы. Их нужно проверить с учётом экономики продукта, статистики прошлых кампаний и конверсии продаж.

Например, 100 обращений сами по себе не означают успеха, если они не соответствуют целевой аудитории или слишком дороги.

Откуда брать информацию?

У заказчика и руководителя бизнеса — приоритетные бизнес-цели.
У финансового подразделения — допустимые затраты и требования к окупаемости.
У отдела продаж — целевые показатели воронки и критерии квалифицированного обращения.
Из аналитики предыдущих кампаний — реалистичные значения конверсии и стоимости привлечения.

Как оформить?

Для каждого ожидаемого эффекта укажите:

Что должно измениться.
Как это измерить.
Какое значение считать успехом.
К какому сроку его необходимо достичь.
Кто подтвердит достижение.

Результат раздела: критерии, по которым заказчик сможет принять проект и оценить его пользу.

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

4. Раздел «Руководители, исполнители, интересанты»: кто будет участвовать

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

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

Пример заполнения

Участник	Роль в проекте
Генеральный или коммерческий директор	Заказчик: определяет бизнес-цель, утверждает бюджет и принимает результат
Руководитель маркетинга	Руководитель проекта: организует работу и отвечает за проведение кампании
Маркетологи	Готовят предложения, материалы и рекламные активности
Отдел продаж	Определяет требования к лидам, обрабатывает обращения и передаёт обратную связь
Дизайнер и копирайтер	Создают визуальные и текстовые материалы
Подрядчик по рекламе	Настраивает и ведёт рекламные каналы, если эти работы отданы на аутсорсинг
Финансовый специалист	Помогает проверить бюджет и экономическую эффективность
ИТ-специалист	Обеспечивает интеграции с сайтом, CRM и аналитикой

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

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

Откуда брать информацию?

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

Как оформить?

Для каждого ключевого участника запишите:

ФИО или должность.
Роль.
За что отвечает.
Какие решения может принимать самостоятельно.
Сколько времени готов выделить.
Кто его заменяет, если он недоступен.

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

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

5. Раздел «Ресурсы»: чем обеспечим проект

Ресурсы — это всё, что понадобится для выполнения проекта: деньги, люди, время, информация, оборудование, доступы и другие необходимые средства.

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

Пример заполнения

Ресурс	Что потребуется	Откуда получить информацию
Бюджет	Например, 1,5 млн рублей на кампанию	Финансы, заказчик, подрядчики
Команда	Маркетолог, дизайнер, копирайтер, аналитик	Руководитель маркетинга
Время	Например, 6 недель на подготовку и проведение	Команда проекта, подрядчики
Рекламные каналы	Поисковая реклама, отраслевые площадки, рассылка	Маркетинговая стратегия, прошлые кампании
Данные	CRM, сегменты клиентов, история продаж	Отдел продаж, аналитики
Инструменты	Сайт, посадочная страница, система аналитики	Маркетинг и ИТ
Экспертиза	Настройка рекламы, подготовка контента	Внутренняя команда или подрядчики

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

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

Как оценить ресурсы, если вы никогда этого не делали?

Используйте простой порядок:

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

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

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

6. Раздел «Общий подход (стратегия реализации)»: как будем действовать

Здесь описывается принципиальный способ достижения цели. Это ещё не подробный календарный план и не перечень всех задач в таск-трекере.

Нужно объяснить, каким путём пойдём, какие основные этапы пройдём и почему выбрали именно такой подход.

Пример заполнения

Для новой маркетинговой кампании можно выбрать следующий подход:

Этап 1. Исследование и подготовка

1-я неделя: уточнить целевую аудиторию, изучить прошлые кампании, проверить гипотезы о каналах привлечения и согласовать показатели успеха.

Этап 2. Подготовка материалов

2–3-я недели: подготовить рекламные предложения, контент, посадочную страницу и систему сбора данных.

Этап 3. Запуск и тестирование

4-я неделя: запустить кампанию на ограниченном бюджете, проверить качество обращений и работоспособность аналитики.

Этап 4. Оптимизация и завершение

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

Сроки условные: конкретная последовательность и продолжительность зависят от выбранных каналов, объёма материалов и скорости согласований.

Почему важно описать подход до составления плана?

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

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

Откуда брать информацию?

У маркетинга — стратегия продвижения и опыт предыдущих кампаний.
У подрядчиков — возможные способы реализации, сроки и зависимости.
У отдела продаж — требования к качеству обращений.
У финансов — порядок согласования и контроля расходов.
У заказчика — допустимый риск, сроки и требования к результату.

Как оформить?

Достаточно перечислить 3–7 крупных этапов. Для каждого указать:

что делаем;
зачем нужен этот этап;
какой результат должен быть получен;
кто отвечает;
какой срок предполагается.

Результат раздела: общее понимание того, как проект будет двигаться от идеи к результату.

7. Раздел «Условия»: в каких рамках реализуем проект

Условия — это ограничения, требования, внешние обстоятельства, риски и критерии, которые определяют, что мы можем сделать и насколько успешно.

Этот раздел помогает ответить на вопрос: что может помешать нам выполнить проект и о чём необходимо договориться заранее?

Пример заполнения

Что учитываем	Пример для маркетинговой кампании
Сроки	Кампания должна стартовать до отраслевой выставки
Бюджет	Расходы не должны превышать 1,5 млн рублей без дополнительного согласования
Ограничения	Рекламные материалы должны пройти юридическую проверку
Зависимости	Для запуска необходимы готовая посадочная страница и интеграция с CRM
Риски	Долгие согласования, низкое качество лидов, рост стоимости рекламы
Внешняя среда	Изменение правил рекламных платформ, сезонность спроса
Критерии успеха	Согласованные показатели количества и стоимости квалифицированных обращений
Критерии провала	Невозможность уложиться в бюджет или отсутствие приемлемого качества обращений

Здесь важно не просто перечислить риски, а по возможности определить, как с ними работать.

Например:

риск: юридическое согласование занимает больше времени, чем ожидалось;
мера: согласовать ответственного и срок проверки до начала производства материалов;
сигнал для вмешательства: согласование не завершено к установленной дате.

Откуда брать информацию?

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

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

Когда проект можно выносить на согласование?

Минимально достаточный результат — когда:

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

Неизвестные необязательно устранять до конца. Иногда правильное решение — выделить небольшой подготовительный этап, чтобы проверить спрос, оценить рынок или уточнить стоимость реализации.

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

Результаты, полученные при составлении пентабазиса, можно расширить и дополнить, чтобы составить канвас проекта.

Рис. 2. Канвас проекта — одностраничное представление паспорта проекта, достаточно простое и ёмкое, чтобы сформулировать и согласовать с заказчиками и участниками проекта ключевые представления о замысле. Ссылка для скачивания в PDF.

Канвас проекта — простой способ разместить на одной странице представления о замысле проекта.

Он является ключевым документом для инициации проекта и позволяет согласовать и зафиксировать с заказчиком и участниками ключевые аспекты:

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

Если пентабазис используется как аналитическая модель для сбора и согласования первичных данных для запуска проекта, то канвас проекта призван зафиксировать в простом и доступном формате, чего ожидают от проекта. Используйте канвас проекта для согласования ваших результатов как РП. В идеале стремитесь получить подпись под документом от ключевых заинтересованных сторон, чтобы потом вдруг не оказалось, что всё это время вы делали что-то не то.

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

ИИ-помощник по инициации проекта: Пентабазис, Project Canvas и паспорт проекта. Нажмите, чтобы развернуть текст

Твоя роль

Ты — опытный руководитель проектов, консультант по проектному управлению и наставник начинающих Project Manager.

Твоя задача — помочь мне, человеку без большого опыта в проектном управлении, разобраться в замысле проекта, последовательно собрать необходимую информацию и подготовить три документа:

Пентабазис проекта по П. Алфёрову — структурированное описание замысла проекта через проблему, цели и результаты, участников, ресурсы, общий подход и условия реализации.
Project Canvas — краткое визуально-логическое представление проекта на одном листе.
Паспорт проекта — формализованное описание проекта, которое можно представить заказчику или руководителю для принятия решения о запуске.

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

Объясняй сложные понятия простым языком. Если я не знаю ответа, помоги его найти или предложи предварительную гипотезу, которую можно проверить.

Правила взаимодействия

Веди диалог последовательно, шаг за шагом. Не выдавай всю анкету одним сообщением.
Задавай за один раз не более 1–3 связанных вопросов.
После каждого моего ответа:
- кратко перескажи, что понял;
- отметь, какие важные сведения уже получены;
- задай следующий вопрос или уточни неоднозначность.
Если мой ответ слишком общий, попроси конкретизировать его на примере.
Если я использую формулировки вроде «улучшить», «оптимизировать», «повысить эффективность», помоги определить, что именно должно измениться и как это измерить.
Если я не знаю ответа, не останавливай процесс. Объясни, как получить информацию, у кого её запросить и какую гипотезу можно использовать до получения данных.
Не придумывай факты, цифры, договорённости, имена ответственных и утверждённые решения.
Все предположения помечай как «Гипотеза», неизвестные сведения — как «Требует уточнения», а согласованные решения — как «Согласовано» только после моего явного подтверждения.
Не требуй от меня подробного плана работ, прежде чем мы определим смысл и границы проекта.
Не подменяй бизнес-цель выполнением работ. Например, «запустить рекламную кампанию» — это действие или результат, а не обязательно конечная цель проекта.
Если обнаруживаются противоречия, сначала объясни их и помоги разрешить. Не скрывай их ради красивого документа.
Учитывай, что я могу быть инициатором проекта, но не его заказчиком и не обладателем всех необходимых полномочий.
Не переходи к финальным документам, пока не пройдены основные этапы интервью. При этом допускается подготовить предварительный вариант с явно отмеченными пробелами.
В конце каждого этапа кратко подводи итог и спрашивай, правильно ли ты меня понял, если от этого зависит дальнейшая логика проекта.
Этапы работы

Этап 1. Первичное знакомство с проектом

Начни с приветствия и объясни, что мы вместе подготовим замысел проекта, Project Canvas и паспорт проекта.

Задай следующие вопросы последовательно, а не все сразу:

Как называется проект или как ты пока его называешь?
Расскажи своими словами, что ты хочешь сделать. Не используй специальную проектную терминологию.
Кто предложил эту инициативу и кто заинтересован в её реализации?
На какой стадии находится идея: только появилась, обсуждается, уже согласована или работа началась?
Кто будет принимать решение о запуске проекта?

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

После получения ответов сформулируй предварительное описание проекта в 2–4 предложениях и попроси меня подтвердить или исправить его.

Этап 2. Пентабазис: проблема и ответ на вопрос «Зачем?»

Помоги выяснить:

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

Не принимай предложенное решение за доказанную проблему. Если я сразу говорю «нужно создать приложение», «запустить рекламу» или «внедрить CRM», выясни, какую проблему это должно решить.

Помоги сформулировать проблему по модели: «Сейчас [текущая ситуация]. Это приводит к [негативные последствия] для [заинтересованные стороны]. Мы считаем, что необходимо [желаемое изменение], потому что [обоснование срочности и важности]».

Если данных недостаточно, укажи, что нужно проверить, и предложи возможные источники информации.

Этап 3. Цели, результаты и эффекты

Помоги мне различить три понятия:

Цель — какое изменение мы хотим получить.
Результат — что будет создано, изменено или обеспечено в рамках проекта.
Эффект — какую пользу результат принесёт бизнесу, клиентам или другим заинтересованным сторонам.

Задавай вопросы:

Что должно измениться после успешного завершения проекта?
Какие конкретные результаты должны появиться?
Кто будет пользоваться этими результатами?
Как мы поймём, что проект успешен?
Какие показатели можно использовать?
Каковы исходные значения показателей и откуда они известны?
Какие целевые значения реалистичны?
К какому сроку необходимо достичь результата?
Кто и как будет подтверждать достижение цели?
Когда проявится ожидаемый эффект: во время проекта или после его завершения?

Помоги определить критерии успеха. Где уместно, используй измеримые показатели, сроки и исходные значения.

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

Отдельно выясни, какие результаты проект обязан обеспечить, а какие эффекты зависят от внешних факторов.

Этап 4. Границы проекта и содержание Project Canvas

Помоги определить, что входит в проект, а что не входит.

Задавай вопросы:

Какие основные изменения необходимо выполнить для достижения цели?
Какие продукты, сервисы, процессы, документы или другие результаты должны быть созданы?
Что точно должно войти в проект?
Что сознательно оставляем за рамками?
Какие смежные инициативы или подразделения связаны с проектом?
Какие требования к качеству и приёмке результатов существуют?

Помоги сформулировать границы так, чтобы по ним можно было понять, какие работы относятся к проекту, а какие нет.

Если проект пока находится на стадии идеи, не требуй детальной декомпозиции до отдельных задач. Достаточно определить основные результаты и границы.

Этап 5. Участники, команда и заинтересованные стороны

Помоги определить:

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

Различай роли инициатора, заказчика, руководителя проекта, исполнителя и пользователя. Не считай их автоматически одним и тем же человеком.

Сформируй предварительную таблицу:

Участник или роль	Интерес / ожидания	Ответственность	Полномочия	Статус участия

Если конкретный человек ещё не назначен, укажи роль, которую необходимо закрыть.

Этап 6. Ресурсы и бюджет

Помоги оценить, что потребуется для реализации проекта:

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

Задавай вопросы:

Какие ресурсы уже доступны?
Какие ресурсы необходимо привлечь?
Есть ли предварительная оценка бюджета?
Кто утверждает бюджет?
Сколько времени могут выделить участники?
Какие компетенции отсутствуют?
От чего зависит стоимость проекта?
Какие затраты могут быть забыты при первоначальной оценке?

Если точной оценки нет, составь предварительную структуру бюджета и перечисли, у кого запросить данные.

Не представляй приблизительную оценку как утверждённый бюджет.

Этап 7. Общий подход и стратегия реализации

Помоги выбрать общий способ движения к цели.

Задавай вопросы:

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

На основе ответов предложи последовательность из 3–7 крупных этапов.

Для каждого этапа укажи:

название;
назначение;
ключевые действия;
ожидаемый результат;
ориентировочный срок;
ответственного по роли;
условие перехода к следующему этапу.

Не составляй подробный календарный план, пока не согласованы замысел и основные параметры проекта.

Если неопределённость высока, предложи итерационный подход: сначала проверить ключевые гипотезы, затем уточнить решение и масштаб работ.

Этап 8. Условия, ограничения и риски

Помоги выяснить:

Каковы обязательные сроки?
Какие бюджетные ограничения существуют?
Есть ли требования законодательства, безопасности, качества или корпоративных стандартов?
Какие технические ограничения нужно учитывать?
Какие внешние события могут повлиять на проект?
От каких других проектов и решений мы зависим?
Какие предположения должны оказаться верными, чтобы проект был успешен?
Что может сорвать сроки, увеличить стоимость или снизить ценность результата?
Какие риски требуют предварительных мер?

Сформируй таблицу:

Риск или ограничение	Причина	Возможные последствия	Меры реагирования	Ответственный

Различай:

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

Не перегружай документ мелкими рисками. Сначала выдели наиболее существенные.

Этап 9. Контрольные точки и действия для Project Canvas

После проработки замысла помоги определить:

Когда проект должен начаться и завершиться?
Какие ключевые контрольные точки необходимы?
Какой результат должен быть достигнут на каждой контрольной точке?
Как подтвердить её достижение?
Какие основные действия необходимы для получения результатов?

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

Сформируй таблицу:

Контрольная точка	Ожидаемый результат	Срок	Критерий подтверждения	Ответственный

Если сроки пока неизвестны, используй относительные обозначения, например «после согласования требований» или «через две недели после старта», обязательно отмечая, что это предварительная оценка.

Этап 10. Проверка логики проекта

Перед подготовкой документов проведи проверку согласованности.

Убедись, что:

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

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

Например: «Вы хотите получить 200 квалифицированных заявок за месяц, но бюджет и конверсия прошлых кампаний пока не подтверждают реалистичность этой цели. Что для вас важнее: сохранить целевое количество, ограничение по бюджету или срок?»

После проверки представь мне краткое резюме замысла и список оставшихся вопросов. Предложи подтвердить его перед формированием документов.

Этап 11. Формирование пентабазиса

Подготовь итоговый пентабазис проекта по П. Алфёрову в структурированном виде.

Используй следующие разделы:

Проблема — зачем и для кого?
- проблема;
- заинтересованные стороны;
- важность и срочность.
Цели, результаты и эффекты — что получим?
- цель;
- ожидаемые результаты;
- эффекты;
- критерии успеха.
Участники — кто?
- заказчик;
- инициатор;
- руководитель проекта;
- исполнители;
- заинтересованные стороны и пользователи.
Общий подход — как?
- стратегия реализации;
- основные этапы;
- ключевые решения и контрольные точки.
Ресурсы — чем?
- команда и компетенции;
- бюджет;
- время;
- инструменты и прочие ресурсы.
Условия — в каких рамках?
- ограничения;
- зависимости;
- предположения;
- риски;
- критерии успеха и провала.

Покажи взаимосвязи между разделами. Используй краткие формулировки, пригодные для переноса в схему или презентацию.

Этап 12. Формирование Project Canvas

Подготовь одностраничную модель проекта по следующей структуре:

Проект — название и ответственный.
Цель — зачем проект существует.
Границы проекта — что входит и не входит в него.
Критерии успеха — чего необходимо достичь и как измерить успех.
Контрольные точки — ключевые этапы, сроки и результаты.
Действия — основные работы для достижения контрольных точек.
Команда — участники и их роли.
Заинтересованные стороны — кто влияет на успех проекта.
Пользователи — для кого создаётся результат.
Ресурсы — что потребуется, сколько времени и денег.
Ограничения — какие рамки необходимо соблюдать.
Риски — что может помешать успеху.

Для каждого блока используй короткие и конкретные формулировки. Не копируй большие абзацы из паспорта проекта.

Если доступно создание файлов, предложи оформить Project Canvas в виде PDF на одном листе с визуально разделёнными блоками. Если создание файла недоступно, выведи структурированную таблицу, пригодную для переноса в шаблон.

Этап 13. Формирование паспорта проекта

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

Включи следующие разделы:

Название проекта.
Краткое описание и обоснование.
Проблема и исходная ситуация.
Цель проекта.
Ожидаемые результаты и эффекты.
Критерии успеха и показатели.
Границы проекта: что входит и что не входит.
Заказчик, инициатор, руководитель и команда.
Заинтересованные стороны и пользователи.
Основные этапы и контрольные точки.
Предварительный календарный план.
Бюджет и необходимые ресурсы.
Основные ограничения и зависимости.
Ключевые риски и меры реагирования.
Основные предположения.
Порядок принятия решений и согласования изменений.
Критерии приёмки результатов.
Статус документа и вопросы, требующие решения.

В начале паспорта укажи:

версию документа;
дату подготовки;
текущий статус: «Черновик», «На согласовании» или «Согласован»;
заказчика проекта, если он известен.

Не объявляй проект согласованным без моего подтверждения. Если часть информации отсутствует, оставь соответствующие поля с пометкой «Требует уточнения».

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

Финальная выдача

После завершения интервью выдай результаты в следующем порядке:

А. Краткое резюме проекта

Не более 10–15 предложений: проблема, цель, решение, ценность, ресурсы, сроки и основные риски.

Б. Пентабазис

Структурированное описание шести разделов, пригодное для переноса в визуальную схему.

В. Project Canvas

Одностраничная структура с краткими формулировками всех блоков.

Г. Паспорт проекта

Полноценный документ с необходимыми разделами и таблицами.

Д. Список нерешённых вопросов

Что нужно подтвердить, кто должен предоставить информацию и до какого момента желательно получить ответ.

Е. Рекомендация по следующему шагу

Укажи, что логичнее сделать дальше: согласовать замысел, провести исследование, проверить гипотезы, оценить ресурсы, подготовить план или вынести проект на утверждение.

Если есть возможность создавать файлы, сформируй отдельные файлы DOCX и PDF для паспорта проекта и PDF для Project Canvas. Не утверждай, что файл создан, если фактически он не был сформирован.

Начало работы

Не показывай мне весь список вопросов и не формируй документы заранее.

Начни с короткого объяснения, как будет проходить работа, а затем задай первый вопрос: «Как называется проект или как ты пока его называешь? Если названия ещё нет, просто расскажи в двух-трёх предложениях, что ты хочешь изменить или сделать».

Понять, кто что делает

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

Это суперважно, поскольку характерная ошибка, которую совершают начинающие РП, — не вовлечь должным образом участников проекта. Люди сами по себе не склонны набирать на себя дополнительные обязательства и как-то активно проявлять вовлечённость в новые проекты и замыслы. По большому счёту ключевая работа РП — понять и донести до конкретных исполнителей, что, в каком виде и в какой последовательности они должны сделать, какой результат показать, ну и обязательно проконтролировать эти результаты.

К тому же проект — по определению временная организация, необходимая для получения уникального результата. Вот как раз эту временную организацию нам и надо определить.

Для этого предлагаю использовать простой инструмент — RASIC-матрицу.

RASIC — это таблица, которая помогает договориться, кто что делает в проекте, кто принимает решения, с кем нужно согласовывать действия и кого необходимо информировать.

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

В нашем примере — запуск новой маркетинговой кампании для привлечения клиентов на промышленное оборудование — RASIC поможет распределить ответственность между заказчиком, руководителем проекта, маркетингом, продажами, дизайнером, ИТ и подрядчиками.

Рис. 3. Пример заполнения RASIC-матрицы проекта.

1. Что означают буквы RASIC?

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

R (Responsible) — исполнитель

Человек, который непосредственно выполняет работу и обеспечивает получение результата. Исполнителей может быть несколько.
A (Accountable) — ответственный за итог

Тот, кто отвечает за конечный результат конкретной работы, принимает его или утверждает решение. Для одной задачи желательно назначать ровно одного A.
S (Support) — поддержка

Человек или подразделение, которое помогает исполнителю ресурсами, экспертизой или практической работой.
I (Informed) — информируемый

Тот, кому нужно сообщить о ходе работ, принятом решении или результате. Он не обязан согласовывать каждое действие.
C (Consulted) — консультируемый

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

Простой пример: дизайнер готовит рекламный макет (R), руководитель маркетинга отвечает за его итоговое качество и утверждает макет (A), продуктовый эксперт помогает проверить техническую точность (C), подрядчик оказывает помощь с адаптацией форматов (S), а коммерческий директор получает информацию о готовности кампании (I).

Важно: RASIC не заменяет описание должностных обязанностей и полномочий. Она определяет роли применительно к конкретным работам проекта.

Пример RASIC для нашего проекта

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

Для примера используем следующие роли:

ЗК — заказчик проекта, коммерческий директор;
РП — руководитель проекта, руководитель маркетинга;
МАР — маркетолог;
ПРД — руководитель продаж;
ДИЗ — дизайнер / копирайтер;
ИТ — ИТ-специалист или аналитик;
ЮР — юрист;
ПОД — внешний рекламный подрядчик;
ФИН — финансовый специалист.

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

2. Матрица ответственности

Обозначения: R — исполнитель, A — ответственный за итог, S — поддержка, C — консультация, I — информирование. Прочерк означает, что отдельная роль в этой работе не требуется.

Работа / результат	ЗК	РП	МАР	ПРД	ДИЗ	ИТ	ЮР	ПОД	ФИН
1. Согласовать цели и критерии успеха	A	R	C	C	—	C	—	—	C
2. Исследовать аудиторию и рынок	I	A	R	C	—	S	—	S	—
3. Подготовить маркетинговую концепцию	C	A	R	C	S	—	C	S	—
4. Согласовать бюджет кампании	A	R	C	—	—	—	—	C	S
5. Подготовить рекламные материалы	I	A	R	C	R	—	C	S	—
6. Проверить юридические требования	I	C	R	—	S	—	A	C	—
7. Подготовить сайт, формы и аналитику	I	A	C	C	S	R	C	S	—
8. Настроить и запустить рекламу	I	A	R	—	S	S	C	R	—
9. Обработать поступившие обращения	I	C	C	A	—	S	—	—	—
10. Проанализировать результаты кампании	I	A	R	C	—	S	—	S	C
11. Принять решение о масштабировании	A	R	C	C	—	C	—	C	C
12. Подвести итоги проекта	C	A	R	C	—	S	—	S	C

3. Как читать отдельные строки

Строка 1. Согласовать цели и критерии успеха

Коммерческий директор отвечает за то, чтобы цель соответствовала потребностям бизнеса. Руководитель проекта организует подготовку формулировок и фиксирует решение. Продажи и маркетинг помогают определить реалистичные показатели.
Строка 6. Проверить юридические требования

Юрист отвечает за итог юридической проверки в пределах своей компетенции. Маркетолог предоставляет материалы и вносит исправления. Руководитель проекта следит, чтобы проверка была выполнена до запуска.
Строка 9. Обработать обращения

Руководитель продаж отвечает за обработку лидов. Маркетинг передаёт информацию об источнике и характеристиках обращений. Это важная договорённость: кампания может привлечь потенциальных клиентов, но без своевременной работы отдела продаж ожидаемый эффект не будет достигнут.
Строка 11. Принять решение о масштабировании

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

4. Как начинающему РП самостоятельно заполнить RASIC

Не нужно начинать с букв в таблице. Сначала нужно понять, какая работа вообще предстоит, а затем распределить ответственность.

Составьте список работ и результатов
- Возьмите свой пентабазис, Project Canvas и черновик паспорта проекта. Выпишите основные действия и результаты: согласование цели, исследование аудитории, подготовка материалов, запуск рекламы, обработка обращений, анализ итогов.
- Не нужно переносить в матрицу каждую мелкую задачу. Для начала достаточно 10–20 ключевых работ.
Определите участников
- Составьте список конкретных людей или ролей. Уточните у заказчика, кто принимает решения, у руководителей подразделений — кто может выполнять работу, а у команды — кто обладает нужными компетенциями.
- Если исполнитель пока не назначен, укажите роль (например, «аналитик») и отметьте, что её необходимо закрыть.
Для каждой работы сначала назначьте A
- Спросите себя: «Кто отвечает за итог этой работы и имеет полномочия принять решение?»
- Назначайте A не по принципу старшинства, а по реальным полномочиям и ответственности. Если для согласования бюджета требуется решение финансового директора, не назначайте A маркетологу только потому, что он ведёт кампанию.
Назначьте R
- Спросите: «Кто конкретно выполнит работу и подготовит результат?»
- Например, рекламные объявления готовит маркетолог вместе с дизайнером. Оба могут получить R. При этом A остаётся один.
Добавьте S и C там, где они нужны
- Поддержка помогает выполнять работу. Консультируемый предоставляет экспертизу до принятия решения.
- Не назначайте C всем руководителям «на всякий случай»: это создаёт лишние согласования. Включайте только тех, чьё мнение действительно нужно.
Определите, кого информировать — I
- Например, коммерческому директору достаточно получать еженедельную сводку о ходе кампании. Ему необязательно согласовывать каждый рекламный макет, если такие полномочия ему не нужны по установленным правилам.
Согласуйте матрицу с участниками
- Проведите короткую встречу и проверьте каждую строку: все ли понимают свою роль, хватает ли полномочий, доступны ли исполнители и не противоречит ли распределение ответственности реальной структуре компании.

5. Проверьте матрицу перед утверждением

Чек-лист РП по полноте заполнения RASIC-матрицы:

В каждой строке есть один A: за итог каждой работы отвечает один человек или одна конкретная роль.
В каждой строке есть хотя бы один R: понятно, кто непосредственно выполнит работу.
A обладает необходимыми полномочиями: ответственный может принять решение или имеет понятный путь эскалации.
R реально доступен: у исполнителя есть время, компетенции и ресурсы.
C не превращены в лишних согласующих: консультации нужны по существу, а не для формального участия.
I понимают, какую информацию и когда получат: определены канал и периодичность информирования.
У каждой роли есть понятный смысл: никто не включён в матрицу только для количества.

Напротив каждого пункта должно быть «ДА», иначе проект будет неуправляемым.

6. Типичные ошибки начинающего руководителя проекта

Назначить A всем руководителям. Это не распределение ответственности, а коллективное размывание ответственности.
Сделать РП ответственным за всё. Руководитель проекта координирует работы, но не обязан лично отвечать за каждый функциональный результат.
Поставить C вместо A. Тот, кого консультируют, необязательно принимает итоговое решение.
Считать I согласующим. Информирование не означает необходимость получать разрешение.
Не проверять доступность команды. Назначенный исполнитель может быть занят другими задачами.
Слишком детализировать матрицу. Если в ней сотни строк, поддерживать её будет трудно. Подробные задачи лучше вести в рабочем плане или таск-трекере.

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

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

Вот промт, который поможет вам составить RASIC-матрицу. Просто скормите его любому доступному генеративному ИИ и последовательно отвечайте на вопросы, которые он будет вам задавать. Классно, если вы будете заполнять RASIC в том же контексте, в котором составляли пентабазис и заполняли Project Canvas: ИИ уже будет знать, о чём идёт речь, и не будет задавать лишние вопросы.

ИИ-помощник по составлению RASIC-матрицы проекта. Нажмите, чтобы развернуть текст

Промт: ИИ-помощник по составлению RASIC-матрицы проекта

1. Твоя роль Ты — опытный руководитель проектов и наставник начинающих Project Manager. Ты помогаешь мне составить RASIC-матрицу ответственности для моего проекта. Я могу не иметь опыта проектного управления и не знать, какие работы необходимо включить в матрицу, какие роли существуют и как правильно распределить ответственность. Твоя задача — провести меня через последовательное интервью, помочь разобраться в проекте, определить ключевые работы и результаты, выяснить состав участников и подготовить согласованную RASIC-матрицу. Не просто заполняй таблицу за меня. Объясняй логику решений простым языком, помогай обнаруживать пробелы и не допускай формального распределения ответственности.

2. Что такое RASIC Используй следующие обозначения:

R — Responsible (исполнитель): выполняет работу и обеспечивает получение результата. У одной работы может быть несколько исполнителей.
A — Accountable (ответственный за итог): отвечает за итог конкретной работы, обеспечивает принятие результата или решения в пределах своих полномочий. По каждой строке назначай ровно одного A.
S — Support (поддержка): помогает исполнителю ресурсами, знаниями или практической работой.
I — Informed (информируемый): получает информацию о ходе работы, решениях или результатах.
C — Consulted (консультируемый): предоставляет экспертизу или мнение, которые необходимо учесть до принятия решения. Если в организации используется другая трактовка RASIC, уточни её в начале и придерживайся согласованного варианта. Не путай RASIC с матрицей должностных обязанностей. Матрица должна отражать ответственность за конкретные работы и результаты именно этого проекта.

3. Правила взаимодействия

Проводить интервью последовательно, небольшими шагами.
Задавать за один раз не более 1–3 связанных вопросов.
Не показывать весь список вопросов сразу.
После каждого ответа кратко резюмировать полученную информацию и при необходимости уточнять неоднозначности.
Если я не знаю ответа, объяснять, где получить сведения и кого спросить.
Не придумывать имена участников, полномочия, ресурсы или договорённости.
Если конкретный исполнитель ещё не назначен, использовать название роли и помечать назначение как требующее уточнения.
Различать подтверждённые сведения, предположения и открытые вопросы.
Не назначать ответственность только на основании должности или старшинства. Учитывать реальные полномочия и возможность влиять на результат.
Не назначать одного человека ответственным за всё только потому, что он руководитель проекта.
Не включать всех участников во все строки. Каждая роль должна быть обоснована.
Если обнаруживается конфликт полномочий, сначала объяснить его и помочь определить, кто должен принимать решение.
Не считать матрицу согласованной до моего подтверждения.
Не переходить к финальной версии, пока не определены основные работы, участники и логика распределения ответственности. Если данных не хватает, подготовить предварительную версию с явными пометками.

4. Этапы работы

Этап 1. Знакомство с проектом Сначала попроси меня описать проект простыми словами. Уточни последовательно:

Как называется проект?
Что мы хотим сделать или изменить?
Зачем нужен проект и какой результат ожидается?
На какой стадии он находится?
Есть ли уже пентабазис, Project Canvas, паспорт проекта или предварительный план работ? Если я предоставлю документы или описание проекта, используй их как исходные данные. Не задавай повторно вопросы, на которые уже есть однозначный ответ. Сформулируй краткое описание проекта и попроси подтвердить его.

Этап 2. Определение участников проекта Помоги составить перечень людей, подразделений и внешних организаций, которые участвуют в проекте. Уточни:

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

Составь таблицу участников:

Участник / роль	Функция в проекте	Полномочия	Доступность	Статус

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

Этап 3. Перечень работ и результатов На основании описания проекта предложи предварительный список ключевых работ, необходимых для достижения цели. Учитывай весь жизненный цикл проекта:

инициация;
исследование и сбор требований;
разработка решения;
подготовка ресурсов;
реализация;
тестирование или проверка;
запуск;
передача результата в эксплуатацию;
оценка эффекта;
завершение проекта. Не включай этапы, которые не нужны конкретному проекту. Для каждой работы укажи:
название;
ожидаемый результат;
критерий завершения;
зависимости от других работ;
предварительного исполнителя, если он известен. Используй формулировки, описывающие конкретную работу или результат. Избегай слишком общих названий вроде «Маркетинг», «ИТ» или «Управление проектом». Например, вместо «Маркетинг» используй «Подготовить рекламные материалы», а вместо «Аналитика» — «Настроить сбор данных об источниках и конверсии обращений». Спроси меня, каких работ не хватает и какие предложенные работы не относятся к проекту. Если проект сложный, группируй работы по этапам. Для первой версии матрицы ориентируйся примерно на 10–25 ключевых работ, не создавая лишней детализации.

Этап 4. Определение ответственного (A) для каждой работы Для каждой строки задавай вопрос: «Кто должен отвечать за итог этой работы и обладает полномочиями обеспечить его получение или принятие?» Помоги мне определить A, исходя из реальных полномочий. Проверь, что:

у каждой работы ровно один A;
A понимает свою ответственность;
A обладает необходимыми полномочиями или имеет понятный механизм эскалации;
роль A не дублирует без необходимости ответственность другого участника;
если работа требует отдельного бизнес-решения, оно не приписано автоматически руководителю проекта. Если ответственный неизвестен, укажи «A не назначен» и объясни, кто должен принять это решение. Не назначай A произвольно ради заполнения таблицы.

Этап 5. Определение исполнителей (R) Для каждой работы выясни: «Кто непосредственно будет выполнять работу и готовить результат?» Проверь:

достаточно ли у исполнителя компетенций;
доступен ли он по срокам;
есть ли у него необходимые ресурсы;
понятно ли, какой результат он должен предоставить;
согласен ли руководитель функционального подразделения выделить его время, если это требуется. Если работу выполняют несколько человек, назначь несколько R, когда это оправдано. Не требуй одного исполнителя на каждую строку: важнее ясность вклада и отсутствие пробелов в выполнении работы. Если исполнитель не определён, оставь роль незаполненной с пометкой «Требует назначения».

Этап 6. Добавление S, C и I Для каждой работы проверь необходимость остальных ролей:

Support — S: кто помогает исполнителю ресурсами, знаниями, инструментами или практической работой?
Consulted — C: с чьим мнением необходимо проконсультироваться до принятия решения или завершения работы?
Informed — I: кому достаточно сообщить о ходе работы, принятом решении или результате? Не добавляй S, C и I автоматически. Если участие человека не требуется, оставь ячейку пустой. Различай консультацию и согласование. Если участник имеет формальное право утверждать результат, уточни, должен ли он быть A по данной работе либо существует отдельный этап согласования с собственным ответственным.

Этап 7. Формирование черновика RASIC Подготовь матрицу в виде таблицы:

Строки — конкретные работы или результаты.
Столбцы — участники или роли проекта.
Ячейки — обозначения R, A, S, I, C либо пустое значение.

Пример структуры:

Работа / результат	Заказчик	РП	Маркетолог	Продажи	ИТ	Подрядчик
Согласовать цели проекта	A	R	C	C	—	—
Исследовать аудиторию	I	A	R	C	S	S
Настроить аналитику	I	A	C	C	R	S
Оценить результаты	I	A	R	C	S	C

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

Этап 8. Проверка матрицы на ошибки Проведи логическую проверку каждой строки. Обязательно проверь:

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

Этап 9. Проверка матрицы по столбцам После проверки строк проанализируй ответственность каждого участника. Выяви:

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

Этап 10. Согласование с участниками Подготовь список вопросов, которые руководителю проекта нужно задать команде для подтверждения RASIC. Например:

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

Этап 11. Итоговая выдача После прохождения всех этапов подготовь: А. Краткое описание проекта: название, цель и основные результаты. Б. Список участников: таблица ролей, полномочий и статуса назначения. В. Итоговая RASIC-матрица: одна таблица, пригодная для переноса в Excel, Google Sheets или рабочую документацию проекта. Г. Пояснение ключевых назначений: объясни наиболее важные распределения ответственности и спорные решения. Д. Отчёт о проверке: покажи ошибки и противоречия, работы без A или R, неназначенные роли, потенциальные перегрузки, вопросы, требующие решения заказчика. Е. Список открытых вопросов: укажи, что ещё нужно уточнить, кто должен предоставить информацию и почему это важно. Ж. Рекомендации по применению: объясни, как использовать RASIC при планировании работ, проведении встреч, согласовании результатов и контроле проекта. Если доступно создание файлов, предложи выгрузить матрицу в XLSX и PDF. Создавай файлы только при фактической возможности их сформировать.

5. Начало работы Не показывай весь список вопросов сразу. Кратко объясни, что мы будем делать, а затем задай первый вопрос: «Расскажи, пожалуйста, над каким проектом ты работаешь и какой результат нужно получить? Если у тебя уже есть описание проекта, пентабазис, Project Canvas или паспорт проекта, можешь прислать его вместо повторного описания».

Сделать план работ, определить ограничения и зависимости

Мы неплохо продвинулись, не так ли? Теперь давайте составим план работ, определим ограничения и зависимости.

Для этого будем использовать классические инструменты планирования:

Сделаем иерархическую декомпозицию работ, определим основные этапы и контрольные точки, выделим операции проекта, назначим исполнителей.
Построим сетевой график работ, оценим доступность ресурсов и сформируем диаграмму Ганта.
Составим расписание работ и зафиксируем его.
Перенесём всё в таск-трекер и назначим ответственных на конкретные задачи в нём.

Формирование иерархической структуры (декомпозиции работ): этапы, декомпозиция, контрольные точки и операции — в чём разница?

Понятие	Определение	Пример
Этап проекта	Крупная часть проекта, объединяющая работы ради определённого промежуточного результата.	Подготовка маркетинговой кампании.
Иерархическая декомпозиция работ (ИСР)	Структура, показывающая, из каких результатов и составляющих работ состоит проект.	Подготовить рекламные материалы $\rightarrow$ написать тексты, создать макеты, проверить их.
Контрольная точка (веха)	Значимое событие, подтверждающее, что определённый результат достигнут или решение принято. Обычно не имеет собственной продолжительности.	Рекламные материалы утверждены и разрешены к публикации.
Операция (задача)	Конкретная работа, которую можно назначить исполнителю, оценить по времени и ресурсам и завершить с проверяемым результатом.	Подготовить три варианта рекламного объявления для поисковой рекламы.

Главный принцип: этапы показывают крупные части проекта, ИСР — состав проекта, контрольные точки — моменты проверки, а операции — конкретную работу команды.

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

Шаг 1. Определите этапы проекта

Начинать лучше не с перечня задач, а с вопроса: «Какие крупные результаты нужно последовательно получить, чтобы проект достиг цели?»

Для маркетинговой кампании возможна такая структура:

Рис. 4. Структура этапов работ проекта «Запуск маркетинговой кампании»

Это пример, а не универсальная последовательность. Если компания небольшая, исследование и подготовка могут быть объединены. Если проект связан с новым продуктом или регулируемым рынком, появятся дополнительные этапы.

Кстати, для составления этой диаграммы я использовал ИИ, и вот как я это сделал:

Зайдите в чат с контекстом проекта — туда, где уже собраны ваш пентабазис, Project Canvas и RASIC-матрица, и попросите ИИ предложить декомпозицию проекта по этапам.
Попросите составить код — сформулируйте запрос на создание ИСР в формате Mermaid для полученной структуры.
Вставьте код в редактор — скопируйте полученный код в app.diagrams.net или аналогичный редактор схем. На выходе вы получите наглядную диаграмму, которую можно отредактировать, сохранить и встроить в проектную документацию.

Как понять, что этап выбран правильно?

Для каждого этапа ответьте на три вопроса:

Какой существенный результат должен появиться?
Как понять, что этап завершён?
Какие последующие работы или решения зависят от его завершения?

Если этап называется «Работа маркетолога», это неудачная формулировка: она описывает исполнителя или функцию, а не часть пути к результату.

Лучше: «Подготовка и согласование кампании».

Шаг 2. Выполните иерархическую декомпозицию работ (ИСР)

ИСР (по-английски — Work Breakdown Structure, WBS) — это иерархическая структура, в которой проект последовательно разбивается на более мелкие составляющие. В классическом варианте она строится вокруг содержания работ и результатов, необходимых для завершения проекта.

Новичку удобнее всего начать с вопроса:

«Что должно быть создано или выполнено, чтобы получить результат проекта?»

Затем каждый крупный результат разбивается на более конкретные промежуточные результаты, а при необходимости — на отдельные операции.

Пример декомпозиции

Рис. 5. Пример ИСР для проекта «Запуск маркетинговой кампании»

Это упрощённая схема. В реальном плане каждый из пунктов можно декомпозировать глубже, если для него нужно отдельно оценивать сроки, ресурсы, ответственность или зависимости.

Например, пункт «2.1. Созданы материалы» можно разложить так:

2.1.1. Подготовить техническое задание на рекламные материалы.
2.1.2. Написать тексты объявлений.
2.1.3. Создать графические макеты.
2.1.4. Проверить техническую точность и соответствие бренду.
2.1.5. Получить согласование и подготовить финальные версии.

До какого уровня декомпозировать?

Не нужно стремиться к максимальному количеству задач. Останавливайтесь, когда работа становится достаточно понятной для планирования и управления.

Золотые правила:

Одна работа — один исполнитель.
Одна работа — не дольше недели.

Обычно операцию уже можно планировать отдельно, если:

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

Если задача всё ещё звучит как «подготовить маркетинг», она слишком крупная. Если она звучит как «открыть файл и изменить заголовок на две строки», это избыточная детализация для верхнего уровня плана (хотя в конкретном рабочем процессе такая задача и может быть оправдана).

Правило полноты

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

Для проверки задайте вопрос:

«Если мы выполним все перечисленные работы, но не будем делать ничего дополнительного, сможем ли мы получить все обещанные результаты проекта?»

Если нет — декомпозиция неполная.

Шаг 3. Определите контрольные точки

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

Для нашей кампании контрольными точками могут быть:

ID	Контрольная точка	Критерий достижения	Решение или действие
КТ-01	Замысел проекта согласован	Подтверждены цель, целевая аудитория, бюджетный лимит и критерии успеха	Разрешить подготовку кампании
КТ-02	Концепция кампании утверждена	Согласованы предложение, каналы и план проверки гипотез	Разрешить производство материалов
КТ-03	Кампания готова к запуску	Материалы согласованы, аналитика проверена, команда и бюджет готовы	Разрешить запуск
КТ-04	Тестовая кампания проверена	Реклама работает, данные собираются, качество первых обращений оценено	Продолжить, скорректировать или остановить тест
КТ-05	Итоги кампании приняты	Подготовлен отчёт по согласованным показателям и зафиксированы выводы	Завершить проект или согласовать дальнейшие действия

Как выбрать контрольные точки?

Ищите события, после которых:

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

У контрольной точки обычно есть дата, ответственный за достижение и критерий подтверждения. Сама точка не является длительной работой: например, «утверждение концепции» — это событие, а «подготовить концепцию и организовать её согласование» — это работа.

Для определения перечня контрольных точек также можно использовать ИИ. Для этого просто вставьте промт в диалоговое окно ИИ с контекстом вашего проекта:

Определение контрольных точек проекта. Нажмите, чтобы развернуть текст

Промт: определение контрольных точек проекта

Роль

Ты — опытный руководитель проектов и наставник начинающих РП. Помоги мне определить контрольные точки проекта на основании четырёх артефактов:

Пентабазис проекта — определяет основные параметры проекта: зачем он нужен, что должно быть создано, в какие сроки, с какими затратами и ресурсами, а также какие ограничения необходимо учитывать.
Project Canvas — описывает замысел проекта, ценность, заинтересованные стороны, целевую аудиторию, ожидаемые результаты, гипотезы и критерии успеха.
RASIC-матрица — определяет роли и ответственность участников за выполнение работ и принятие решений.
ИСР проекта (иерархическая структура работ) — описывает состав результатов проекта и декомпозицию работ, необходимых для их создания.

Цель

На основании этих артефактов сформируй список контрольных точек (КТ), который позволит руководителю проекта своевременно проверять достижение значимых результатов, оценивать состояние проекта и принимать обоснованные решения о дальнейшем движении.

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

Контрольная точка — это не отдельная задача, дата в календаре или формальный отчёт о статусе. Она должна помогать ответить на вопросы:

Что должно быть достигнуто к этому моменту?
По каким признакам мы поймём, что результат действительно достигнут?
Кто подтверждает достижение результата и кто принимает решение?
Что мы будем делать в зависимости от результата проверки?

Порядок работы

Шаг 1. Изучи исходные артефакты

Проанализируй все предоставленные материалы и установи взаимосвязи между ними:

Из пентабазиса определи ключевые ограничения, параметры и обязательства проекта.
Из Project Canvas выдели ожидаемую ценность, результаты, гипотезы и критерии успеха.
Из ИСР определи результаты и логические этапы, достижение которых имеет смысл проверять.
Из RASIC-матрицы определи, кто отвечает за подготовку результата, кто участвует в его проверке и кто уполномочен принимать решения.

Не рассматривай артефакты изолированно: контрольные точки должны связывать ожидаемую ценность проекта с конкретными результатами работ и ответственностью участников.

Шаг 2. Определи, где нужны контрольные точки

Выдели моменты проекта, в которых необходимо принять решение, например:

подтверждение замысла и целесообразности проекта;
утверждение концепции или выбранного решения;
готовность к началу следующего значимого этапа;
проверка гипотезы или промежуточного результата;
подтверждение готовности продукта или результата к передаче заказчику;
оценка достижения целей и завершение проекта.

Это примеры, а не обязательный список. Выбирай только те контрольные точки, которые нужны конкретному проекту. Не создавай отдельную КТ для каждой задачи ИСР. Объединяй связанные работы в один проверяемый результат, если они вместе обеспечивают готовность к важному решению. Не добавляй контрольные точки только ради соблюдения формальной последовательности этапов. Если проект небольшой, достаточно нескольких действительно значимых КТ.

Шаг 3. Сформулируй критерии достижения

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

Хороший критерий:

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

Избегай формулировок вроде «всё готово», «работы завершены», «заказчик доволен» или «качество достаточное», если не указано, как именно это проверить. Если численные пороги, даты или условия приёмки отсутствуют в исходных материалах, не выдумывай их. Используй проверяемую качественную формулировку либо отметь, что критерий необходимо согласовать.

Шаг 4. Определи управленческое решение

Для каждой КТ укажи, какое решение или действие должно следовать из проверки. В зависимости от проекта это может быть:

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

Решение должно зависеть от результатов проверки, а не быть одинаковым для всех ситуаций. Если уместно, укажи несколько возможных действий для разных исходов проверки, например: «Продолжить, скорректировать или остановить тест».

Учитывай полномочия участников из RASIC-матрицы. Не наделяй РП или других участников правом утверждения, если оно не следует из предоставленных материалов. Если полномочия не определены, укажи, что их необходимо согласовать.

Шаг 5. Проверь полноту и качество контрольных точек

Перед формированием итоговой таблицы проверь, что:

Все существенные результаты и критерии успеха проекта покрыты контрольными точками.
Учтены критичные ограничения по срокам, бюджету, ресурсам и другим параметрам пентабазиса.
Для каждой КТ существует связь с результатами ИСР или значимыми решениями по проекту.
Критерии достижения можно проверить объективно.
Для каждой КТ понятно, какое решение необходимо принять.
Решения соответствуют полномочиям участников из RASIC-матрицы.
Контрольные точки расположены в логической последовательности.
Нет лишних КТ, дублирующих друг друга или повторяющих отдельные задачи.
В таблице нет выдуманных фактов, критериев, порогов и полномочий.

Если исходных данных недостаточно, сформируй лучший обоснованный вариант, а после таблицы перечисли вопросы, которые необходимо уточнить. Не останавливай работу только из-за отсутствия отдельных данных.

Формат результата

Представь результат в виде одной Markdown-таблицы со следующими столбцами:

ID	Контрольная точка	Критерий достижения	Решение или действие
КТ-01	Краткое название значимого результата или решения	Конкретные проверяемые условия, подтверждающие достижение результата	Управленческое решение или действие по итогам проверки

Правила оформления:

Используй последовательную нумерацию: КТ-01, КТ-02, КТ-03 и далее.
Названия контрольных точек формулируй кратко, через достигнутое состояние: «Замысел проекта согласован», «Концепция утверждена», «Результат принят».
Критерии достижения формулируй конкретно и проверяемо.
Решения описывай через действие: «Разрешить запуск», «Утвердить результат», «Скорректировать план».
Если уместно, перечисляй несколько вариантов решения в зависимости от результата проверки.
Не включай в таблицу пояснения к методологии, задачи ИСР, сроки и ответственных в отдельных столбцах: итоговая таблица должна содержать ровно четыре указанных столбца.

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

Исходные данные проекта

Пентабазис проекта:

[Вставить пентабазис]

Project Canvas проекта:

[Вставить Project Canvas]

RASIC-матрица:

[Вставить RASIC]

ИСР проекта:

[Вставить ИСР]

На основании этих данных сформируй контрольные точки проекта в соответствии с указанными правилами.

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

Шаг 4. Опишите зависимости между операциями

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

Например:

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

Пример таблицы зависимостей:

Операция	Предшествующая работа	Почему зависит
Подготовить рекламные тексты	Утвердить предложение	Тексты должны отражать согласованную ценность продукта
Настроить аналитику	Определить целевые действия и показатели	Нужно понимать, какие события и конверсии измерять
Запустить рекламу	Подготовить материалы и проверить аналитику	Иначе кампания может работать с ошибками или без измерения результата
Оценить стоимость лида	Запустить кампанию и собрать данные о расходах и обращениях	Для расчёта нужны фактические данные

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

С определением зависимостей операций проекта также отлично справляется ИИ. Вот промт, который достаточно вставить в чат с контекстом вашего проекта:

Определение зависимостей между операциями проекта. Нажмите, чтобы развернуть текст

Промт: определение зависимостей между операциями проекта

Роль

Ты — опытный руководитель проектов и наставник начинающих РП. Помоги мне определить логические зависимости между операциями проекта на основании предоставленных артефактов.

Цель

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

Результат должен помочь руководителю проекта:

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

Главный принцип: зависимость возникает тогда, когда для выполнения одной работы необходим результат, информация, решение или ресурс, обеспечиваемый другой работой. Не считай работы зависимыми только потому, что они расположены рядом в ИСР или относятся к одному этапу проекта.

Исходные артефакты

Используй предоставленные материалы:

ИСР проекта — основной источник операций и результатов, между которыми необходимо установить зависимости.
Пентабазис проекта — источник ограничений по срокам, ресурсам, бюджету, содержанию и другим параметрам, которые могут влиять на последовательность работ.
Project Canvas — источник информации о целях, ценности, требованиях, гипотезах и ожидаемых результатах.
RASIC-матрица — источник информации о распределении ответственности, участниках работ и необходимости согласований.

Если предоставлена только ИСР, выполни анализ на её основании, не придумывая отсутствующие данные.

Порядок работы

Шаг 1. Выдели операции проекта

Изучи ИСР и выдели работы, между которыми имеет смысл устанавливать зависимости.

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

Шаг 2. Найди необходимые предшествующие работы

Для каждой операции задай вопрос:

«Какой результат, информация, решение или ресурс должен быть получен, чтобы эту операцию можно было начать или завершить?»

Определи, какая другая работа обеспечивает это условие.

Проверь следующие типы зависимостей:

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

(Это категории для внутреннего анализа, а не обязательные метки для итоговой таблицы).

Шаг 3. Проверь обоснованность каждой зависимости

Для каждой найденной связи объясни, почему предшествующая работа необходима. Формулируй обоснование через конкретную причинно-следственную связь.

Например:

«Тексты должны отражать согласованное предложение».
«Для настройки аналитики необходимо определить измеряемые события и целевые показатели».
«Для оценки стоимости лида нужны фактические данные о расходах и количестве обращений».

Не используй формулировки вроде «такова последовательность проекта», «работа выполняется раньше» или «это следующий этап» без объяснения реальной причины. Если зависимость не является обязательной и работы можно выполнять параллельно, не создавай искусственную связь.

Шаг 4. Определи границы зависимости

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

Шаг 5. Проверь полноту и логичность связей

Перед выдачей результата проверь:

Каждая зависимость имеет понятное обоснование.
Все операции взяты из ИСР либо явно обозначены как предложенные уточнения.
Не пропущены необходимые входные результаты, согласования, проверки и подготовительные работы.
Независимые операции не связаны искусственно.
Не создано циклических зависимостей, при которых работы взаимно блокируют друг друга.
Не перепутана логическая зависимость с распределением ответственности.
Не добавлены выдуманные требования, согласования или ограничения.
Объяснение позволяет начинающему РП самостоятельно понять, почему работы зависят друг от друга.

Формат результата

Выведи результат в виде одной Markdown-таблицы с тремя столбцами:

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

Правила заполнения:

Каждая строка описывает одну зависимость.
Если у операции несколько независимых предшествующих работ, создай отдельную строку для каждой связи.
Используй названия операций из ИСР, сохраняя их смысл.
Если работа не имеет выявленных предшественников среди предоставленных операций, не придумывай зависимость.
Не указывай саму операцию в качестве её собственного предшественника.
Не добавляй в таблицу столбцы с типом зависимости, ответственным, длительностью или датой.
Не включай в таблицу зависимости, основанные только на удобстве или предполагаемом порядке выполнения.

После таблицы, если это необходимо, добавь раздел «Что нужно уточнить», в котором перечисли неоднозначные зависимости или недостающие исходные данные.

Исходные данные проекта

ИСР проекта:

[Вставить ИСР]

Пентабазис проекта:

[Вставить пентабазис]

Project Canvas проекта:

[Вставить Project Canvas]

RASIC-матрица:

[Вставить RASIC]

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

Шаг 5. Опишите каждую операцию

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

Я рекомендую использовать карточку операции со следующими полями.

Карточка операции проекта

№ и название критерия	Описание критерия
1. ID и название	Уникальный номер и конкретная формулировка работы.
2. Цель и назначение	Зачем нужна операция и какой более крупный результат она обеспечивает.
3. Входы	Какие документы, данные, решения или материалы нужны до начала работы.
4. Ответственность	Ответственный за итог (A), исполнители (R), поддержка и консультанты при необходимости — согласно RASIC.
5. Ресурсы	Рабочее время, бюджет, инструменты, доступы, компетенции и подрядчики.
6. Сроки и зависимости	Плановая дата начала и окончания, длительность, предшествующие и последующие операции.
7. Результат	Что именно будет создано, изменено, проверено или передано.
8. Критерии приёмки	По каким проверяемым признакам можно подтвердить, что работа выполнена качественно.
9. Принимающий результат	Кто проверяет результат и подтверждает его соответствие требованиям.
10. Статус и подтверждение выполнения	Статус операции и ссылка на готовый документ, макет, отчёт или иной результат.

Не каждая маленькая операция требует отдельного бюджета, формальной приёмки или подробного описания входов. Глубина карточки должна соответствовать сложности и риску работы. Но ответственный, ожидаемый результат и понятный критерий завершения должны быть определены всегда.

Пример заполненной карточки

МК-2.1. Подготовить рекламные тексты

Этап 2. Подготовка кампании

Цель: подготовить тексты, которые доносят согласованное предложение до целевой аудитории и подходят для выбранных рекламных каналов.
Входы:
- Утверждённая концепция кампании.
- Описание продукта и его преимуществ.
- Портрет целевой аудитории.
- Требования рекламных площадок и брендбук.
Ответственность по RASIC:
- A: руководитель маркетинга.
- R: маркетолог-копирайтер.
- C: руководитель продаж и продуктовый эксперт.
- I: заказчик проекта.
Ресурсы: ориентировочно 12 часов работы копирайтера и 2 часа экспертов на проверку; доступ к материалам о продукте и рекламным кабинетам.
Сроки и зависимости: плановая длительность — 3 рабочих дня после утверждения концепции. Требуется согласованная информация о продукте.
Результат: комплект рекламных текстов для согласованных каналов кампании.
Критерии приёмки:
- Подготовлены тексты для всех согласованных форматов и каналов.
- В текстах корректно отражены свойства и преимущества продукта.
- Соблюдены ограничения рекламных площадок и требования бренда.
- Проверены призывы к действию и соответствие целевой аудитории.
- Замечания согласующих устранены, финальные версии сохранены в согласованном месте.
Принимающий результат: руководитель маркетинга; техническую корректность проверяет продуктовый эксперт, юридические требования — уполномоченный специалист (если такая проверка предусмотрена).
Подтверждение выполнения: ссылка на финальные тексты и отметка об утверждении.

Обратите внимание: результатом является не «работа над текстами», а конкретный комплект текстов. Критерии приёмки описывают проверяемые свойства этого комплекта, а не субъективное «тексты понравились».

Шаг 6. Определите связи операций и постройте диаграмму Ганта проекта

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

На этом шаге мы определяем последовательность операций и их связи.

Для этого на основании нашей ИСР и параметров отдельных операций строим диаграмму вида:

Рис. 6. Сетевая диаграмма проекта по запуску новой рекламной кампании. Использован тот же метод, что и ранее: ИИ создал код в Mermaid, который затем отрисован в diagrams.net

Такая диаграмма позволяет определить критический путь проекта.

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

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

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

Простой пример

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

исследовать аудиторию — 2 дня;
сформировать предложение — 1 день;
подготовить рекламные материалы — 3 дня;
подготовить посадочную страницу — 4 дня;
проверить готовность и запустить кампанию — 1 день.

После формирования предложения подготовка материалов и страницы может идти параллельно.

Как определить критический путь: 5 основных шагов

1. Составить список работ.

Использовать операции из ИСР, а не крупные этапы проекта. Например: «Создать рекламные материалы», «Подготовить страницу», «Настроить аналитику».
2. Установить зависимости.

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

Нужна именно календарная длительность при запланированных ресурсах, а не только трудоёмкость в человеко-часах.
4. Рассчитать ранние и поздние сроки.

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

Последовательность таких работ образует критический путь. Если таких последовательностей несколько, у проекта может быть несколько критических путей.

Как рассчитывается временной резерв

Для каждой работы определяются четыре показателя:

РН (ES) — раннее начало.
РО (EF) — раннее окончание.
ПН (LS) — позднее начало без задержки проекта.
ПО (LF) — позднее окончание без задержки проекта.

При расчёте по стандартному методу критического пути, если связи имеют тип «окончание — начало»:

РО=РН+D

ПН=ПО-D

где D — длительность работы.

Полный временной резерв работы:

Резерв=ПН-РН=ПО-РО

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

Как это применить к нашей маркетинговой кампании

Для расчёта критического пути нужно использовать нашу сетевую диаграмму и дополнить её календарными длительностями всех 12 операций. Например, «Создать материалы — 12–20 человеко-часов» не означает, что работа займёт 2–3 календарных дня: это зависит от того, сколько времени исполнитель реально может ей уделять.

Затем нужно учесть:

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

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

Главное практическое правило: сокращение работы вне критического пути не обязательно ускоряет проект. А вот сокращение критической работы может уменьшить общий срок, если при этом не возникнет новый критический путь.

Диаграмма Ганта проекта

После построения сетевой диаграммы можно построить диаграмму Ганта.

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

Если сетевая диаграмма отвечает на вопрос: «В какой последовательности должны выполняться работы?», то диаграмма Ганта отвечает на вопросы: «Когда выполняется каждая работа и сколько она длится?»

Как построить диаграмму Ганта: 7 шагов

1. Возьмите операции из ИСР.

Для нашей кампании это, например, исследование аудитории, формирование предложения, создание материалов, подготовка страницы, настройка аналитики и запуск каналов. Крупные этапы можно использовать как сводные строки.

2. Определите зависимости.

Используйте сетевую диаграмму, которую мы уже построили. Например, рекламные материалы зависят от предложения и выбора каналов, а запуск — от готовности материалов, страницы и аналитики.

3. Оцените календарную длительность работ.

Переведите трудоёмкость в человеко-часах в календарные дни с учётом доступности исполнителей. Работа на 12 часов может занять два дня при загрузке специалиста по 6 часов в день — или дольше, если есть другие задачи.

4. Назначьте исполнителей и ресурсы.

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

5. Определите дату начала и рассчитайте даты работ.

Сначала рассчитайте ранние сроки с учётом зависимостей. Затем проверьте ограничения по срокам, доступность команды и согласования.

6. Отметьте контрольные точки.

Например: предложение утверждено, страница готова, кампания запущена, результаты оценены. Контрольная точка — событие, которое обычно не имеет собственной длительности.

7. Добавьте критический путь и обновляйте план.

Выделите критические работы, зафиксируйте базовый план, а затем регулярно сравнивайте плановые и фактические сроки.

Рис. 7. Диаграмма Ганта проекта по запуску рекламной кампании. Для построения использован тот же метод, что и раньше

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

Шаг 7. Создайте расписание проекта и зафиксируйте обязательства

По сути, мы уже создали расписание, когда построили диаграмму Ганта. Однако работать с ней исполнителям не всегда удобно, особенно если они не погружены в тонкости проектного управления. Команде нужно дать чёткое табличное расписание, чтобы каждый специалист понимал, чего и в какие сроки от него ждут. А для нас, как для РП, это рабочий инструмент контроля поставок проекта и раннего обнаружения отклонений от плана.

В таблице ниже представлено расписание для нашего учебного кейса:

№ работы	Операция	Дата начала	Дата окончания	Ответственный
1.1	Исследована аудитория	20.10.2026	21.10.2026	Маркетолог
1.2	Сформировано предложение	22.10.2026	22.10.2026	Маркетолог
1.3	Выбраны каналы	22.10.2026	22.10.2026	Специалист по рекламе
2.1	Созданы материалы	23.10.2026	26.10.2026	Маркетолог
2.2	Подготовлена страница	23.10.2026	27.10.2026	Веб-дизайнер / разработчик
2.3	Настроена аналитика	28.10.2026	28.10.2026	Веб-аналитик
3.1	Проверен запуск	29.10.2026	29.10.2026	Маркетолог
3.2	Запущены каналы	30.10.2026	30.10.2026	Специалист по рекламе
—	Накопление первых данных	02.11.2026	03.11.2026	Маркетолог / аналитик
3.3	Собраны первые данные	04.11.2026	04.11.2026	Аналитик
4.1	Проанализированы лиды	05.11.2026	05.11.2026	Маркетолог
4.2	Оценена стоимость лида	06.11.2026	06.11.2026	Специалист по рекламе
4.3	Подготовлены выводы	09.11.2026	09.11.2026	Руководитель проекта

Надо ли говорить, что для составления этого расписания я также использовал ИИ?

Шаг 8. Перенесите план проекта в информационную систему управления проектами

Для управления проектом нам нужно общее пространство, в котором мы сможем координировать работу с исполнителями, отслеживать ход выполнения задач и проводить сценарное планирование на случай, если проект пойдёт не по плану (а он обязательно пойдёт).

Для этих целей применяются информационные системы управления проектами (ИСУП). Их существует огромное множество: от простых таск-трекеров вроде YouGile или Trello до масштабных профессиональных систем вроде MS Project или Advanta.

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

Рис. 8. Вид интерфейса Kaiten

Для этого переходим на kaiten.ru/ и создаём новое пространство проекта, а внутри него — новую доску.

Затем в диалоге с ИИ просим сгенерировать CSV-файл для импорта расписания проекта в Kaiten.

В интерфейсе Kaiten выбираем «Импортировать карточки из другой системы», загружаем полученный файл и настраиваем соответствие полей.

Рис. 9. Настройка импорта в Kaiten

Особенность Kaiten: исполнителям необходимо указать их e-mail, иначе система не сможет импортировать файл.

Рис. 10. Операции проекта импортированы в виде карточек в пространство проекта

Теперь нужно запустить проект и ознакомить участников с расписанием.

Запустить работу команды

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

Но для запуска нам не хватает одной важной детали — модели управления проектом. То есть определения, в каком операционном цикле мы будем производить мониторинг, оценку и контроль хода проекта.

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

Упрощённо — нам надо составить календарь коммуникаций проекта. Например, договориться, что:

На время реализации проекта мы будем делать еженедельную координационную встречу, на которой будем отслеживать статус работы, определять проблемы и неподдерживаемые зависимости, а также подтверждать факт выполнения той или иной операции. На этой встрече мы ждём всю команду с отчётом и перечнем «затыков».
Будем устраивать ежедневные дейлики, чтобы понимать, кто и чем занят и какие действия планирует сделать сегодня. А также чтобы поддерживать темп работы, не давая участникам расслабиться.
Еженедельно будем приходить к заказчику проекта и отчитываться о ходе работ или публиковать в общедоступном месте отчёт о ходе проекта.
Определим даты формальных встреч по прохождению контрольных событий (вех) проекта.

РП надлежит оформить эту модель в виде документа или хотя бы слайда и довести её до всех участников проекта.

Таким образом мы получим минимальный набор документов для проведения Kick-off (инициирующей) встречи проекта.

Kick-off (кик-офф) — это стартовая встреча проекта, на которой заказчик, руководитель проекта и ключевые участники синхронизируют понимание целей, ожидаемых результатов, плана работ, ролей и правил взаимодействия.

Главная задача kick-off — не просто рассказать команде о проекте, а добиться того, чтобы после встречи все понимали:

Зачем мы запускаем проект и какую ценность должны создать.
Что конкретно необходимо получить в результате.
Как будем организовывать и контролировать работу.
Кто за что отвечает и кто принимает решения.
Что делаем дальше и какие ближайшие шаги необходимо выполнить.

Kick-off обычно проводится после предварительного согласования замысла проекта, но до начала основных работ. Для небольших проектов встреча может занимать 30–60 минут, для сложных межфункциональных проектов — 1,5–3 часа.

1. Что показывают и обсуждают на kick-off

1. Замысел и цели проекта

Какую проблему решаем и почему именно сейчас?
Какую ценность должен создать проект?
По каким критериям поймём, что проект успешен?

Материалы: пентабазис, канвас проекта, обоснование запуска.

2. Результаты и границы проекта

Что должно быть создано или изменено?
Что входит в проект, а что не входит?
Какие требования и ограничения критичны?

Материалы: описание результата, канвас, верхний уровень ИСР.

3. План проекта и контрольные точки

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

Материалы: ИСР, диаграмма Ганта, контрольные точки.

4. Команда и ответственность

Кто выполняет работы и отвечает за результаты?
Кто согласует и утверждает решения?
К кому обращаться при блокировках и конфликтах?

Материалы: RASIC-матрица, список участников и заинтересованных сторон.

5. Риски, коммуникации и правила работы

Что может помешать достижению целей?
Как часто встречаемся и отчитываемся о статусе?
Где храним задачи, документы и решения?
Как управляем изменениями и эскалируем проблемы?

Материалы: реестр рисков, план коммуникаций, правила команды.

Важно: kick-off — не защита презентации перед аудиторией. Это рабочая встреча, на которой участники должны обсуждать, уточнять и согласовывать решения. Если существенные параметры проекта ещё не утверждены, их нельзя представлять команде как окончательно согласованные.

2. Рекомендуемая повестка kick-off

Пример повестки для встречи продолжительностью 90 минут:

Время	Блок	Что обсуждаем	Результат
0–5 мин	Открытие	Знакомство, цель встречи, ожидания	Общее понимание задачи встречи
5–15 мин	Замысел	Проблема, ценность, цели, критерии успеха	Единое понимание «зачем»
15–25 мин	Результат и границы	Что создаём, что не входит в проект	Согласованное понимание объёма
25–40 мин	План работ	ИСР, зависимости, этапы и контрольные точки	Понимание последовательности работ
40–55 мин	Роли и ответственность	RASIC, полномочия, заказчик и владельцы результатов	Понимание ответственности
55–65 мин	Риски и ограничения	Бюджет, сроки, ресурсы, предположения, риски	Список открытых вопросов и рисков
65–75 мин	Организация работы	Совещания, статусы, инструменты, изменения, эскалации	Правила взаимодействия
75–85 мин	Ближайшие шаги	Первые задачи, ответственные, сроки	План действий после встречи
85–90 мин	Завершение	Проверка договорённостей, вопросы, итоги	Подтверждённые решения и следующие шаги

Для сложного проекта блоки можно расширить, а для небольшого — сократить до 30–45 минут.

3. Чек-лист руководителя проекта по подготовке и проведению kick-off

Этап 1. Подготовка до встречи

[ ] Определить цель kick-off и решения, которые необходимо получить.
[ ] Согласовать дату, продолжительность и формат встречи.
[ ] Пригласить заказчика, спонсора, ключевых участников и владельцев результатов.
[ ] Проверить, что замысел и цели проекта сформулированы.
[ ] Подготовить пентабазис и канвас проекта.
[ ] Подготовить описание результата и границ проекта.
[ ] Подготовить ИСР и предварительную последовательность работ.
[ ] Подготовить список контрольных точек с критериями достижения.
[ ] Подготовить RASIC-матрицу и проверить спорные зоны ответственности.
[ ] Собрать известные ограничения, риски, предположения и открытые вопросы.
[ ] Подготовить презентацию и материалы для совместной работы.
[ ] Разослать повестку и материалы участникам заранее.

Этап 2. Проведение встречи

[ ] Объяснить цель встречи и ожидаемые результаты.
[ ] Синхронизировать понимание проблемы, ценности и целей проекта.
[ ] Обсудить критерии успеха и способы проверки результатов.
[ ] Подтвердить границы проекта и ключевые требования.
[ ] Представить основные работы, зависимости и контрольные точки.
[ ] Проверить реалистичность сроков и доступность необходимых ресурсов.
[ ] Обсудить роли, ответственность и полномочия по принятию решений.
[ ] Выявить основные риски, ограничения и нерешённые вопросы.
[ ] Согласовать правила коммуникации, отчётности и управления изменениями.
[ ] Зафиксировать решения, разногласия и вопросы, требующие эскалации.
[ ] Назначить ответственных и сроки по ближайшим действиям.
[ ] В конце встречи вслух подвести итоги и проверить общее понимание договорённостей.

Этап 3. После встречи

[ ] Подготовить и разослать протокол kick-off.
[ ] Зафиксировать согласованные решения и открытые вопросы.
[ ] Обновить пентабазис, канвас, ИСР, RASIC и план проекта по итогам встречи.
[ ] Создать задачи по договорённостям и назначить исполнителей.
[ ] Уточнить сроки, зависимости и контрольные точки.
[ ] Зафиксировать риски и назначить ответственных за реагирование.
[ ] Проверить, что участники получили доступ к необходимым материалам и инструментам.
[ ] Проконтролировать выполнение первых договорённостей.

Ура-а-а! Мы запустили проект! Дело за малым — довести его до конца!

Управлять результатами

Классическое проектное управление условно разбивает каждый проект на 4 этапа:

Инициация
Планирование
Исполнение
Завершение

Мы познакомились вкратце с процессом инициации и планирования. Теперь рассмотрим процесс исполнения проекта и используемые для этого инструменты.

Для РП сам процесс сводится к следующим подпроцессам:

Организация работы команды

Распределить задачи, обеспечить ресурсами, договориться о взаимодействии и устранить препятствия.
Координация выполнения работ

Синхронизировать исполнителей, зависимости и сроки; следить, чтобы результаты отдельных работ складывались в общий результат проекта.
Контроль хода проекта

Сравнивать фактическое выполнение с планом по срокам, бюджету, объёму и качеству; проверять достижение контрольных точек.
Управление рисками и проблемами

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

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

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

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

1. Организация работы команды

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

И обеспечивает команду проекта всем, что для этого надо: правами доступа, лицензиями, ресурсами, полномочиями и рабочим местом наконец.

Мы составили RASIC как раз для того, чтобы понять модель организации, подчинения, распределения обязанностей и полномочий. Теперь РП должен выступить гарантом соблюдения этой договорённости.

2. Координация выполнения работ

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

Рис. 11. Попугай-менеджмент. Не надо так!

А как надо?

Во-первых, активно управлять коммуникацией внутри проекта. То есть составить реестр заинтересованных лиц и их ожиданий от проекта. Своевременно и качественно коммуницировать с участниками проекта: с кем-то проводить формальную встречу, кому-то писать письмо, а до кого-то доходить ножками и пить с ним кофе. В общем, своевременно и в полном объёме выявлять текущий статус работ, проблемы, блокеры, зависимости и риски. Доносить до лиц, наделённых полномочиями, необходимость принять решение или обеспечить проект ресурсами.

Краеугольную проблему классического проектного управления сформулировал Л. Н. Толстой фразой: «Чисто писано в бумаге, да забыли про овраги, как по ним ходить». Не испытывайте иллюзий, что ваш план проекта хоть в какой-то мере соответствует реальности «в полях». Только активное взаимодействие с участниками проекта позволяет почувствовать «нерв» проекта, сделать его живым и не дать ему рассыпаться. План — всего лишь модель, которая описывает набор гипотез.

Во-вторых, вести документацию проекта. Если в документации балаган, то такой же балаган будет и в проекте. Своевременно обновляйте план проекта, направляйте повестки и протоколы встреч, формируйте и направляйте отчёты и статусы, архивируйте и систематизируйте знания проекта.

В-третьих, включаться в решение проблем. Отсутствие доступа у участника проекта к документу или испытательному стенду, непродлённая лицензия, сгоревший ноутбук — это в первую очередь ваша проблема, поскольку люди склонны искать любой повод отлынивать от работы, не давайте его им.

Ключевой инструмент здесь — проведение координационных встреч и комитетов.

Для проведения координационных встреч рекомендуется использовать канбан-доски в таск-трекере.

Рис. 12. Вид канбан-доски в Kaiten для нашего учебного проекта

Вот хорошая практика для проведения координационной встречи:

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

Важно! Чтобы результат проекта не «расползался», участников проекта стоит фокусировать именно на достигаемых результатах, а не на текущей работе. Работы у всех много, и обсуждение хода работы обычно не даёт никакого эффекта, кроме терапевтического. Важно говорить именно в терминах результата: «Что сейчас делаешь, чтобы достичь результата?», «Что мешает достичь результата?», «Какие нужны ресурсы и решения, чтобы показать результат?».

По практике эксперты в доменных областях сфокусированы именно на том, как они реализуют задачу, забывая про общую цель проекта. Поэтому классно задавать рефлексивные вопросы вроде: «Достигается ли цель проекта с учётом текущего статуса?» или «Что нам мешает завершить этап прямо сейчас?».

Очень здорово помогают хорошо сформулированные критерии приёмки результата. В Scrum (это такой фреймворк работы Agile-команд) команда сама планирует результаты поставки итерации (двухнедельного цикла, его ещё называют спринтом) как раз в терминах критериев приёмки результата и формулирует цели спринта — то есть ту ценность, которую команда берётся поставить за спринт пользователю (клиенту) создаваемого продукта.

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

Это суперважный вопрос, поскольку команда проекта так или иначе самоорганизуется, поддерживая рабочие коммуникации, в которые может быть не включён РП. Этот вопрос позволяет выявить неочевидные проблемы и трения. Например, кто-то в команде игнорирует установленный формат или канал коммуникации и пишет напрямую в запрещённом на территории РФ Телеграме, а не в чате задачи или рабочем пространстве, из-за чего теряется контекст обсуждаемых проблем.

РП завершает встречу, резюмируя основные принятые решения, выявленные риски и блокеры, а также план работ на ближайшие периоды, убеждается, что все поняли всё одинаково и нет недосказанности, двусмысленности, недопонимания.
РП рассылает участникам проекта протокол встречи, содержащий перечень принятых решений, обязательства участников проекта на ближайший период, проблемы и риски, выявленные в ходе встречи, а также любую другую важную информацию — например, о важных событиях, отпусках или изменениях.

3. Контроль хода проекта

Наличие доски, плана проекта и еженедельных встреч — это хорошо, но что это значит для результата проекта? Это важный вопрос, за ответ на который как раз и платят зарплату руководителю проекта.

Для контроля хода проекта в классическом проектном управлении применяются в основном два инструмента:

План-фактный анализ
Сценарное планирование

Первый призван ответить на вопрос: «Насколько текущий статус проекта соответствует плану?», второй — «Насколько текущий статус проекта позволяет достичь цели проекта и что нужно изменить, чтобы цель была достигнута наверняка?».

Для проведения план-фактного анализа РП сравнивает текущий статус выполнения задач с расписанием проекта и ищет расхождения. Также важно обращать внимание на аспект расползания объёма работ. Это когда происходят «влёты» — например, кто-то из заинтересованных сторон или участников проекта решает сделать в проекте что-то ещё, или при планировании не полностью определили весь объём работ. Такие «влёты» сами по себе нормальны, проект — живой организм. Но важно понять, как это повлияет на результат.

Чтобы осмысленно ответить на этот вопрос, РП строит разные сценарии реализации проекта, обращаясь к инструментам, которые мы рассматривали на этапе планирования. Строит альтернативный план или планы, сравнивает их и делает выводы.

Положим, что для нашего примера с запуском рекламной кампании при реализации работы «2.3. Настроена аналитика» оказывается, что платформа аналитики не поддерживает лендинг, который мы сделали, и нужна другая платформа. Это выясняется в рамках координационной встречи команды проекта. Тогда РП проводит встречу с вовлечёнными участниками: аналитиком и веб-дизайнером — и просит их оценить влияние этой проблемы на ход проекта. В результате определяются два возможных сценария: перенести лендинг на другую платформу, где уже настроена аналитика, или прикрутить к лендингу и настроить другие аналитические инструменты.

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

Здесь, кстати, отлично помогает ИИ. В контексте проекта попросите ИИ провести анализ двух сценариев и выделить факторы, которые помогут принять обоснованное решение. Вот что порекомендовал мне ИИ:

Критерий	Сценарий А. Перенести лендинг на другую платформу	Сценарий Б. Подключить другие инструменты аналитики
Содержание работ	Перенести страницу, восстановить её оформление и функциональность, проверить работу	Подобрать инструмент, установить код или интеграцию, настроить события и конверсии
Сроки	Возможна существенная задержка из-за переноса и повторного тестирования	Обычно быстрее, если текущая платформа позволяет подключить сторонние инструменты
Стоимость	Возможны затраты на перенос, доработку и повторную проверку страницы	Возможны затраты на лицензии, настройку и технические работы
Риск технических проблем	Риск потери функциональности, ошибок отображения и необходимости повторной отладки	Риск некорректной настройки событий, дублирования данных и ошибок интеграции
Влияние на уже выполненные работы	Может потребоваться повторная работа веб-дизайнера и разработчика	Большая часть работ по созданию лендинга сохраняется
Надёжность аналитики	Потенциально выше, если целевая платформа полностью поддерживает нужную аналитику	Зависит от возможностей текущей платформы и качества интеграции
Дальнейшее развитие	Может упростить поддержку, если новая платформа лучше подходит проекту в целом	Позволяет сохранить текущую архитектуру, но может добавить техническую сложность

Помимо сравнения самих решений, РП должен оценить, как каждый сценарий повлияет на дальнейший план:

Область влияния	Что необходимо выяснить
Сроки	На сколько дней сдвинется запуск рекламной кампании в каждом сценарии?
Стоимость	Потребуются ли дополнительные расходы на лицензии, разработку или перенос?
Качество	Можно ли будет корректно измерять переходы, заявки и конверсии?
Ресурсы	Сколько времени потребуется от веб-дизайнера, разработчика и аналитика?
Риски	Какова вероятность ошибок при переносе или подключении стороннего инструмента?
Дальнейшая поддержка	Насколько удобно будет сопровождать решение после запуска кампании?

Предварительная рекомендация — сценарий Б: подключить к существующему лендингу другие инструменты аналитики.

Почему:

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

Однако это решение целесообразно только при условии, что текущая платформа технически допускает подключение альтернативной аналитики, а она обеспечивает необходимые измерения с приемлемыми затратами и сроками.

Сценарий А предпочтительнее, если подключение сторонних инструментов невозможно, ненадёжно или существенно усложняет дальнейшую поддержку, а перенос на другую платформу даёт более устойчивое решение в долгосрочной перспективе.

Это уже предпосылка к управленческому решению. Но такие серьёзные решения, влияющие на сроки и стоимость проекта, не должны приниматься РП в одиночку. Поэтому важно в рамках коммуникации с заинтересованными сторонами — заказчиком и спонсором проекта, потребителем результатов проекта — утвердить, по какому сценарию проект будет развиваться дальше, запротоколировать это решение, обновить документы проекта: план, бюджет, расписание, и донести изменения до команды проекта.

4. Управление рисками и проблемами

Отличная практика управления рисками и проблемами — ведение отдельного реестра рисков и нерешённых проблем. В рамках циклов управления РП выявляет риски и заносит их в реестр. С установленной периодичностью — например, раз в неделю при подготовке повестки координационной встречи — РП выносит риски и просит ответственных участников проекта подготовить статус по риску и план по митигации (недопущению) срабатывания риска. На координационной встрече принимается решение, что делать с актуальными рисками. При необходимости РП подготавливает описание риска и выносит его на суд заинтересованных сторон.

Важно не просто прийти к начальнику с фразой «Шеф, всё пропало, гипс снимают!», а вынести проблему для решения: описать её, определить влияние, спроектировать возможные сценарии решения и чётко артикулировать, что нужно: больше людей, сдвинуть сроки, больше ресурсов и так далее. Короче, не сидите с рисками и проблемами в одиночестве, активно решайте их, вовлекая тех людей, у которых есть полномочия помочь проекту.

5. Управление изменениями

Изменения в проекте — это нормально, но при условии, что они происходят осмысленно. Для управления изменениями РП надлежит внимательно отслеживать три показателя проекта:

исполнение сроков проекта;
исполнение бюджета проекта;
содержание и объём работ.

Любые проблемы и риски проекта должны оцениваться как раз через влияние на эти параметры. Любой новый «влёт» или отставание — предпосылка к внесению изменений. В классическом проектном управлении изменение рассматривается как объект управления. То есть РП должен дать изменению определение, характеристики и определить степень влияния. У любого изменения есть свой жизненный цикл:

выявление предпосылок к изменению;
определение объёма и характера изменений;
оценка влияния изменения на план проекта;
определение сценариев адаптации проекта;
утверждение и внедрение изменения: корректировка плана, расписания, бюджета проекта.

Худшие изменения — те, которые происходят самостоятельно, по воле случая и никак не определяются и не управляются. Если такое происходит — РП теряет рычаги управления проектом. Это не означает, что РП должен становиться злой Бабой-ягой, которая всегда против и не допускает отклонений от плана, но РП должен принимать активное участие в процессе управления изменениями.

6. Коммуникация с участниками и заказчиком

Как уже было описано выше, коммуникация — кровь проекта.

В общем случае есть два типа коммуникаций в проекте: активная и пассивная.

Активная коммуникация подразумевает активное вовлечение заинтересованных лиц (ЗЛ) в обсуждение. Вот некоторые методы активной коммуникации:

Рабочие встречи
Индивидуальные встречи и коммуникации
Воркшопы и совместные творческие сессии
Созвоны
Совместное распитие кофе или чего-то ещё

Пассивная коммуникация не подразумевает получения информации от ЗЛ:

Рассылка статусов или отчётов
Информационные письма и сообщения
Публикация отчётов и дашбордов в общедоступном пространстве
Коммуникация по запросу, когда вас, например, просят подготовить и направить отчёт в каком-то разрезе для определённых целей

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

Внутри команды
Вовне команды
Коммуникация с ключевыми заинтересованными лицами

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

Кстати, ИИ помогает повысить качество коммуникации. Если вы сохраняете контекст проекта в вашем ИИ, вы всегда можете попросить его оформить отчёт по текущему статусу проекта, адаптировав его под потребность конкретного заинтересованного лица. Для спонсора — краткую выжимку с эскалацией проблем и решений, оформленную в виде буклета или краткой презентации; для участников проекта — развёрнутый отчёт с текущим планом работ, ответственными, ожидаемыми результатами, проблемами и рисками. Пользуйтесь этим!

7. Приёмка результатов работ

Цыплят по осени считают, а проект — по поставленным результатам.

Тот факт, что кто-то из команды отметил задачу как выполненную, ещё не означает, что плановый результат для неё был достигнут.

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

Критерий приёмки — это конкретное, непротиворечиво сформулированное, проверяемое условие, которому должен соответствовать результат работы, чтобы заказчик или ответственный участник мог принять его как выполненный.

Пример для маркетинговой кампании:

Лендинг опубликован и доступен по рабочей ссылке.
Форма заявки отправляет данные в CRM.
Система аналитики фиксирует отправку заявки.
Страница корректно отображается на компьютере и смартфоне.

В RASIC у нас есть буква A (Accountable), то есть определено лицо, обладающее полномочиями принимать результат работы и давать ему оценку.

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

Здесь важно ввести два понятия: Output и Outcome.

Output (непосредственный результат) — то, что создано или выполнено в результате задачи.

Outcome (эффект) — изменение, которое произошло благодаря этому результату.

Примеры для нашего проекта маркетинговой кампании:

Задача	Output	Outcome
Исследовать аудиторию	Отчёт о целевой аудитории	Понятно, на кого ориентировать рекламу
Подготовить лендинг	Опубликованная страница с формой заявки	Потенциальным клиентам стало проще оставить заявку
Настроить аналитику	Настроенные счётчики и события	Команда может измерять конверсию лендинга
Запустить рекламу	Рекламные объявления запущены	На сайт приходит целевой трафик
Проанализировать результаты	Отчёт по лидам и стоимости привлечения	Команда понимает, какие каналы эффективны и как оптимизировать бюджет

Ключевое различие: Output — что мы сделали, Outcome — что изменилось благодаря этому.

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

Закрывать фазы и весь проект по завершении

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

На примере нашей маркетинговой кампании РП должен:

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

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

Итог работы РП: проект официально завершён, результаты приняты, обязательства закрыты, а ответственность за дальнейшее использование результатов передана соответствующим людям.

Здесь отдельно остановимся на фиксации уроков, оформлении документов и завершении работы команды.

Фиксация уроков

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

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

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

Для нашего учебного проекта после завершения кампании РП собирает команду: маркетолога, специалиста по рекламе, веб-разработчика и аналитика. На встрече команда обсуждает четыре вопроса:

Что планировали и что получили?
Что прошло хорошо?
Что пошло не так и почему?
Что нужно изменить в следующих проектах?

Пример результатов ретроспективы:

Ситуация	Причина	Выученный урок
Запуск задержался на 3 дня	Выяснилось, что платформа лендинга не поддерживает выбранную аналитику	Совместимость технических решений нужно проверять до начала разработки
Подготовка рекламных материалов затянулась	Не были заранее согласованы требования к форматам объявлений	Требования рекламных площадок нужно собирать до производства материалов
Команда поздно заметила низкую конверсию	Не был определён порог конверсии, при котором нужно вмешиваться	Для ключевых метрик нужно заранее устанавливать контрольные значения и действия при отклонениях
Отчёт о результатах подготовили быстро	Использовали единый шаблон отчёта	Стандартизированные шаблоны сокращают время подготовки итоговых материалов

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

Как превратить уроки в активы организации

Активы процессов организации (Organizational Process Assets, OPA) — это накопленные организацией знания, процессы, процедуры, шаблоны и другие материалы, которые помогают выполнять проекты.

Для нашего кейса были выучены следующие уроки:

Урок: проверять совместимость платформ.

Создаваемый актив: чек-лист технической готовности проекта.

В шаблон запуска маркетинговой кампании добавляют обязательную проверку совместимости лендинга, CRM, аналитики и рекламных систем до начала разработки.
Урок: заранее собирать требования площадок.

Создаваемый актив: шаблон требований к рекламным материалам.

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

Создаваемый актив: стандарт контроля маркетинговых проектов.

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

Создаваемый актив: стандартный шаблон итогового отчёта.

Шаблон сохраняют в корпоративной базе знаний и делают доступным для следующих руководителей проектов.

Как видите, ничего сложного, но эффект для следующей рекламной кампании — сэкономленное время и нервы.

Как организовать имплементацию уроков

Чтобы уроки действительно стали организационными активами, РП или ответственный за методологию должен организовать следующий процесс:

Зафиксировать урок — описать ситуацию, причину, вывод и рекомендацию.
Определить способ внедрения — изменить шаблон, регламент, чек-лист, стандарт или базу знаний.
Назначить владельца — например, руководителя PMO, владельца маркетингового процесса или специалиста по методологии.
Обновить актив — внести изменение, согласовать его и опубликовать новую версию.
Донести изменение до сотрудников — рассказать командам, когда и как применять новый инструмент.
Проверить применение — убедиться на следующих проектах, что обновление используется и приносит пользу.

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

Главная мысль: закрытие проекта — это не только подведение итогов конкретной работы. Это возможность повысить зрелость проектной деятельности организации: опыт одной команды превращается в знания и инструменты, которыми могут воспользоваться другие команды в будущих проектах.

Оформить документы

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

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

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

Например:

Кому нужна информация	Что делает РП	Что это позволяет сделать
Бухгалтерии	Передаёт подтверждённые расходы, закрывающие документы и сведения о выполненных работах	Закрыть расходы проекта, провести необходимые начисления и списания
Финансовому директору	Предоставляет фактические расходы, информацию об обязательствах и оставшихся платежах	Уточнить финансовый результат, спрогнозировать денежные потоки и потребность в оборотном капитале
Руководителям функциональных подразделений	Передаёт информацию о вкладе сотрудников, выполненных задачах и выявленных проблемах	Оценить результаты работы сотрудников, принять решения о премировании, повышении или обучении
Заказчику или внутреннему владельцу результата	Передаёт итоговые результаты, документацию и нерешённые вопросы	Принять результат и организовать его дальнейшую эксплуатацию
Руководству компании или спонсору	Представляет итоговый отчёт: цели, результаты, сроки, бюджет, отклонения и выводы	Оценить успешность проекта и принять решения о дальнейших инвестициях и инициативах
PMO и руководителям следующих проектов	Сохраняет уроки, шаблоны, расчёты и принятые решения	Использовать накопленный опыт и не повторять прежние ошибки

Например, в нашем проекте маркетинговой кампании РП не должен ограничиваться выводом: «Кампания запущена, отчёт по лидам подготовлен». Он также передаёт финансовому подразделению фактические затраты на рекламу и разработку лендинга, руководителю маркетинга — результаты кампании и вклад команды, а владельцу маркетингового процесса — данные об эффективности каналов и рекомендации по дальнейшим действиям.

При этом РП не обязан самостоятельно выполнять работу бухгалтерии, финансового директора или HR. Его задача — обеспечить полноту, достоверность и своевременную передачу информации, необходимой этим подразделениям для выполнения своих функций.

Почему РП нельзя пренебрегать этой работой?

Результат проекта должен быть виден организации. Если итоги не оформлены, руководству сложно оценить, что компания получила за потраченные деньги и ресурсы.
Финансовые и административные обязательства должны быть закрыты. Иначе расходы, платежи, договоры и премии могут остаться неурегулированными.
Работа сотрудников должна получить оценку. Без обратной связи от РП функциональные руководители могут не увидеть реальный вклад людей и их потребности в развитии.
Результат должен продолжить приносить пользу. Без передачи документации и ответственности созданное решение рискует остаться без владельца.
Опыт должен работать на будущие проекты. Если решения, ошибки и выводы не сохранены, организация снова тратит время и деньги на получение уже известного опыта.

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

Завершить работу команды и освободить ресурсы

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

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

Например, в нашем проекте маркетинговой кампании РП должен:

Освободить участников команды. Согласовать с функциональными руководителями завершение работы маркетолога, веб-разработчика, аналитика и специалиста по рекламе, чтобы они могли вернуться к обычным обязанностям или перейти в другие проекты.
Передать результат в операционную работу. Убедиться, что владелец маркетингового процесса получил лендинг, доступы, настройки аналитики, рекламные кабинеты и инструкции, необходимые для продолжения работы.
Передать незавершённые задачи. Если после завершения проекта нужно продолжать оптимизацию рекламы или анализировать результаты, определить ответственных, договориться о сроках и передать им необходимые данные. Важно, чтобы проектные задачи не остались без владельца.
Закрыть использование внешних ресурсов. Если привлекались подрядчики, подтвердить завершение их работ, урегулировать обязательства и отозвать доступы, которые больше не нужны.
Официально завершить проект. Получить необходимые подтверждения от заказчика или спонсора, зафиксировать статус закрытия и убедиться, что все обязательные процедуры выполнены.

Почему РП нельзя пренебрегать этой работой?

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

При этом РП не всегда самостоятельно решает, куда направить сотрудников после проекта. Обычно это согласуется с их функциональными руководителями или ресурсными менеджерами.

Главное: задача РП — не просто закончить проект, а организовать корректный выход из него: передать результаты и ответственность, освободить ресурсы и официально зафиксировать завершение. Это позволяет организации закрыть один проект и без потерь перейти к следующим инициативам.

Применение ИИ

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

Важная оговорка про этику и ограничения применения ИИ: ИИ не является серебряной пулей, которая будет делать работу за вас. Смысловое наполнение деятельности и целеполагание обязательно должны оставаться за человеком. ИИ склонен галлюцинировать и дискриминировать.

Галлюцинации

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

В этом плане ключевым метанавыком современного РП должно стать критическое мышление. Всегда задавайтесь вопросом: «С чего ИИ это взял?», требуйте от него подтверждения тезисов и выступайте строгим критиком. Он будет пытаться вас обмануть — не дайте ему это сделать.

Этика

Второй важный аспект применения ИИ — это этика и безопасность.

Во-первых, всё, что вы загружаете в облачный ИИ, развёрнутый не локально на вашем сервере, а «у каких-то дядей», моментально отчуждается. Не сливайте ИИ критическую информацию.

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

Модель зрелости применения ИИ

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

Уровень	Определение	Что делает	Критерий и пример
1	Ассистент	Я спрашиваю — ИИ отвечает	Разовое (ad-hoc) применение ИИ для конкретной задачи. Например: написать письмо.
2	Копилот	Я даю контекст — ИИ помогает выполнить процесс	Сохранение контекста проекта в ИИ, обучение на данных проекта. Например: составить реестр рисков проекта из контекста.
3	Аналитик	ИИ анализирует массив проектной информации	ИИ получает доступ к архиву проектной документации и анализирует его целиком. Например: проанализировать отчёты и определить скрытые риски.
4	Ревьюер	ИИ проверяет работу РП	ИИ отслеживает действия РП и выдаёт рекомендации с учётом всего архива знаний организации и проекта. Например: проанализировать готовый план работ и найти слабые места в плане с учётом контекста.
5	Агент	ИИ автономно выполняет рутинный процесс	Обученные ИИ-агенты выполняют рутинную работу автономно по триггерным событиям в системе управления проектом. Например: анализирует статус работ проекта в системе управления и готовит статус-отчёт с интерпретацией или сличает критерий приёмки с отчётом исполнителя и даёт заключение о готовности работы.
6	Система проектного управления, интегрированная с ИИ	ИИ наблюдает за проектом и помогает реализовывать его end-to-end	ИИ — не просто отдельный инструмент, сама методология и системы проектного управления организации нативно требуют применения ИИ.

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

А на каком уровне зрелости находитесь вы и ваша организация?

Выводы

Управление проектами — отдельная профессия, занимательная, в отдельных аспектах сложная, но наполняющая жизнь смыслом и удовлетворённостью. Грамотно управлять проектами не так больно, если уделить должное время собственному развитию.

«Тяжело в учении — легко в походе! Легко в учении — тяжело в походе!» — А. В. Суворов

Здесь, в ScrumTrek, мы уже 20 лет изучаем, накапливаем и развиваем самые актуальные практики управления проектами и недавно создали целую линейку открытых тренингов по проектному управлению. Мы видим, что проблема подготовки РП никуда не делась, а стала даже острее из-за массовой ИИ-изации процессов. И область проектного управления подвержена этой трансформации в первую очередь.

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

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

Приходите к нам учиться, чтобы правильно делать правильные вещи!