Рисунок 6: Форма для заполнения заявки на сопровождение

Источник: Сайт Московского Метрополитена - URL: http://www.mosmetro.ru/mobile/podat-zayavku-na-soprovozhdenie/

Для полноты описываемой ситуации в городе Санкт - Петербург, следующим по значимости городе России, существует похожая служба у ГУП «Петербургский метрополитен», которая занимается сопровождением пассажиров с ограниченными возможностями. [29] Однако, она не обладает цифровым способом регистрации (веб форма не реализована), но работоспособна, поскольку существуют минимальный персонал и инструменты для помощи. Большая заслуга локального метрополитена в создании комфортных условий для инвалидов, к примеру на большинстве станций размещены специальные устройства, с помощью которых инвалиды-колясочники могут беспрепятственно подниматься и опускаться по лестницам и эскалаторам.

Необычный пример для данного сегмента рынка - это мобильное приложение «Мобильный центр социальных услуг». [30] Оно было создано для повышения информированности широкой аудитории граждан старшего возраста, инвалидов и их родственников, проживающих на всей территории Московской области, с использованием современных IT-технологий, о социальных учреждениях и предоставляемыми ими социальных услугах. Среди описанных ранее решений оно является наиболее комплексным поскольку содержит следующие блоки включенных услуг:

* «Ближайшие социальные центры» - интерактивная карта расположенных на территории Московской области центров социального обслуживания с указанием адреса местонахождения, режима работы, контактных телефонов.

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

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

* «Социальные сиделки» - раздел, в котором пользователи могут выбрать сиделку по возрасту, образованию, стажу работы, перечню предоставляемых услуг.

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

Выделенная положительная особенность - это оптимизированная структура приложения с комфортной навигацией между разными услугами, и выступая в качестве агрегатора, приложение соединяет пользователя с нужными инстанциями. С другой стороны есть несколько недочетов подобного типа продукта, во-первых инновационных подходов к решению известных проблем включено и использовано не было. Получить помощь быстро, используя данный продукт, всё еще не выйдет. Еще одним лимитом решения является региональное ограничение использования, поскольку приложение работает в полной мере исключительно с центрами предоставления услуг в Подмосковье, причём еще не на всей её территории. В данном случае было крайне сложным выделять отдельный сегмент для данного решения, хотя на то есть полные основания, потому что оно явно отличается от ранее описанных инструментов. Но, поскольку следующие несколько решений еще более нетипичны, было принято отнести данный агрегатор социальных услуг к сегменту - решение содержащее инструмент для поиска волонтера, так как такой функционал существует и работоспособен. Касаемо вопроса актуальности и работоспособности приложения я представлю несколько фактов, один из них о количестве связанных социальных учреждений. В настоящее время в «МЦСУ» зарегистрировано 62 учреждения социального обслуживания, подведомственных Министерству социального развития Московской области. Мобильное приложение имеет бесплатную форму распространения, активно загружается пользователями двух популярных магазинов App Store и Google Play, соответственно приложение разработано на обе платформы. Последнее актуальное на момент описания исследования обновление датируется 15 января 2019 года. Более активно приложение скачивается и оценивается пользователями Android устройств, средняя оценка 4.6 из 5 возможных от 68 пользователей, а пользователи iOS предоставили всего 3 отзыва, но с максимальной оценкой. Общее количество скачиваний насчитывает менее 5 тысяч скачиваний на обе платформы. Из всего этого можно подвести следующий подытог: данное приложение является актуальным средством для граждан, объединяет в себе и информационную и прикладную функции, показывает, что на данном рынке возможны успешные решения, которые помогают решать проблемы пользователей, при этом используя современные технологии и новые пути взаимодействия (через UI мобильного приложения). Это хороший сигнал для развития рынка, заполнения его новыми решениями в ближайшем будущем.

