Как клиент оплачивает пресейл?

Отличный и очень практичный вопрос, который затрагивает важнейший аспект границы между коммерцией и проектным управлением. Как IT Project Manager (PM), я должен чётко понимать эти механизмы, так как от них зависит финансирование проекта, с которым я буду работать, и легитимность старта работ.

Короткий ответ: Клиент оплачивает пресейл (presale) на основании договора об оказании услуг/договора на пресейл или как часть аванса/первого платежа по основному договору, если пресейл формально является нулевой (или подготовительной) фазой проекта. Конкретная модель зависит от политики компании, сложности работ и отношений с клиентом.

Давайте разберем это подробно, так как для PM понимание процесса финансирования пресейла критически важно для планирования и управления рисками.

Основные модели оплаты пресейла

На практике я сталкивался со следующими схемами:

1. Отдельный договор на консультационные/аналитические услуги.

    *   **Суть:** Пресейл оформляется как самостоятельный проект с ограниченным scope, бюджетом и сроками. Это самый чистый и прозрачный вариант.
    *   **Что входит (пример scope):** Проведение интервью, анализ "как есть", формирование требований (Requirements Gathering), создание **Teсhnical Proposal**, **Feasibility Study** или прототипа.
    *   **Финансирование:** Фиксированная цена или Time & Materials (T&M) с еженедельным/ежемесячным биллингом. Клиент получает конкретный документированный результат.
    *   **Роль PM:** Часто в таком пресейле PM либо уже назначен, либо работу ведут бизнес-аналитики и архитекторы под управлением менеджера по продажам или выделенного пресейл-менеджера. PM может быть привлечен как консультант.

1. Пресейл как часть коммерческого предложения (бесплатный для клиента).

    *   **Суть:** Компания инвестирует свои ресурсы в надежде выиграть tender или получить крупный проект. Это стандартная практика для конкурсных процедур.
    *   **Финансирование:** Затраты покрываются из маркетингового бюджета или **пресейльного бюджета** отдела продаж. Клиент не платит напрямую.
    *   **Роль PM:** На этой стадии проектный менеджер обычно не вовлечен глубоко. Его могут попросить оценить риски или сроки на основе готового предложения. Основная работа ведется **пресейл-инженерами и архитекторами**.

1. Пресейл как нулевая фаза (Phase 0) основного договора.

    *   **Суть:** Это самая тесная связь с последующим проектом. Компания и клиент подписывают **основной договор** с постадийной (итерационной) оплатой. Первый этап — это и есть пресейл, результат которого — детализированный **Project Charter**, **Roadmap** и спецификации для следующих фаз.
    *   **Финансирование:** Клиент оплачивает **авансовый платёж** или первый инвойс, который покрывает работу Phase 0. Это снижает риски исполнителя и демонстрирует серьезность намерений клиента.
    *   **Роль PM:** В этой модели PM **назначается с первого дня**, его ключевая задача — успешно провести Phase 0, согласовать с клиентом все базовые документы и план, чтобы получить "go-ahead" и финансирование на следующую фазу. Это идеальная с точки зрения управления модель.

1. Гибридная модель с последующим зачётом.

    *   **Суть:** Часть пресейльных работ (например, первичный анализ) проводится бесплатно. Но глубинная проработка архитектуры или создание Proof of Concept (PoC) оплачивается либо по отдельному договору, либо с условием, что если проект будет подписан, эта сумма зачтется в счет первого платежа.
    *   **Роль PM:** PM включается на этапе обсуждения условий зачёта и оценки трудоёмкости PoC, так как его задача — планирование бюджета основного проекта.

Процесс оплаты с точки зрения PM: что должно быть на моём радаре

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

# Checklist для PM при приёмке проекта после пресейла
1.  Юридическая основа:
    - Есть ли подписанный договор/доп.соглашение на пресейл?
    - Какой тип оплаты был использован (фикс, T&M)?
    - Инвойсы выставлены и оплачены?

2.  Финансовая ясность:
    - Были ли затраты на пресейл (часы команды)? # Это важно для рентабельности проекта
    - Заложены ли они в бюджет основной фазы или списаны?
    - Чётко ли разделены часы "пресейл" и "проект" в тайм-трекинге?

3.  Управленческие артефакты:
    - Получены ли мне все выходные документы пресейла (ТЗ, прототипы, согласования)?
    - Ясны ли "серые зоны" и допущения, сделанные в пресейле?
    - Зафиксированы ли в коммерческом предложении все обязательства?

Риски, которые я, как PM, должен минимизировать

• Размытие границ: Самая частая проблема — когда работы, начатые в пресейле "на доверии", продолжаются без формального разрешения и оплаты. Мое правило: никаких работ без утверждённого сторонами документа (SOW, Change Request) и финансирования.
• Нереалистичные ожидания: Пресейл-команда (часто мотивированная на продажу) могла пообещать "золотые горы". Моя задача — ещё на стадии Kick-off Meeting аккуратно перепроверить и задокументировать все expectations, сверив их с техническим возможностями и бюджетом.
• Неучтенные часы: Если пресейл был частично бесплатным, команда могла уже потратить много неформального времени. Я должен это знать, чтобы корректно оценивать остаток ресурсов.

Вывод для IT Project Manager: Пресейл — это фундамент будущего проекта. Модель его оплаты определяет, насколько этот фундамент прочен, документально оформлен и финансирован. Моя задача — не только разобраться в этой модели, но и обеспечить плавный, управляемый переход от пресейльной активности к полноценному проектному исполнению, чётко отделив коммерческие гипотезы от проектных обязательств. Наиболее здоровой и управляемой я считаю модель «Пресейл как Phase 0», где PM вовлечён с самого начала, а клиент разделяет риски, инвестируя в совместное планирование.