Оценка IT-проекта без ТЗ: как рассчитать стоимость разработки

Предприниматели и руководители регулярно сталкиваются с ситуацией: продукт нужен, общее видение есть, а формализованного описания проекта нет.

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

Как разорвать этот круг? Рассказываем о трёх работающих методиках, которые позволяют оценить проект с точностью достаточной, чтобы принять взвешенное решение. Разберем их все и покажем, как аутстаффинг помогает не переплачивать за неизвестность.

Метод 1: Оценка по MVP

MVP (Minimum Viable Product) — это самая простая версия продукта, которая решает основную задачу клиента. Оценка по MVP — это способ оценить проект без детального ТЗ, когда рассчитывается стоимость не всей системы целиком, а её минимальной рабочей версии. Такой подход позволяет быстро определить бюджет и сроки первого запуска, а затем развивать продукт на основе реальных потребностей пользователей и данных рынка.

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

Точно оставляем:

• каталог букетов;
• карточку товара с фото и описанием;
• форму заказа, кнопку «Перезвоните мне»;
• уведомление менеджеру о новой заявке.

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

Убираем:

• онлайн-оплату;
• корзину;
• личный кабинет;
• программу лояльности;
• отзывы;
• историю заказов;
• конструктор букетов;
• мобильное приложение.

Всё это, несомненно, полезно, однако не критично для жизнеспособности бизнеса.

• 80% клиентов звонят по телефону, а форму заказа почти никто не использует (вместо доработки сайта лучше вложиться в колл-центр);
• клиенты просят приложить открытку к букету (хорошо бы оформить раздел сопутствующих товаров);
• многие клиенты заказывают по нескольку раз (можно задуматься над системой лояльности, чтобы процент повторных заказов увеличился);
• или что самая популярная услуга — срочная доставка, а не сбор индивидуального букета (умнее вложиться в логистику, чем разрабатывать сложный конструктор).

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

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

Гайд “Как организовать разработку IT продукта с привлечением внешней команды”

Получить гайд

Метод 2: Сравнительный анализ

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

Специалисты изучают функционал, определяют примерный объём работ и на основе своего опыта рассчитывают стоимость разработки аналогичного решения.

Сравнительный анализ не дает точной цифры. Зато он дает реалистичный диапазон, внутри которого имеет смысл планировать бюджет.

Однако есть важный момент — невозможно узнать, сколько именно стоила разработка чужого проекта. Разработчик не может просто взглянуть на форму и сказать “это стоило 10 000 ₽”. Но разработчик может прикинуть, что ему на реализацию подобного функционала потребуется примерно 4 часа.

Как же узнать примерную стоимость проекта без ТЗ?

1. Из опыта команды

Это самый распространённый способ; ведь если агентство уже делало 5 интернет-магазинов, оно примерно понимает:

• сколько времени занимает каталог;
• сколько стоит интеграция оплаты;
• сколько часов уходит на личный кабинет.

Поэтому новые проекты сравниваются с уже реализованными.

2. Из кейсов агентств

Некоторые IT-студии публикуют кейсы с бюджетами. Например, «Разработали маркетплейс за 5.000.000₽» или «Создали мобильное приложение за 2.100.000₽».

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

3. Через общение с владельцами похожих проектов

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

4. Через анализ бирж и тендерных площадок

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

Это не идеальный источник, но он помогает понять рынок.

Важное замечание: даже если вы узнаете, что конкурент потратил ровно 674 356 ₽ на разработку, это почти ничего не гарантирует. Ведь цены зависят от размера агентства, от количества функций и интеграций, требований к нагрузке и безопасности…

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

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

Метод 3: Четыре параметра сложности

Даже без точного списка функций опытная команда может примерно оценить проект по четырём параметрам:

Кто будет пользоваться? Если только покупатель — это несложно. Другое дело, если пользоваться приложением нужно будет ещё и менеджеру, администратору, другим сотрудникам. Для каждого нужно будет задавать права доступа.

