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