Бизнес развивает свои IT-продукты постоянно. «Остановить мгновение» здесь нельзя, иначе даже лучшая программа неизбежно устареет. Рассказываем, как мы создавали новую версию медицинского приложения для Европы и какие проблемы при этом решили.
Мы работаем с медицинским приложением для госпиталей Европы. Оно помогает докторам уделять пациентам больше времени, сократив объемы бумажной работы. Доктора надиктовывают информацию о пациентах и осмотрах, приложение переводит аудиозаписи в текстовый формат, заполняет шаблон и формирует документы для медицинских работников и пациентов. На каждой стадии работы заложена своя бизнес-логика и интеграция с несколькими внешними системами.
Клиент поставил перед нами задачу разработать новую версию приложения для демонстрации инвесторам.
Как записывали аудио в версии 2.0:
Теперь, в версии 3.0 для записи нужно приложить меньше усилий:
В версии 3.0 работа доктора максимально автоматизирована. Количество операций сократилось, при этом программа сама добавляет данные о пациентах.
Работа с письмами тоже стала проще. В версии 2.0 была сложная очередь их обработки. Доктор не мог получить сразу полный список писем – только частями и в определенном порядке. Чтобы начать работу, нужно было:
В версии 3.0 доктор видит все письма, доступные для обработки. Он может выбрать документ двумя способами – либо вручную в списке, либо с помощью фильтров и сортировок (их можно сохранить, чтобы далее открывать письмо одним кликом). Для открытия письма достаточно кликнуть один раз.
В целом, интерфейс версии 2.0 был громоздким и неудобным. Первоначально задачей приложения было сэкономить время медицинских специалистов за счет сокращения бумажного документооборота и работы с аудиозаписями. На практике приложение справлялось с этой задачей не настолько хорошо, как хотелось бы. Для того, чтобы сделать запись, доктору нужно было выбирать множество настроек в длинных выпадающих списках.
Наши эксперты поработали с интерфейсом и вынесли на первый план кнопку аудиозаписи, чтобы пользователи могли выполнить свою задачу за наименьшее количество кликов.
Далее расскажем подробности о том, как мы разрабатывали новую версию.
Когда клиент обратился к нам для модернизации версии 2.0, приложение работало уже около трех лет. Оно было хорошо знакомо пользователям и имело определенные преимущества:
Однако, при анализе работы приложения мы нашли такие проблемы:
При оценке сильных и проблемных сторон мы пришли к выводу, что приложение нужно сделать более мобильным (веб-версия вместо десктопной) и удобным, конкурентоспособным, легко адаптируемым к задачам бизнеса.
Мы проанализировали функции приложения и выделили наиболее важные, которые делали продукт ценным для бизнеса. На основе этих данных мы определили, какой должна быть программа в новой версии:
К тому же нельзя было допустить, чтобы новая версия оказалась «усложненным клоном» старой. Поэтому ключевые функции нужно было сохранить, но не перегружая приложение. Мы безжалостно отказались от избыточных сложных настроек.
Бизнес-аналитики, работавшие с версией 2.0, не сразу приняли изменения. В техзадании часто встречались фразы: «Здесь должно быть как в версии 2.0», «Возьмите схему работы в версии 2.0». Самым сложным на этом этапе было сопротивление соблазну взять все, как в предыдущей версии.
Как правило, мы в SimbirSoft на старте каждого проекта подключаем к команде экспертов разных профилей – аналитиков, специалистов по обеспечению качества (QA) и других. При работе над медицинским приложением мы собрали следующую команду:
В процессе работы мы постоянно вели таблицы предполагаемых рисков в новой версии. Для их предотвращения мы продумали гибкую систему настроек приложения и автоматизировали его тестирование, чтобы защитить пользователей от ошибок. В частности, наш SDET-специалист написал фреймворк, который помогал быстрее проверять все изменения в коде и тратить меньше времени на регрессное тестирование.
При модернизации приложения мы столкнулись с несколькими сложными этапами, о которых расскажем ниже.
Поскольку прошлая версия имела громоздкий интерфейс, мы переработали дизайн приложения. Мы предложили пять предварительных вариантов и показали их фокус-группе из числа пользователей приложения, провели юзабилити-тесты. В результате медицинские специалисты выбрали один вариант, который, по их мнению, оказался самым удобным, привлекательным и простым в использовании.
Мы предусмотрели различные технические риски, связанные с приложением. Например, выбранный для реализации плагин мог не подходить для некоторых интернет-браузеров. Для снижения этого риска мы сначала разработали плагин для того программного обеспечения, которое используется в большинстве партнерских медицинских учреждений. В дальнейшем мы спокойно дорабатывали плагин под другие браузеры.
Нашей задачей была разработка ограниченной версии продукта для презентации инвесторам. По этой причине мы стремились к тому, чтобы реализовать в приложении только наиболее необходимые функции. Некоторые гипотезы заказчика мы проанализировали и отказались от их реализации.
Например, заказчик предложил сделать календарь для планирования работы медицинских специалистов. Согласно гипотезе, календарь мог сделать труд докторов удобнее. Однако, в реальных условиях эта функция не пользовалась успехом, поэтому в конце концов ее отключили. Позднее календарь был адаптирован под нужды другой группы пользователей ─ пациентов, а не медицинских работников. Неверные гипотезы ─ это неотъемлемая часть бизнеса, и к ним нужно быть готовыми.
Немало времени ушло на то, чтобы договориться с нашим партнером о порядке интеграции приложения с внешними системами для отправки и хранения писем.
Пользователи приложения ─ медицинские учреждения ─ хотели использовать для версии 3.0 старые, привычные интеграционные системы, их нельзя было менять. Наш партнер предполагал, что в таком случае интеграция будет быстрой. Однако, на самом деле с интеграцией было связано много задач:
В процессе переговоров с заказчиком мы смогли доказать, что работа с интеграцией требует времени. Наш партнер согласился с нами: нельзя просто взять и перенести код из одной версии в другую.
Прошлая версия проекта создавалась без участия аналитиков. Разработчики и QA-специалисты уточняли требования в процессе создания приложения. Третья версия уже была основана на требованиях аналитиков, однако, все еще оставались сложности с тестированием:
Для работы над новой версией продукта нам потребовалось преобразовать отдельные рабочие процессы, например:
Регулярные онлайн-митинги с заказчиком помогли нам улучшить понимание его бизнес-процессов. Во время общения наш партнер рассказывал подробности о том, как работают доктора, и пояснял бизнес-цели. Мы, в свою очередь, объясняли технические нюансы и показывали различные неочевидные кейсы. Это позволило нам сформировать требования к продукту, которые покрывают потребности медицинских учреждений и оптимальны с точки зрения затрат на реализацию.
Гибкость в рабочих процессах и внимание к потребностям бизнеса позволили нам преодолеть все сложности, которые возникали в процессе разработки. Мы успешно сделали и запустили новую версию приложения для медицинских учреждений Европы.
Сейчас мы продолжаем развивать продукт и внедрять новые функции. Мы смотрим, как реальные пользователи работают с системой, собираем неучтенные кейсы и пользовательские истории, выявляем новые бизнес-ценности.
При создании новой версии продукта разработчики, как правило, сталкиваются с теми же проблемами, что и мы, например:
Главное, что выпуск новой версии IT-продукта ─ это не копирование кода «Ctrl+С», «Ctrl+V» из предыдущей версии, а полноценная разработка, практически с нуля. Это происходит потому, что меняются бизнес-процессы, требования пользователей, а также ситуация на рынке IT-решений.
Спасибо за внимание! Надеемся, что статья была для вас полезна.
Приложение для госпиталей
Мы работаем с медицинским приложением для госпиталей Европы. Оно помогает докторам уделять пациентам больше времени, сократив объемы бумажной работы. Доктора надиктовывают информацию о пациентах и осмотрах, приложение переводит аудиозаписи в текстовый формат, заполняет шаблон и формирует документы для медицинских работников и пациентов. На каждой стадии работы заложена своя бизнес-логика и интеграция с несколькими внешними системами.
Клиент поставил перед нами задачу разработать новую версию приложения для демонстрации инвесторам.
Детали проекта
Аудио
Как записывали аудио в версии 2.0:
- Открывали приложение.
- Нажимали на кнопку добавления записи.
- Выбирали в появившемся окне нужный вариант записывающего устройства.
- Надиктовывали аудио-запись.
- Вводили номер пациента, дату визита, номер визита (визит = приём врача).
- Нажимали кнопку Complete для загрузки на сервер аудиозаписи и данных о визите.
Теперь, в версии 3.0 для записи нужно приложить меньше усилий:
- Доктор открывает приложение.
- Выбирает прием (по дате, времени, номеру или имени пациента) из списка и кликает 1 раз для открытия карточки визита.
- Записывает аудио.
- Нажимает кнопку 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-решений.
Спасибо за внимание! Надеемся, что статья была для вас полезна.
