После демонстрации от подрядчика всё выглядит гладко, но при приёмке вдруг обнаруживается: вход иногда не срабатывает, callback платежа не проходит, данные в админке не сходятся — такие переделки выматывают больше всего. Приёмка на аутсорсинге по разработке приложений по сути не «взглянуть, что всё запускается», а поочерёдное согласование трёх вещей: требований, качества и результатов поставки. Ниже — по порядку, как это сделать на практике.
1. Сначала проверьте список требований, не принимайте «на ощущениях»
Первый документ для приёмки — не установочный пакет, а документ с требованиями и список функций. Многие переделки возникают из-за того, что изначально не было прописано: кто пользуется, в каком сценарии, как показывать ошибки.
Рекомендации:
- Разбейте требования на пункты с чекбоксами, в каждом укажите «ввод — действие — ожидаемый результат», например: «Вход по номеру телефона: ввод незарегистрированного номера — показать сообщение о том, что номер не зарегистрирован, и предложить регистрацию».
- Отметьте приоритеты: ключевые сценарии (регистрация и вход, оформление и оплата заказа, основные бизнес-операции) должны проходить на 100%, второстепенные функции можно вынести в список доработок.
- При приёмке отмечайте пункты по одному, фиксируйте скриншоты или запись экрана, чтобы не было устных «это не работает» без доказательств.
Подводный камень: не используйте «это не то, что я представлял» как критерий приёмки. Детали интерфейса можно поправить, но отсутствующие функции и ошибки в данных должны быть внесены в лист доработок с указанием ответственного и сроков.
2. Тестирование на реальных устройствах должно охватывать модели и исключительные сценарии
То, что работает на эмуляторе, не значит, что работает на реальном устройстве. Самая частая переделка в разработке приложений: на телефоне определённого бренда приложение вылетает, при слабой сети — белый экран, после отказа в разрешении процесс зависает.
Как делать:
- Охватите минимум по 2–3 реальных устройства на iOS и Android, включая одну модель с низкими характеристиками.
- В первую очередь тестируйте исключения: отключение сети, переход в фон и возврат, прерывание входящим звонком, отказ в разрешении, повторное нажатие на отправку.
- Модули, зависящие от системных возможностей — оплата, push-уведомления, геолокация, камера — обязательно проверяйте на каждом реальном устройстве.
- Фиксируйте логи падений и шаги воспроизведения как основание для доработок.
Подводный камень: тестировать только «нормальный путь» — главная ошибка при приёмке. Именно исключительные сценарии пользователи встречают в реальности, и именно они дают самые высокие затраты на поддержку в будущем.
3. API, бэкенд и данные нужно проверять вместе
Приложение — только фронтенд. Откуда берутся данные и куда сохраняются — это определяет, сможет ли система работать долго. Во многих проектах фронтенд красивый, а в админке данные не находятся, экспорт выдаёт кракозябры, права доступа запутаны.
На что обратить внимание при приёмке:
- Стабильны ли API, есть ли в приложении запасные сообщения при повторных запросах, тайм-аутах и ошибках ответа.
- Работают ли в админке создание, чтение, изменение и удаление, разграничение прав, экспорт данных.
- Прослеживаемы ли ключевые данные, например, есть ли история изменения статуса заказа.
- Если задействована разработка мини-программ или разработка сайтов с общей админкой, убедитесь в согласованности данных между платформами.
Подводный камень: не смотрите только на интерфейс приложения. Админка — повседневный инструмент операционной работы; при приёмке дайте реальным пользователям поработать с ней — это убедительнее технической демонстрации.
4. Код, документация и аккаунты должны быть переданы полностью
Переделки часто возникают при «смене исполнителя». Код не у вас, аккаунты сервера у подрядчика, документации по развёртыванию нет — и каждая следующая правка требует новых переговоров о деньгах.
Список передачи рекомендуется прописать в договоре:
- Полный исходный код и инструкция по сборке, чтобы проект запускался в чистой среде.
- Документация по API, описание структуры базы данных, инструкция по настройке сторонних сервисов.
- Права администратора на сервер, домен, магазины приложений, платёжные сервисы, push-уведомления и т. п.
- История версий и список известных проблем.
Подводный камень: ещё до приёмки сделайте «список результатов поставки» условием этапа оплаты. Код на вашем аккаунте с возможностью передачи прав надёжнее устных обещаний.
5. Запуск и период поддержки нужно оговорить заранее
Запуск — не финиш. Проверка в магазинах приложений, истечение сертификатов, проблемы совместимости из-за обновлений системы — всё это появится после передачи.
Рекомендуется уточнить:
- Кто отвечает за подачу на публикацию и кто исправляет при отказе в проверке.
- Какова длительность бесплатной поддержки после передачи и что в неё входит (исправление падений, проблемы совместимости).
- Как рассчитывается стоимость новых требований, чтобы «мелкие правки» не превратились в бездонную бочку.
Конкретный пример: одна компания делала приложение для записи на приём. При приёмке все функции прошли, но после запуска выяснилось, что на старых версиях Android выбор даты смещён и пользователь не может выбрать время. Если бы на этапе приёмки провели тестирование на реальном устройстве с низкими характеристиками, эта проблема выявилась бы заранее.
В каких случаях стоит обратиться в MIC Studio
Если вы находитесь на одном из этих этапов, можно рассмотреть привлечение MIC Studio: требования ещё не окончательно сформированы и нужен кто-то, кто поможет разбить их на список; есть существующее приложение или корпоративный сайт, которые нужно переделать или подключить к бэкенду; перед запуском нужно провести раунд тестирования безопасности или обратного тестирования, чтобы убедиться в отсутствии очевидных уязвимостей в API и данных; или в команде не хватает людей, и требуется помощь в разработке скриптов, разработке сайтов, разработке мини-программ и т. п. Мы предпочитаем сначала чётко договориться о критериях приёмки и результатах поставки, а затем приступать к работе — это снижает переделки на поздних этапах.
Три практические рекомендации в заключение
1. До приёмки получите список функций и список результатов поставки, отмечайте пункты по одному, проблемы вносите в лист доработок с указанием сроков.
2. Тестирование на реальных устройствах должно охватывать модели с низкими характеристиками и исключительные сценарии; оплату, push-уведомления и разрешения проверяйте по отдельности.
3. Пропишите в договоре исходный код, документацию, права на аккаунты и объём бесплатной поддержки как условие этапа оплаты.