Найди помощь и помогай друг другу - так звучит ценностное предложение следующего решения. Продукт имеет название Chummy и представляет из себя социальную сеть, главной задачей которой является соединять пользователей для взаимопомощи друг другу, особенно если они их геопозиция располагается близко. [31] Её характеризуют как американскую социальную сеть соседской взаимопомощи для добрых, дружелюбных и ответственных людей. Большая команда проекта заявила: «мы стремимся вдохновлять сообщество помогать друг другу и совершать добрые поступки каждый день». После такого описания становится ясна специфика разработанного решения, продукт полностью работоспособен и распространяется только благодаря пользователям, которые активно им пользуются. В качестве доступа к данной социальной сети пользователи имеют единственный вариант - мобильное приложение. Реализованное на обе популярных платформы (iOS и Android) приложение имеет заметно большую популярность на Android платформе суда по активности пользователей в оценке, а она составляет 4,1 из 5 при 244 отзывах, это крайне неплохой результат. В случае с iOS оценка 3,5 звезды, но при намного меньшем количестве отзывов. Интересный факт, несмотря на факт того, что родина проекта - Америка, свою популярность приложение приобрело в двух регионах: Россия и Украина. Что касается заметных преимуществ продукта, я выделил следующие из них:

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

· высокая интерактивность пользовательского интерфейса приложения;

· имплементированная система мотивации пользователей, рейтинга;

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

Такой вектор приложения, при соотнесении к рассматриваемым в исследовании проблемам может быть крайне эффективен, пользователи сами могут быть как инициаторами, так и получателями помощи. Существует всего два явных ограничения такого решения, которые напрямую будут влиять на скорость и качество работы: количество активных пользователей решения в конкретной области/районе/округе и стабильность работы GPS на выбранной местности. Другими словами, данный продукт не сможет работать так, как задумала команда разработки, если вы будете находиться в отдаленном уголке мира со слабым сигналом доступа к ближайшим GPS спутникам. Это так, поскольку приложение требует постоянного уточнения геопозиции всех пользователей для актуализации местоположения в приложении, иначе можно лишь запутать других пользователей или поставить их в неудобное положение, если кто - то поставит неверное расположение ради злого умысла. Таким образом это одновременно и отличительная особенность, гарантирующая безопасность и актуальность данных, а с другой стороны и ограничивающий фактор в зонах с плохим покрытием спутников. Однако, наверняка, найти в таких районах еще людей, которые были бы пользователями этого приложения, это задача не из лёгких, тем самым становится понятно, что приложение сильно ориентировано на регионы с крупным скоплением людей. Чем больше людей рядом с пользователем, тем больше вероятность получения, в итоге, помощи. Как я заметил в списке достоинств, приложение обладает вполне сбалансированным пользовательским интерфейсом, с которым вы можете ознакомиться на рисунке 7, расположенном ниже.

Рисунок 7: Интерфейс мобильного приложения социальной сети Chummy

Источник: Google Play - URL: https://play.google.com/store/apps/details?id=co.friendlyworld.chummy&hl=ru

Подводя подытог по данному решению хочется заметить, что количество пользователей социальной сети Chummy с сентября 2016 года (дата релиза приложения в магазины) на момент написания исследования составляет 67828 человек по всему миру и продолжает расти, учитывая, что приложение бесплатно и не содержит рекламы. Мобильное приложение было принято отнести к сегменту - поиск помощи, так как прикрепить его к первому сегменту невозможно по причине отсутствия ярко выраженной ориентации на людей с ограниченными возможностями . Выбранное создателями продукта направление к улучшению мира путём использования современных IT технологий внушает надежду, поскольку на текущий момент подобные инструменты всё еще развиваются и ожидается увидеть намного больше подобных попыток.

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

