Как мы стали «руками» клиента, у которого есть инхаус-разработчики, и сделали приложение для тех, кто хочет бросить курить. Кейс Plonq

Идея заказчика — помочь людям контролировать потребление никотина

Plonq разрабатывает и производит электронные сигареты и внедряет более осознанный подход к курению. Например, компания запустила первый в России экопроект по сбору и переработке электронных сигарет. На этот раз они разработали многоразовую сигарету, которая собирает статистику по количеству затяжек, изучает привычки пользователя и помогает отслеживать уровень потребления никотина.

По замыслу Plonq, POD-система синхронизируется с приложением и передает в него данные. Владельцы устройств видят статистику потребления никотина и берут свою привычку под контроль, а устройство им в этом помогает.

Прежде чем обратиться в Purrweb, клиенты уже пробовали собрать приложение сами: сделали минималистичный дизайн, продумали отображение статистики, пользовательский путь. Но с разработкой возникли проблемы.

Продукты, связанные с курением, нельзя размещать в App Store и Google Play. И чтобы обойти это ограничение, компании понадобилось PWA-приложение.

Инхаус-команде не хватало экспертизы, и компания привлекла ее извне, чтобы сэкономить время и деньги.

Plonq стали искать опытную команду, которая глубоко вникнет в продукт, возьмет на себя бэкенд и фронтенд и бесшовно интегрируется в систему устройства. Так мы с ними и встретились — мы не только умеем создавать IoT-приложения разной сложности, но и знаем, как интегрироваться с внутренней командой клиента. То есть выстраивать здоровую коммуникацию, адаптироваться под уже существующие методы работы и оптимизировать процессы для достижения совместного результата.

Мы всегда объясняем, что делаем и как, сами задаем вопросы, если нам нужно что-то узнать, держим клиента в курсе всех обновлений — это особенно важно, если у проекта сжатые сроки.

А еще, когда мы видим, что на этапе разработки что-то можно улучшить, мы обязательно скажем об этом. Наш главный критерий оценки любой фичи — решает ли она бизнес-цели клиента.

Приняли горящую задачу на PWA-приложение

Если вы слышали о PWA-приложениях, то поздравляем, о них знают не все! PWA (progressive web app) — это технология, которая превращает сайт в приложение. Получается мобильное приложение в браузере, которое выглядит почти неотличимо от привычного пользователю — то, что это PWA понятно только по адресной строке сверху или снизу.

Plonq уже презентовали продукт, и времени на разработку было критически мало. Мы провели оценку и поняли, что сможем уложиться за месяц. Клиенту это понравилось, как и сам наш подход к оценке — понятный, дотошный и структурный. Мы ударили по рукам и приступили к работе.

Вместе мы обсудили функции приложения:

Состояние устройства. Приложение показывает вкус картриджа, уровень заряда и сигнала (апп синхронизируется с сигаретой по Bluetooth).

Количество затяжек и умная статистика. Минималистичные дашборды показывают, сколько затяжек человек сделал за день и сравнивает это число со средним за день, неделю и месяц. Если пользователь вышел из зоны действия Bluetooth — например, ушел с устройством, оставив телефон дома — приложение автоматически подгружает актуальную статистику при повторном подключении.

Цвет девайса. Plonq хотели отображать на экране цвет устройства, но мы предложили убрать эту функцию, потому что сигарета не фиксировала такие данные. Разработка фичи на стороне клиента или поиск обходных путей заняли бы время и потратили много сил и денег компании.

Режим контроля затяжек. Приложение дает возможность установить лимит затяжек на определенный промежуток времени. Если превысить указанное количество, то устройство начинает вибрировать.

Нам предстояло:

• • разработать всю внешнюю часть и техническую начинку, чтобы пользоваться PWA было так же удобно, как и классическим приложением, и работало оно так же быстро;
  • синхронизировать приложение с электронной сигаретой так, чтобы время совпадало до секунды и данные приходили без багов;
  • согласовать работу и протестировать все вместе с клиентом и его инхаус-разработчиками.

Как мы разбирались с наработками клиента и всем отделом использовали электронки

Проект подразумевал общение между несколькими экспертными группами. Мы уже отточили такую коммуникацию в работе над IoT-проектами: приложением для аренды павербанков Energo и приложением для умных холодильников Vendify, поэтому с Plonq мы общались в штатном режиме.

Клиенты предоставили нам дизайн, свои наработки и привезли в офис три устройства с разными вкусами, чтобы мы тестировали их связь с приложением по мере разработки. Что именно мы сделали?

