Offschool: Разработка мобильного приложения на iOS и Android

Заказчик
Offschool, Москва.

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

Форма продукта
Мобильное приложение.

--- Бриф заказчика ---

Концепция приложения

OFFSCHOOL — это приложение, которое объединяет родителей, детей и индустрию дополнительного образования.

С OFFSCHOOL можно:

• Управлять расписанием внешкольной жизни семьи.
• Автоматизировать контроль и оплату дополнительных занятий.
• Общаться в едином информационном поле «родители — дети — учителя».
• Регулярно поощрять детей за прогресс и полезные привычки в свободное время.

Описание целевой аудитории

1. Родители. Настраивают и управляют расписанием детей без многочисленных чатов и звонков.
2. Репетиторы. Создают гибкое расписание с запросами и уведомлениями при замене, переносе времени, а также отправки виртуальных вознаграждений ученикам.
3. Дети. В приветливом интерфейсе знакомятся с основами тайм-менеджмента и формируют полезные привычки.

Основные пользователи и их действия в мобильном приложении

Родители

• Отправка приглашений ребенку, учителю, члену семьи.
• Добавление ребенка через настройки.
• Настройка расписания занятий.
• Постановка задач ребенку.
• Доступ к расписанию занятий ребенка.
• Оплата занятий.
• Чтение обратной связи преподавателей.
• Изменение, перенос занятия.
• Отправка стикеров-поощрений ребенку.
• Приглашение репетиторов.

Преподаватели

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

Дети

• Доступ к расписанию занятий.
• Организация собственного расписания.
• Доступ к семейным задачам.
• Тренировка привычек.
• Персональный трек и программа мотивации (запрос выходных дней, получение стикеров и бейджей).

Аналоги и конкуренты приложения

Calendly, Doodle, iStudiez pro, Timetable, WeDo и другие мобильные таск-менеджеры.

--- Брифа заказчика ---

При погружении в проект выяснилось что:

• Приложение делали программисты — индусы. Часто это говорит о своеобразной архитектуре и качестве кода.
• Код писался при отсутствии технического задания и описания логики приложения.
• В качестве технического задания использовался только дизайн мобильных экранов, прорисованных в облачном сервисе Figma.
• Львиная доля сервисов приложения не работали, возникало много ошибок, не дающие понять, как работает тот или иной раздел или сервис.
• Техническое задание для сбора пользовательских событий в сервис аналитики отсутствовало. Сервис аналитики не подключался.
• Оплата подписки в приложении не работала, так как Apple Store и Google Play присоединились к санкциям в отношении на России после 24 февраля 2022 года. Требовалось найти решение для обхода этой блокировки, чтобы пользователи покупали подписку, а собственники монетизировали продукт.

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

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

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

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

• Исправление ошибок и запуск приложения.
• Управление проектом (проджект-менеджмент).
• Тестирование приложения.
• Решение вопроса блокировки оплаты подписки для пользователей из России.

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

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

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

Анализ программного кода партнерами показал, что код ужасен. Мягко сказать на двойку и тройку для Android и iOS по пятибалльной шкале соответственно.

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

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

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


Решение задачи органического роста

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

Установление таких связей на ранней стадии позволило бы пользователям как можно быстрее опробовать функциональность приложения, оценить удобство и функциональность в организации и контроле проведения внеклассных занятий, и формировании расписания. Это могло бы повлиять на метрику Удержания (Retention) пользователей в приложении и быстрее перевести таковых в разряд постоянных пользователей.


Удержание пользователей

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

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

Для родителей сделали онбординг с добавлением детей и членов семьи и функцией поиска учителя, зарегистрированного в приложении, или приглашения в приложение через СМС или email.

Для учителей сделали онбординг с поиском и приглашением в приложение родителей. Приглашение родителей реализовали в той же механике, как и в онбординге для родителей — путем отправки СМС по телефону или приглашения по email.

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

Раньше логика приложения предусматривала, что учитель добавлял ребенка по номеру телефона или email напрямую, без участия родителей. Но решили, что это небезопасно для детей. К тому же у Apple Store и Google Play предъявляют специфические требования к передаче контактных данных несовершеннолетних детей. Поэтому функцию привязки детей к профилю учителя решили оставить только родителям. Родитель платит за внеклассные занятия, и прежде чем занятие будет проведено, взаимодействие родителя с учителем — обязательный этап, который не пропускается. Таким образом, в онбординге учителя предусмотрели функцию поиска или приглашения родителей, но добавить детей в окружение учителя может только родитель.

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

Поэтому онбординг для детей и членов семьи получился коротким.

Виральность

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

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

Учителей мотивировали зарабатывать щедрые комиссионные с оплаченных подписок привлеченных родителей.

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

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

Поэтому согласовали и расширили список задач, подлежащих выполнению, следующими:

• Управление продуктом (продакт-менеджмент). Анализ и переосмысление логики приложения. Прорисовка недостающих экранов приложения и состояний экранов.
• Написание технического задания для разработчиков.
• Написание технического задания для сбора аналитики.

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

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

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

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

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

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

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

Параллельно с управлением перерисовывали и описывали задачи, выделенные в этап «Б».

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

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


Результат работы над проектом

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

Тем не менее задачи этапа «А» на платформе iOs и по бэкенду выполнены на 100%, приступили к выполнению этапа «Б». Для реализации этапа «Б» на платформе iOs и запуска приложения требовался месяц работы одного программиста.

Задачи по бэкенду для этапа «Б» выполнены на 80%.

Большие трудности вызвала работа с кодом на Android-платформе. В восьми из десяти случаев разработчики не вписывались в собственную оценку. На этой платформе трудозатраты часто превышали изначальную оценку в два — три раза. Задачи этапа «А» на платформе Android выполнены на 90%. По завершении этапа «А» текущий подрядчик отказался реализовывать этап «Б» на Android-платформе ввиду качества исходного кода. За 5 месяцев работы пришлось инициировать смену пяти Android-разработчиков со стороны подрядчика, предполагая, что на проект привлекаются программисты не того уровня. Но, видимо, изначальная архитектура приложения и качество кода и правда ужасные.

Из-за отказа подрядчика делать этап «Б» на Android подняли и согласовали с заказчиком вопрос поиска другой команды для этой платформы или привлечения программиста из другой компании уровня Senior на другой часовой ставке. Второе предложение одобрения не получило. Решили искать подрядчика плюс минус с таким же «рейтом».

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

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

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