- PVSM.RU - https://www.pvsm.ru -
В середине ноября наши друзья из Sports.ru запустили курс для тех, кто хочет стать продакт-менеджером [1] мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev [2] рассказывает, как проходит обучение. Сегодня – инсайды с лекции об этапах разработки приложения.
–… вот только, братцы, добраться б дотемна. С. Галанин.
В прошлой статье [3] я рассказал, зачем нужны продуктовые менеджеры, откуда они берутся и с чего начинают работу над дизайном приложения. Моя неточность возвысила Антона Байцура до директора по продажам Aviasales и выдала его выступлению неоднозначный аванс (а зря). О лекции Антона – в следующий раз, а пока я потомлю вас еще немного и опишу этапы разработки приложения на основе рассказа Сергея Кузьменко из Cassby [4].
Думаю, выражу мнение большинства, если скажу, что мало что ценится так высоко и остается в памяти так долго, как прикольный мерч. Если вам удалось соединить в нем простоту, красоту и смысл, – это большой успех. В самом начале занятий мы получили по стикеру, содержание которого явно было позаимствовано со слайда Сергея Кузьменко, – сравните две картинки ниже:
Шутки-шутками, но во время курса все студенты работают над своим мобильным приложением, и, чувствую, эта наклейка будет полезным методическим материалом. Пора бы прикинуть, что у меня уже готово, а о чем еще предстоит подумать на каждом из этапов разработки.
В комментариях к первой статье было верно подмечено: важно написать хороший, детальный бриф. С самого начала работы над приложением у вас должна быть какая-то тактика :) На этапе концепта важно точно понимать, что и для кого вы делаете, и какую перспективу – радужную или не очень – рисуете. Рекомендую подходить к вопросу перспективы с обеих сторон: и пользователя, и разработчика.
Одним из первых документов, который вам предстоит создать, будет бизнес-план, сначала менее детальный, но обрастающий все большим количеством нюансов: как оплачивать работу команды, какие траты предстоят и за счет чего их покрывать. Например, я работаю над приложением для программы вознаграждения за взаимодействия с брендом. Это небольшой сайд-проект, и для меня особенно важна эффективность финансирования и формирования команды. Пока мой рабочий вариант – максимально проработать концепт приложения и идти на поклон к коммерческому директору компании, где я работаю, в надежде, что он увидит потенциал для инвестирования.
В содержание концепции полезно заложить продуктовый roadmap и описание минимального жизнеспособного продукта (Minimum Valuable Product). В программ-менеджменте есть понятие business case, аналогичное нашему MVP: считайте, что MVP – это инструмент, позволяющий вам в любой момент проверить, стоит ли идти дальше.
Кажется, только ленивый не шутил на счет россиян, не читающих инструкции по сборке домашней техники. Но если вы рассчитываете на успех в создании приложений, документы придется не только читать, но и писать.
Лайфхак: совсем не обязательно составлять длинные полотна; техзадание может (и должно!) быть коротким, удобным, недвусмысленным, однозначным, актуальным. Ценность этого документа сильно завязана на времени, поэтому не стоит делать его бесконечным.
Вот примерный список того, что стоит учесть в ТЗ (в скобках примеры из моего приложения):
Аналогом известной дилеммы является вопрос, что делать сначала, тексты или дизайн. Аргументы с обеих сторон приводятся железные, а если судить по рекомендациям всех спикеров курса («Не оставляйте… на конец»), в конце разработки приложения нам вообще нечем будет заняться. Мое скромное мнение: сначала нужно создать пользовательскую историю, потом заголовки, потом дизайн на блок-схемах, потом полноценные тексты. Конечно, правильно использовать в разработке дизайна не Lorem ipsum, а содержательный текст, но будет преувеличением ожидать, что эта версия текста доживет до релиза.
В работе над текстом стоит уделить особенно большое внимание целостности (чтобы не сказать «консистентности») и ключевым частям мессаджинга, таким как название или слоган. Если есть возможность, пишите ключевые сценарии самостоятельно или хотя бы вовлекайтесь в работу над ними по полной.
Второй по хронологии, но, пожалуй, не по важности шаг – аккуратное планирование контента. С самого начала зафиксируйте правильные требования к нему (длину текстов, формат снимков, объемы видео и т.п.) и необходимый для запуска объем. Определите, какой контент вы будете выпускать, как часто и кто за это будет отвечать. В качестве иллюстрации скажу, что я рассчитываю в своем приложении по максимуму использовать контент брендовых сайтов, обеспечивая постоянный поток и формируя ту самую пресловутую целостность коммуникации.
Я не стану подробнее останавливаться на этапе дизайна. Если вам хочется узнать больше, посмотрите кусок, написанный по материалам Марии Михальчук [3], в прошлой заметке. Скажу лишь, что важно помнить, что контент всегда кому-то принадлежит, и некоторые платформы (да, мистер Кук?) следят за этим особенно пристально.
Для многих людей веб-мастер, front-end, back-end, full-stack-разработчики и просто «компьютерщики» практически не различимы. Думаю, Хабр – последнее место, где нужно рассказывать, кто из них чем занимается. Позволю себе только один совет, ссылаясь на мнение Сергея Кузьменко: если вы продуктовый менеджер и ваши возможности сильно ограничены, нанимайте front-end'а. Обратите особое внимание на его знание разных браузеров, мобильных ОС и на опыт реализованных проектов. Обязательным навыком также является владение Photoshop и вообще любовь к упражнениям с дизайном.
И еще раз про ТЗ. Убедитесь, что вы передаете разработчику полное описание задач, проработанный дизайн и близкий к готовому контент – тогда на выходе велика вероятность получить пригодную для тестирования версию приложения.
Возвращаясь к идее о том, что продукт нужно запускать, пока за него еще немного стыдно, отмечу, что ключевое слово здесь – «немного». Поиск баланса остается самой важной для продуктового менеджера задачей. Одного лишь запуска недостаточно, качество самого продукта должно постоянно расти.
Вот несколько вариантов тестирования, которые актуальны именно для мобильных приложений (в скобках снова иллюстрации на моем примере):
Релевантный и актуальный тест-план – это очень и очень хороший показатель зрелости проекта.
Все перечисленные выше этапы пройдут гладко, если у вас хорошая команда. Кажется, в плане лекций есть отдельная тема по набору сотрудников, поэтому для экономии времени скажу только, что сейчас очень много внимания уделяется социальным связям и общим интересам членов команды. Вам предстоит многое пережить вместе, поэтому важно, чтобы этот путь был комфортным. Банально, но общие ценности, открытость и настрой на позитив обеспечивают значительную долю успеха в релизе приложения.
В завершение приведу короткий релизный чек-лист:
Ну и устройте вечеринку, если все пройдёт хорошо :) В следующий раз я чуть подробнее расскажу о внутренних процессах продуктовой команды, о работе с мобильными сторами и постараюсь показать свои наработки по экранам и описанию приложения.
Спасибо Appodeal [8] за площадку и Марку Тену за эксперимент.
Автор: Appodeal
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mobil-ny-e-prilozheniya/216013
Ссылки в тексте:
[1] курс для тех, кто хочет стать продакт-менеджером: https://product.degree/
[2] kirillkobelev: https://habrahabr.ru/users/kirillkobelev/
[3] прошлой статье: https://habrahabr.ru/company/appodeal/blog/316154/
[4] Cassby: https://cassby.com/
[5] попытка порассуждать: https://habrahabr.ru/company/redmadrobot/blog/280618
[6] хостинг: https://www.reg.ru/?rlink=reflink-717
[7] Github: http://Github.com
[8] Appodeal: http://www.appodeal.com/
[9] Источник: https://habrahabr.ru/post/316654/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.