Бизнес развивает свои IT-продукты постоянно. «Остановить мгновение» здесь нельзя, иначе даже лучшая программа неизбежно устареет. Рассказываем, как мы создавали новую версию медицинского приложения для Европы и какие проблемы при этом решили.

Приложение для госпиталей

Мы работаем с медицинским приложением для госпиталей Европы. Оно помогает докторам уделять пациентам больше времени, сократив объемы бумажной работы. Доктора надиктовывают информацию о пациентах и осмотрах, приложение переводит аудиозаписи в текстовый формат, заполняет шаблон и формирует документы для медицинских работников и пациентов. На каждой стадии работы заложена своя бизнес-логика и интеграция с несколькими внешними системами.

Клиент поставил перед нами задачу разработать новую версию приложения для демонстрации инвесторам.

Детали проекта

Аудио

Как записывали аудио в версии 2.0:

1. Открывали приложение.
2. Нажимали на кнопку добавления записи.
3. Выбирали в появившемся окне нужный вариант записывающего устройства.
4. Надиктовывали аудио-запись.
5. Вводили номер пациента, дату визита, номер визита (визит = приём врача).
6. Нажимали кнопку Complete для загрузки на сервер аудиозаписи и данных о визите.

Теперь, в версии 3.0 для записи нужно приложить меньше усилий:

1. Доктор открывает приложение.
2. Выбирает прием (по дате, времени, номеру или имени пациента) из списка и кликает 1 раз для открытия карточки визита.
3. Записывает аудио.
4. Нажимает кнопку Complete для отправки аудио на сервер.

В версии 3.0 работа доктора максимально автоматизирована. Количество операций сократилось, при этом программа сама добавляет данные о пациентах.

Работа с письмами

Работа с письмами тоже стала проще. В версии 2.0 была сложная очередь их обработки. Доктор не мог получить сразу полный список писем – только частями и в определенном порядке. Чтобы начать работу, нужно было:

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

В версии 3.0 доктор видит все письма, доступные для обработки. Он может выбрать документ двумя способами – либо вручную в списке, либо с помощью фильтров и сортировок (их можно сохранить, чтобы далее открывать письмо одним кликом). Для открытия письма достаточно кликнуть один раз.

Интерфейс

В целом, интерфейс версии 2.0 был громоздким и неудобным. Первоначально задачей приложения было сэкономить время медицинских специалистов за счет сокращения бумажного документооборота и работы с аудиозаписями. На практике приложение справлялось с этой задачей не настолько хорошо, как хотелось бы. Для того, чтобы сделать запись, доктору нужно было выбирать множество настроек в длинных выпадающих списках.

Наши эксперты поработали с интерфейсом и вынесли на первый план кнопку аудиозаписи, чтобы пользователи могли выполнить свою задачу за наименьшее количество кликов.

Далее расскажем подробности о том, как мы разрабатывали новую версию.

Новые потребности

Когда клиент обратился к нам для модернизации версии 2.0, приложение работало уже около трех лет. Оно было хорошо знакомо пользователям и имело определенные преимущества:

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

Однако, при анализе работы приложения мы нашли такие проблемы:

• разработка и тестирование новых возможностей занимали все больше времени;
• при добавлении новых функций в системе появлялись ошибки;
• в результате до 30% сложных доработок откладывались в долгий ящик, что грозило устареванием приложения. Например, в госпиталях появлялись все более сложные шаблоны, нужно было добавлять новые роли в Workflow;
• архитектура приложения не могла поддерживать новые решения;
• на поддержку приходилось тратить 40% от времени разработки;
• возникали сложности при установке новых версий и обновлений десктоп-продукта;
• громоздкий интерфейс 2000-х годов отпугивал новых клиентов;
• неудобная система настроек мешала быстро запустить систему, а также увеличивала риски ошибок.

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

Требования к новой версии

Мы проанализировали функции приложения и выделили наиболее важные, которые делали продукт ценным для бизнеса. На основе этих данных мы определили, какой должна быть программа в новой версии:

• нужны интуитивно понятные для докторов и других пользователей ключевые функции приложения;
• пользователям – медработникам и службе поддержки – должно быть легко обучаться работе с программой;
• исключить потерю данных даже при экстремальных условиях (перебои с электричеством, нестабильный доступ в интернет и т.д.);
• документы, сгенерированные системой, должны соответствовать нормам и требованиям законодательства;
• во время обновлений системы возможные неудобства для пользователя и службы поддержки нужно свести к минимуму;
• необходимо создать сервис-ориентированную модульную архитектуру на базе распределенных, слабосвязанных компонентов, что позволит использовать их для выстраивания сложных программных комплексов;
• использовать Active Directory для единообразия настроек рабочей среды.

К тому же нельзя было допустить, чтобы новая версия оказалась «усложненным клоном» старой. Поэтому ключевые функции нужно было сохранить, но не перегружая приложение. Мы безжалостно отказались от избыточных сложных настроек.

