Как запустить мобильное приложение за 2 месяца и провести гибкую трансформацию

Как запустить мобильное приложение за 2 месяца и провести гибкую трансформацию

Я расскажу вам историю о том, как моя команда всего за 2 месяца запустила приложение для iOS и Android для службы продажи билетов, без особых проблем осуществив переход от Waterfall к Agile. Я начну с описания начальной точки проекта, того, как процессы разработки программного обеспечения работали раньше, и с описания основных действий, которые помогли нам добиться успеха. Эта статья не предназначена для замены Agile-манифеста или Книги Scrum Джеффа Сазерленда. Вместо этого я расскажу вам, как мы изменили наш рабочий процесс, чтобы доставлять продукт быстрее, не нанимая армию Agile-коучей и скрам-мастеров. Эта статья будет полезна и тем из вас, ребята, кто задумывался о создании собственного домашнего проекта. Я покажу вам, на чем стоит сосредоточиться в конкретный момент времени, а на чем нет. Итак, приступим :)

Как все началось

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

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

• Устаревший дизайн пользовательского интерфейса
• Проблемы юзабилити
• Невозможность просмотреть карту мест

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

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

Минимальный ценный продукт

Как я уже упоминал выше, в своей работе мы широко использовали подход Waterfall. Мы разделили iOS, Android, дизайн, QA, бэкэнд-команды и армию менеджеров проектов. Итак, когда мой руководитель проекта впервые обратился ко мне с этим захватывающим новым проектом, я был более чем счастлив начать свой самый первый продукт в этой компании с нуля. Но все мое счастье исчезло после первой встречи. Что случилось? Основная цель этой встречи заключалась в том, чтобы оценить дату выпуска на основе очень небольшого количества дизайнов пользовательского интерфейса, которые у нас были. Мы выяснили, что

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

Вот почему мы обнаружили, что не можем делать оценки, чтобы зарезервировать ресурсы для мобильных разработчиков для этого проекта. Честно говоря, мы не смогли предсказать дату релиза. Конечно, можно сказать, что это займет около 6 месяцев. Но если вы не имеете представления об общем объеме и сложности такого огромного приложения, ваши оценки будут довольно неточными. И это довольно обычная ситуация для команд Waterfall. Чтобы исправить это, я предложил сначала запустить Minimum Valuable Product (MVP) с нашим собственным дизайном пользовательского интерфейса и небольшим количеством важных функций в первом выпуске, оставив все остальные для следующих версий нашего приложения. Идея выглядела довольно свежо и увлекательно, мы решили попробовать.

Сосредоточьтесь на том, что действительно важно

В технических требованиях и тех экранах пользовательского интерфейса, которые у нас есть, было много особенностей. Мы четко понимали, что невозможно разработать их все с максимально возможным качеством. А вот и Agile!

Мы составили список всех функций и спросили себя: «Какая из них самая важная? Без каких функций наше приложение просто не могло бы работать? »

А вот список важнейших функций, определяющих наш продукт:

• Список кинотеатров
• Список фильмов
• Расписание
• Карта мест
• Совершение покупки
• Купленные билеты

Это просто. Всего 6 экранов. Мы постарались максимально сократить количество экранов, чтобы сделать процесс покупки проще и быстрее, наконец, мы смогли сократить его до всего 4 шагов: взять кинотеатр или фильм, выбрать подходящее время на экране расписания, выбрать места на карте мест и совершите покупку. Наше приложение просто не работало бы без любой из этих функций. Никакой красивой анимации, никаких сложных жестов, никаких настраиваемых элементов управления. Вместо этого предоставляемая системой навигация на основе вкладок, стандартные элементы управления пользовательского интерфейса с минимальными настройками. Мы были сосредоточены на предоставлении нашим клиентам контента, а не интерфейса. Именно так мы на самом деле создали отличный пользовательский интерфейс, получивший оценку A + на сессии WWDC UI design labs.

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

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

Сосредоточьтесь на важнейших характеристиках вашего продукта. А всех остальных отложите до следующих выпусков. Помните, вы предоставляете своим клиентам контент, а не интерфейс.

Общение - это ключ

Теперь, когда мы получили карту экрана, мы смогли понять, какие API нам нужны. Но бэкэнд-команда была очень занята, и здесь у нас было узкое место. К счастью, мы смогли оценить объем работы, которую необходимо сделать, и [здесь случилось чудо] мы договорились о 4-х неделях рабочего времени разработчика.

Как мы раньше работали с другими командами? Когда вам нужно, чтобы что-то сделала другая команда, вы должны спросить своего менеджера проекта, он или она идет к менеджеру этой команды, который несет задачу. Это был слишком долгий путь для задач, когда у нас было всего 4 недели. Поэтому вместо этого мы создали новую небольшую команду исключительно для этого проекта и поместили ее внутрь наших разработчиков. У нас был собственный проект в JIRA, собственный бэклог, и мы не принимали никаких входящих задач из других проектов, чтобы полностью сосредоточиться на нашем приложении. В нашу команду входили:

• Я как менеджер создаю задачи, обеспечиваю общение между членами команды и продвигаю весь процесс разработки
• 2 разработчика iOS
• 2 разработчика Android
• Backend разработчик
• Дизайнер

Теперь, когда у нас была команда и мы знали основные функции, которые нам нужно разработать, нам нужно было убедиться, что все мы выполняем правильные задачи. Но какова правильная задача? Это тот, который предоставляет нашим клиентам функции в кратчайшие сроки. Отличный пример такого подхода - дизайн пользовательского интерфейса. Я попросил нашего дизайнера создать пользовательский интерфейс, максимально приближенный к нативному, потому что он знаком пользователям и легко реализуется разработчиками. Итак, мы провели небольшой семинар для наших дизайнеров, рассказав им, какие стандартные элементы управления и анимации пользовательского интерфейса у нас есть и как мы можем их настроить. Мы запустили процесс «проверки дизайна», в ходе которого мы вместе обсуждали каждый экран внутри моей команды: дизайнер старался сделать его лучше, а разработчики - проще реализовать. Мы смогли развить и поддерживать этот процесс коммуникации внутри нашей команды, и это привело нас к успеху. Мы делали почти одинаковые разработки API: серверные и мобильные разработчики смотрели на экраны пользовательского интерфейса и писали протокол API, удобный для обеих сторон.

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

Слушайте своих товарищей по команде

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

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

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

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

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

После первого выпуска

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

• Они начинают с кино или подборки фильмов?
• Сколько времени наши клиенты проводят за конкретным экраном?
• Почему пользователь закрывает экран оплаты?

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

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

Вывод

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

Наш новый подход не был близок к Scrum, он был больше похож на Kanban, что отлично подходит, когда вам нужно запустить новый продукт в короткие сроки. И этот переход от Waterfall не был болезненным, мы действительно наслаждались новым способом совместной работы, влияя на созданное нами приложение и еженедельно получая новые результаты.

Спасибо за чтение!