Третья глава магистерской работы — это проектная часть, где вы превращаете выводы из главы 2 в план действий. Вы не просто говорите: «гипотеза подтвердилась», а показываете, как теперь можно улучшить ситуацию. Проектная модель — это набор инструментов и событий, который меняет процесс: ускоряет сертификацию, снижает долю импортных компонентов, повышает долю локализации. Для этого глава 3 строится из пяти блоков: 1) паспорт проекта, 2) карта вех, 3) календарный план, 4) сценарии чувствительности, 5) правила верификации. Всё это подаётся в виде таблиц, схем и чётких формулировок. Основная цель главы — доказать, что ваши рекомендации реализуемы, измеримы и полезны для компаний, регионов и индустриальных площадок.
Первый блок — паспорт проекта. Он оформляется как одностраничный документ. В нём вы указываете: цель (например, рост доли локализации с 20 до 45% за 12 месяцев), бенефициары (китайская ТНК, регион, промышленный парк), ключевые действия (создание лаборатории, настройка сертификации, участие в реестре), ожидаемые эффекты (снижение срока сертификации, рост числа закупок, повышение баллов по постановлению №719). Паспорт должен быть логично связан с гипотезами, выводами и данными. Он нужен не только для текста, но и для презентации. Пример оформления — в Таблице 30. Там есть шаблон для GPT, структура паспорта и рекомендации по стилю.
Таблица 30 — Паспорт проектной модели
Второй блок — карта вех. Это основной инструмент проектного управления. Каждая веха — это проверяемое событие: лаборатория создана, протокол получен, предприятие включено в реестр, уровень локализации достиг 40%. Веха отличается от задачи тем, что она подтверждается документом: приказом, записью в реестре, протоколом испытаний. Каждая веха привязана ко времени и к гипотезе. Это видно в Таблице 31: она включает в себя шаблон вехи, способ верификации, документ, срок, и связь с результатами. Карта вех делает проект управляемым: видно, где вы находитесь, что должно быть готово и как проверить.
Таблица 31 — Карта вех проекта
Третий блок — календарный план проекта. Он строится по неделям или месяцам: какие действия должны быть завершены, какие документы получены, кто отвечает. Это план не всей работы, а именно реализации проекта, основанного на гипотезах. План помогает показать, что вы знаете последовательность действий, кто что делает и когда. Для каждой активности указывается: срок, исполнитель, результат, документ. Таблица 32 показывает, как это оформить. Такие таблицы полезны при защите: они доказывают, что вы не ограничиваетесь анализом, а предлагаете реалистичный путь внедрения.
Таблица 32 — Календарный план проекта
Четвёртый блок — сценарии чувствительности. Это раздел, где вы показываете: проект устойчив к изменениям условий. Например, если курс вырастет на 10%, ставка по кредиту изменится, или срок сертификации затянется на 30 дней — что произойдёт с NPV, с закупками, с эффектом? Такие расчёты важны: они доказывают, что вы не просто придумали идеальный вариант, а предусмотрели риски. Таблица 33 включает типовые сценарии (оптимистичный, базовый, пессимистичный), факторы, показатели, результат. Всё это связывается с выводами глав 1 и 2 и вехами из плана. При защите это будет плюсом.
Таблица 33 — Сценарии чувствительности и риски
Пятый блок — правила верификации проекта. Это набор критериев, по которым можно сказать: проект выполнен, результат достигнут. Это отличается от задач: критерии верификации всегда основаны на документе. Пример: «результат подтверждён, если предприятие включено в реестр до 15.10.2025 и доля локализации по компоненту X превышает 45% согласно актам». Таблица 34 помогает структурировать верификацию: критерий, документ, дата, связь с вехой и KPI. Это превращает проект в чёткую систему: всё измеряется, всё подтверждено. Это важно для защиты и для внедрения.
Таблица 34 — Критерии приёмки и документы
Третья глава не пишется по шаблону «проблема — решение». Она строится по логике проектного управления: паспорт, вехи, план, сценарии, приёмка. Всё оформлено в таблицах, каждая таблица — это связка между гипотезами главы 2 и практикой. Такой подход показывает: вы умеете превращать анализ в конкретный план, видите риски, умеете измерять результат. Это и есть проектная логика, которую проверяют на защите.