Включаешь ли пресейл в инициацию проекта

Преселлинг и его связь с фазой инициации проекта

Вопрос о включении пресейла (pre-sales) в инициацию проекта – один из самых практичных и дискуссионных в управлении IT-проектами. В качестве менеджера с большим опытом, я всегда утверждаю, что эффективный пресейл является фундаментальной частью успешной инициации и должен быть интегрирован в этот процесс как его логическое продолжение и подготовка. Это не просто "продажа", а критически важный этап формирования проекта.

Пресейл как часть инициации: логическая связь

Инициация проекта (Initiation Phase) по классическим стандартам (например, PMI PMBOK) включает в себя определение высокоуровневых целей, границ проекта, анализ бизнес-кейса и принятие решения о его запуске. Пресейл же в IT — это активность, предшествующая формальному контракту, где компания (исполнитель) совместно с потенциальным клиентом:

• Анализирует и детализирует потребности и проблемы клиента.
• Формулирует возможные решения и их ценность.
• Определяет технический и ресурсный подход.
• Обосновывает бюджет и сроки.

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

graph LR
    A[Пресейл-активность с клиентом] --> B[Согласование концепции и границ];
    B --> C[Подписание контракта / Утверждение проекта];
    C --> D[Формальная Инициация проекта<br/>Утверждение устава];
    D --> E[Создание детального плана];

Ключевые элементы пресейла, переходящие в инициацию

Когда проект переходит от пресейла к формальной инициации, менеджер проекта должен получить и "упаковать" в формальные документы следующие результаты пресейла:

1. Уточненное видение и цели проекта. Часто в виде согласованного с клиентом документа (Proposal, Vision Statement).
2. Первоначальные ограничения и риски. Например, бюджетные рамки, ключевые технологические ограничения, выявленные на пресейле.
3. Согласованные ключевые требования (High-Level Requirements). Это основа для будущего подробного технического задания (ТЗ).
4. Предварительная оценка сроков и ресурсов. Эта оценка становится входными данными для планирования.
5. Сформированная команда продаж/аналитиков/технических экспертов, которая становится естественным источником информации для проектной команды.

Почему формальное включение пресейла в инициацию критически важно

Если не считать пресейл частью инициации, возникают серьезные риски:

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

Моя практика: процесс интеграции

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

• Совместную встречу с ключевыми участниками пресейла (продажи, бизнес-аналитики, технические архитекторы) и будущей проектной командой.
• Анализ и утверждение всех документов, созданных на пресейле: коммерческое предложение, предварительные оценки, протоколы встреч с клиентом.
• Создание проекта Устава (Project Charter), который прямо ссылается на эти документы и фиксирует согласованные на пресейле цели, границы и ограничения.

# Пример структуры данных в Уставе проекта, отражающей информацию из пресейла
project_charter = {
    "project_title": "Разработка системы аналитики для клиента X",
    "business_case": "Основано на анализе потребностей, проведенном в пресейле (Doc-ID: PS-2023-045).",
    "high_level_objectives": [
        "Увеличить скорость обработки данных на 40% (цель, согласованная с клиентом на встрече 15.05.2023).",
        "Интеграция с внешними системами A и B (ограничение, выявленное архитектором на пресейле)."
    ],
    "key_assumptions_and_constraints": [
        "Бюджет: не превышать согласованную на пресейле сумму в 500k USD.",
        "Первоначальный состав команды: ключевые разработчики, участвовавшие в техническом диалоге на пресейле."
    ],
    "initial_risks": [
        {"description": "Неполная документация системы B от клиента (риск, озвученный клиентом на пресейле).", "owner": "PM"}
    ]
}

Вывод

Пресейл — это де-факто первая часть инициации проекта. Грамотный IT Project Manager должен активно участвовать в поздних этапах пресейла или, как минимум, формально включить все его результаты в процессы и документы инициации. Это позволяет создать прочный, непротиворечивый фундамент для проекта, избежать "сюрпризов" и обеспечить полное соответствие между ожиданиями клиента, обещаниями компании и планом исполнения проекта. Исключение пресейла из рассмотрения — это управление проектом с пробелами в данных, что в современном сложном IT-мире является прямым риском для его успеха.