ТОВ Літа Хелз: медицина, профилактика, онкология

Мы раскажем как строился стартап - не только программная часть. Обсудим тонкости и нюансы создания MVP без больших инвестиций, особенности организации процессов, тонкости в выходе на рынок, особенности проектирования и прототипирования, тестирования спроса, получение разрешений на платёжки. ООО Лита Хелз - это медицинскя софтверная компания, партнёр компании Ingello Systems. Наш архитектор и наша бизнес-аналитик являются соучредителями и бенифициарами данной компании, помогая разрабатывать медицинский софт, а также строить саму компанию с нуля. Для развития компании проектировалась не только системная, но и ентерпрайз архитектура. Комплексно: от бизнес-структуры, продуктовой модели до архитектуры ришения, системной архитектуры и контроля процесса разработки приложений, баз данных и программных интерфейсов. От модели управления людьми и процессами до глубоких технологических решений. История этой компании пишется и по сей день уже несколько лет.

В общих чертах о проекте

Все мы хотим чувствовать себя бодрыми здоровыми в любом возрасте. Лита Хелз была задумана, как компания-разработчик приложения и системы управления для комплексной профилактики, как приложение для семей, которое контроллирует графики вакцинации, напоминает про плановые визиты, присылает уведомления, помогает обнаружить сложные заболевания (в том числе онкологические) на ранних стадиях и прогнозирует риски.

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

Однако даже такой урезанный продукт оказался существенно сложнее, чем нам видилось на самом старте. Как обеспечить безопасность медицинских сенсейтив данных? Как их анонимизировать, при этом не утратив связь с пациентами и лидами? Как внедрить протоколы опросов так, чтобы их можно было масштабировать? Как получить разрешение от платёжных шлюзов на продажу? Как получить первый трекшен? В конце-концов - как организовать нашу команду (на старте было около 10 человек суммарно)? И как баллансировать на грани сложной функциональности и прагматичности с постоянными релизами, обновлениями и пользовательским фидбеком? Если Вы пытались сосздавать технологический не тривиальный стартап - Вы нас прекрасно понимаете.

Вот так выглядит предметная область: это схема всего лишь одного сценарного потока для женской онкологии (полностью пайплайн не поместился на скрин). А таких схем - множество.

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

Решения

Конструктор тестов по онкологии (и другим категориям).

Так как предметная область была необъятна - было принято важное архитектурное решение - гибкая модель мед-протоколов, которую можно расширять без непосредственного "хардкорного" программирования и без программирования вообще. Это часто называют "конструктор". Наш архитектор, Григорьев Олег, проанализировал предметную облсть (не только протоколы которые нужно было реализовать в ближайшее время, но и те, до которых нужно было масштабироваться). Стало очевидно, что если решать задачу программно "в лоб" - потребуется существенный бюджет для реализации лгоритмов и в дальнейшем еще больший бюджет для их саппорта. Потому была спроектирована модель конструктора протоколов (важно понимать - мы не использовали конструктор, а создали свой конструктор, т.к. для таких протоколов конструкторов не существовало ранее). Выглядела модель с расшифровкой в черновой версии примерно так:

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

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

Это позволило вносить тексты, делать связи с контекстами и типами виджетов (разные вопросы требовали разного типа ввода уже со стороны пациента, и это также было возможно отмечать на конструкторе, это похоже на то, как вы создаёте формы в гугл-формс, но в гугл формс нет контектсуальных графов, позволяющих варьировать вопросы от ответов, запоминать ответы, на основе ответов запускать алгоритмы определения рисков). Теперь конструктор имел необходимое количество степеней свободы, чтобы не только внести первый тестовый рпотокол для женской онкологии, но и обеспечить инструмент для расширения тестов, что было необходимо для роста приложения.

Реакт-приложение

Архитектура - это принятие ключевых решений. Вот и было принято решение создавать веб-версию приложения и в дальнейшем адаптировать её под различные платформы - айос, андроид, десктоп. Это универсальное решение, ценность которого понимают многие (OpenAI создал ChatGPT как браузерное веб-приложение, таким образом был мультиплатформенным сразу, и уже со временем были созданы мобильные и десктопные приложения, индивидуализированные под гайдлайны платформ).

Стратегия была примерно такой: создаём браузерное приложение, используем подход "mobile first", запускаемся на всех платформах, тестируем без установки в сторах, собираем фидбек, делаем обёртку веб-вью или даже PWA (прогрессивные веб приложения) с возможностью установить на устройство. Для работы с реакт приложениям мы подключили React Developer, т.к. React хорошо подходил для наших задач и плавного интерфейса. Для обеспечения приложения данными на бекенде было создано API на Swagger (Open API).

Как результат, наше приложение должно было выдать пациенту примерно такой экран с результатами и планом дальнейших действий:

Экраны вопросов и полиморфизм

На старте пациента встречал анимированный интерактивный круг, призывающий инициировать опрос. Была создана лёгкая, минималистичная, но манящая анимация, пульсирующий круг, который так и хочется кликнуть.