Завершает блок найденных решений представитель еще одного сегмента решений - кнопки экстренной помощи SOS. Один из существующих в данной нише продуктов - Кнопка 24. [32] Решение представляет из себя физически носимое устройство - аксессуар, при нажатии на которое происходит оповещение по заданной последовательности: звонок врачу, дежурящему 24/7, далее происходит получение местоположения, вызов скорой помощи по полученной позиции, оповещение родственников и заложенных при активации аксессуара телефонов. Продукт сегментирует аудиторию пользователей на две группы: пожилые люди и дети. Согласно этому разделению отличаются цены на приобретение самого носимого браслета-аксессуара, так и условия и цены тарифов на поддержку со стороны врача, медицинских центров. Для взрослых людей средняя цена на носимое устройство 5 990 рублей, когда у детей цена варьируется от 3 990 до 4 990 рублей. Базовые тарифы отличаются соответственно, 590 рублей в месяц против 99 рублей в месяц для детей. Стоит сразу же заметить самый главный недостаток таких решений - наличие носимого дополнительно аксессуара, помимо того, что за него необходимо заплатить отдельно от приобретаемой услуги. Возможно большое количество некомфортных ситуаций для пользователей, например, элементарная потеря или разрядка устройства отрежет возможность его использования. Для решения этого неудобства компания выпустила собственное мобильное приложение, ориентированное для сегмента детей, которое не только дублирует функционал аксессуара, но и позволяет получить дополнительные возможности не только для носителей браслета, но и для их родителей. Среди них такие функциональные возможности как: получение актуальных данных перемещения используя GPS геолокацию; отслеживание перемещения внутри помещений с помощью WI-FI; установка безопасной зоны и оповещение при выходе пользователя за границы; датчик снятия аксессуара с руки; запись истории перемещений ребенка; функция «обратный звонок» позволяет услышать все то, что происходит вокруг ребенка используя встроенный в аксессуар микрофон; поиск браслета-аксессуара в случае потери.

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

Основной смысл рассмотрения подобного типа продуктов направлен на исследование работающих механик и инструментов, использующихся успешными в конкретной нише рынка компаниями с целью их отбора и последующего использования. Не смотря на факт того, что данные решения часто узкоспециализированы, существует вероятность найти работоспособное сочетание функций, которое действительно помогает людям. Следовательно, их разбор и исследования для будущего использования в других решениях на иных от рассмотренного рынках может иметь такой же положительный характер. К примеру, использованная функция GPS отслеживания позиции ребенка на карте может быть крайне полезна для разрабатываемого мною продукта с точки зрения добавления интерактивности при поиске волонтера. Поясню, что подход к разработке приложения или продукта ориентированный исключительно на добавлении желаемых функций - это заведомо ошибочный путь. Многие методологии по созданию продуктов, включая книгу-практикум «Разработка ценностных предложений», говорят, что основой начального видения товара/продукта является четко сформулированное понимание следующих блоков: решаемые проблемы пользователя, известные задачи потенциальных потребителей и выгоды, которые они могут получить от данного решения. [33] Рекомендуется после формулирования и создания каркаса продукта приступать к проектированию и добавлению функций продукта. Тем самым я хотел подчеркнуть, что заявленное выше решение о добавлении функции в создаваемый мною продукт подкреплено первичным каркасом, иными словами шаблоном, продукта и имеет характер добавления дополнительной ценности и удобства для пользователя. Подобное решение внутренней проблемы актуализации данных вместе с предоставлением пользователям возможности более удобно взаимодействовать с интерфейсом мобильного приложения является интересной как со стороны задачи разработки, так и со стороны проектирования продукта как такового. Рассматривая все ранее перечисленные функции, очевидно, что они указывают на специфику продукта - предотвращать и быстро поднимать тревогу в случае опасности здоровья или по инициативе пользователя аксессуара. Планируется, что такая проблема частично должна быть разрешима, используя проектируемый сервис. В качестве оптимизации самого серьезного недостатка рассмотренного решения этот функционал можно перенести на мобильное приложение, поскольку очень часто люди, попавшие в трудную ситуацию, нуждаются в незамедлительной помощи. Тем самым пользователя освобождается от необходимости покупки и ношения дополнительных аксессуаров при этом обладая желаемым функционалом на устройстве, которое всегда с собой: на смартфоне или планшете.

2.2 Составление критериев сравнения

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

· Доступность получения помощи

· Скорость получения помощи

· Интерактивность и простота используемого интерфейса

· Необходимость использования дополнительных аксессуаров

· Использование источников отправки/получения данных (GPS, 3G, Телефонная сеть, Bluetooth)

