Продуктивная Работа Мозга Разработчика: Как Перестать Писать Код И Начать Писать Приложения

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

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

Как балансировать между написанием кода и креативными идеями, где сейчас самые интересные проекты и нужны ли пользовательские данные для создания крутого приложения? Об этом мы поговорили с экспертом по разработке Android Джонатаном Левином.

Продуктивная работа мозга разработчика: как перестать писать код и начать писать приложения

Джонатан Левин — эксперт по Google Android. В свое время он сыграл ключевую роль в успехе Gett и получил финансирование от соединителя генетического рынка KolGene. Йонатан — опытный разработчик Android и предприниматель, который знает, как превратить хорошие идеи приложений в прибыльные продукты.

Код и инструменты

— Приложения обычно разрабатываются по четко определенному техническому заданию.

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

Но тоже ничего хорошего.

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

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

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

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

— Как правильно поставить задачу с самого начала и какие инструменты и подходы использовать? Джонатан Левин: Не знаю, как это сделать правильно, но расскажу, как я пытаюсь это сделать сама.

Еще на этапе формирования фичи/продукта эту фичу обсуждают все разработчики в команде.

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

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

Каждый из моих коллег-разработчиков является экспертом в своей области.

Я не могу сказать им, что можно сделать лучше на iPhone, в Интернете или на бэкенде.

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

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

— Многие разработчики решают типовые задачи внутри конвейера (например, в веб-студиях).

Как можно разнообразить обычные задачи и нужно ли это делать? Джонатан Левин: Кто-то когда-то сказал, что любая разработка под Android сводится к извлечению данных из бэкенда, их анализу и отображению в виде списка.

Любое задание может превратиться в утомительное и скучное.

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

Я думаю так: если вы получаете задание, с которым вы уже знакомы, сделали 100 500 раз и можете выполнить его за треть отведенного времени — это ваша возможность.

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

Пользовательский анализ

— Как научиться переходить от полировки и красоты кода к анализу пользователей? В какой момент приходит понимание: «Хватит. Пользователям нужно качественное приложение, мой код им не интересен»? Джонатан Левин: В какой момент вы поняли? — В Gett каждый раз, когда меня очень волновал выход той или иной инновации в технологии, я сразу бежал ее делать, внедрять и интегрировать в приложение.

Это привело к бессонным ночам исправления ошибок и пользователям, которые не могли безопасно использовать приложение.

Я думаю, что вначале мы все были такими.

Однажды вице-президент по RnD, когда я в очередной раз увлеченно рассказывал о новинке, которую сделала Square, спросил меня: «Ну, ладно, какую пользу это принесет нашему бизнесу, какую пользу мы от этого получимЭ» Я не мог ответить.

Позже я понял, насколько он был прав.

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

Больше кода — больше ошибок.

Любой рефакторинг — это бизнес-риск.

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

Его не будет волновать, что у вас теперь там есть Rx, Clean Architecture или какой-то новый ORM. Если вы не можете четко описать, какую пользу ваш рефакторинг принесет вашему бизнесу, вам следует подумать, нужен ли он вообще.

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

Как создать уникальное приложение?

— Мне бы хотелось сделать какой-то полезный и интересный продукт для пользователей.

На какие направления вы рекомендуете обратить внимание? Есть ли интересная ниша, которую по каким-то причинам не занимают разработчики? Джонатан Левин: Машинное обучение, пожалуй, самая горячая тема сегодня.

Но не как продукт, а как технология.

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

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

Ведь лучший продукт — тот, которым вы пользуетесь сами.

— Допустим, у меня есть замечательное приложение в узкой нише.

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

Как вообще выделиться из толпы? Джонатан Левин: У меня есть такой экзамен.

Я называю это «вау» экзаменом.

И начинается с того, что если это не вау, то я на это не согласен.

Если человек пришел на собеседование, а у меня не возникло чувства «вау», я не беру его в свою команду.

И «вау» не обязательно связано с технологической частью.

В основном речь идет о том, какой он человек, какой он.

То же самое и с продуктами — нужно стремиться делать «вау»: вау дизайн, вау User Experience, вау код, вау коммуникации.

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

Надо стремиться к тому, чтобы все было «вау» — чтобы шансы стать лучшими были самыми высокими.

— Как впечатлить пользователя с первых секунд запуска приложения? Чего не делать? Например, когда лучше использовать заставки, push-уведомления и другие средства? Джонатан Левин: Мое личное мнение: SplashScreen — это боль.

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

Обычно SplashScreen представляет собой логотип компании на красивом фоне.

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

На самом деле именно это должно заставлять пользователей запоминать ваше приложение.

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

Я думаю, что отличный трюк — сразу показать пользователю наживку: то есть, что делает ваше приложение.

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

Например, если у вас есть приложение «супермаркет», сразу покажите возможность добавить в корзину самые вкусные товары (шоколад!), и только когда он закончит выбор, предложите зарегистрироваться.

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

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

Рано или поздно кто-то проведет реверс-инжиниринг вашего приложения, и все выйдет наружу.

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

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

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

— Нужен ли вообще сбор пользовательских данных и в каком объеме? Не нарушает ли это их конфиденциальность? Как это на самом деле помогло? Какие сервисы и расширения вы рекомендуете использовать? Джонатан Левин: Без данных это как без глаз.

Трудно найти истинный путь в темноте.

С точки зрения законности, самый прямой способ — опубликовать условия, с которыми согласны пользователи.

Это может уберечь вас от многих проблем в дальнейшем.

Это не значит, что нужно бежать к адвокату и платить ему кучу тугриков.

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

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

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

На самом деле, такая информация является сокровищем.

Сокровище, которое позже поможет разобраться, что работает, как работает и как пользоваться функциями приложения.

Для начала я бы посоветовал установить FullStory для веба и TestFairy для мобильных приложений.

Это позволит вам увидеть, что именно делает ваш пользователь на сайте или в приложении.

Уверяю вас, вы будете удивлены многим вещам.

Кроме того, Google Analytics/Firebase Analytics предоставляет множество бесплатных плюшек в виде событий, которые можно записывать и использовать для дальнейшей обработки.

Если есть возможность, все следует измерить.

От того, сколько раз была нажата кнопка, какую фотографию просматривали больше всего.

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

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

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

Допустим, мы добавили функцию автозаполнения названия генетического теста при его заказе.

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

А если не заработает, отрезать функционал как гнилую деталь.

Как узнать, успешна ли заявка?

— Как правильно поставить KPI для вашего проекта? Как проверить их выполнение аналитическими системами? Джонатан Левин: Методом проб и ошибок.

Самый простой способ — начать с бизнес-модели.

Те.

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

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

— Расскажите об A/B-тестах.

Как и с помощью чего их правильно реализовать? Как не переборщить с A/B-тестами? Джонатан Левин: Мне понравился Firebase Remote Config. Он позволяет назначать разные значения в зависимости от того, кем является пользователь, откуда он и как он ведет себя.

Вы можете создавать разные события в Firebase Analytics, и если одно из них произойдет, сделать что-то особенное для этого пользователя.

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

Эти эксперименты можно запускать непрерывно и продолжать сколь угодно долго.

Что хорошо в RemoteConfig, так это то, что вы можете постоянно проводить эти эксперименты и тесты.

От разных цветов до навигации внутри приложения.

Главное, подумать о них заранее при разработке функционала.

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

Лучше всего подключить это к RemoteConfig и посмотреть, что работает надежнее.

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

Меньше кода — меньше ошибок.

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

Мебиус 2017 Москва :