Помогли улучшить дизайн. Мы взяли в работу минималистичный интерфейс, ничего не меняя — дизайнеры клиента нашли удачное решение, с которым мы были полностью согласны. В процессе мы только помогли его немного докрутить. Например, заметили, что не хватало некоторых стейтов и попапов ошибок, и предложили их добавить.

Изучили исходный код. Разработчики Plonq уже пробовали связывать устройство и сайт. Они создали простую страницу с кодом и консолью под названием Plonq No Bugs для Chrome и протестировали передачу данных в реальном времени. Это изобретение впоследствии помогло нашим фронтендерам, но с кодом были небольшие проблемы. О том, как мы их исправили, подробнее расскажем дальше.

Попарили, не прерывая работу. Наши разработчики дымили прямо за рабочим столом, а все курящие сотрудники просились на проект.

Когда жидкость в картриджах закончилась, клиенты подсказали нам забавную фишку: если просто дунуть в устройство, то затяжки все равно засчитываются. Несколько недель весь офис наблюдал, как разработчики с умным видом дуют в электронные сигареты.

Изучили новый протокол и сконнектили кастомный браузер с Bluetooth

Как часто вы пользуетесь Bluetooth в браузере на смартфоне? Скорее всего, вы им вообще не пользуетесь! Вы просто подключаете наушники через настройки или разрешаете какому-нибудь приложению это сделать. Каждый раз, когда Bluetooth коннектится, автоматически включается нужный протокол, и все работает.

У браузеров все иначе. Если у мобильного Chrome на Android есть поддержка Bluetooth API, то у Safari такой функции просто нет — этот браузер не коннектится с Bluetooth. Занятный факт: «под капотом» все браузеры на айфоне — это Safari, поэтому ни один из них не подходил для нашего кейса.

Клиенты хотели, чтобы их приложением пользовались люди с разными типами смартфонов, поэтому они сделали свой браузер для IOS. Чтобы сконнектить PWA-приложение и устройство, наши разработчики погрузились в изучение документации по нему. А параллельно изучали BLE — протокол подключения Bluetooth к браузеру.

Дело усложнялось тем, что кастомный браузер — это отдельное изобретение, по которому нет информации в полезных статьях или на форумах для разработчиков, где описаны разные кейсы и проблемы. Наша команда изобретала решения на практике.

Если наши разработчики находили небольшие баги, то инхаус-команда быстро их исправляла, но многое мы не могли преодолеть в принципе. Очевидно, что компания, которая занимается производством электронных сигарет, не разработает браузер на уровне многомиллиардной Google. Например, мы не смогли ускорить коннект с устройством, который по мере работы немного замедляется.

Мы улучшили ситуацию обходным путем. Например, заметили, что после реконнекта скорость передачи данных резко увеличивается. Поэтому в критически важных местах мы добавили невидимые реконнекты. Похожих кейсов было несколько, но почти все они — это дебри языка разработчиков. Мы не стали их сюда включать, верьте на слово!

Совместная работа с кастомным браузером помогала коммуникации — мы с командой клиента были в постоянном контакте и стали еще лучше понимать друг друга. Но вместе с изучением BLE все это сильно затягивало время.

Подключить дополнительных разработчиков мы не могли, потому что проект был сложный: кастомный браузер, технологии PWA и BLE — один только онбординг занял бы очень много времени.

Это не только не помогло бы успеть в срок, но и увеличило бы бюджет на проект. Мы же стараемся всегда экономить деньги клиента.

Наши разработчики разобрались с протоколом, и связали Bluetooth, кастомный браузер и устройство. А потом возникли новые сложности.

Улучшили подсчет и отображение статистики

Клиенты придумали для приложения классную функцию — подсчет среднего количества затяжек за определенный период.

Чтобы эту функцию реализовать, команда клиента придумала формулу подсчета затяжек. Но у формулы был недостаток — она показывала адекватные числа только для тех пользователей, которые уже давно пользуются устройством. Если человек только зарегистрировался, то он получал нерелевантную статистику — например, в первую неделю курения он видел среднее в 4 раза меньше реального, потому что 4 расчетные недели еще не прошли.

Мы предложили улучшить математику:

1. Сделали алгоритм проверки того, когда человек в первый раз взял POD-систему в руки.
2. Предложили разные формулы для разных отрезков времени.

Помимо этого, мы храним данные о том, какое количество никотина было выкурено в конкретный момент времени. Теперь если человек возьмет сигарету в 7 утра, то он сравнит себя с предыдущими днями именно в 7 утра. Это тоже помогает лучше контролировать потребление никотина и механику своих привычек.

Исправили проблему девайса и синхронизировали приложение с электронной сигаретой

