Можно ли сделать чтобы оценка с пресейла была такая же как и после составления ТЗ?

Можно ли сделать оценку с пресейла такой же, как после составления ТЗ?

Нет, сделать оценку с пресейла точно такой же, как после составления ТЗ (Технического задания) — невозможно. Это две разные точки на проектной оси с принципиально разным уровнем детализации и доступной информации. Цель пресейла и пост-ТЗ оценки — разные, и они решают разные задачи. Однако, можно систематически улучшать процесс, чтобы оценки на разных стадиях были максимально консистентными, а разница — управляемой и понятной.

1. Почему оценки всегда будут разными?

Разница неизбежна из-за фундаментальных различий в входных данных:

• Пресейл (Pre-Sales): Базируется на предварительных требованиях, часто в форме общих бизнес-целей, презентаций, высокоуровневых обсуждений. Информация ограничена, много допущений (assumptions). Задача здесь — дать клиенту предварительную картину стоимости и сроков для принятия решения о старте проекта, а не построить детальный план.
• После ТЗ: Работа начинается с детального, формализованного документа, который описывает функциональность, технические решения, интеграции, ограничения. В процесс вовлечена вся команда (разработчики, архитекторы, тестировщики). Это оценка для внутреннего планирования и исполнения.

Наглядный пример в виде блоков кода:

# Пример высокоуровневого требования на пресейле
presale_requirement = {
    "goal": "Создать мобильное приложение для онлайн-заказа еды",
    "platforms": ["iOS", "Android"],
    "key_features": ["Каталог", "Оформление заказа", "Профиль пользователя"]
}

# Пример детального требования после ТЗ
tz_requirement = {
    "feature": "Оформление заказа",
    "subtasks": [
        "Разработка UI экрана корзины (3 экрана)",
        "Интеграция с платежным гейтом (2 API, обработка 5 статусов)",
        "Логика расчета стоимости (с учетом скидок, налогов, доставки)",
        "Реализация уведомлений (email, push)",
        "Написание unit-тестов (30 сценариев)"
    ],
    "tech_stack": ["React Native", "Node.js", "PostgreSQL"],
    "dependencies": ["Каталог", "Профиль пользователя"]
}

2. Цели и допущения на разных этапах

Цель пресейл-оценки:

• Быстро ответить на вопрос клиента: "Какова ориентировочная стоимость и сроки?"
• Сформулировать коммерческое предложение.
• Зафиксировать базовые рамки проекта (scope) и начать диалог.
• Ключевые допущения: Используются исторические данные (historical data), аналоги (analogues), грубые метрики (например, "средняя стоимость разработки модуля").

Цель пост-ТЗ оценки:

• Создать детальный план проекта (project plan) для исполнения: backlog, списания ресурсов.
• Определить конкретные задачи для команды.
• Выявить все технические риски и зависимости.
• Допущения минимизируются: Каждая задача разбивается, оценивается специалистами.

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

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

1. Использовать диапазоны и типы оценок:

    *   На пресейле давать оценку в виде **диапазона** (например, 100-150 тыс. USD) или указывать уровень точности: "Эскизная (Ballpark)", "Предварительная (Preliminary)".
    *   После ТЗ давать **детальную (Detailed)** оценку.

# Уровни точности оценки (в терминах PMI)
Ballpark Estimate -> ±50% погрешность (пресейл)
Preliminary Estimate -> ±25% погрешность (после уточнения)
Detailed Estimate -> ±10% погрешность (после ТЗ)

1. Формализовать процесс сбора требований: Использовать стандартные опросники, workshops уже на пресейле, чтобы собрать больше деталей.
2. Применять эталонные метрики и нормативы: Внутренняя база данных о средней скорости разработки (velocity), стоимости стандартных модулей (например, "стоимость интеграции с 1 внешним API").
3. Вести историю и анализировать отклонения: После каждого проекта анализировать разницу между пресейл и пост-ТЗ оценкой. Это дает коэффициент коррекции для будущих пресейлов.

-- Пример аналитической таблицы для отслеживания отклонений
CREATE TABLE estimate_history (
    project_id INT,
    presale_estimate DECIMAL,
    tz_estimate DECIMAL,
    deviation_percentage DECIMAL,
    root_cause VARCHAR(255) -- 'Новые требования', 'Неучтенные интеграции', etc.
);

1. Четко документировать допущения на пресейле: Все предположения (We assume that...) должны быть явно перечислены в коммерческом предложении и контракте. Это создает основание для пересмотра оценки при их изменении.
2. Использовать гибкие контрактные модели: Если оценка на пресейле сильно неопределенна, предлагать клиенту модели Time & Materials или фиксированный бюджет за этап (Phase-Based Fixed Price) вместо полного Fixed Price за весь проект.

4. Практический вывод для IT Project Manager

Стремление к абсолютной точности на пресейле — контрпродуктивно. Вместо этого следует:

• Принимать разницу как норму и объяснять ее клиенту как естественный результат процесса детализации.
• Сфокусироваться на управлении этой разницей: сделать процесс оценок прозрачным, а допущения — управляемыми.
• Коммуницировать риски: явно указывать в контракте, что оценка после ТЗ может отличаться, и предусматривать процедуры согласования изменений (change control process).

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