· Автономность

· Возможность использования в различных регионах

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

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

Глава №3 - Проектирование и разработка интерактивного сервиса

Данная глава содержит в себе описание первичной концепции сервиса интерактивного поиска помощи, сформулированное базовое видение продукта. Далее на основе полученных данных, описанных в двух предыдущих главах, было сформулировано новое видение продукта, подкрепленное анализом инструментов и практик, реализованных у выделенных решений на рынке инструментов социальной помощи, смежным с ним рынком экстренной помощи. Следующий за ним этап - формулирование требований для реализации минимально работоспособного продукта (MVP), демонстрирующим основную часть бизнес логики каждого модуля сервиса. После этого следует этап проектирования сервиса, причем как модулей, так и всего сервиса, а точнее всех входящих в него потоков данных, связывающих работу модулей между собой. Без необходимости выделения дополнительного этапа, однако протекая одновременно с предыдущим происходила работа по разделению обязанностей и задач команды разработки, состоящей из трех человек. Принято решение внести информацию о выбранных инструментах отслеживания задач, менеджерской составляющей работы. Завершает главу описание последних двух этапов работы: поэтапной модульной разработки, сбора сервиса воедино и оценки перспектив развития сервиса, включая возможности проведения анализа собранных данных и формулирование вероятных сценариев выпуска продукта.

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

3.1 Первичная концепция продукта

Первичное видение создаваемого продукта появилось у команды после встречи с одним из потенциальных пользователей будущего сервиса. Запрос пользователя состоял из сформулированной проблемы, ссылки на её актуальность и опыте о неудачных попытках поиска подходящего решения на рынке, которое бы позволяло хоть каким - то образом частично решить поставленную проблему. Проблема была сформулирована в следующем виде: человек ограниченный физически ситуативно испытывает трудности при передвижении по городу. К примеру, пожилой человек или инвалид по состоянию здоровья не может самостоятельно добраться до или от магазина до дома. За таким, казалось бы, примитивным примером скрывается большое количество опасных ситуаций, в которые попадают люди в городах России каждый день. К большому сожалению, среди доступных социальных услуг и сервисов ни один не способен предоставить людям такой вид поддержки. Политика государства, направленная на поддержку граждан, повлекла за собой многое количество изменений в облике и оснащении города, для того чтобы сделать его более доступным для всех групп общества, однако, как показывает практика, этих мер все еще недостаточно. Ровно это же можно сказать и о интерактивных социальных сервисах, разработка и внедрение которых уже происходит, но не на соответствующих спросу темпах и масштабах. Таким образом именно с такой идеи и началась работа по созданию сервиса по предоставлению помощи людям в социальной среде. В качестве основного ресурса были выбраны волонтеры, поскольку хорошо известен факт роста этого движения в стране за последние несколько лет. Создание и выпуск продукта повлечет за собой дополнительное положительное стимулирования этого рынка, а потенциально привнесет возможности популяризации волонтерского движения, запустит процесс поиска новых волонтеров, добавит функцию для связи существующих волонтеров и волонтерских центров между собой. Особая ставка так же должна быть сделана на интерактивность и легкость использования продукта пользователями. Эти пункты стали ключевыми элементами в первоначальной концепции продукта. В качестве технического решения планировалось создать бота, существующего в одном из известных чат-приложений, который на основе полученных при запросе от пользователя данных (тип проблемы, местоположение, срочность помощи) связывал бы его с ближайшим свободным и доступным волонтером. Тем самым устанавливался так называемый «канал связи» между двумя сторонами, далее должно было бы произойти уточнение данных и деталей встречи. Выбор реализации бота был сделан из побуждений высокой скорости реализации подобного функционала вместе с высокой вероятностью доступности решения, поскольку чат-приложения на сегодняшний день кроссплатформенны, имеют огромную аудиторию и гарантируют безопасность передачи данных.

3.2 Обновленная концепция продукта

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

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

3.3 Этап формулирования требований

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

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

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

1. Авторизация и регистрация в сервис через интерактивный пользовательский интерфейс, строго разделяющий группы друг от друга. Хранение пар логинов/паролей для повторных входов пользователей;