Устройство сконструировано так, что забрать с него информацию можно только один раз, после чего его нужно чистить. Мы не можем копировать данные частями. Поэтому раз в 5 секунд мы выкачивали весь пакет, отправляли его на бэк и очищали систему.

Но просто забирать данные вот так — это рискованно, потому что если случится дисконнект или баг (например, не удастся очистить устройство), то одни и те же записи могут отправляться дважды. Тогда пользователь получит некорректную статистику.

⚠️Дисклеймер: дальше мы рассказываем о победах разработчиков — будет звучать, как квантовая механика! Мы постарались максимально упростить все объяснения. Ну, поехали!

1. Избавились от ограничений устройства, добавив фильтрацию. Мы подтягивали на фронтенд последнюю запись с бэкенда, смотрели дату и отсеивали по ней: все, что после — новое, все, что перед — старое. Это защищало нас от рисков, описанных выше.

2. Отреагировали на изменение на стороне клиента. В какой-то момент Plonq поменяли алгоритм выкачивания пакетов, и теперь первая затяжка показывалась как самая новая. Она улетала на бэк, а после фильтрации прилетала обратно, потому что, с точки зрения, системы «самая новая» = «самая последняя». Весь остальной пакет отсеивался, потому что устройство отправляло данные не в том порядке.

Мы можем отсеивать данные разными способами, но чтобы снизить сетевой трафик и быстро загружать страницу, мы выбрали работу с сервером. Теперь отправляли пакет информации с устройства на него, и оттуда же подтягивали нужное, так же отсеивая по дате.

3. Синхронизировались со временем устройства. Время устройства немного отставало от настоящего текущего. Чтобы убрать временные разрывы, мы добавили еще один шаг: теперь, подключаясь к устройству, приложение запрашивает у него его время, сравнивает с реальным и добавляет разницу к каждой затяжке. Казалось бы, теперь точно все работает! Но нет…

4. Исправили баг с нестабильностью времени на устройстве. Оказалось, что в сигарете есть свой таймер. Главное, что о нем важно знать: он работал нестабильно. Происходили тики в подсчете времени, из-за которых и разница во времени постоянно оказывалась разной.

Пример: мы запрашиваем время устройства, сравниваем с текущим, разница оказывается 200 секунд. Запрашиваем еще раз, а она вдруг 196. Поэтому у одной и той же затяжки оказывалось разное время. Клиенты исправили недостаток на своей стороне, но мы потратили время на его обнаружение.

5. Синхронизировались по часовым поясам. Электронные сигареты Plonq любят люди по всей стране, а значит, что и приложение, и устройство работают в разных часовых поясах. Чтобы корректно отображать статистику, нам нужно было считать затяжки по времени пользователя. Если человек в последний раз покурил в первую секунду понедельника, то +1 должна появиться на этой неделе, а не на прошлой.

Дело осложнялось тем, что сервер, который хранит данные и нужен нам для фильтрации, использует для расчетов UTC (Coordinated Universal Time — Всемирное координированное время). Мы придумали, как синхронизировать данные — квантовую механику опустим!

На каждом этапе мы были на связи с клиентом. Мы пошагово расписывали, что и зачем делаем, 3-4 раза в день сверялись с инхаус-разработчиками и загружали новые версии на стейдж.

Из-за решения скрытых проблем — от кастомного браузера до тиков времени в устройстве — мы потратили больше времени, чем рассчитывали. Проект растянулся на 2 месяца. Получившийся срок был больше, чем первоначальный «горящий». Но для проектов такого типа два месяца разработки — это стандартная практика.

Добавили чайлд-лок после релиза

После релиза мы не оставляем клиентов, а продолжаем разрабатывать для них обновления, новые фичи и версии ПО. Для Plonq мы сделали классную функцию «Child Lock». Она помогает блокировать устройство после установленного времени, чтобы дети не игрались с ним, пока родители не видят.

Есть 3 варианта блокировки:

Мануальная: пользователь просто нажимает кнопку в приложении, и функция активируется.

По таймеру: можно заранее выставить таймер. Например, на 2 минуты. Отсчет начнется после последней затяжки.

По картриджу: если несколько раз высунуть-всунуть картридж, то устройство заблокируется. Разблокировать его можно мануально.

P.S.

Сейчас приложение активно используют покупатели Plonq: после релиза его установили свыше 1000 человек.

Мы ждем новых функций и идей от клиента. И новых головоломок для наших разработчиков! Они их любят: посмотрите, как мы собрали мозаику из API для криптокошелька (и сэкономили деньги клиента!) и создали омниканальный чат для закупщиков.