Одна из частых причин проблем на проекте появляется еще до его старта — на пресейле.

Не в разработке. Не в аналитике. Не в управлении сроками.

А в моменте, когда проект еще только оценивают.

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

Первая — диагональная оценка.

Это когда проект оценивают крупными мазками: «тут примерно 200 часов аналитики», «тут около 400 часов разработки», «тестирование возьмем коэффициентом», «риски заложим сверху».

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

Вторая ошибка — оценка проекта одним человеком.

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

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

Третья ошибка — слабая передача проекта из пресейла в delivery.

Бюджет согласован, договор ушел в работу, команда назначена — и дальше проектный отдел начинает заново собирать контекст: Что обещали заказчику? Какие ограничения проговаривали? Какие риски уже были известны? Какие допущения заложены в оценку? Что не вошло в объем работ? Где граница между базовым scope и потенциальными change request?

Если эта информация не передана системно, проект стартует не с нуля, а с минуса.

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

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

Хороший пресейл — это не просто выигранная сделка.

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

А у вас было такое, что проект начинался с фразы: «А кто вообще это оценивал?»