Как подготовить IT-проект к оценке подрядчиками и получить сопоставимые предложения

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

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

Почему три коммерческих предложения могут оценивать три разных проекта

Разброс цен и сроков редко объясняется только «дорогой» или «дешёвой» командой. Чаще подрядчики молча принимают разные допущения.

Один включает интеграцию как полноценный обмен данными, другой — выгрузку отчёта раз в сутки. Один закладывает миграцию истории, другой считает, что старт идёт с чистого листа. Один пишет срок на пилот для двух ролей, другой — на запуск для всей организации. В КП это может выглядеть одинаково: «разработка», «интеграция», «запуск».

Расхождение усиливается, когда в запросе смешаны цель, пожелание к решению и список функций. Подрядчик угадывает приоритет: кто-то оценивает узкий сценарий, кто-то — «правильную» платформу на будущее. Сравнивать такие ответы по итоговой сумме бессмысленно — это разные проекты.

До запроса оценки полезно отделить три слоя: бизнес-результат; объём первой рабочей версии; то, что сознательно остаётся за рамками. Без этого сравнение превращается в спор о цифрах без общей основы.

Что должно быть определено до запроса оценки

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

Цель и критерий результата. Что изменится после первой версии: какой процесс станет управляемее, какая ручная работа уйдёт, какой отчёт станет доступен. Формулировка «сделать удобную систему» почти бесполезна. Лучше наблюдаемый результат: «руководитель видит сводку по заявкам без ручной сборки» или «оператор закрывает сценарий без перехода в смежную систему».

Ключевые роли и сценарии. Кто работает в первой версии и какие 5–10 действий обязательны. Это ограничивает объём лучше списка экранов. Если ролей много — явно сказать, какие входят сейчас.

Границы первой версии. Что входит и что нет. Особенно полезны исключения: без мобильного приложения, без кабинета клиента, без миграции архива, без двусторонней синхронизации справочников. Исключения снижают разброс оценок сильнее дополнительных пожеланий.

Интеграции на уровне смысла. Какие системы затрагиваются и зачем: какие данные, в какую сторону, с какой периодичностью, кто источник истины. Достаточно направлений и бизнес-ожиданий, не схемы API.

Ограничения среды. Окно запуска, размещение, регламенты, доступность внутренних специалистов. Это не детали реализации, но влияет на состав работ и календарь.

Формат ответа. Попросите одну структуру: объём, этапы, сроки, команда, допущения, исключения, что не входит в цену. Иначе каждый ответит в своём шаблоне.

Если внутри нет практики регулярного заказа разработки, этот минимум удобнее собрать через подготовку IT-проекта к оценке: зафиксировать первую версию и единый бриф до рассылки.

Что не нужно детализировать заранее

Желание «сначала всё описать» понятно, но избыточная детализация до оценки замедляет старт и почти не улучшает сопоставимость смет.

Не обязательно заранее проектировать архитектуру, модель данных, UX всех экранов и ТЗ на десятки страниц. Для сопоставимых первых оценок обычно достаточно предмета работ и ограничений; детальная архитектура на этом шаге чаще не нужна. В отдельных проектах — при высокой сложности или заметных технических рисках — до выбора подрядчика может понадобиться отдельная техническая, архитектурная или security-экспертиза. Это не универсальное правило, а вопрос конкретного проекта; такая экспертиза не заменяет подготовку предмета оценки.

Не нужно описывать все будущие версии. Коротко обозначьте направление развития, чтобы временное ограничение не приняли за отказ от функциональности. Оценивать имеет смысл первую рабочую версию.

Не стоит требовать понедельной точности до прояснения объёма. Сначала нужна рамка: что делается, что исключено, какие допущения. Уточнение сроков идёт уже на этой основе.

Не подменяйте подготовку длинным списком «хотелок» без приоритетов — каждый подрядчик выберет свой центр тяжести.

Как оформить материал для подрядчиков

Материал должен читаться как рабочий бриф, а не как презентация идеи и не как договор.

Удобная структура:

1. Контекст и зачем запускается проект.
2. Результат первой версии в бизнес-терминах.
3. Роли и ключевые сценарии.
4. Что входит / что не входит.
5. Интеграции и источники данных.
6. Ограничения и известные риски.
7. Что ожидается в коммерческом предложении.

Текст — короткий и однозначный. Спорные места называйте прямо: «не определено, нужны варианты» или «достаточно односторонней выгрузки». Неопределённость всё равно останется; важно, чтобы она была общей для всех.

Полезно приложить фрагмент регламента, образец отчёта, схему текущего процесса — это снижает фантазию сильнее общих формулировок. Пометьте статус: утверждено, гипотеза или пример «как есть».

Один пакет — всем кандидатам. Устные уточнения одному без фиксации в общем материале снова делают оценки несопоставимыми.

Как понять, что проект уже можно отдавать на оценку

Чеклист перед рассылкой:

• Есть формулировка результата первой версии, понятная бизнесу и ИТ-заказчику.
• Перечислены роли и ограниченный набор сценариев, без которых запуск не имеет смысла.
• Явно сказано, что не входит в первую версию.
• Интеграции описаны как направления и смысл обмена, а не «нужно интегрироваться».
• Зафиксированы ограничения: сроки, размещение, доступность своих специалистов.
• Критические разногласия между подразделениями выявлены и вынесены в открытые вопросы.
• Подготовлена единая структура ответа для подрядчиков.
• Есть человек на стороне заказчика, который отвечает на уточнения в одном контуре.

Если по двум-трём пунктам ответа нет, оценка разъедется. Дешевле сначала сузить предмет. Это видно на примере сокращения объёма интеграции: после уточнения потребности оценочный объём сократился примерно с 1,5 млн до 350 тыс. ₽ — не за счёт скидки, а за счёт точной постановки задачи.

Что происходит, если сначала запросить цену, а потом уточнять задачу

Типичный путь: срочно нужны ориентиры, письмо уходит «в общих чертах», приходят разные суммы, начинается уточнение. Каждый ответ меняет объём только у того, кому задали вопрос. Через две недели на столе не три предложения, а три ветки переговоров.

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

Второй эффект: подрядчики оценивают неопределённость. В смету — запас, в срок — буфер, в договор — широкие оговорки. Заказчик платит за туманность постановки ещё до разработки.

Подготовка не снимает все риски. Она меняет сам акт сравнения: вы смотрите на разные способы выполнить одну работу, а не на разные работы под одним названием.

Если перед рассылкой нужно зафиксировать объём первой версии и единый бриф, можно начать с короткого обсуждения через контакты. Обычно этого достаточно, чтобы понять, готова ли постановка к оценке или её ещё стоит сузить.