Далее пользователь проходил серию вопросов. Технически каждый экран с вопросом был полиморфен - то есть задумка одна и та же - пользовательский ответ. Но иногда это был выбор одного из нескольких пунктов, иногда это ввод даты, иногда это выбор нескольких вариантов ответов. Соответственно, можно было настроить через админку - какой тип ввода подразумевался. И задачей разработчика мобильного веб приложения было подхватить этот полиморфизм, который диктовали данные из API. Это и было реализовано.

Интеграция платежных систем

Интеграция платёжных систем - это всегда интересная история, это всега сложнее чем могло бы показаться. Но когда речь о медицинском проекте, в котором храняться чувствительные медицинские данные пациентов - всё становится на порядок сложнее. Это обеспечено как законодательством страны, в которой Вы запускаете приложение, так и требованиями платёжных служб, которые этому правовому полю подчиняются. И требований к нам было много. Пришлось сделать множество изменений, нас не приняли ни с первого ни со второго раза. Мы подвались в разные платёжные аггрегаторы и банки. И первое время это был тупик - нам везде отказывали. Важной спецификой платёжек является то, что в последнее время они как сговорились - они не объясняют конкретную причину отказа, просто ссылаются на законы и регламенты, "думайте сами что не так". И лишь опыт предыдущих проектов и настойчивость помогли нам изменить приложение и создать необходимые юридические материалы, которые в конечном итоге позволили нам запуститься с платёжной системой Фонди (ныне этот шлюз под другим брендом). У нас было зарегистрировано ТОВ (ООО) - общество с ограниченной ответственностью, это помогло нам получить доверие. Но мы не хотели на старте создавать сайт, не хотели портить интерфейс приложения лишними согласиями со стороны пользователя, не хотели добавлять лишнюю информацию. Но мир не вертится вокруг того что мы хотели, потому нам пришлось внедрять множество задач, которые изначально делать не хотелось. И таким образом наша и так усложнившаяся MVP усложнилась еще сильнее. Тут еще можно рассказать про разные нюансы хранения данных и размещения на сервер-провайдерах, это тоже как оказалось играло важную роль и не позволяло стартовать, но об этом может напишем в отдельной статье про платёжные сервисы.

Сайт и лендинг

И таким образом у нас появился сайт лендинг. У нас был сайт и раньше, но он был скорее просто презентацией, а не корпоративным объектом. Пришлось его сильно переделать, оптимизировать, дополнить информацией, сделать более прозрачным для государства, банков и комиссий платёжных систем. Также в связи с планами на различные акселерационные программы и поиск инвестиций на маркетинг мы сразу сделали и английскую версию сайта (итого была украинская и английская).

Вызовы и проблемы

(Далее набросаем тезисно про проблемы и вызовы, особенности построения не только приложения и сервера, но и самой компании, позже допишем это всё подробно, пока нет времени)

Участники команды и партнёры-сооснователи

Амбициозные глобальные планы

ТОВ, орг-структура, роли

Отсутствие достаточного бюджета

Цели, план-факты

Рабочие циклы, конвейер взаимодействия

Изменения в команде

Бизнес-требования, ТЗ, аналитика

Дизайн, визуализация, изменения

Проектирование архитектуры приложения и сервера

Анализ и программное внедрение схемы женской онкологии

Минимализм - убрать всё лишнее

Безопасность и анонимизация пользователей

Разработка базы данных и административных экранов

Разработка приложения

Разработка серверного АПИ

Юридические вопросы, обработка данных

Проблемы с платежными системами

Моделирование портрета клиента, запуск рекламы

Первые пользователи и прохождения

Гарвардский хакатон и Лита доктор

Первые продажи

Технологии

React - набор библиотек для разработки реактивных веб-интерфейсов.

SFL - Структурный фрактальный язык - автоматизирует прототипирование баз данных, АПИ и документации.

PHP - Основной и самый популярный язык для веб-разработки.

JavaScript - Основной и самый популярный язык для программирования браузерных компонентов.

HTML - Язык разметки для структуры веб-приложений и сайтов.

CSS - Язык каскадных стилей для создания внешнего вида веб-страниц.

Linux - Самая надёжная ОС для серверов и бизнес-приложений в контексте веб.

BASH - Скриптовый язык для автоматизации системных и инфраструктурных задач.

Docker - Платформа для контейнеризации, изоляции процессов и развертывания приложений.

Docker-Compose - Инструмент для упрощенной оркестрации контейнеров в многоконтейнерном приложении.

Fast CGI PM - Менеджер процессов, оптимизирует и позволяет обрабатывать больше запросов одновременно чем упрощает масштабирование.

MySQL - Самая популярная система управления реляционными базами данных SQL.

Nginx - Высокопроизводительный веб-сервер и прокси, самый популярный в мире.

Fractal - Фреймворк разработанный ingello для автоматизации процессов разработки приложений и оптимизации бюджетов на проект.

Yii2 components - Компоненты самого высокопроизводительного PHP фреймворка.

Symfony components - Переиспользуемые компоненты самого структурного PHP фреймворка.