Версия 3.0: Сделайте Ее Лучше

Предприятия постоянно совершенствуют свои ИТ-продукты.

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

Заявка для больниц

Это помогает врачам проводить больше времени с пациентами за счет сокращения бумажной работы.

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

Каждый этап работы имеет свою бизнес-логику и интеграцию с несколькими внешними системами.

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

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

Аудио

1. Открыл приложение.

2. Нажал кнопку добавить запись.

3. В появившемся окне выберите нужный вариант записывающего устройства.

4. Была продиктована аудиозапись.

5. Введите номер пациента, дату визита, номер визита (визит = запись к врачу).

6. Нажмите кнопку «Завершить», чтобы загрузить аудиозапись и данные о посещениях на сервер.

1. Врач открывает приложение.

2. Выбирает встречу (по дате, времени, номеру пациента или имени) из списка и щелкает один раз, чтобы открыть карточку посещения.

3. Записывает звук.

4. Нажимает кнопку «Завершить», чтобы отправить аудио на сервер.

Количество операций уменьшено, при этом программа сама добавляет данные о пациенте.

Работа с буквами

В версии 2.0 была сложная очередь на их обработку.

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

Для начала вам понадобилось:

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

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

Чтобы открыть письмо, достаточно нажать один раз.

Интерфейс

Изначально целью приложения была экономия времени медицинских специалистов за счет сокращения документооборота и работы с аудиозаписями.

На практике с этой задачей приложение справилось не так хорошо, как хотелось бы.

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

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

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

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

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

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

  Например, в больницах появлялись все более сложные шаблоны; в Workflow пришлось добавить новые роли;

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

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

На основе этих данных мы определили, какой должна быть программа в новой версии:

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

Поэтому ключевые функции нужно было сохранить, но не перегружать приложение.

Мы безжалостно исключили ненужные сложные настройки.

Бизнес-аналитики, работавшие с версией 2.0, не сразу приняли изменения.

В техзадании часто содержались такие фразы: «Должно быть как в версии 2.0», «Возьмите схему работы в версии 2.0».

Самым сложным на этом этапе было устоять перед искушением взять все, как и в предыдущем варианте.

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

В ходе работы над медицинским приложением мы собрали следующую команду:

• разработчики, написавшие код и адаптировавшие возможности версии 2.0;
• Специалисты по обеспечению качества (QA).

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

• Инженер по автоматизации тестирования (SDET), настроивший автоматическую проверку тест-кейсов в десктопной и веб-версии;
• Бизнес-аналитики.

  Пообщались с заказчиком и врачами, выяснили, как устроены бизнес-процессы, какие требования и пожелания к приложению.

  После этого создали диаграммы бизнес-процессов, понятные всей команде;

• Дизайнер и эксперт по юзабилити.

  Они отвечали за разработку удобного интерфейса.

• Менеджер проекта, который занимался тайм-менеджментом и планированием.

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

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

Трудности и решения

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

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

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

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

Например, выбранный для реализации плагин может не подойти для некоторых интернет-браузеров.

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

В дальнейшем мы потихоньку модифицировали плагин для других браузеров.

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

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

Мы проанализировали некоторые гипотезы заказчика и отказались от их реализации.

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

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

Однако в реальном мире эта функция не имела успеха, поэтому в конечном итоге ее отключили.

Позже календарь был адаптирован под нужды другой группы пользователей — пациентов, а не медицинских работников.

Ложные гипотезы — неотъемлемая часть бизнеса, и к ним нужно быть готовым.

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

Пользователи приложения ─ медицинские учреждения ─ хотели использовать старые, привычные системы интеграции для версии 3.0; их нельзя было изменить.

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

Однако на самом деле с интеграцией было много проблем:

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

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

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

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

Разработчики и специалисты по контролю качества уточнили требования в процессе создания приложения.

Третья версия уже была основана на требованиях аналитиков, однако с тестированием все еще были сложности:

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

• Мы усилили аналитику по части разработки и QA и выделили для этого дополнительные часы.

• Мы взяли за правило указывать цели тестируемой функции в требованиях к обзору.

  Это улучшило понимание проблемы аналитиками и позволило им предложить оптимальное решение.

• Для уточнения сроков работы мы изменили терминологию: вместо примерной оценки в часах мы стали классифицировать задачи на «большие» или «маленькие».

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

  Если задача расширялась, то мы пересчитывали оценку времени.

• Мы начали планировать, какие функции необходимо реализовать в ближайшие кварталы ─ на ближайшие 2-3 релиза.

  Чтобы точнее прогнозировать развитие, мы больше не включали в план релиза те задачи, которые не прошли оценку.

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

  Также мы разработали единые правила оформления статей в Confluence и документации в JIRA и стали их придерживаться.

В ходе беседы наш партнер поделился подробностями о том, как работают врачи, и объяснил цели бизнеса.

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

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

Полученные результаты

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

В настоящее время мы продолжаем развивать продукт и внедрять новые функции.

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

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

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

Это происходит потому, что меняются бизнес-процессы, требования пользователей и ситуация на рынке ИТ-решений.

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

Теги: #Управление разработкой #Управление проектами #qa #тестирование #Тестирование веб-сервисов #аналитика #Веб-аналитика #scrum #бизнес-процессы #юзабилити

• Чашки - Свежезаваренный Кофе, Чай И Другие Напитки По Абонементу

  19 Oct, 24

• Выпущен Стандарт Unicode 6, Более 2000 Дополнительных Символов

  19 Oct, 24

• Установка Сборки Zimbra 9 Ose От Zextras На Centos 8

  19 Oct, 24

• Контрольный Список При Подготовке Презентации

  19 Oct, 24

• Исследование Феномена «Цветного Слуха» Показало, Что Большинство Этих Людей «Видят» Буквы Одного Цвета.

  19 Oct, 24

• Новый Участник Рынка Квантовых Вычислений С Уникальной Технологией

  19 Oct, 24

• Опубликованы Цены На Облачный Photoshop

  19 Oct, 24

• Реклама Появилась Во Вконтакте...

  19 Oct, 24

• Продолжение. Распространенные Ошибки В Настройках Nginx, Делающие Веб-Сервер Уязвимым

  19 Oct, 24

• Диванный Маркетинг Мобильной Игры (120 000 Установок За Первый Месяц. Совпадение?)

  19 Oct, 24