Что спрятано за кнопкой «Заказать»
Представим два предложения на разработку сервиса. В обоих есть каталог, личный кабинет и оформление заказа. На встрече показывают похожие экраны. Одно предложение заметно дешевле. Ни одна из этих деталей пока не объясняет разницу.
Откроем всего одну кнопку — «Заказать». Что происходит после нажатия? Система проверяет наличие или отправляет пожелание менеджеру? Цена окончательная или предварительная? Заказ можно отменить? Остаток уменьшается сразу? Клиент узнает об изменении статуса автоматически?
У одного исполнителя за кнопкой может стоять отправка письма. У другого — согласование нескольких систем с проверкой доступности и обработкой ошибок. Оба добросовестно оценили «оформление заказа», только представили разные продукты.
Поэтому первая работа со сметой — восстановить рассказ о действиях человека. Кто приходит, что выбирает, какой результат получает, кто подхватывает процесс внутри компании. Названия экранов полезны для навигации. Для сравнения предложений нужны их обязанности.
Цена неизвестного
Теперь выясняется, что сведения о товарах уже живут в учётной системе. В смете появляется строка «интеграция». Под ней тоже может скрываться разная работа: от настройки готового подключения до самостоятельной разработки обмена с ограничениями и исключениями.
Чтобы оценить её, нужны конкретная система, тариф, доступные способы обмена и состав передаваемых данных. Иногда документация обещает нужный метод, но на практике у заказчика нет необходимого доступа. Иногда данные получить можно, но они обновляются реже, чем требуется продукту.
Такая неизвестность не исчезает от просьбы назвать точную цену. Её можно проверить отдельным коротким этапом: получить тестовые данные, подтвердить права и ограничения, посмотреть на ошибки. Результатом становится решение о способе подключения и более определённый объём разработки.
Полезно спросить исполнителя, на каких предположениях держится оценка и как изменится работа, если они не подтвердятся. Прозрачный ответ здесь ценнее уверенности, которую ничем не проверяли.
В какой момент заканчивается оплаченная работа
Вернёмся к двум предложениям. Допустим, состав функций теперь совпадает. Но одно заканчивается передачей файлов, а другое включает настройку рабочего окружения, проверку основного маршрута и передачу доступа владельцу. Это снова разные результаты.
Проектирование тоже стоит оценивать по тому, что остаётся у заказчика: сценарии, прототип, правила, список зависимостей и план запуска. Эти материалы должны помогать принимать решения и переходить к разработке. Встречи сами по себе таким результатом не являются.
Следующая граница — после запуска. Кто исправляет обнаруженные дефекты, а какие обращения считаются новой работой? Кто обновляет подключение, если внешний сервис меняет правила? Где заканчивается согласованная поддержка? Ответы нужны до того, как возникнет первый спор.
Хостинг, лицензии, использование модели ИИ и другие регулярные расходы показывают отдельно. Они помогают увидеть стоимость владения продуктом после разработки. Наши форматы и ценовые ориентиры — отправная точка для разговора; состав большого приложения всё равно требует отдельной оценки.
Как читать предложения рядом
Положите сметы рядом и для каждой функции задайте одинаковые вопросы: что человек сможет сделать, какие данные нужны, что произойдёт при ошибке и как принимается результат. Там, где ответы расходятся, сравнение одной итоговой суммы теряет смысл.
Отдельно выпишите исключения и зависимости от заказчика. Кто готовит тексты? В каком состоянии данные для переноса? Когда будут доступны внешние системы? Срок «с момента начала работ» мало о чём говорит, если половина необходимых материалов пока не готова.
Критерий приёмки лучше описывать через проверяемое действие. Например: заказ создан, сотрудник его видит, повторное нажатие не создаёт дубль, человек без нужного права не получает доступ. Такой критерий помогает и заказчику, и исполнителю понять границу обещания.
Новые идеи будут появляться. Для каждой полезно увидеть влияние на срок и бюджет, затем выбрать: включить сейчас, заменить менее важную функцию или перенести. Так изменение остаётся решением владельца, а не сюрпризом в очередном счёте.
Что взять на первую встречу
Необязательно приходить с большим техническим заданием. Достаточно описать будущего пользователя, его задачу и сегодняшний процесс. Особенно полезен реальный пример: как сейчас оформляется заказ, где приходится переносить данные вручную, в каком месте возникает ожидание.
Добавьте список работающих систем, желаемую дату первого результата и ориентир бюджета, если он есть. Они помогут обсуждать выполнимый первый этап. Без этих границ легко спроектировать замечательный продукт, который компания пока не собирается оплачивать.
Хороший итог первой встречи — понятный следующий шаг с собственным результатом. Для небольшой задачи это может быть оценка реализации. Для большого сервиса — проектирование перед разработкой, которое снимет наиболее дорогие неизвестности.
После такого разговора две сметы могут остаться разными. Это нормально: у исполнителей отличаются подход, опыт и устройство работы. Зато вы сможете объяснить, за что платите в каждом случае. С этого момента сравнение становится выбором, а не угадыванием.