2. Возможность ускоренного входа в сервис с использованием последней сохраненной на устройстве пары логин/пароль для экономии времени повторного ввода информации;

3. Выход из аккаунта с отключением ускоренного входа;

4. Получение геопозиции, просмотр собственной актуальной позиции на карте для удобства ориентации на местности;

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

6. Центрирование и масштабирование карты на актуальной геопозиции пользователя при нажатии на соответствующую кнопку на интерфейсе. Параллельно повторно актуализируется и обновляется информация о возможных пользователях поблизости (в зависимости от роли и состояния);

7. Получать детализированные уведомления о важных этапах и изменения состояния сессии на интерфейс используемого устройства;

8. Быстрое восстановление активной сессии сразу же после процесса авторизации при возникновении проблем с используемым устройством или работой приложения.

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

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

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

3. Пользователь должен иметь возможность отменять установившуюся сессию (связь) с волонтером после факта ее подтверждения;

4. Предоставление оценки волонтеру после завершения сессии.

Блок функций доступных исключительно пользователям, которые имеют роль помощника (волонтеры):

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

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

3. Валидация актуальности сессии, инициируемая со стороны волонтера. Требует обязательного установления контакта со второй стороной с целью уточнения вопросов безопасности (защита от злоумышленников), деталей встречи и других особенностей.

Именно такими представились нашей команде функциональные требования продукта. Большое влияние так же оказал опыт использования такого сервиса как Яндекс Такси, многие из механик, используемых в их решении, были переработаны и внесены в вышеописанные пункты функциональных возможностей сервиса. Легко заметить, что большинство из описываемых пунктов относятся напрямую к работе модуля мобильное приложение, поскольку речь идет о внесение интерактивности в работу с интерфейсом на устройстве пользователя. А в качестве представления такого интерфейса, как уже было замечено многократно, в реализовываемом сервисе выступает мобильное приложение, написанное для платформы iOS. Но этот факт совершенно не отменяет того, что эти же функциональные требования имеют большое количество информации для еще одного модуля - сервера. Дело в том, что без слаженной работы с модулем мобильного приложения достичь работоспособного и стабильного сервиса - не выйдет. Это факт не очевиден по причине особенности формулирования функциональных требований, так как обычно они направленны на удовлетворение нужд будущих пользователей продукта, которые не знают и не должны знать о сложной внутренней архитектуре работы продукта.

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

3.4 Этап проектирования модулей

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

Начну описание с модуля мобильное приложение. Достаточно подробно было сказано о причинах выбора используемого языка программирования, однако, было замечено, что для реализовываемого в контексте текущего исследования приложения использовался оптимизированный паттерн SOA. Информация, предоставленная о этом дизайн шаблоне в пункте «Блок архитектурного решения» универсальна, следовательно, любое мобильное приложение, реализованное с соблюдением правил данного паттерна, будет обладать выделенными в описании особенностями, реализованное мною приложение - не исключение. Главная идея, ради которой был использован данный дизайн шаблон для текущего сервиса - это упор на легкое обновление, абстрагирование и быструю замену функциональных блоков приложения. Стоит обратить внимание на устройство структуры слоев приложения. Показанное ниже схематическое изображение зависимости и порядка логических слоев (рисунок 8) является основой проектирования мобильного приложения.

Рисунок 8: Структура логических слоев мобильного приложения

Ранее обозначенные функциональные блоки приложения - это различные способности приложения, которые напрямую используют один или несколько системных функций смартфона. Повторюсь, что находятся они в самом нижнем слое структуры (в Функциональном слое). Любой из таких написанных блоков может быть с легкостью заменен аналогичным ему, для этого существуют предписанные правила разработки, при выполнении которых весь процесс обновления или быстрой замены может быть произведен практически моментально, без необходимости переписи всего приложения. Правда, следует так же обновлять соответствующий функции из нижнего слоя блок в среднем слое (Сервисный слой) приложения, поскольку именно он выполняет функции посредника логики приложения и использования служб (функциональных блоков). Важно эффективно разделить данные блоки для того, чтобы поддерживать быстродействие приложения и удобство его разработки. Для данного приложения были выделены следующие блоки:

· органайзер профиля в приложении;

· служба сохранения и загрузки данных в память приложения, для будущего использования без Интернет-соединения;

· функционал по сбору и отправке запроса на сервер (к встроенному на него API) и в последующем получении ответа.

Далее оценивается наполнение верхнего слоя структуры - Слоя представления. Учитывая особенности текущего приложения его экраны и визуальные элементы составляют следующий связанный набор:

· экран выбора роли пользователя;

· форма регистрации/входа в сервис;

· уведомления к различным событиям на шаге регистрации/входа в сервис;

· главный экран с встроенной картой, показывающий текущее местоположение;

· необходимые инструменты, необходимые на главном экране, выступающие в качестве меню или панели;

· элементы, обозначающие других участников сервиса на карте, включая дополнительные информационные панели с дополнительными сведениями о выбранном пользователе;

· модульные уведомления о важных этапах и изменениях состояния текущей сессии.

Следующий описываемый модуль - сервер. Подробный разбор его архитектуры не несет большой важности, скорей следует обратить внимание на внутреннее наполнение элементов (API и База данных). Все запросы к реализованной API имеют свои особенности в зависимости от роли пользователя, таким образом каждый указанный запрос на самом деле представляет из себя пару запросов, в соответствии с разделением пользователей, ищущих помощь и её предоставляющих. Так были спроектированы следующие шаблонные запросы от мобильного приложения к реализованному API:

· запрос на подтверждение входа пользователя в сервис;

· запрос на регистрацию пользователя в сервис;

· запрос на выход из активного аккаунта;

· запрос на получение списка доступных пользователей в зависимости от роли пользователя;

· запрос на старт инициализации процесса поиска/готовности к предоставлению помощи;

· запрос на обновление и синхронизацию текущей геопозиции пользователя;

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

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

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

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

База данных, находящаяся в постоянной связке с API, является универсальным источником данных, распространяемых на весь сервис. Абсолютно вся информация актуализируется в ней, поскольку именно таким способом возможно добиться одновременно быстрой и корректной работы у множества активных пользователей. В отличие от вынесения этой функции на мобильные приложения, такой вариант реализации единого хранилища данных является более распространенной, стабильной практикой, учитывая при этом, что такой способ подразумевает легкую конфигурацию такого хранилища. Такое становится возможным поскольку данная база данных вместе с работающим API, содержащиеся вместе на одном экземпляре сервера могут быть запущены на выделенном ПК или системе, поддерживающей выполнение исполняемых файлов сервера, и, разумеется, имеющая прямое стабильное подключение к интернету. Такой вариант легко настраиваем и масштабируем, а такое часто требуется современным решениям, поскольку количество предполагаемых пользователей сервиса на самом старте продукта и через некоторое время сильно различаются, чтобы избежать таких проблем, такая стратегия - это отличное решение и часто используемая в индустрии практика. Сама же табличная иерархия и структура базы данных сведена к наиболее элементарной, поскольку нет особой необходимости в создании большого числа сущностей. Две таблицы хранят в себе всю необходимую информацию, при этом верность заполнения данных постоянно проверяется API, таким образом облегченная структура работоспособна и достаточна. Основную функциональную особенность работы сервиса содержит в себе разработанная система статусов пользователя. Используя минимальное количество памяти - символ, закодировав основные состояния, удалось без усложнения структуры базы данных добиться стабильной работы сервиса. Среди обозначенных нами статусов были выделены: пользователь не инициализировал готовность к нахождению помощи или её предоставление (в зависимости от роли пользователя) - код 0; пользователь инициализировал готовность к нахождению помощи или её предоставлению (в зависимости от роли пользователя) - код 1; между пользователями разных ролей произошло соединение, создана рабочая сессия помощи - код 2.

Далее представлено перечисление полей, входящих в запись о пользователе:

· ID (Уникальный идентификатор пользователя присваиваемый автоматически для внутренней работы сервиса);

