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