Привет, Хабр!
На связи Whoosh — лидер в разработке и интеграции технологий микромобильности в стране. Если вы живете в России или СНГ (мы уже присутствуем в некоторых городах Казахстана и Беларуси), то наверняка видели наши электросамокаты или пользовались ими. Вероятность этого большая: за 9 месяцев 2022 года года уже совершено 46 млн поездок, парк вырос до 82 тысяч устройств и размещены они в 40+ городах трех стран.
За четыре года мы прошли путь от стартапа до зрелой IT-компании. То, какими мы были в начале и сейчас — два разных проекта. За период работы компании мы создали собственную IT-инфраструктуру для управления флотом и процессами, связанными с его непрерывной доступностью для пользователей, сервисным обслуживанием и мониторингом состояния.
Меня зовут Сергей Шилин, я руководитель отдела разработки электроники и встроенного ПО. Вместе с CIO и со-основателем Whoosh Егором Баяндиным мы вспомним, как все начиналось несколько лет назад, как все устроено сейчас с точки зрения IT и какие у нас планы на будущее.
Каждый самокат, помимо колес, основания и руля, укомплектован набором электроники. Сердцем является IoT модуль, оснащенный блоком спутниковой навигации, GSM модемом и различными сенсорами: барометром, гироскопом, акселерометром, магнитометром и другими. Все устройства связаны в облаке, а доступ к ним человек получает через мобильное приложение. Точнее, разные люди с разными ролями через разные приложения. А еще происходит много интересных внутренних процессов, не связанных с IT. Другими словами, есть и софт, и хард, и много чего ещё.
Как росли и выросли
Егор
Четыре года назад Whoosh был классическим стартапом. Наша команда работала в “гараже” на бывшем заводе реактивных двигателей в Лужниках. Загоревшись самокатами и необычной моделью сдачи в аренду без стационарных мест выдачи под паспорт и залог, мы собирались и пыталась придумать, как запустить что-то подобное в России, обсуждали существующие проекты в мире и искали ответы, можно ли сделать ещё лучше. Четкого распределения на роли не было, четыре фаундера (Дмитрий Чуйко, Егор Баяндин, Олег Журавлев и Сергей Лаврентьев) решали первые задачи вместе.
В то же время появилась команда на аутсорсе для разработки платформы и приложения, около четырех человек, но работали они не full-time. Мы хотели попытаться залететь с самокатами в сезон 2018, но не получалось скомплектовать минимально рабочую команду для реализации этого плана, поэтому решили получше подготовиться к сезону 2019.
С железом было сложнее: у нас не было опыта в этом направлении, поэтому мы пробовали пойти по пути софта — то есть, найти людей или организацию, которые бы сделали рабочий продукт под ключ. Поиск компании для разработки под заказ ни к чему не привел, готового решения не нашли, а люди, предлагавшие свои услуги, были не слишком убедительны. Тогда решили, что нужен сотрудник в штат и разместили вакансию в надежде найти человека соответствующей квалификации на рынке, который будет отвечать за это направление — так в команду попал Сережа Шилин. И впоследствии стал отвечать за всю embedded разработку в компании.
Сергей
Это был интересный этап в жизни: интервью проходило в помещении, забитом самокатами, досками с маркерными зарисовками; на столах инструменты, наклейки, печатные платы и... все. В Whoosh срочно искали того, кто бы занялся электроникой — до запуска оставалось примерно три месяца. Взвешивая за и против, любопытство перевесило риски. К тому же, на предыдущем месте работы не было производственных целей, все ограничивалось двумя-тремя экземплярами устройств в проекте, а мне хотелось попробовать зайти в mass production. Получилось? Да!
Сейчас мы производим электронику десятками тысяч устройств на нескольких фабриках в Китае и России. И результат этой работы можно ощутить, просто гуляя по городу; иногда, достаточно выйти на балкон и оглядеться вокруг.
По началу не было понимания, во что все это превратится — был «гараж», были прототипы железа и видение направления. На старте не было большой, сформированной команды, да и чувство, что вполне можно справиться в одиночку, не покидало еще долгое время. Казалось, делов-то — прикрутить к самокату сеть и навигацию…
Егор
Для начала нужно было выбрать базовую модель скутера для запуска. На рынке было очень много низкокачественного китайского, но эти варианты мы не рассматривали по понятным причинам. Из известного были Ninebot ES2/ES4 и Xiaomi M365. Мы смотрели по внешним признакам и модель ES показалась нам уступающей по удобству для пользователя. Пособирали обратную связь по форумам и весной - в начале лета 2018 года приобрели в компанию два M365 — один для меня, другой для Димы. Мой стоял в офисе для экспериментов, а Дима весь остаток 2018 года ездил на своем на работу и тестировал его. Сидели на гиковских форумах по доработкам, шили тюнеными прошивками — в общем, всячески пытались дать адекватную оценку на основе собственного опыта — то ли это, с чем мы хотим выходить в город.
Параллельно мы искали варианты, как интегрировать самокаты в нашу платформу. Сначала пытались выбирать из готовых, доступных на рынке решений для трекинга, но всегда находились нюансы, которые отталкивали от выбора: недостаточная возможность кастомизации, неудобный формат установки в самокат, непрозрачные условия при необходимости кратного масштабирования в будущем. В итоге, начали разработку IoT модуля самостоятельно.
Тогда же, в 2018 году, запустился ДелиСамокат и YouDrive Lite, в ходу были оригинальные модели ES, копии M365 — мы собрали дополнительный фидбек еще и с этого. Не помню точно, что там было с IoT модулями; возможно, они просто цеплялись приложением к самокату через Bluetooth телефона.
Так или иначе, самокат выбрали и сделали заказ в несколько сотен штук. Да, у него были некоторые минусы, что доставили нам впоследствии много проблем (пневматические колеса в шеринге обернулись адом), но и плюсов было предостаточно. У модели было много поклонников из числа пользователей — решение сменить удобные и юркие M365 на шеринговую модель в 2020 году понравилось не всем.
В итоге, к тестовому запуску, 150 коробок с самокатами стояли в офисе, 500 было в пути и будущий рост флота уже зависел от наших дальнейших действий. Мы имели довольно четкий критерий дедлайна запуска: самокаты должны появиться на улице Москвы в первый теплый день весны.
Сергей
Идея превращения модели Xiaomi M365 в шеринговую была, в общем-то, не сложная: берем самокат и частично заменяем электронику управления своей, а именно плату дашборда, что установлена в центре руля. Назовем эту железку — IoT-модуль: про него мы еще расскажем вам не раз в других, технических статьях.
Дальше от IoT уходит интерфейс чтения данных с ECU (Electronic Control Unit) и BMS (Battery Management System). Так, IoT модуль получает доступ к телеметрии и управлению основными функциями самоката — разгон, торможение и т.д. с одной стороны, а с другой — имеет выход в сеть и подключается к нашей платформе верхнего уровня.
Руль самоката имеет колодец для установки платы дашборда, которая в оригинале отвечает за включение самоката, индикацию, считывание показаний датчиков Холла с ручек газа/тормоза и общение с телефоном по Bluetooth. Мы извлекали дефолтную плату, заменяя ее на двухэтажный IoT модуль, повторяющий форму колодца и наследующий схему установки и крепления.
В то время, на руках не было протокола общения с ECU и BMS. Это сейчас мы работаем с крупнейшими мировыми поставщиками микромобильных транспортных средств — Ninebot, OKAI и другими, а протокол оформлен в документацию, поставляемую вместе с самокатом. Но в 2019 были скутеры Xiaomi, которые для них делал Ninebot — что-то реверсили, какие-то данные брали в интернете — модель популярная, не мы одни хотели уметь читать телеметрию и тюнить настройки.
Егор
Параллельно доработкам в части электроники и прошивки мы доделывали платформу: изначально было понимание, что хотим получать и хранить всю доступную информацию по каждому самокату; у каждого устройства есть статус и с этими статусами связаны системные процессы. Понимали, что нам нужны отдельно клиентское и сервисное приложения для внутренних операций с флотом. Звучит, как какие-то базовые и очевидные вещи, но сейчас это то немногое, что сохранилось с первого запуска до сих пор — мы не потеряли ни байта телеметрии от устройств, мы до сих пор используем конечное множество статусов, на которых основаны все наши процессы — от пользовательских до операционных.
Каждый из самокатов имеет выход в сеть через сотовую связь и публикации данных по MQTT; да, мы смотрим в сторону более экономичных способов оставаться устройствам онлайн, но пока что GSM выглядит хорошим решением, компенсируя не самую низкую стоимость простотой интеграции и надежностью соединения.
Еще в какой-то момент мы поняли, что китайские BLE замки, на которые мы опирались для выполнения требований городов по пристегиванию самокатов (например, в Москве иначе работать нельзя), нас подводят. Их механика могла заедать при низких температурах, Bluetooth плохо работал в зависимости от модели телефона пользователя, они разряжались несколько раз в сезон и имели нестандартный, не перезаряжаемый элемент питания. И самое главное, они не имели обратной связи, которая позволила бы нам видеть удаленно, что происходит с замком в момент взаимодействия с пользователем. Мы срочно решили делать свой модуль замка, управляемый от IoT, с обратной связью и индикацией.
В разработке платформы мы сразу же пошли по пути облачных технологий — это было важно на стадии стартапа, так как позволяло быстро использовать технологические решения без больших ресурсных затрат и времени на развертывание и поддержку. К тому же, когда архитектура еще не сформировалась и команда разработки ищет оптимальные пути, облачные решения ускоряют проверку гипотез и упрощают внедрение новых решений.
Однако и сейчас это является неотъемлемой частью продукта, от которой у нас нет планов отказываться в ближайшее время. Как обычно, везде есть свои нюансы — в serverless их не меньше, а иногда и больше, чем в классических решениях. Обязательно расскажем что-нибудь интересное на эту тему в следующих статьях.
Мы примерно понимали, насколько быстро сможем подготовить бэкенд с внутренней админкой к запуску; были готовы первые версии приложений для двух мобильных платформ. Важной задачей оставалась электроника, которую нужно было не только разработать и связать с бэкендом, но еще и где-то скомплектовать, собрать и установить в самокаты.
Сергей
Вместе с тем, большой нагрузкой стали для нас не IT-шные вещи: весь парк нужно было обклеить пленкой, изготовить кастомные крышки руля, оснастить замками для пристегивания к парковкам и специальным узлом крепления.
Изначально, конструкция самоката содержит механизм складывания для компактной переноски; такое решение для шеринга — однозначный минус, в силу понятных причин. Мы пришли к необходимости замены этого узла на муфту, но в штате на тот момент не было конструктора, который мог бы заняться этой задачей — поэтому ей занимались все. Нашли того, кто нарисовал и подготовил КД, нашли того, кто изготовил мастер-модель, а литьем и фрезеровкой занимались другие люди. Получили и установили первую партию — она оказалась недостаточно прочной, как нам того хотелось. Зато быстро узнали, что отжиг, закалка и старение деталей — действительно важные нюансы работы с металлическими сплавами. А в перерывах между обзвоном десятка-второго производств, продолжали решать собственные задачи.
Используя модель M365, мы столкнулись с нестандартными ситуациями в их эксплуатации. В массе устройств проявлялись все возможные проблемы, только с отдельными из которых вы могли столкнуться, как пользователь личного самоката.
Например, внешнее питание: модуль контроллера отдавал наружу напряжение на дашборд, который с фабрики комплектовался низкопотребляющим BLE чипом и небольшой светодиодной сборкой; потребление было в 2-3 раза меньше, чем у нашего IoT устройства — выходной PTC предохранитель в ECU постепенно деградировал, ухудшая цепь питания IoT модуля — перезагрузки и другие странные эффекты происходили со временем чаще, а иногда предохранитель выгорал, полностью обесточивая IoT. В личном использовании вы могли с этим никогда и не столкнуться, но когда в парке уже несколько тысяч устройств — и все разных ревизий, важно отслеживать их состояние и системно подходить к решению проблемы.
Так мы пришли к сервисной команде по ремонту и обслуживанию электроники — как модулей самоката, так и собственного производства.
Как запускались
Так выглядело наше помещение на Лужнецкой набережной в пятничный день, предшествующий запуску: 5 апреля 2019 года.
Уже не так легко вспомнить, что именно там происходило. Скорее всего, как обычно — все, но в десятикратном темпе. Мы клеили наклейки, писали код, ускоряли апрув приложений в сторах, назначали QR коды, привязывали BLE замки, заводили IoT модули в систему. Мы успевали сделать все, что запланировали и часам к 23, в офисе, на зарядке, остались ждать следующего дня 30 самокатов (в город мы вывезли 20) и 0 людей.
Без проблем, правда, не обошлось: разослав приглашение регистрации по друзьям, мы узнали, что не у всех получается создать аккаунт на Android устройствах. Но к запуску удалось все починить.
6 апреля, часам к 8 утра, самокаты были выставлены на Мясницкой улице, заботливо пристегнутые к парковкам в ожидании, когда на них кто-то обратит внимание. Перед запуском мы выгрузили из открытых источников координаты парковок, проехали и руками верифицировали их — хотели быть уверены, что у наших пользователей не возникнет проблем с завершением аренды в правильном месте. В первый запуск проверяли не только технический бэкграунд — было интересно, насколько нативный сервис предлагаем людям. Это нам очевидно, что с этим делать, но остальным предстояло столкнуться лицом к лицу с новым транспортом и самостоятельно пройти всю последовательность действий — от регистрации до правильной парковки в нужном месте с фотоподтверждением и фиксацией скутера замком. А ведь многие до этого даже не ездили на электросамокате!
Никаких паспортов, договоров аренды и залогов — мы оставляли людей один на один с самокатом, мобильным приложением и любопытством к чему-то новому.
И это сработало, люди вставали на самокаты и ехали!
Мы оказывали поддержку в чате и по телефону, вели мониторинг устройств и сервиса; в какой-то момент часть команды приехала на Мясницкую и стала наблюдать, как люди реагируют на самокаты, с какими проблемами сталкиваются, как берут их и разъезжаются по Москве. На тестирование отреагировал и город, заметив самокаты на улице и связавшись с нами с вопросами о том, что же это было.
Отработав полный день, мы свернулись и ушли на доработку техники, улучшение пользовательского опыта и конечно же, собирать оставшиеся несколько сотен самокатов, что бы через две недели полноценно развернуть имеющийся флот.
Немного статистики за первый день работы сервиса:
Зарегистрировалось 220 новых пользователей и 161 из них совершат поездки в будущем
Было сделано 35 поездок, общей дистанцией 75.9 км, однако 6 из них были нулевыми; медиана пройденной дистанции в поездке — 2.1 км
Если исключить нулевые поездки, то был 21 уникальный пользователь на 19 уникальных самокатов
Если все-таки смотреть и нулевые, то уникальных пользователей останется столько же, а вот самокатов 20 — то есть был один самокат, на котором так и не удалось покататься в тот день, однако пользователя это не спугнуло
4 пользователя взяли в аренду самокаты, как минимум, дважды
Нулевые поездки скорее всего были связаны с плохо работающими замками, либо же пользователь не смог разобраться, что с самокатом надо делать.
Спустя пару недель, офис на Лужнецкой превратился в небольшую зарядную станцию и мастерскую, а потом мы сняли еще одно помещение, куда поместились оставшиеся 500 штук и были готовы встречать новые. Там самокаты ремонтировались и заряжались; это сейчас мы возим только аккумуляторы на замену, с M365 так не работало — нужно было везти в СЦ сам самокат, а спустя несколько часов, вернуть его в город.
В общем, мы начали работать системно, изо дня в день выставляя самокаты в город. Из интересного — какое-то время у нас не было круглосуточной поддержки, но флот мы не собирали, оставляя его на улице. Сейчас сложно представить, буквально невозможно, что в чате приложения может никто не отвечать несколько часов! Наша поддержка в пике сезона имеет среднее время ответа ~2-4 минуты и ваша проблема скорее всего будет решена достаточно быстро, в любое время суток, в любом городе присутствия сервиса.
Как выстраивали процессы
Егор
Мы строим большую технологическую компанию, избегая превращения в энтерпрайз - без формализации процессов в такой команде уже не обойтись, но стараемся делать это максимально осознанно. С ростом компании, росла ответственность за стабильность сервиса, что влекло за собой не только увеличение отдела разработки, но и тестирования. Команда стала расширяться, выстаивались вертикали управления, происходило разделение по направлениям, по специализациям. Мы пришли к тому, что внутри разработки сформировались несколько групп, отвечающих за разные составляющие продукта. Закономерно возникла необходимость комплектации этих направлений менеджерами. Разделив команды, нам было важно, что бы все продолжали оставаться в тесном контакте друг с другом. Звучит, как парадокс — разделяя, сохранить целостность, но это важная особенность управления, к которой мы пришли, итеративно пробуя разные подходы.
Учитывая специфику бизнеса (у нас много работы с платформой, электроникой, самими самокатами и их начинкой) стараемся собирать всю команду в одном месте. Есть даже требование при аренде офисов, чтобы работающие с железом ребята находились на первом этаже и сразу могли тестировать устройства на улице.
Немного про менеджмент проектов: сначала у нас был канбан, который с ростом компании плавно переходил в хаос. Для фокусировки команд решили попробовать скрам, не вполне канонический, но все же соблюдая основные его правила. Потом поняли, что период в две недели — слишком долго для наших объемов, а с недельными спринтами издержки на следование всем ритуалам стали бы слишком большими. В итоге, мы снова вернулись к канбану, наполнив его лучшими практиками из всех методологий, что удалось протестировать. С одной стороны, мы ждем от сотрудника погружения в проблемы бизнеса и самостоятельную работу с задачами, с другой — стараемся прорабатывать проблемы бизнеса, максимально четко ставить цели и давать ясные формулировки при постановке задач в разработку.
По технике тоже все успело поменяться за это время. На этапе малого бизнеса, эксперименты давались дешево, но с ростом это перестало работать. К примеру, в первый год мы могли запланировать какую-нибудь жесткую миграцию с полной недоступностью сервиса в течение получаса — и этого мог никто и не заметить из пользователей. Сейчас же минутный простой уже несет серьезные издержки.
Каждый год шло кратное увеличение нагрузок; старые процессы переставали работать — это приводило к тому, что нужны были как срочные правки, так и планирование переработки какого-то сервиса под новые требования, с учетом нагрузок на вырост. Удаляясь от точки стартапа в направлении взрослой компании, мы стали планировать такие вещи тщательнее, заранее пытаясь спрогнозировать потенциально узкие места. Например, в силу специфики работы сервиса, у нас есть часы пиковой нагрузки, когда число поездок вырастает в несколько раз — мы выработали успешные практики работы в serverless инфраструктуре, которые позволяют скалироваться и легко обрабатывать такие ситуации. Про нашу архитектуру мы вам еще расскажем, там много всего интересного — как решаем проблемы highload, как готовим serverless, как наш сервис взаимодействует с устройствами и т.д.
Сергей
До Whoosh у меня был опыт работы только в одиночку, без серьезного планирования, трекинга задач, code review и других полезных практик из современной software разработки. Поток найма и расширения команды постепенно корректировал внутренние процессы, фиксируя наиболее удачные паттерны взаимодействия внутри команды. Несомненно, много к чему еще можно стремиться, но оглядываясь назад я понимаю, насколько большой путь уже проделан.
Зачастую, embedded development заключен сам в себе: люди делают железки и софт под них, которые являются самостоятельным продуктом; не говорю, что так делают все, но такого много и именно так я и работал до прихода в Whoosh. У нас же в одном месте собран весь стек разработки и для меня было необычно расти профессионально в коллективе, где люди рядом решают проблемы высоких нагрузок, оперируют большими данными и делают это по каким-то устоявшимся процессам, на которые ты обращаешь внимание и пытаешься вникнуть, зачем это вообще нужно.
Но опять же, тут главное вбирать лучшие практики, что хорошо лягут на наши особенности работы. К примеру, пытаясь использовать спринты, мы столкнулись с несколькими препятствиями:
Трудно оптимально для всех синхронизировать тайминги, когда внутри собрана разноплановая команда. А в embedded она такая — электроника, софт, математика, аналитика, прототипирование, производство и тестирование. Поэтому мы заводим цели без жёстких привязок к каким-то стандартам с учетом здравого смысла и контролируем процессы, чтобы всё выполнялось в срок
В железе многое зависит от внешних факторов. Если разработку можно спланировать, потому что всё нужное уже есть у команды, то хард опирается на сроки поставки образцов, изготовления печатных плат, доступность компонентов и т.д. Отсутствие одного ключевого элемента может сдвинуть сроки тестирования и выход в производство всего устройства
Интересные вызовы были за эти года в разработке, особенно с началом ковидного чипогедона. Нужно было срочно «переехать» с одного чипа на другой, в силу полной недоступности первого и хорошего официального предложения на второй. Мы три месяца переделывали проект под новую архитектуру, а потом на созвоне с европейским представительством ST нам сказали, что на Восточную Европу было выделено 0 чипов для продажи через официальных дилеров. Тогда мы поняли, что эти грабли могут быть не в последний раз, выбрали третий чип и отделили уровень платформы от приложения так, что сейчас ПО IoT может работать как на STM32F413, так и на RT1021 — нужно просто указать соответствующий target при сборке проекта.
Сейчас мы идем к тому, чтобы уметь запускать application часть кода везде, даже на x86 машинах — это очень важно для внутренних тестов, а так же возможности мультипликации виртуальных устройств с продуктовым кодом, что может сильно помочь, например, в интеграционном тестировании с бэкендом.
Про расширение команды
Егор
До 2020 года в разработке было 15 человек, в железе — трое. Чтобы бежать с нужной нам скоростью, с 2021-го мы стали активнее расширяться. Со временем у нас увеличивалось число штатных разработчиков: сегодня в IT-направлении работают более 70 человек. Кроме софтовой разработки (платформа + приложение) и харда (схемотехника + прошивка) в компании есть отделы по работе с данными, информ. безопасности и эксплуатации.
По мере роста появляется понимание, какие люди нам нужны. Приходят смежные специалисты по направлениям, о которых мы, будучи стартапом, даже не думали. Например, специалист по применению и ведению документации — и люди, которых это касалось в прошлом, с облегчением выдыхают, повышается качество с обеих сторон. А еще, если в прошлом ведущий разработчик тратил рабочие часы на заполнение договора, то с учетом стоимости этого времени — документация становилась очень дорогой.
Нам постоянно нужны специалисты, но к расширению команды мы подходим с осторожностью: задач и проектов становится все больше, но мы не можем расти в 5-10 раз за год — получится хаос. Перед наймом разработчика, мы с командой фиксируем, зачем он необходим, какие задачи будет выполнять, сможем ли мы долгосрочно обеспечивать его работой по нужному профилю. В тех людях, которых мы выбираем, нам важно увидеть высокий уровень ответственности, устремленности, которые бы позволили получить результаты даже при не идеально выстроенных внутренних процессах. Людей, которых мы нанимаем, очень важно прокачать и научиться делегировать им компоненты продукта, доверяя их компетенции, а не брать исполнителей и заниматься микроменеджментом.
А ещё важно позаботиться о сохранении энергии, гибкости и драйва стартапа — мы стараемся не забывать о них с тех времен, когда в Whoosh работали несколько человек.
Сергей
Спустя некоторое время после завершения первого сезона появилась мысль: «Не пора ли взять джуна?». У нас тогда не было HR, а у меня опыта проведения интервью: сами писали вакансии, собеседовали и решали, кто подходит, а кто нет. Предпочтение отдавали людям, которые не боятся предлагать свои идеи и не просто решают отдельно взятые задачи, а видят, что вокруг есть проблемы, подхватывают суть и закрывают их.
Работа в embedded, на мой взгляд, отличается от типичного распределения стеков и технологий в современном IT. У нас нет такого разделения труда, что схемотехникой занимается один отдел, топологию разрабатывает другой, а над прошивкой трудится третий — в той или иной степени, но каждый человек в команде разработки электроники и встроенного ПО обладает смежными навыками.
В моем понимании, сложно писать код под платформу, схемотехнику которой ты не понимаешь, или же заниматься разработкой железки, для которой ты не можешь написать хотя бы минимальный код запуска и проверки работоспособности.
Про новые направления
Егор
Сейчас стало появляться много новых проектов: батареи для самокатов, дашборд, кастомное навесное оборудование, а вместе с ними приходит большой объём менеджерской и технологической работы. Мы активно ищем людей для развития собственной экспертизы в этих и других направлениях и будем рады обсудить задачи с теми, у кого есть необходимый опыт и желание принять участие в проекте.
Наша задача — улучшать сервис, используя алгоритмы и данные, предлагать новые маршруты и способы (сценарии?) поездок, правильно расставлять самокаты в городе, динамически влиять на ценообразование, создавая баланс спроса и предложения в зависимости от времени, места и множества других факторов. Уже сегодня самокаты — это не развлечение, а элемент транспортной инфраструктуры, и именно поэтому нам важно постоянно улучшать user experience. Для ежедневных поездок каждый шаг пользователя должен быть продуман и максимально удобен — для этого мы постоянно анализируем и прорабатываем кейсы, с которыми встречается человек при использовании транспорта последней мили.
Сергей
Одна из важных целей на ближайшее время — вместе с партнерами разработать собственную батарею и модуль управления (BMS). Мы хотим приобрести и развивать экспертизу этого направления внутри компании: очевидно, что каким бы ни было транспортное средство ближайшего будущего — ему всегда будет нужен элемент питания — надежный, безопасный и технологичный. Плюс, мы хотим больше понимать, что происходит с зарядом в поле при разных окружающих условиях. Это одна из основных операционных метрик, влияющих на эффективность, но еще, это прямое улучшение пользовательского опыта взаимодействия с продуктом — понимая процессы, происходящие внутри аккумулятора, мы сможем обеспечить лучший прогноз его работы, а повысив функциональные характеристики — сделать сервис более эффективным.
У нас всегда было и будет очень много работы над функционалом IoT модуля, которого уже существует пять функционально разных поколений. IoT генерирует большое количество уникальных данных, на основе которых мы проектируем алгоритмы, корректируем внутренние процессы и принимаем важные решения, анализируя потоки данных миллионов треков.
Например, совершая поездку, самокаты прощупывают дорожное полотно и отдают данные в систему верхнего уровня, где мы используем их для планирования технического обслуживания, регулирования зон ограничения скорости, а так же для разного рода аналитики. Посмотрите на картинку — может быть вспомните, где вам было комфортно ехать, а где не очень:
Из большого и интересного — разрабатываем модуль компьютерного зрения, который позволит собирать больше данных об окружающем пространстве, разрабатываем алгоритмы, позволяющие анализировать поездки для обнаружения опасного вождения, учим самокаты определять препятствия и предупреждать о них во время поездки и многое другое.
Обо всем расскажем в свое время, о чем-то — уже совсем скоро. А может, у вас есть вопросы, на которые мы можем ответить в следующих статьях?