· ID special (Уникальный идентификатор пользователей с инвалидностью, который они смогут использовать для подтверждения статуса инвалидности внутри приложения);

· Name (Строка полного имени пользователя, отображается при вызове дополнительной информации при запросе от других пользователей);

· Phone (Строка телефона пользователя, отображается при вызове дополнительной информации при запросе от других пользователей);

· Geo (Пара значений latitude и longitude / широта и долгота - для хранения актуального местоположения пользователя, часто обновляется, может быть запрошена для отображения у других пользователей);

· Password (Строка, использующаяся пользователем для идентификации в процессе входа в сервис);

· Good reviews (Существует только для записей внутри таблицы волонтеров. Счетчик количества положительных отзывов после совершения сессии помощи);

· Bad reviews (Существует только для записей внутри таблицы волонтеров. Счетчик количества отрицательных отзывов после совершения сессии помощи);

· State (Описанная выше универсальное закодированное значение состояния пользователя в сервисе);

· Online (Поле характеризующее наличие или отсутствие входа и доступности пользователя в сервисе, необходимо для процесса проверок и основной логики работы сервиса);

· Conid (Уникальный идентификатор, не совпадающий с оригинальным ID, но выдаваемый самим сервисом для связи двух пользователей разных ролей для объединения в одну сессию, по умолчанию равен -1);

· Helper / In trouble (Строка, в которую вносится телефон связанного сессией волонтера в случае роли пользователя, как инициатора поиска помощи - поле helper, а в случае волонтера в поле in trouble вносится информация о универсальном идентификаторе пользователя, с которым существует активная сессия).

Последний не рассмотренный модуль сервиса - Telegram Бот. Как и в случае с предыдущем модулем проектирование внутренней архитектуры не требуется по причине легковесной структуры исполняемых файлов и малого количества объектов. Несколько нестандартных решений было принято для привнесения в работу с чат ботом функционала работы как с полноценным инструментом, поскольку часто на подобные решения тратится намного большее количество сил и создается отдельное полноценное веб или декстопное приложение ровно с аналогичным набором функций. Чат боты же в свою очередь обычно выполняют крайне примитивные функции, однако, на данном примере, мы смогли показать, что привнесение дополнительного функционала и работа с ним как с полноценным решением - задача вполне выполнимая. Среди опорных точек модуля мы выделили:

· Использование нестандартного метода общения с ботом. Обычно на каждый запрос бот отправляет в чат новое сообщение и таким образом происходит работа. В нашем же случае для облегчения интерфейса было принято решение заменять отправленное ботом сообщение актуальным, тем самым экономя пространство на экране и привнося типичную для работы с приложениями фиксируемое поле, на котором сосредоточено внимание;

· Богатое и подробное множество вложенных меню для легкого взаимодействия пользователя с функциями инструмента;

· Доступ к состоянию подмодулей сервера (API и Базы данных), удаленный просмотр ошибок, возможность за одно нажатие удаленно остановить/запустить/перезапустить службы по отдельности;

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

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

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

3.5 Этап разработки сервиса

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

Сервер. Говоря более подробно о специфике реализации сервера на языке Go, хочется заметить, что при реализации модуля не было использовано дополнительных фреймворков (наборов библиотек). Обычно их использование связано с попыткой команды разработки добиться более оптимальных результатов работы сложных логических конструкций или получить доступ к недоступному ранее функционалу. Оба данных примера не подходят в нашем случае, поскольку реализуемый модуль не имеет такой жесткой необходимости. Весь функционал уже доступен в стандартном пакете языка. API имеет прямую связь с второй составляющей модуля - базой данных. Типичный процесс работы данного модуля будет происходить по следующему алгоритму:

1. Произошел запрос из авторизованного источника (мобильного приложения или Telegram Бота);

2. Запросы легко отделяемы друг от друга (другими словами, каждый имеет конкретную ссылку и заранее известную структуру посылаемой информации), следовательно, каждый из них запускает отдельную функцию на сервере;

