Привет! Мы — диджитал-продакшен Далее. Сегодня делимся кейсом разработки медицинского сервиса для МЕДСИ, который из MVP превратился в полноценный продукт. Потратили 1500 часов на разработку, еще 300 на аналитику и отловили 189 багов. Все для того, чтобы современные пациенты могли эффективно наблюдаться у врачей и получать индивидуальный план лечения в смартфоне.
Что за сервис
МЕДСИ, наш постоянный клиент, пришел к нам с задачей разработать MVP сервиса для контроля здоровья. Своего рода дневник наблюдений для врачей и пациентов, который станет частью платформы МЕДСИ SmartMed. В основе дневника — опросы, которые врач запускает в личном кабинете и отправляет пациенту.
Задача приложения — отслеживать прогресс лечения, запрашивать обратную связь от пациента при назначении процедур, препаратов, контролировать самочувствие и изменения.
С чего начали
На старте у нас был бриф от клиента с верхнеуровневым описанием решения и его функциональных характеристик. Этот бриф мы расширили и уточнили, согласовали с клиентом и пошли на стадию аналитики.
На основе брифа сформировали техническое задание, декомпозировали отдельные блоки будущего решения, прописывали требования и характеристики и начали проектировать и отрисовывать эскизы.
В процессе работы клиент вошел во вкус. Макеты и функциональность согласовывала не только продуктовая команда со стороны МЕДСИ, но и врачи — одни из конечных пользователи сервиса. Требований и пожеланий становилось больше, продукт из MVP начал превращаться в полноценный сервис.
На этапе создания концепции и брифа порой сложно представить конечный результат, тем более, когда работаешь с принципиально новым решением. Понимание, что именно хочется получить на выходе, у клиента складывалось в процессе работы над проектом. Поэтому мы много времени уделяли аналитике, максимально четко прописывали функциональные требования решения, модулей и экранов.
Опросы и админка — главная первичная сущность
Создание прототипов и демо начали с админки. Это логично, потому что в основе сервиса лежит сущность опросов, которая создается и запускается из административной панели.
В системе есть несколько типов вопросов: с выбором одного или нескольких вариантов, открытые, открытые с референсными значениями, вопросы с картинкой, которую подгружает пациент.
Цель опроса — быстро оценить состояние пациента. Поэтому сервис не просто собирает информацию от пациента, но и анализирует. Для удобства аналитики ответам можно присвоить значение (индекс) и выбрать цветовой код.
Опросы создаются в привязке к диагнозу или к назначению. Например, в случае когда опрос касается не оценки общего состояния, а реакции пациента на препарат.
После того, как мы согласовали функциональность и эскизы админки, перешли к работе над двумя другими сущностями сервиса: врачи и пациенты.
С ростом изменений и расширения функциональности админ-панели, требования к двум другим разделам, «Врачи» и «Пациенты», тоже выросли. Потребовалось больше времени, чтобы их систематизировать, а сроки работы над админкой и так растянулись. Но так как функционал опросов и общая логика работы всей системы уже была зафиксирована, мы смогли запараллелить процесс аналитики и бэкенд-разработки
Функциональность для врачей и пациентов
Врачи в сервисе могут добавлять и редактировать списки пациентов, просматривать информацию о них, назначать опросы, устанавливать их длительность и регулярность и анализировать результаты.
Опросы разделяются на опросы качества жизни и общего состояния. Цветовые коды помогают быстро среагировать, если что-то идет не так — отклонения от референсных значений помечаются красным. Результаты опросов доступны в разбивке по датам.
В модуле сервиса для врача есть не только аналитика по опросам, но и по препаратам и назначениям. Врач может посмотреть результаты исследований, регулярность приема назначенных препаратов.
Пациенты подключаются к сервису через платформу SmartMed, в личном кабинете им доступны назначения, препараты и опросы, которые назначил врач.
Врачам и пациентам в сервисе доступны чаты и планирование онлайн-консультации.
Фронтенд-разработка и дизайн
В МЕДСИ есть внутренние стандарты и правила для разработки IT-решений. Они касаются не только используемых языков разработки, но и компонентов. Так, фронтенд сервиса должен был быть написан на Vue.js с использованием библиотек, которые применяются в МЕДСИ.
В дизайне тоже есть свои требования. Несмотря на то, что мы делали предварительную аналитику по дизайну, UX-исследования и с первого раза достаточно точно попали в ожидания клиента, часть элементов пришлось менять в соответствии с правилами МЕДСИ.
Например, просто отрисовать раскрывающееся меню мы не могли — нужно было ориентироваться на доступные подобные элементы в библиотеке. Если подходящего элемента нет, но без него не обойтись — мы шли к клиенту, согласовывали эти изменения, а они добавляли в библиотеку дополнительный элемент.
Конечно, это было не просто и трудозатратно, но плюсы такого подхода мы тоже ощутили. Так как проект сильно вырос в объемах относительно первого согласованного брифа, часть задач закрывал клиент: дизайн и разработку фронтенда некоторых элементов. Единый подход к дизайну и разработке упростил взаимодействие между командами, передать ТЗ было проще, чем если бы мы писали сервис по своим стандартам.
Еще сейчас МЕДСИ меняют дизайн-систему. Элементы в нашем сервисе обновятся автоматически, не придется ничего перерисовывать и тратить время на доработки и изменения.
Бэкенд и интеграции
Дневник можно считать самостоятельным приложением, встроенным в микросервисную архитектуру приложения МЕДСИ SmartMed и связанным в нескольких местах с их сервисами.
Изначально Дневник наблюдений планировался как отдельное приложение, который работает через редиректы и лежит не в контуре клиента. Но так как в процессе работы требования изменились, его нужно было интегрировать в инфраструктуру МЕДСИ, соединив его со SmartMed. Причем таким образом, чтобы для пользователей приложения этот переход был бесшовным.
Чтобы этого достичь, мы использовали аутентификацию через один из сервисов клиента. Эта интеграция была запланирована в финальной части разработки, но архитектурно заложили ее сразу, написав код для валидации.
Схема релизов тоже заслуживает упоминания. Изначально мы поднимали бэкенд на своих серверах, затем развернули его на препроде в контуре МЕДСИ. На прод клиент выкатывает бэкенд самостоятельно и делает это быстро и без проблем, так как мы учли все требования и особенности инфраструктуры МЕДСИ.
С учетом этих требований нам также нужно было либо держать репозиторий в гитлабе клиента, чтобы было не очень удобно для команды, либо решать вопрос с автоматизацией контроля версий. Мы выбрали второй вариант. Придумали скрипт, который переносит все изменения из нашего репозитория к команде МЕДСИ, и наоборот.
Что в результате
У нас было много жестких требований к разработке и архитектуре решения. Проект сильно расширился в процессе работы, приходилось быстро перестраиваться и искать способы оптимизации трудозатрат.
Я считаю, что правильным решением с нашей стороны было не стесняться тратить время на аналитику. Благодаря этому мы избежали сложностей, связанных с тем, что клиенту может что-то не понравиться, а прогресс разработки уже такой, что вносить изменения и откатывать очень дорого. С проектами, в которых требований много и они регулярно обновляются такие риски особенно высоки. А значит аналитика становится особенно важной
Помогла и слаженная работа с клиентом. Договариваться приходилось много: из-за изменений в требованиях менялся скоуп работ и наши трудозатраты, нужно было пересматривать часть функционала, что-то сокращать. Нам всегда удавалось прийти к оптимальному решению в таких случаях.
За счет того, что МЕДСИ взяли на себя часть работ по проекту, сроки запуска не сильно пострадали. Продукт действительно стал гораздо сложнее и объемнее относительно запланированного MVP, но не потерял в качестве.
С нетерпением ждем результатов пилота и готовимся к следующей итерации доработок.
Команда проекта
Вера Осолодкина — руководитель проекта
Влад Климанов — Lead backend-разработчик
Даниил Лихачев — Backend-разработчик
Юля Зубова — руководитель отдела аналитики
Яна Марченкова — frontend-разработчица
Валерия Лашко — продуктовый дизайнер
Станислав Репков — QA
