За что бизнес платит разработчику, кроме кода

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

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

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

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

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

В Mini App для доставки цветов связаны адрес, стоимость доставки, статусы и работа курьеров. При обсуждении похожей системы полезно пройти конкретный пример: адрес исправили после назначения доставки. Кто должен узнать об изменении, что пересчитывается и какое состояние остаётся в истории? Это вопросы для проектирования и приёмки, а не детали, которые стоит молча оставлять программисту.

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

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

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

Разделите устранение дефекта в согласованном сценарии и новый запрос к продукту. Если эту границу не обсудили, любое изменение превращается в спор о гарантии. Удобнее заранее записать несколько примеров: кнопка не сохраняет согласованные данные; понадобился новый тип документа; внешний поставщик изменил API. Для каждого случая понятны ответственный и порядок оценки.

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

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