Бизнес-аналитики, работавшие с версией 2.0, не сразу приняли изменения. В техзадании часто встречались фразы: «Здесь должно быть как в версии 2.0», «Возьмите схему работы в версии 2.0». Самым сложным на этом этапе было сопротивление соблазну взять все, как в предыдущей версии.

Команда проекта

Как правило, мы в SimbirSoft на старте каждого проекта подключаем к команде экспертов разных профилей – аналитиков, специалистов по обеспечению качества (QA) и других. При работе над медицинским приложением мы собрали следующую команду:

• разработчики, которые писали код и адаптировали функции версии 2.0;
• специалисты по обеспечению качества (QA). Они вместе с разработчиками разбирались в унаследованном коде, архитектурных решениях и ошибках версии 2.0, а также тестировали новые функции;
• Инженер по автоматизации тестирования (SDET), который настроил автоматическую проверку тест-кейсов в десктопной и веб-версии;
• Бизнес-аналитики. Они общались с заказчиком и медиками, выясняли, как построены бизнес-процессы, какие есть требования и пожелания к приложению. После этого они составили схемы бизнес-процессов, понятные для всей команды;
• Дизайнер и эксперт по юзабилити. Они отвечали за разработку удобного интерфейса.
• Проектный менеджер, который занимался управлением и планированием времени.

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

Сложности и решения

При модернизации приложения мы столкнулись с несколькими сложными этапами, о которых расскажем ниже.

Дизайн приложения

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

Разработка плагина для разных браузеров

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

Неверные гипотезы от бизнеса

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

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

Интеграция с внешними системами

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

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

• собрать общую информацию о том, как работают системы отправки писем;
• составить список критических багов, которые были в 2.0;
• рассмотреть эти кейсы на этапе аналитики и разработки, чтобы учесть их и не наступать на те же грабли;
• проанализировать, подходят ли функции версии 2.0 к процессам версии 3.0 или нужно что-то менять. В случае изменений каждый раз уточнять, для чего нужны конкретные функции, и общаться с техническими специалистами заказчика, а не только с аналитиками.

В процессе переговоров с заказчиком мы смогли доказать, что работа с интеграцией требует времени. Наш партнер согласился с нами: нельзя просто взять и перенести код из одной версии в другую.

Проведение тестирования и аналитики

Прошлая версия проекта создавалась без участия аналитиков. Разработчики и QA-специалисты уточняли требования в процессе создания приложения. Третья версия уже была основана на требованиях аналитиков, однако, все еще оставались сложности с тестированием:

• над проектом работали разные команды;
• существовал большой объем параллельных задач;
• в процессе спринта часто менялись требования и задачи;
• требовалось учитывать взаимодействие новых фич с уже утвержденными.

Для работы над новой версией продукта нам потребовалось преобразовать отдельные рабочие процессы, например:

• Мы усилили аналитику со стороны разработки и QA и заложили на это дополнительные часы.
• Взяли за правило указывать цели проверяемой функции в требованиях на ревью. Это улучшило понимание задач для аналитиков и обеспечило возможность предложить оптимальное решение.
• Для уточнения сроков работы мы изменили терминологию: вместо приблизительной оценки в часах стали классифицировать задачи как “большие” либо “небольшие”. Время выполнения мы стали рассчитывать только после полного ревью задачи со стороны разработки, QA и утверждения итоговой версии требований со стороны заказчика. Если задача расширялась, то мы пересчитывали оценку временных затрат.
• Мы стали планировать, какие функции нужно реализовать в ближайшие кварталы - на 2-3 следующих релиза. Для того, чтобы точнее прогнозировать разработку, мы больше не включали в план на релиз те задачи, которые не прошли оценку.
• Для удобства аналитиков и лучшего понимания системы мы указывали в чек-листах, какие взаимодействия нужно учесть при составлении требований. Также мы разработали единые правила оформления статей в Confluence и документации в JIRA и стали их придерживаться.

Регулярные онлайн-митинги с заказчиком помогли нам улучшить понимание его бизнес-процессов. Во время общения наш партнер рассказывал подробности о том, как работают доктора, и пояснял бизнес-цели. Мы, в свою очередь, объясняли технические нюансы и показывали различные неочевидные кейсы. Это позволило нам сформировать требования к продукту, которые покрывают потребности медицинских учреждений и оптимальны с точки зрения затрат на реализацию.

Итоги

Гибкость в рабочих процессах и внимание к потребностям бизнеса позволили нам преодолеть все сложности, которые возникали в процессе разработки. Мы успешно сделали и запустили новую версию приложения для медицинских учреждений Европы.

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

При создании новой версии продукта разработчики, как правило, сталкиваются с теми же проблемами, что и мы, например:

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

Главное, что выпуск новой версии IT-продукта - это не копирование кода «Ctrl+С», «Ctrl+V» из предыдущей версии, а полноценная разработка, практически с нуля. Это происходит потому, что меняются бизнес-процессы, требования пользователей, а также ситуация на рынке IT-решений.

Спасибо за внимание! Надеемся, что статья была для вас полезна.