Сколько людей будут пользоваться? Требования к нагрузке будут разительно отличаться для сайта на 10 заявок в день и на 10 тысяч за счёт кэширования, отказоустойчивости, очередей.

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

Сколько внешних сервисов надо подключать? Telegram для сбора заявок, платёжная система, CRM — для каждой интеграции нужно изучить документацию, настроить обмен данными, всё протестировать и отладить.

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

Как зафиксировать рамки проекта без технического задания

Чтобы оценка IT-проекта без спецификации была корректной, а старт разработки — быстрым, используется минимальный набор документов:

Карта пользовательских сценариев (CJM). Иными словами — что должен сделать пользователь. Документ с описанием ключевых действий: вход, основные операции, получение результата.

Список интеграций. То есть, какие внешние сервисы надо подключить. Перечень с пометкой «обязательно / желательно».

Референсы. Всё, что нравится визуально. Скриншоты или ссылки на существующие продукты, которые иллюстрируют ожидаемый уровень дизайна и интерфейса.

Этого набора достаточно для того же MVP, чтобы команда дала бюджет IT-проекта на ближайший этап и приступила к работе. Детализация происходит параллельно с разработкой, когда появляются реальные данные для обсуждения.

Почему проекты без ТЗ часто запускают через гибкую разработку

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

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

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

В таких случаях часто используют внешнюю команду или аутстаффинг. Вместо покупки готового результата заказчик получает выделенных специалистов и определяет приоритеты по мере развития продукта. Большой плюс в том, что внешнюю команду можно привлечь быстро и ограничить ее работу временными рамками. Сделать MVP и далее принимать решение, продолжать ли разработку полновесного продукта, в каком направлении и формате.

Например, владелец цветочного магазина планирует запустить сайт с каталогом и формой заказа. На старте кажется, что этого достаточно. Через несколько недель может выясниться, что клиентам нужна интеграция с CRM, уведомления в Telegram или личный кабинет для менеджеров. В модели аутстаффинга команда просто переключается на актуальные задачи без пересогласования всей сметы проекта.

Такой подход особенно полезен, когда:

• требования ещё формируются;
• продукт создаётся впервые, и нет готовой спецификации;
• важно быстро выпустить первую версию и собрать обратную связь пользователей;
• список функций может существенно измениться после запуска.

При этом аутстаффинг не отменяет необходимость предварительной оценки. Обычно команда определяет бюджет ближайшего этапа на 1–3 месяца, запускает разработку и уточняет дальнейший план по мере появления новых данных о продукте и потребностях пользователей.

Практические рекомендации: что сделать прямо сейчас

Подготовьте ответы на пять вопросов перед созвоном с потенциальным IT-подрядчиком.

1. Кто конечный пользователь?

   • внешние клиенты (B2C),
   • корпоративные партнеры (B2B),
   • ваши сотрудники (если разрабатываете внутренний инструмент).

2. Где происходит взаимодействие?

   • веб-сайт,
   • мобильное приложение,
   • десктопная программа,
   • чат-бот.

3. Какой ключевой сценарий выполняет пользователь?

   • главное действие пользователя одной фразой;
   • пример: «Пользователь выбирает в каталоге букет и оформляет заказ».

4. Кто ваши ориентиры?

   • две-три ссылки на конкурентов или референсы;
   • укажите, что нравится, а что сделали бы иначе.

5. Есть ли технологические ограничения?

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

Ответили хотя бы на три вопроса?

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

Вместо заключения

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

Ключевое решение, влияющее на бюджет — выбор модели сотрудничества. Цена разработки IT продукта без ТЗ всегда содержит наценку за риск неизвестности. Аутстаффинговая модель устраняет эту наценку: заказчик платит за время работы специалистов и управляет приоритетами без посредников.

Компания IQ Dev предоставляет выделенные команды разработки для проектов с неполными требованиями. Специалисты включаются в работу за считанные дни. Менеджер помогает провести оценку по одному или нескольким описанным методам до начала сотрудничества.