Версия 3.0: сделать лучше

    Бизнес развивает свои 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-решений.

    Спасибо за внимание! Надеемся, что статья была для вас полезна.
    SimbirSoft
    92,44
    Лидер в разработке современных ИТ-решений на заказ
    Поделиться публикацией

    Комментарии 2

      0

      Статья интересная, но судя по всему автор связан NDA. Очень не хватает визуализации описанных решений.

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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое