Как оценить проект, когда требований ещё нет

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

Почему точная цифра без требований — обман

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

Одна и та же фраза «магазин детских товаров» превращается в 100 000 ₽ и в 400 000 ₽ в зависимости от того, сколько там ролей, откуда берутся товары и что происходит после оплаты. Никакой опыт не заменяет этих ответов.

Поэтому нормальный разговор начинается не с «сколько стоит», а с «от чего это зависит у меня».

Шаг 1. Опишите не сайт, а день сотрудника

Возьмите человека, который будет работать с системой чаще всех. Опишите его обычный вторник: что он открывает, куда переносит данные, где ждёт.

Именно отсюда вырастает объём. В проекте ToYou Wood разговор начался с того, что менеджер переносил размеры из письма в смету, потом ту же смету в накладную. Из этого выросли расчёт по размерам, оплата с чеком и печать этикетки — а не из фразы «нужен сайт про мебель».

Напишите такой день на полстраницы. Это уже половина оценки.

Шаг 2. Посчитайте роли

Роль — это человек, который видит не то же самое, что остальные.

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

Три роли вместо одной — это не плюс 20% к цене, а плюс примерно треть, потому что проверять придётся каждый сценарий трижды.

Шаг 3. Перечислите чужие системы

Выпишите всё, что должно обмениваться данными: касса, эквайринг, служба доставки, 1С, CRM, маркетплейс, мессенджер.

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

Пункты без ответа не вычёркивайте. Пусть висят как риск.

Шаг 4. Разделите «надо к запуску» и «хочу потом»

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

Правая колонка не исчезает, она превращается во второй этап. Это единственный честный способ сбить цену вдвое, не потеряв проект.

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

Шаг 5. Попросите вилку и список допущений

Теперь можно спрашивать цену. Ответ должен выглядеть примерно так: диапазон, срок и три-пять строк «оценка верна, если».

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

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

Ориентиры по нашим типам работ простые: лендинг от 40 000 ₽ и 3–5 дней, сайт с админкой от 100 000 ₽ и 7–14 дней, платформа от 150 000 ₽ и от двух недель. Дальше вилка сужается ответами на шаги выше.

Шаг 6. Проверьте оценку одним вопросом

Спросите: «Что здесь может пойти не так и удвоить срок?»

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

Когда оценивать рано

Если вы сами не знаете, будете ли продавать этот продукт через три месяца, оценка не нужна — нужен самый дешёвый способ проверить спрос. Лендинг и таблица закрывают эту задачу за пару дней и за деньги, которые не жалко.

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

Как выглядит нормальный ответ подрядчика

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

Хороший ответ звучит примерно так: «Похоже на сайт с админкой, 120–180 тысяч, 10–14 дней. Верхняя граница, если ролей три и нужна выгрузка в 1С. Нижняя — если роль одна и товары грузите сами. До ответа про кассу я не считаю оплату вообще».

Здесь есть всё нужное: диапазон, срок, названные развилки и честно отмеченная дыра в данных.

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

Ошибка, которая портит оценку чаще всего

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

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

Правило простое: говорите про людей и про данные, а не про экраны. Экраны — работа разработчика.

Что делать с оценкой дальше

Полученную вилку не кладите в стол. Она нужна для трёх решений.

Первое — можно ли вообще заходить в проект. Если верхняя граница вдвое больше вашего бюджета, разговор про дизайн бессмысленен, надо резать объём.

Второе — какой этап делать первым. Из левой колонки со шага 4 выберите то, что снимает больше всего ручной работы. Обычно это не главная страница, а какая-нибудь скучная вкладка вроде импорта товаров.

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

Коротко

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