Создание приложения по улучшению ментального здоровья

Этапы работы и выполнение ключевых задач

Разработка архитектуры системы

 
На первом этапе мы определили структуру ролевой системы, а именно какие роли пользователей в приложении будут существовать и какими правами, обязанностями они будут обладать. Мы выделили администратора, у которого будет полный контроль над системой, чтобы он мог управлять пользователями и настройками; менеджера, который проконтролирует работу практишнеров и клиентов; практишнеров, что будут назначать клиентам персональные звуковые «рецепты», и клиентов, которые будут получать уведомления о назначениях и прослушивать записи.
 
Далее мы приступили к проектированию логики взаимодействия между пользователями разных ролей — как практишнер будет назначать рецепт клиенту, а он получать уведомление, связываться напрямую с практишнером. Также спроектировали функциональность приложения, которая бы позволила практишнерам выбирать и назначать определенные аудиофайлы и их последовательности («рецепты») конкретным клиентам.
 

Разработка функционала приложения

 
После того, как были согласованы с клиентом прототипы и мы убедились, что все ключевые функции учтены, мы приступили к созданию системы управления файлами (CRUD).
 
CRUD: C — create (создание), R — read (чтение), U — update (обновление), D — delete (удаление).
CRUD обозначает основные операции с данными — загрузку, воспроизведение, редактирование и удаление.
 
Реализовали систему уведомлений, чтобы при назначении практишнерами аудиопрограмм, клиенту приходили оповещения и напоминания в течение дня о необходимости пройти сеанс прослушивания в назначенное время. Нашей задачей здесь было также создать понятное взаимодействие с интерфейсом для пользователей всех ролей, обеспечить адаптивность — корректную работу и отображение приложения на экранах с разным разрешением.
 

Тестирование и оптимизация

 
Разработав основные функции и настроив шифрование файлов, облачное хранение, наш клиент смог протестировать MVP-версию приложения (Minimal Viable Product — минимально жизнеспособный продукт) и дать нам фидбек.
 
После того, как мы приняли комментарии нашего заказчика, можно было перейти к тестированию продукта. Мы удостоверились в корректности работы механизма по назначению аудиопрограмм и их последующего прослушивания, проверили, что каждая роль пользователя имеет доступ только к разрешенным функциям и данным. Убедились, что шифрование и дешифрование работают правильно и не влияют на качество воспроизведения, что работают меры по эффективности защиты от скачивания. Осталось улучшить скорость работы приложения и исправить обнаруженные ошибки.
 

Финальные доработки и запуск

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

Подход к разработке и взаимодействие с клиентом

 
На данном проекте мы использовали гибкий подход к управлению. Он сочетал в себе принципы Agile и методологию Kanban. Разработка велась итеративно, т.е. разбивалась на небольшие части, результаты которых регулярно предоставлялись клиенту. Благодаря гибкости и отсутствию жестких спринтов, наша команда могла быстро реагировать на новые потребности клиента, эффективно управлять рабочим процессом и постоянно предоставлять рабочие части продукта.
 
В разработке мы также руководствовались практиками CI/CD (Continuous Integration/Continuous Delivery — непрерывная интеграция и непрерывная доставка/развертывание), т.е. автоматизация процессов сборки, тестирования и развертывания приложения. Наши разработчики регулярно в течение дня объединяли свои изменения кода в общий репозиторий. После каждого слияния кода запускалась сборка приложения и выполнялся набор автоматических тестов, что позволяло как можно раньше обнаружить ошибки интеграции и конфликты между кодом разных разработчиков. После успешного прохождения всех тестов код автоматически развертывался непосредственно в рабочее окружение.
 
Такой подход позволил нам ускорить процесс разработки, оперативно выявлять ошибки, снизить риски при выпуске новых версий, т.к. небольшие и частые релизы менее рискованны, чем крупные и редкие. Также это способствовало налаживанию быстрой обратной связи и более тесному взаимодействию между командами разработки и эксплуатации.
 

Формат взаимодействия с клиентом

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