3. Выполняемый метод написан с использованием абстракций, таким программный код написан один раз для одного типа запроса. То есть полученный запрос моментально запускает закрепленную за ним функцию на сервере. В этот код передаются данные из тела запроса и алгоритм начинает свою работу;

4. Существует ряд проверок перед выполнением инструкции запроса «вслепую», таким образом гарантируется безопасность и стабильность работы сервиса в целом;

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

a. Чтение информации из базы данных по особому указателю;

b. Запись информации в базу данных по особому указателю;

c. Процесс сравнения двух величин;

d. Создание новой записи в базе данных по указателю на конкретную таблицу

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

Мобильное приложение. Замеченная ранее разработка концепции дизайна и логики экранов мобильного приложения завершилась. Итоговым результатом проведенной работы является конечный дизайн приложения, который будет представлен позже в этом пункте. Следующей актуальной задачей является полная реализация приложения, преимущественно будет выполнена связывание с созданным к этому моменту сервером. На основе слоевой архитектуры (SOA), учитывая все функциональные требования, описанные ранее в текущей главе, удалось за короткие сроки создать работоспособный продукт. Большая часть работы связанна с созданием, получением и обработкой ответов на запросы, отправляемые приложением к серверу (API). Для реализации данной возможности я воспользовался известным фреймворком под названием Alamofire, который позволяет выстроить более визуально оптимизированную и легко читаемую архитектуру кода службы общения приложения с API, помимо этого, он позволяет более удобно обрабатывать ответы сервера, что и стало причиной включения данного фреймворка в проект. [34] Для выстраивания логики периодического обновления данных, комфортного для пользователя, были выбраны усредненные временные показатели через которые срабатывал бы автоматический запрос приложения к API. Тем самым произведена работа по встраиванию системы таймеров, инициализация которых происходит при совершении завязанных с ними запросов.

Еще одна реализованная служба, находящаяся на самом нижнем слое приложения (в Функциональном слое) - это сохранение и загрузка данных в локальное хранилище приложения. Особенность работы мобильных приложений состоит в том, что обычно информация с которой ведется работа во время использования приложения выгружена в оперативную память устройства и при выходе из приложения или выключении телефона она моментально стирается и не может быть возвращена. Тем самым разработчики определяют набор информации доступ к которой должен быть возможен из любого состояния, включая возможность длительного хранения или краткосрочного хранения на определенный период времени. В данном случае самым важным аспектом, который необходимо постоянно хранить, является профиль пользователя. Этот объект содержит информацию о: логине, пароле, полном имени, телефоне, идентификаторе инвалида (при наличии и при выборе соответствующей роли), фотографии. Запись профиля в память устройства происходит при удачном входе в приложение, затем эти данные могут быть повторно использованы при повторном входе в приложение, тем самым делая процесс работы с мобильным приложением проще.

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

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

Рисунок 9: Первичный экран выбора роли с вытекающим экраном авторизации и регистрации

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

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

Рисунок 10: Главный экран приложения с активной точкой местоположения

Более детально опишу технические особенности данного экрана. Помещенная в центр экрана интерактивная карта позволяет отслеживать текущую геопозицию пользователя, помимо этого, она выступает в роли обычной карты, то есть обладает набором стандартных жестов для масштабирования и просмотра других мест. Для этого использовалась встроенная стандартная библиотека, созданная компанией Apple с названием MapKit. Более подробно о ней можно узнать уже из указанного ранее руководства-документации для разработчиков на языке Swift. [10] Для определения геолокации и настройкой работы взаимодействия приложения с GPS модулем устройства (помимо этого, часто и с WI-FI модулем) используется еще одна стандартная библиотека - CoreLocation.

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

Упомянутый ранее фреймворк SCLAlertView позволяет упростить процесс уведомления пользователя. Абсолютно все нотификации о изменении состояния сессии, успешности выполнения того или иного действия в приложении выполнены с использованием этого инструмента. С одним из примеров его работы можно ознакомиться на рисунке 11. В данном случае при регистрации волонтера в одном из полей формы не было введено никакой информации, приложение уведомляет пользователя следующим образом.