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