Как превратить идею в фичу для мобильного приложения?

Релизный цикл Яндекс.Музыки под микроскопом

Как превратить идею в фичу для мобильного приложения?

Менеджмент

Добавление новых возможностей в мобильное приложение — это многоступенчатый процесс, который требует согласованности в команде. В то же время он должен быть итеративным: в больших компаниях любят термин «релизный цикл». Не так давно разработчик Яндекс.Музыки Дмитрий Трубников разобрал весь путь фичи (новой функциональности) на Mobile Junior meetup. Эта встреча собрала начинающих специалистов по Android и iOS и будущих участников стажировки Яндекса. Перед вами статья Димы, написанная по мотивам его доклада.

Когда я отвечаю на вопрос, чем же я занимаюсь, то часто встречаю непонимание: что делает мобильный разработчик в Яндекс.Музыке? Приложение уже написано, что же я там делаю, протираю пыль с кода или что? Пользователи не всегда понимают, что приложение живет, дышит, постоянно меняется. В нём появляются новые фичи, о них я и хочу рассказать. Важно видеть всю картину целиком: понимать, что происходит до написания кода, во время него и после.

alt

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

Команда

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

alt

Последняя роль на самом деле наиболее важная. Без нее не может обойтись ни одно приложение.

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

alt

Идея

Где же здесь пользователь? Чтобы это понять, нужно глобально взглянуть на задачу и подумать, а для чего вообще создаются приложения.

alt

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

Таким образом, идеи идут от пользователей. Вопрос: а как мы о них узнаем и как реагируем? У нас может быть какой-то явный фичреквест от пользователей. Например, пользователь может написать где-нибудь в Play Market или в support, мол, я хочу кнопочку, которая запускает пятый трек снизу. Странно, но окей, мы тебя услышали.

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

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

Задача

Задачи приходится фильтровать. Здесь может возникнуть вопрос: а как? Какой использовать компаратор для того, чтобы отсортировать задачи и выбрать приоритетные для нас?

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

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

alt

Сводились они примерно к тому, что, да, мне очень нравятся подкасты, это здорово, круто, но слушать два часа подкасты мне тяжело. Добавьте возможность увеличить скорость воспроизведения. И тут не надо быть аналитиком, чтобы стало понятно: да, действительно, фича нужная, классная. Давайте будем делать. Так появилась идея.

На примере этой фичи можно пройти до конца и понять, как она попадет на устройства пользователей.

Разработка

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

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

Код-ревью

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

Тестирование и merge

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

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

alt

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

Альфа-тестирование

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

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

Бета-тестирование

Если альфа-тестирование, включая этап с асессорами, пройдено — новая версия попадает к бета-тестировщикам. Это обычные пользователи, которые решили, что хотят видеть все новые фичи самыми первыми.

Здесь может возникнуть вопрос: зачем столько этапов, столько людей?

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

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

Итак, альфа- и бета-тестирование прошло, выкатываемся в Play Market или в App Store. После этого наш релизный цикл начинается заново, на то он и цикл:

alt

Выводы

  1. Сделать всё невозможно. Выполнить все желания пользователей нельзя физически. Пропускная способность разработчиков меньше, чем количество фичреквестов от пользователей.
  2. Делая новое, не ломай старое. Когда вы вносите изменения в код вашего приложения, помните, думайте о возможных сайд-эффектах. Все помнят гифку с котиком? На самом деле на гифке показан идеальный случай: котик что-то повернул, что-то сломал и сразу увидел сзади водопад. Чаще всего происходит не так: водопад случится, но это такая бомба замедленного действия, она сработает гораздо позже. Для этого должно выполниться много условий.
  3. Вероятность бага в полпроцента — это много.
  4. Ранний баг — это хорошо. Чем раньше мы его обнаружим, тем проще и дешевле нам будет его исправить.
  5. Пользователь всё помнит. Есть разные версии приложений, и если вы когда-то написали код, работающий с базой данных, вам его, скорее всего, уже не удастся удалить. Он навсегда останется, чтобы поддерживать переходы по версиям.

Больше по теме

Менеджмент

Отличные книги для менеджеров, изданные в последние годы

От исследований трендов к документальным детективам о стартапах

Менеджмент, Разработка

«На своей работе я учусь решать проблемы»

Рассказ сотрудников внутренней службы техподдержки Яндекса Олега Безушко и Николая Чхиквадзе

Разработка, Менеджмент

Советы по удаленной работе для разработчиков

Сотрудники Яндекса рассказали о том, как продуктивно работать из дома

Анализ данных, Менеджмент

Как переводчики в Яндексе помогают улучшать машинный перевод?

Руководитель группы лингвистической экспертизы Эми Кришневски о том, как связаны машинный перевод и работа её команды

Менеджмент, Анализ данных

Санитары леса: как устроен антифрод в Яндекс.Дзене

Борьба с накрутчиками, любителями эротической живописи и комментаторами-ненавистниками

Разработка, Менеджмент

Наставничество в IT: кто и как применяет его в работе?

Три истории людей, которые работали с наставниками или сами обучали новичков

Разработка, Менеджмент

Чем занимается внутренняя техподдержка Яндекса

Рассказ руководителя службы ServiceDesk Арвидаса Гафиулина