Идеи новых функций для российского мессенджера Frisbee появляются из нескольких источников:

• Изучение актуальных опций в средствах общения. Этим занимаются UX-дизайнеры и бизнес-аналитики.
• Обратная связь от клиентов: какой функционал необходим в мессенджере для работы.
• Собственные идеи разработчиков.

Из этих функций команда разработки формирует дорожную карту развития мессенджера. В рождении новой функции задействована вся команда мессенджера Frisbee: от проработки требований к опции до ее реализации.

Разработка функций корпоративного мессенджера Frisbee делится на три этапа:

• проектирование,
• реализация,
• доставка.

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

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

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

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

Мы всегда учитываем пользовательский опыт. Если воспроизводим функцию, которая популярна в публичных мессенджерах, то стараемся сохранить привычные паттерны ее применения, чтобы лишний раз не переучивать пользователей. Напомним, Frisbee собрал в себе пользовательский опыт популярных публичных мессенджеров: это замена Telegram, WhatsApp, Viber.

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

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

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

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

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

Финальная сборка проходит цикл регрессионного тестирования, которое подразумевает полную проверку самого приложения и интеграции нового функционала корпоративного мессенджера.

Стандартная полноценная фича-команда состоит из Android-разработчика, iOS-разработчика, frontend-разработчика, backend-разработчика, бизнес-аналитика UI/UX-дизайнера, QA-инженера. Если функция объемная и требует написания большого количества тест-кейсов, то привлекают двух QA-инженеров. Опционально может быть привлечен также технический писатель, который может, как было, например, с чат-ботами, подготовить документацию или техническое описание функции, либо же FAQ и тд. Это все опционально.

После всех проверок наступает этап доставки, т.е. установка новых функций в приложения клиентов.

Мы придерживаемся графика один релиз в месяц. Релизный цикл начинается с составления плана, к процессу подключаются все члены команды. Мы собираем обратную связь от специалистов из техподдержки, бизнес-анализа и дизайна, чтобы понять, какие улучшения и функции необходимы приложению с их точки зрения сейчас, соответствуют ли они текущей дорожной карте. Также учитываем пожелания самих пользователей. На основе собранной информации формируем релизный план, который будет реализован в следующем месяце. Например, в конце ноября создаем план на декабрь, и с 20 ноября по 15 декабря мы активно работаем над его выполнением. Если новая функция требует больше времени, чем один релизный цикл (обычно 25-35 дней), она переносится в следующий релиз. Мы стремимся как можно быстрее включать готовые функции в наш релиз-кандидат, который затем доставляем нашим клиентам.

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

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