Привет! Я — Вера Осолодкина, работаю аккаунт-директором в диджитал-продакшене Далее. Сегодня хочу рассказать о разработке медицинского сервиса для МЕДСИ, который из MVP превратился в полноценный продукт. Это один из самых интересных проектов в моем послужном списке и в целом полезная штука для мониторинга своего здоровья.
Перед моей командой поставили задачу разработать MVP сервиса для контроля здоровья. Своего рода дневник наблюдений для врачей и пациентов. В основе дневника — опросы, которые врач запускает в личном кабинете и отправляет пациенту. С помощью дневника можно отслеживать прогресс лечения, запрашивать обратную связь от пациента при назначении процедур, препаратов, контролировать самочувствие и изменения.
С чего начали
На старте у нас был бриф с верхнеуровневым описанием решения и его функциональных характеристик. Этот бриф мы расширили и уточнили, согласовали с клиентом и пошли на стадию аналитики.
На основе брифа сформировали техническое задание, декомпозировали отдельные блоки будущего решения, прописывали требования и характеристики и начали проектировать и отрисовывать эскизы.
В процессе работы команда МЕДСИ вошла во вкус. Макеты и функциональность согласовывала не только продуктовая команда со стороны МЕДСИ, но и врачи — одни из конечных пользователи сервиса. Требований и пожеланий становилось больше, продукт из MVP начал превращаться в полноценный сервис.
На этапе создания концепции и брифа порой сложно представить конечный результат, тем более, когда работаешь с принципиально новым решением. Понимание, что именно хочется получить на выходе, у клиента складывалось в процессе работы над проектом. Поэтому мы много времени уделяли аналитике, максимально четко прописывали функциональные требования решения, модулей и экранов.
Опросы и админка — главная первичная сущность
Создание прототипов и демо начали с админки. Это логично, потому что в основе сервиса лежит сущность опросов, которая создается и запускается из административной панели.
В системе есть несколько типов вопросов: с выбором одного или нескольких вариантов, открытые, открытые с референсными значениями, вопросы с картинкой, которую подгружает пациент.
Цель опроса — быстро оценить состояние пациента. Поэтому сервис не просто собирает информацию от пациента, но и анализирует. Для удобства аналитики ответам можно присвоить значение (индекс) и выбрать цветовой код.
Опросы создаются в привязке к диагнозу или к назначению. Например, в случае когда опрос касается не оценки общего состояния, а реакции пациента на препарат.
После того, как мы согласовали функциональность и эскизы админки, перешли к работе над двумя другими сущностями сервиса: врачи и пациенты.
С ростом изменений и расширения функциональности админ-панели, требования к двум другим разделам, «Врачи» и «Пациенты», тоже выросли. Потребовалось больше времени, чтобы их систематизировать, а сроки работы над админкой и так растянулись. Но так как функциональность опросов и общая логика работы всей системы уже была зафиксирована, мы смогли запараллелить процесс аналитики и бэкенд-разработки.
Функциональность для врачей и пациентов
Врачи в сервисе могут добавлять и редактировать списки пациентов, просматривать информацию о них, назначать опросы, устанавливать их длительность и регулярность и анализировать результаты.
Опросы разделяются на опросы качества жизни и общего состояния. Цветовые коды помогают быстро среагировать, если что-то идет не так — отклонения от референсных значений помечаются красным. Результаты доступны в разбивке по датам.
В модуле сервиса для врача есть не только аналитика по опросам, но и по препаратам и назначениям. Врач может посмотреть результаты исследований, регулярность приема назначенных препаратов.
Пациенты подключаются к сервису через платформу SmartMed, в личном кабинете им доступны назначения, препараты и опросы, которые назначил врач.
Фронтенд-разработка и дизайн
В МЕДСИ есть внутренние стандарты и правила для разработки IT-решений. Они касаются не только используемых языков разработки, но и компонентов. Так, фронтенд сервиса должен был быть написан на Vue.js с использованием библиотек, которые применяются в МЕДСИ.
В дизайне тоже есть свои требования. Несмотря на то, что мы делали предварительную аналитику по дизайну, UX-исследования и с первого раза достаточно точно попали в ожидания, часть элементов пришлось менять в соответствии с правилами МЕДСИ.
Например, просто отрисовать раскрывающееся меню мы не могли — нужно было ориентироваться на доступные подобные элементы в библиотеке. Если подходящего элемента нет, но без него не обойтись — мы шли к клиенту, согласовывали эти изменения, а они добавляли в библиотеку дополнительный элемент.
Конечно, это было не просто и трудозатратно, но плюсы такого подхода мы тоже ощутили. Так как проект сильно вырос в объемах относительно первого согласованного брифа, часть задач закрывала команда МЕДСИ: дизайн и разработку фронтенда некоторых элементов. Единый подход к дизайну и разработке упростил взаимодействие между командами, передать ТЗ было проще, чем если бы мы писали сервис по своим стандартам.
Бэкенд и интеграции
Чтобы написать этот раздел, я сходила к нашему разработчику, Дане Лихачеву. Все, что идет дальше, написано с его слов.
Дневник можно считать самостоятельным приложением, встроенным в микросервисную архитектуру приложения МЕДСИ SmartMed и связанным в нескольких местах с их сервисами.
Изначально Дневник наблюдений планировался как отдельное приложение, который работает через редиректы и лежит не в контуре клиента. Но так как в процессе работы требования изменились, его нужно было интегрировать в инфраструктуру МЕДСИ, соединив его со SmartMed. Причем таким образом, чтобы для пользователей приложения этот переход был бесшовным.
Чтобы этого достичь, мы использовали аутентификацию через один из сервисов клиента. Эта интеграция была запланирована в финальной части разработки, но архитектурно заложили ее сразу, написав код для валидации.
Кроме привязок пользователей мы делали интеграцию чата с системой МЕДСИ. У клиента существовал бэкенд чата и компоненты, которые можно было использовать на фронте в части приложения для врачей, но не пациентов.
Поэтому фронт чата для врачей мы дорабатывали, а для пациентов писали с нуля. Далее интегрировали фронт с бэком дневника, который, в свою очередь, инициирует gRPC-запрос в бэкенд МЕДСИ на создание чата. После создания чата нашим бэкендом, фронт связывается непосредственно с сервисом чатов у МЕДСИ и обрабатывает переписку уже на их стороне.
Эти и другие интеграционные требования мы прорабатывали вместе с клиентом. К нам подключился аналитик со стороны МЕДСИ, которая описывала межсервисные интеграции. Это помогло нам не тратить время на исследования сервисов и сразу перейти к поиску решений для интеграций.
Другим требованием была разработка на Python. Нам предложили использовать темплейт приложения на FastAPI с SQLAlchemy с дополнительными внутренними либами под FastAPI. Но возникли сложности. SQLAlchemy хоть и является неким стандартом, который часто используют с FastAPI, нам работать с ней было неудобно.
В какой-то момент мы поняли, что разрабатывать на SQLAlchemy будет слишком трудозатратно, да и качество кода было посредственным из-за определенных решений в библиотеке. Поэтому с частью готового кода мы решили переехать на другую ORM, Tortoise ORM. Она вдохновлена DJango ORM, но при этом асинхронная. Пощупав ее вне проекта, мы начали медленно мигрировать.
Сначала просто добавили в проект, затем начали переписывать имеющийся код, и в самом конце окончательно убрав SQLAlchemy с проекта, мы поняли, что не ошиблись. Количество боли, строк кода и времени сократилось раза в два, если не больше, при переходе на Tortoise ORM. Хотя у нас уже и был работающий функционал, перенести его на новую ORM заняло меньше одного дня.
Схема релизов тоже заслуживает упоминания. Изначально мы поднимали бэкенд на своих серверах, затем развернули его на препроде в контуре МЕДСИ. На прод клиент выкатывает бэкенд самостоятельно и делает это быстро и без проблем, так как мы учли все требования и особенности инфраструктуры МЕДСИ.
С учетом этих требований нам также нужно было либо держать репозиторий в гитлабе клиента, чтобы было не очень удобно для команды, либо решать вопрос с автоматизацией контроля версий. Мы выбрали второй вариант. Придумали скрипт, который переносит все изменения из нашего репозитория к команде МЕДСИ, и наоборот.
Что в результате
У нас было много жестких требований к разработке и архитектуре решения. Проект сильно расширился в процессе работы, приходилось быстро перестраиваться и искать способы оптимизации трудозатрат.
Я считаю, что правильным решением с нашей стороны было не стесняться тратить время на аналитику. Благодаря этому мы избежали сложностей, связанных с тем, что клиенту может что-то не понравиться, а прогресс разработки уже такой, что вносить изменения и откатывать очень дорого. С проектами, в которых требований много и они регулярно обновляются такие риски особенно высоки. А значит аналитика становится особенно важной.
Помогла и слаженная работа с командой МЕДСИ. Договариваться приходилось много: из-за изменений в требованиях менялся скоуп работ и наши трудозатраты, нужно было пересматривать часть функционала, что-то сокращать. Нам всегда удавалось прийти к оптимальному решению в таких случаях.
За счет того, что МЕДСИ взяли на себя часть работ по проекту, сроки запуска не сильно пострадали. Продукт действительно стал гораздо сложнее и объемнее относительно запланированного MVP, но зато не потерял в качестве.
ссылка на оригинал статьи https://habr.com/ru/articles/852236/
Добавить комментарий