Принципы разработки HealthTechПо оценкам экспертов, следующие два года станут для медицинских стартапов решающими: ожидается, что объем рынка может превысить отметку в
$180 млрд. Люди ждут появления новых приложений, т.н. медицинских помощников в области удаленного консультирования, подбора лечения, персонализированной терапии. Сегмент HealthTech, в качестве ответвления от MedTech, как раз призван решить эту проблему. Нюансы разработки конкретных продуктов напрямую зависят от выбранного направления:
Построение продуктовых гипотез на основе востребованности продуктаНикакой работы «вслепую» — предполагаемая функциональность и возможности приложения должны быть четко обозначены в самом начале пути. Это не значит, что вы ограничиваете себя в возможностях совершенствовать какие-то функции в будущем. Речь скорее идет о том, чтобы четко расставить приоритеты: отталкиваемся от запроса людей, формируем функционал на основе обратной связи и строим
корректную CJM. Проработанная продуктовая гипотеза должна охватывать информацию о том, как решаются аналогичные задачи конкурентами, какой технический стек актуален. Сюда же входит важный пункт по наличию обратной связи от экспертов. В нашей практике была работа над телемедицинской платформой
iBolit — два отдельных приложения, для врачей и пациентов, позволили собрать фидбэк и понять, как работают продуктовые гипотезы на практике.
Аналитика данныхМожет показаться, что аналитика — это некий «конечный» этап, который мы завершаем сразу после того, как выстроили стратегию и получили на выходе ценностное обоснование продукта. На самом деле, нет.
Аналитика данных превращается в постоянный процесс, просто мы задействуем разные сегменты: где-то требуется доступ к базам данных по заболеваниям, где-то — аналитика
ресурсоемкости приложения. На деле, все что помогает нам оценить корректную работу продукта (нагрузка, функционал, соответствие ТЗ), должно опираться на аналитические данные.
Одним из наших кейсов была работа над созданием универсального инструмента мониторинга данных с систем «умного тонометра». Требовалось не только создать приложение внутри существующей цифровой среды, но и расширить возможности анализа поступающих данных, используя
цифровую автоматизацию. Мы внедрили в приложение графическую визуализацию,
проработали интерфейс таким образом, чтобы на выходе пользователи получили удобный и наглядный инструмент по наблюдению за своим здоровьем. Для реализации такого функционала, еще на этапе проектирования, команда рассматривала варианты user flow, анализировался каждый этап эксплуатации носимого устройства и опыт конкурентов. В итоге, продуктовая команда была максимально ориентирована на потребности пользователя и смогла предложить эффективное архитектурное решение для мобильного приложения.
Обеспечение безопасностиРынок HealthTech в России требует от команды разработки
высокой экспертности в вопросах защиты данных и понимания нюансов федерального законодательства. Все, что касается хранения и распространения персональных данных пользователей, любого размещения правовой информации и этапов оказания услуги внутри продукта,
должно соответствовать закону. Как пример, существует процедура получения согласия пользователя на обработку его персональных данных.
Как правило, ни одна форма на сайте или внутри приложения,
не может быть обработана оператором без получения предварительного согласия пользователя. На практике, такое согласие считается важным условием для оказания любой медицинской услуги. То же приложение iBolit Patient разрабатывалось в строгом соответствии с 242-ФЗ и 323-ФЗ, а любая передача конфиденциальных медицинских данных в нем возможна только через безопасный стандарт
WebRTC. Еще один пример —
наш кейс по разработке мобильного приложения для центра эстетической медицины, Seline Clinic. Безопасность пользовательского профиля мы обеспечили через работу механизма двухфакторной авторизации. При этом все данные с мобильного приложения хранятся и обрабатываются в защищенной облачной среде внутренней медицинской информационной системы клиники.
Продуктовый подходЭффективная разработка не только в сфере
HealthTech, но и любая другая, подразумевает, что у компании-разработчика уже выстроены производственные процессы. Подробно о том, как мы используем для этого методологию
Total Quality Management, мы уже писали ранее. Но обобщив, можно сократить объяснение до простого: идем к совершенству через грамотное планирование и мотивацию специалистов. Нужны люди, которые умеют объяснять, к чему идет команда, и какие инструменты для достижения целей она должна использовать. Если вы не получаете фидбэк от сотрудников, вам важен не результат, а цифры в раздутой смете — у нас для вас плохие новости.
Создание добавочной ценности продуктаКазалось бы, этот принцип в разработке должен касаться не вас, а заказчика. Однако, мы создаем
MVP, помогая клиенту проверить гипотезу успешности для его продукта, не требуя миллионных затрат. Что на выходе:
получаем базу клиентов зачастую раньше, чем это делают конкуренты → получаем фидбэк → понимаем, насколько эффективно закрыли потребности пользователей → анализируем, в каком направлении будет развиваться функционал.При чем же здесь добавочная ценность? Развитие цифрового продукта включает в себя
апгрейд функционала, закрытие болей пользователя, автоматизацию или предложение новых вариантов оказания услуги. Значит, команда разработки напрямую оказывает влияние на те причины, по которым пользователь сделает свой выбор в пользу приложения (или платформы, сервиса).