До разработки приложения проверьте устройство, прошивку, SDK и доступные данные на реальном образце. Затем спроектируйте подключение, синхронизацию, работу в фоне и понятные состояния при сбоях — вместе с полезным для человека сценарием.
Пользователь покупает носимое устройство ради результата: увидеть изменения, получить понятную обратную связь или сделать привычку удобнее. Датчики, мобильное приложение и аналитика должны вместе поддерживать этот сценарий. Разработка отдельных красивых экранов ещё не подтверждает, что продукт работает.
Определите полезное действие
Начните с вопроса: что человек сможет сделать после получения данных? График за день — форма представления. Польза появляется, когда понятно, зачем к нему возвращаться, как его читать и где заканчиваются возможности интерпретации.
Опишите один полный путь: распаковать устройство, подключить к телефону, получить первые данные, понять результат, вернуться завтра. Для каждого шага зафиксируйте ожидаемое состояние и препятствия. Если основной сценарий не требует собственного устройства, стоит отдельно проверить, оправданы ли аппаратная разработка и её сопровождение.
До обещаний по аналитике разделите три вещи: то, что измеряет датчик; то, что рассчитывает алгоритм; то, что сообщает интерфейс. Между ними нужны понятные правила. Нельзя незаметно превращать оценку приложения в установленный факт о человеке.
- 01Физический образец. Снять реальные данные и проверить SDK.
- 02Передача. Телефон и сервер переживают обрыв и повторную синхронизацию.
- 03Польза. Объяснение опирается на полученные данные и их ограничения.
Схематический цикл. Пунктиром показан возврат человека к следующему использованию, а не канал передачи измерений.
Сначала устройство и SDK
Запросите у поставщика работающий образец, версию прошивки, описание протокола и SDK для целевых платформ. Узнайте, какие данные реально доступны приложению, с какой детализацией и задержкой. Таблица в презентации поставщика не заменяет чтение данных с физического устройства.
Первый технический результат — воспроизводимый стенд: телефон подключается, читает нужные данные, переживает отключение и подключается снова. Зафиксируйте модели устройств и версии программ. Если поставщик меняет прошивку, команда должна понимать, как обнаружить изменения формата и проверить совместимость.
- Можно ли получить исторические данные после отсутствия телефона?
- Как определяется время измерения и что происходит при смене часового пояса?
- Есть ли признак качества или недостоверного измерения?
- Как устройство различает пользователей и сбрасывается перед передачей другому владельцу?
- Как обновляется прошивка и что происходит при прерывании обновления?
- t₀–t₂Измерения. События возникают на устройстве до загрузки.
- ПакетСинхронизация. История может прийти позже одним набором.
- ПропускОтдельное состояние. Снятое устройство, разрядка и ожидание синхронизации различаются.
Временные отметки условные; интервалы на схеме не имеют численного масштаба.
Спроектируйте синхронизацию до графиков
Данные проходят несколько систем: память устройства, телефон, сервер, расчёты и интерфейс. На каждом переходе возможны задержка, повтор или частичная передача. Нужен способ отличить новый пакет от уже обработанного и продолжить загрузку после обрыва.
Храните время самого измерения отдельно от времени получения сервером. Для дневных отчётов договоритесь, к какому дню относится запись при поездке или смене часового пояса. Укажите происхождение данных и версию алгоритма: иначе изменение формулы будет выглядеть как внезапное изменение состояния пользователя.
Не заменяйте отсутствие измерения нулём. Нулевая активность, снятое устройство, разряженная батарея и ещё не законченная синхронизация означают разные вещи. Интерфейс должен показывать эти различия и объяснять, когда стоит подождать, подключить устройство или повторить действие.
Проверьте жизнь приложения в фоне
Связь не заканчивается первым успешным подключением. Человек блокирует экран, уходит без телефона, отключает Bluetooth и выдаёт не все разрешения. Операционная система может остановить процесс. Эти состояния входят в основной продукт, даже если демонстрация проходит только с открытым приложением.
На Android выбор механизма фоновой связи зависит от сценария и жизненного цикла процесса. В официальном руководстве отдельно рассматриваются поиск устройства, соединение и поддержание связи; для ряда сценариев предлагаются разные механизмы. Поэтому поведение необходимо проверять на целевых телефонах, а не выводить из одного успешного опыта.
Составьте матрицу: первое подключение, повторное подключение, сутки без телефона, разрядка, перезапуск телефона, переустановка приложения. Добавьте смену аккаунта и два устройства рядом. Проверяйте сохранность истории и отсутствие смешивания данных между пользователями.
AI подключайте к проверенным данным
Если продукт объясняет показатели с помощью AI, задайте контракт ответа: какие данные используются, какой период охвачен, где есть пропуски и что можно заключить. Модель не должна придумывать измерения, скрывать неопределённость или объяснять причину изменения, которой нет в исходных данных.
Проверяйте объяснение вместе с числами, на которых оно основано. Для каждого тестового дня подготовьте ожидаемые факты и недопустимые утверждения. Отдельно проверьте почти пустую историю, конфликт источников и повторную загрузку одного периода. Полезное объяснение помогает читать данные и сохраняет границу между наблюдением и предположением.
Что считать готовностью к пилоту
Для пилота нужны работающий пользовательский путь, список поддерживаемых устройств, диагностика подключения и способ восстановить данные после сбоя. Команда поддержки должна видеть достаточно, чтобы помочь, без избыточного доступа к личной информации. Удаление аккаунта и привязки устройства тоже нужно пройти до массового запуска.
В экономику входят устройство, доставка, замена брака, поддержка, мобильная разработка, сервер и AI. Отдельно оцените зависимость от поставщика: доступ к прошивке, обновлениям и запасным партиям. Эти вопросы определяют жизнеспособность продукта не меньше, чем дизайн приложения.
Что показать на техническом просмотре
Попросите команду пройти один день устройства: снять измерения, разорвать связь, восстановить её и открыть отчёт. Сравните время и количество записей на всех этапах. Покажите, что приложение делает с пакетом, который пришёл повторно, и с днём, за который данных недостаточно.
Такой просмотр связывает прошивку, сервер и пользовательский экран в одну проверку. Отдельный график из тестового файла полезен для дизайна, но не подтверждает доставку данных от физического образца.