Мобильный рынок развивается настолько стремительно, что для того, чтобы понравиться пользователям, уже недостаточно разработать просто хорошее приложение. Нужно ориентироваться на аудиторию, предлагать интересные и полезные фичи, но при этом не переборщить. Как балансировать между написанием кода и творческими идеями, где сейчас самые интересные проекты и нужны ли пользовательские данные для создания классного приложения? Мы поговорили об этом с экспертом по разработке под Android Йонатаном Левином.
Йонатан Левин имеет звание Google Android Experts. В свое время он сыграл ключевую роль в успехе Gett и получил финансирование генетического market connector-а KolGene. Йонатан — состоявшийся Android-разработчик, а также предприниматель, который отлично знает, как превратить хорошие идеи для приложения в прибыльный продукт.
Код и инструменты
— Обычно приложения разрабатываются по четко прописанному ТЗ. Что плохого в том, что разработчик сосредоточится лишь на коде?
Йонатан Левин: Конечно, в этом нет ничего плохого. Но и ничего хорошего. Расписать все в ТЗ — задача крайне тяжелая и подчас практически невыполнимая.
Разработчик, который просто пишет код, — просто напишет код. И он, наверное, будет работать так, как указано в ТЗ.
Разработчик, который понимает, почему он пишет именно такой код, как и кем он будет использоваться, куда этот продукт будет расти и какова вообще цель всего того, что он делает, — напишет не код, а продукт. Ведь именно мы, разработчики, являемся источником знаний о том, что лучше всего делать на той или иной платформе и как правильно построить то или иное техническое решение, основываясь на нуждах юзера. А для этого нужно задавать кучу вопросов, понимать что, почему, и как все это в результате сделает жизнь пользователей продукта лучше.
— Как изначально правильно поставить задачу и какие иструменты и подходы использовать?
Йонатан Левин: Не знаю, как правильно, но я расскажу, как стараюсь делать сам.
Еще на стадии формирования функции/продукта все разработчики команды обсуждают эту функцию. Я подготавливаю описание и все базисные данные в формате: «кто пользователь, почему нужна такая функциональность, кто ей будет пользоваться, как мы будем измерять ее успешность». Дальше мы садимся и все вместе обсуждаем, как лучше прийти к тому или иному решению.
Каждый из моих коллег-разработчиков — эксперт в своей области. Я не могу сказать за них, что можно сделать лучше на айфоне, в вебе или бекенде. Конечно, я смогу написать код под каждую платформу и выбрать какую-то архитектуру, но мои коллеги — эксперты по каждой из этих платформ и гораздо лучше меня знают, что лучше всего подойдет для нее.
В качестве инструментов, думаю, самое лучшее — пара фломастеров, доска для обсуждений, вкусный обед за счет компании и целый день — для непосредственно планирования и обсуждения.
— Многие разработчики решают типовые задачи в рамках конвейера (к примеру, в веб-студиях). Как можно разнообразить рядовые задачи и нужно ли это делать?
Йонатан Левин: Кто-то когда-то сказал, что любая разработка под Android сводится к тому, чтобы вытащить данные с бэкенда, спарсить и показать их в списке. Любая задача может превратиться в нудную и скучную. С другой стороны, эту же задачу можно превратить в суперинтересную и захватывающую.
Я думаю так: если ты получил задачу, с которой уже знаком, делал 100500 раз и сделаешь за треть из отведенного времени — это твоя возможность. В разработке выходит множество разных библиотек, архитектурных решений, изменений — это прекрасная возможность опробовать что-то новое, посмотреть, как оно работает под капотом, и благодаря этому проапгрейдить свои скиллы.
Анализ пользователей
— Как научиться переходить от шлифовки и красоты кода к анализу пользователей? В какой момент приходит понимание: «Все, хватит. Пользователям нужно качественное приложение, они не интересуются моим кодом»?
Йонатан Левин: В какой момент пришло понимание? — В Gett я каждый раз, когда был очень взволнован выходом того или иного новшества в технологиях, сразу бежал делать это, реализовывать и интегрировать в приложение. Это выливалось в бессонные ночи баг-фиксинга и пользователей, которые не могли спокойно пользоваться приложением.
Я думаю, вначале мы все были такими. Как-то VP RnD при моем очередном взволнованном рассказе о новой штуке, которую сделал Square, спросил меня: «ну хорошо, а какой нашему бизнес от этого прок, как мы выиграем от этого?» Я не смог ответить. Позже я понял, насколько он был прав. Это был просто очередной рефакторинг того, что и так работало и не требовало дополнительных ресурсозатрат.
Больше кода — больше багов. Любой рефакторинг — это риск для бизнеса. Достаточно пару крашей, чтобы юзер перестал пользоваться приложением. Его не будет волновать, что сейчас у вас там Rx, Clean Architecture или какой-то новый ORM.
Если вы не можете четко описать, какая будет польза бизнесу от вашего рефакторинга — стоит задуматься, нужен ли он вообще.
Может лучше потратить время на создание новой функции, которая принесет вашему приложению еще больше славы?
Как создать уникальное приложение?
— Хочется сделать какой-то полезный и интересный для пользователей продукт. На какие сферы советуете обратить внимание? Есть ли какая-то интересная ниша, по каким-то причинам не занятая разработчиками?
Йонатан Левин: На сегодняшний день Machine Learning — это наверное самая горячая тема. Но не как продукт, а как технология. С ее помощью можно создавать продукты, которые раньше не были доступны, при этом не нужно быть доктором в прикладной математике или алгоритмике.
Уже существует очень большой набор инструментов для создания продуктов на основе Machine Learning — от TensorFlow до всяких OCRов. А поле деятельности, на котором это можно применять, поистине огромное: я бы посоветовал начать с проблемы, которая больше всего волнует самого разработчика. Ведь лучший продукт — это тот, которым пользуешься сам.
— Допустим, у меня чудесное приложение в узкой нише. Как донести пользователям его уникальность? В сторах огромное число приложений вываливается каждый день. Как вообще выделиться из толпы?
Йонатан Левин: У меня есть такой экзамен. Я называю его экзамен «вау». И он начинается с того, что если это не «вау», то я не соглашаюсь на это.
Если человек пришел на интервью, и у меня не было чувства «вау», я его не беру к себе в команду. И «вау» — это не обязательно по технологической части. По большей части это о том, что за человек, что он из себя представляет.
То же самое и с продуктами — нужно стремиться делать «вау»: вау-дизайн, вау-User Experience, вау-код, вау-коммуникации.
Обычно у любой идеи, о которой можно задуматься, скорее всего есть уже 10 человек, которые подумали об этом и уже начали что-то делать. Поэтому важна не сколько идея, сколько ее реализация. Надо стремиться к тому, чтобы все было «вау» — для того, чтобы шансы стать лучшим были самими высокими.
— Как впечатлить пользователя с первых секунд запуска приложения? Что не нужно делать? К примеру, когда лучше применять splash-экран, push-уведомления и другие средства?
Йонатан Левин: Мое личное мнение: SplashScreen — это боль. В среднем есть около пяти секунд, чтобы составить первое впечатление о приложении и подцепить пользователя на крючок. Обычно SplashScreen — это лого компании на красивом фоне. Чаще всего разработчики используют его, чтобы подгрузить всякие настройки. В действительности это должно быть тем, за счет чего пользователи запомнят ваше приложение. Есть другие более интересные решения, используемые при подгрузке параметров в бекграунде.
Я думаю, что отличный крючок — сразу показать вашему пользователю наживку: то есть то, что делает ваше приложение.
И это можно сделать либо через процесс OnBoarding, где в очень красивом и интерактивном виде рассказать историю того, что есть в вашем приложении, либо сразу показав главные действия. Например, если у вас приложение «супермаркет», — сразу показать возможность добавки самых вкусных продуктов (шоколад!) в корзину, и только когда он закончит выбирать, предложить зарегистрироваться.
— Допустим, апп собирает множество данных в фоне: геолокацию, медиаконтент, контакты и т.п. Как это правильно замаскировать? И надо ли это маскировать?
Йонатан Левин: Прозрачность — это, наверное, самое лучшее, что вы можете дать пользователям. Когда я был маленьким, нам всегда говорили — все тайное становится явным. Рано или поздно кто-то сделает реверс-инжиниринг вашего приложения, и все выплывет. Урон компании будет огромным.
Гораздо лучше дать пользователю возможность решить — хочет он или не хочет отдавать вам свои данные, объяснив, что и как будет происходить с ними.
По моему опыту, большинство готово отдать свои данные за те или иные возможности в приложении.
— Нужно ли вообще собирать данные о пользователях и в каком объеме? Это не нарушает их приватность? Чем это помогло в реальности? Какими сервисами и расширениями рекомендуете пользоваться?
Йонатан Левин: Без данных — как без глаз. Тяжело найти истинный путь в потемках.
С точки зрения легальности самый прямой путь — повесить terms & condition, с которыми юзеры соглашаются. Впоследствии это может избавить от многих проблем. Это не значит, что нужно бежать к юристу и платить ему кучу тугриков. Интернет — очень полезная штука, если немного поискать, вполне можно найти шаблон Terms & Condition, который подойдет на первых этапах развития, пока в компании не появится юрист.
Насчет приватности — я думаю, что она как факт давно уже не существует. Если кто-то думает, что может скрыть что-либо от того, кто действительно хочет заполучить эту информацию — он заблуждается. Поэтому я особо не переживаю, когда кто-то собирает информацию о том, как я пользуюсь тем или иным приложением. И большинство юзеров, как показывает много кейсов, ставят галочку на Terms & Condition, даже не читая.
В реальности такая информация — клад. Клад, который потом поможет разобраться, что и как работает и как пользуются функциями приложения.
Для начала я бы посоветовал поставить FullStory для веба и TestFairy для мобильных приложений. Это позволит смотреть, что именно делает ваш юзер на сайте или в приложении. Я уверяю вас, вы удивитесь многим вещам.
Кроме этого, Google Analytics/Firebase Analytics дает очень много бесплатных плюшек в виде событий, которые можно фиксировать и использовать для дальнейшей обработки.
По возможности нужно измерять все. Начиная с того, сколько раз кликали на кнопку, до того, какую фотографию просматривали больше всего. Не говоря уж о том, что фиксировать бизнес-метрики — это абсолютно необходимое дело.
— Вот мы собираем данные, анализируем каждый шаг пользователя в приложении. Как этими данными правильно распоряжаться?
Йонатан Левин: Каждый раз, когда мы разрабатываем ту или иную фукнцию в приложении, нам нужно определить, какие метрики будут измерять ее успех.
Скажем, вот мы добавили функцию автозаполнения названия генетического теста при его заказе. Как узнать, успешно она работает или нет? Что будет считаться успехом для этой функции? Может быть, количество успешно подсказанных имен в тесте? Или, может быть, общее время, проведенное на экране заказа? Или то, с какой буквы мы попали?
Все это нужно указать заранее и измерять, а потом решать, что с этим делать. И если оно не работает — резать функционал как загнившую часть.
Как понять, успешно ли приложение?
— Как правильно установить KPI для своего проекта? Как проверить их выполнение аналитическими системами?
Йонатан Левин: Методом проб и ошибок. Проще всего исходить из бизнес-модели. Т.е. если заработок идет от количества выполненных генетических тестов, нужно мерить все, что может повлиять на это. К примеру, KPI может быть от уровня и времени взаимодействия лаборатории и скорости выполнения ее работы до разброса цен в предложениях от разных лабораторий.
Расскажите про A/B тесты. Как и чем их корректно реализовать? Как не переборщить с A/B тестами?
Йонатан Левин: Я полюбил Firebase Remote Config. Он позволяет прикручивать разные значения, основываясь на том, кто юзер, откуда он и как он себя ведет.
Можно сделать разные события в Firebase Analytics, и если одно из них произошло, то делать что-нибудь особенное для этого юзера.
Например, можно установить кнопку заказа в верхнем меню, скажем, как Bottom Tab, и замерять, где больше всего пользователей конвертируются в тех, кто заказывает. Эти эксперименты можно запускать постоянно и продолжать сколько угодно времени.
Что замечательного в RemoteConfig — эти эксперименты и тесты можно проводить постоянно. От разных цветов, до навигации внутри приложения. Главное: заранее продумать их при разработки функциональности. В особенности если есть нюансы, о которых нет однозначного мнения. Самое лучшее — прикрутить это к RemoteConfig и смотреть, что работает надежнее.
И самое главное — когда вы поняли, что работает лучше всего, и знаете, что это не будет изменяться в ближайшее время — почистите код и удалите все эти подготовки под кофеварку внутри вашего приложения. Меньше кода — меньше багов.
Если вы любите смаковать детали в мобильной разработке так же, как и мы, наверняка вам будут интересны вот эти доклады на нашей ноябрьской конференции Mobius 2017 Moscow:
- Оптимизация размера приложения (Дмитрий Куркин, Mail.Ru)
- Как самому запилить новую фичу и при этом не быть убитым своим менеджером (Йонатан Левин, KolGene)
- Crash репорты Android NDK (Иван Пономарев, Akvelon)
- Как стать GPU-инженером за час (Андрей Володин, Prisma AI)
Автор: Алексей Городищев
