В середине ноября наши друзья из Sports.ru запустили курс для тех, кто хочет стать продакт-менеджером мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev рассказывает, как проходит обучение. Сегодня – инсайды с лекции об этапах разработки приложения.
–… вот только, братцы, добраться б дотемна. С. Галанин.
В прошлой статье я рассказал, зачем нужны продуктовые менеджеры, откуда они берутся и с чего начинают работу над дизайном приложения. Моя неточность возвысила Антона Байцура до директора по продажам Aviasales и выдала его выступлению неоднозначный аванс (а зря). О лекции Антона – в следующий раз, а пока я потомлю вас еще немного и опишу этапы разработки приложения на основе рассказа Сергея Кузьменко из Cassby.
Думаю, выражу мнение большинства, если скажу, что мало что ценится так высоко и остается в памяти так долго, как прикольный мерч. Если вам удалось соединить в нем простоту, красоту и смысл, – это большой успех. В самом начале занятий мы получили по стикеру, содержание которого явно было позаимствовано со слайда Сергея Кузьменко, – сравните две картинки ниже:
Шутки-шутками, но во время курса все студенты работают над своим мобильным приложением, и, чувствую, эта наклейка будет полезным методическим материалом. Пора бы прикинуть, что у меня уже готово, а о чем еще предстоит подумать на каждом из этапов разработки.
В комментариях к первой статье было верно подмечено: важно написать хороший, детальный бриф. С самого начала работы над приложением у вас должна быть какая-то тактика :) На этапе концепта важно точно понимать, что и для кого вы делаете, и какую перспективу – радужную или не очень – рисуете. Рекомендую подходить к вопросу перспективы с обеих сторон: и пользователя, и разработчика.
Одним из первых документов, который вам предстоит создать, будет бизнес-план, сначала менее детальный, но обрастающий все большим количеством нюансов: как оплачивать работу команды, какие траты предстоят и за счет чего их покрывать. Например, я работаю над приложением для программы вознаграждения за взаимодействия с брендом. Это небольшой сайд-проект, и для меня особенно важна эффективность финансирования и формирования команды. Пока мой рабочий вариант – максимально проработать концепт приложения и идти на поклон к коммерческому директору компании, где я работаю, в надежде, что он увидит потенциал для инвестирования.
В содержание концепции полезно заложить продуктовый roadmap и описание минимального жизнеспособного продукта (Minimum Valuable Product). В программ-менеджменте есть понятие business case, аналогичное нашему MVP: считайте, что MVP – это инструмент, позволяющий вам в любой момент проверить, стоит ли идти дальше.
Кажется, только ленивый не шутил на счет россиян, не читающих инструкции по сборке домашней техники. Но если вы рассчитываете на успех в создании приложений, документы придется не только читать, но и писать.
Лайфхак: совсем не обязательно составлять длинные полотна; техзадание может (и должно!) быть коротким, удобным, недвусмысленным, однозначным, актуальным. Ценность этого документа сильно завязана на времени, поэтому не стоит делать его бесконечным.
Вот примерный список того, что стоит учесть в ТЗ (в скобках примеры из моего приложения):
Аналогом известной дилеммы является вопрос, что делать сначала, тексты или дизайн. Аргументы с обеих сторон приводятся железные, а если судить по рекомендациям всех спикеров курса («Не оставляйте… на конец»), в конце разработки приложения нам вообще нечем будет заняться. Мое скромное мнение: сначала нужно создать пользовательскую историю, потом заголовки, потом дизайн на блок-схемах, потом полноценные тексты. Конечно, правильно использовать в разработке дизайна не Lorem ipsum, а содержательный текст, но будет преувеличением ожидать, что эта версия текста доживет до релиза.
В работе над текстом стоит уделить особенно большое внимание целостности (чтобы не сказать «консистентности») и ключевым частям мессаджинга, таким как название или слоган. Если есть возможность, пишите ключевые сценарии самостоятельно или хотя бы вовлекайтесь в работу над ними по полной.
Второй по хронологии, но, пожалуй, не по важности шаг – аккуратное планирование контента. С самого начала зафиксируйте правильные требования к нему (длину текстов, формат снимков, объемы видео и т.п.) и необходимый для запуска объем. Определите, какой контент вы будете выпускать, как часто и кто за это будет отвечать. В качестве иллюстрации скажу, что я рассчитываю в своем приложении по максимуму использовать контент брендовых сайтов, обеспечивая постоянный поток и формируя ту самую пресловутую целостность коммуникации.
Я не стану подробнее останавливаться на этапе дизайна. Если вам хочется узнать больше, посмотрите кусок, написанный по материалам Марии Михальчук, в прошлой заметке. Скажу лишь, что важно помнить, что контент всегда кому-то принадлежит, и некоторые платформы (да, мистер Кук?) следят за этим особенно пристально.
Для многих людей веб-мастер, front-end, back-end, full-stack-разработчики и просто «компьютерщики» практически не различимы. Думаю, Хабр – последнее место, где нужно рассказывать, кто из них чем занимается. Позволю себе только один совет, ссылаясь на мнение Сергея Кузьменко: если вы продуктовый менеджер и ваши возможности сильно ограничены, нанимайте front-end'а. Обратите особое внимание на его знание разных браузеров, мобильных ОС и на опыт реализованных проектов. Обязательным навыком также является владение Photoshop и вообще любовь к упражнениям с дизайном.
И еще раз про ТЗ. Убедитесь, что вы передаете разработчику полное описание задач, проработанный дизайн и близкий к готовому контент – тогда на выходе велика вероятность получить пригодную для тестирования версию приложения.
Возвращаясь к идее о том, что продукт нужно запускать, пока за него еще немного стыдно, отмечу, что ключевое слово здесь – «немного». Поиск баланса остается самой важной для продуктового менеджера задачей. Одного лишь запуска недостаточно, качество самого продукта должно постоянно расти.
Вот несколько вариантов тестирования, которые актуальны именно для мобильных приложений (в скобках снова иллюстрации на моем примере):
Релевантный и актуальный тест-план – это очень и очень хороший показатель зрелости проекта.
Все перечисленные выше этапы пройдут гладко, если у вас хорошая команда. Кажется, в плане лекций есть отдельная тема по набору сотрудников, поэтому для экономии времени скажу только, что сейчас очень много внимания уделяется социальным связям и общим интересам членов команды. Вам предстоит многое пережить вместе, поэтому важно, чтобы этот путь был комфортным. Банально, но общие ценности, открытость и настрой на позитив обеспечивают значительную долю успеха в релизе приложения.
В завершение приведу короткий релизный чек-лист:
Ну и устройте вечеринку, если все пройдёт хорошо :) В следующий раз я чуть подробнее расскажу о внутренних процессах продуктовой команды, о работе с мобильными сторами и постараюсь показать свои наработки по экранам и описанию приложения.
Спасибо Appodeal за площадку и Марку Тену за эксперимент.
–… вот только, братцы, добраться б дотемна. С. Галанин.
В прошлой статье я рассказал, зачем нужны продуктовые менеджеры, откуда они берутся и с чего начинают работу над дизайном приложения. Моя неточность возвысила Антона Байцура до директора по продажам Aviasales и выдала его выступлению неоднозначный аванс (а зря). О лекции Антона – в следующий раз, а пока я потомлю вас еще немного и опишу этапы разработки приложения на основе рассказа Сергея Кузьменко из Cassby.
От нуля до релиза
Думаю, выражу мнение большинства, если скажу, что мало что ценится так высоко и остается в памяти так долго, как прикольный мерч. Если вам удалось соединить в нем простоту, красоту и смысл, – это большой успех. В самом начале занятий мы получили по стикеру, содержание которого явно было позаимствовано со слайда Сергея Кузьменко, – сравните две картинки ниже:
Шутки-шутками, но во время курса все студенты работают над своим мобильным приложением, и, чувствую, эта наклейка будет полезным методическим материалом. Пора бы прикинуть, что у меня уже готово, а о чем еще предстоит подумать на каждом из этапов разработки.
I have a dream
В комментариях к первой статье было верно подмечено: важно написать хороший, детальный бриф. С самого начала работы над приложением у вас должна быть какая-то тактика :) На этапе концепта важно точно понимать, что и для кого вы делаете, и какую перспективу – радужную или не очень – рисуете. Рекомендую подходить к вопросу перспективы с обеих сторон: и пользователя, и разработчика.
Одним из первых документов, который вам предстоит создать, будет бизнес-план, сначала менее детальный, но обрастающий все большим количеством нюансов: как оплачивать работу команды, какие траты предстоят и за счет чего их покрывать. Например, я работаю над приложением для программы вознаграждения за взаимодействия с брендом. Это небольшой сайд-проект, и для меня особенно важна эффективность финансирования и формирования команды. Пока мой рабочий вариант – максимально проработать концепт приложения и идти на поклон к коммерческому директору компании, где я работаю, в надежде, что он увидит потенциал для инвестирования.
В содержание концепции полезно заложить продуктовый roadmap и описание минимального жизнеспособного продукта (Minimum Valuable Product). В программ-менеджменте есть понятие business case, аналогичное нашему MVP: считайте, что MVP – это инструмент, позволяющий вам в любой момент проверить, стоит ли идти дальше.
Лапы и хвост
Кажется, только ленивый не шутил на счет россиян, не читающих инструкции по сборке домашней техники. Но если вы рассчитываете на успех в создании приложений, документы придется не только читать, но и писать.
Лайфхак: совсем не обязательно составлять длинные полотна; техзадание может (и должно!) быть коротким, удобным, недвусмысленным, однозначным, актуальным. Ценность этого документа сильно завязана на времени, поэтому не стоит делать его бесконечным.
Вот примерный список того, что стоит учесть в ТЗ (в скобках примеры из моего приложения):
- Общее описание предметной области (что я имею в виду под программой вознаграждения взаимодействия с брендом и как это работает),
- Информационная модель и основные сущности (потребитель, бренд, взаимодействие, вознаграждение, инсентивизация),
- Карта экранов (тут я ее не привожу, но держу в голове список для одной-двух критических пользовательских историй),
- Цели простым списком (я хочу получить такое-то количество участников, выполняющих такие-то целевые действия),
- Статистика, оценка, аналитика (частота заходов, продолжительность сессии, количество взаимодействий, динамика базы пользователей),
- Взаимодействие с другими системами (CRM, CMS, DMP),
- Копирайт (тут еще много работы, но у меня есть небольшой план на основе тех же пользовательских историй и экранов).
Курица или яйцо?
Аналогом известной дилеммы является вопрос, что делать сначала, тексты или дизайн. Аргументы с обеих сторон приводятся железные, а если судить по рекомендациям всех спикеров курса («Не оставляйте… на конец»), в конце разработки приложения нам вообще нечем будет заняться. Мое скромное мнение: сначала нужно создать пользовательскую историю, потом заголовки, потом дизайн на блок-схемах, потом полноценные тексты. Конечно, правильно использовать в разработке дизайна не Lorem ipsum, а содержательный текст, но будет преувеличением ожидать, что эта версия текста доживет до релиза.
В работе над текстом стоит уделить особенно большое внимание целостности (чтобы не сказать «консистентности») и ключевым частям мессаджинга, таким как название или слоган. Если есть возможность, пишите ключевые сценарии самостоятельно или хотя бы вовлекайтесь в работу над ними по полной.
Второй по хронологии, но, пожалуй, не по важности шаг – аккуратное планирование контента. С самого начала зафиксируйте правильные требования к нему (длину текстов, формат снимков, объемы видео и т.п.) и необходимый для запуска объем. Определите, какой контент вы будете выпускать, как часто и кто за это будет отвечать. В качестве иллюстрации скажу, что я рассчитываю в своем приложении по максимуму использовать контент брендовых сайтов, обеспечивая постоянный поток и формируя ту самую пресловутую целостность коммуникации.
Я не стану подробнее останавливаться на этапе дизайна. Если вам хочется узнать больше, посмотрите кусок, написанный по материалам Марии Михальчук, в прошлой заметке. Скажу лишь, что важно помнить, что контент всегда кому-то принадлежит, и некоторые платформы (да, мистер Кук?) следят за этим особенно пристально.
Это портал про анимэ?
Для многих людей веб-мастер, front-end, back-end, full-stack-разработчики и просто «компьютерщики» практически не различимы. Думаю, Хабр – последнее место, где нужно рассказывать, кто из них чем занимается. Позволю себе только один совет, ссылаясь на мнение Сергея Кузьменко: если вы продуктовый менеджер и ваши возможности сильно ограничены, нанимайте front-end'а. Обратите особое внимание на его знание разных браузеров, мобильных ОС и на опыт реализованных проектов. Обязательным навыком также является владение Photoshop и вообще любовь к упражнениям с дизайном.
И еще раз про ТЗ. Убедитесь, что вы передаете разработчику полное описание задач, проработанный дизайн и близкий к готовому контент – тогда на выходе велика вероятность получить пригодную для тестирования версию приложения.
Тестер – это отвертка с индикатором
Возвращаясь к идее о том, что продукт нужно запускать, пока за него еще немного стыдно, отмечу, что ключевое слово здесь – «немного». Поиск баланса остается самой важной для продуктового менеджера задачей. Одного лишь запуска недостаточно, качество самого продукта должно постоянно расти.
Вот несколько вариантов тестирования, которые актуальны именно для мобильных приложений (в скобках снова иллюстрации на моем примере):
- Функциональное тестирование (проверка работоспособности ключевых сценариев; в моем случае – это показ брендированного контента, персонализация, начисление вознаграждения),
- Исследовательское тестирование (менее формальное, в меньшей степени привязанное к тест-кейсам; его полезно использовать на ранних этапах, когда еще не вся документация готова, но уже можно проверять работу продукта). Вот тут есть попытка порассуждать на тему.
- Тестирование по кейс-плану (более формальное, классическое, с детально прописанной последовательностью действий и ожидаемых результатов; полезно, когда нужно проверить детальный пользовательский путь, внесённые доработки или если нужно регулярно отслеживать стандартизированные сценарии),
- Тестирование совместимости (в моем случае, прежде всего с обновлениями мобильных платформ),
- Нагрузочное тестирование (важно для моего приложения, поскольку активации привлекают очень большие волнообразные нагрузки),
- Юзабилити-тестирование (тут еще полезно бывает по возможности проверить несколько версий интерфейса).
Релевантный и актуальный тест-план – это очень и очень хороший показатель зрелости проекта.
И немедленно выпил
Все перечисленные выше этапы пройдут гладко, если у вас хорошая команда. Кажется, в плане лекций есть отдельная тема по набору сотрудников, поэтому для экономии времени скажу только, что сейчас очень много внимания уделяется социальным связям и общим интересам членов команды. Вам предстоит многое пережить вместе, поэтому важно, чтобы этот путь был комфортным. Банально, но общие ценности, открытость и настрой на позитив обеспечивают значительную долю успеха в релизе приложения.
В завершение приведу короткий релизный чек-лист:
- Зарегистрируйте домен (на себя),
- Убедитесь, что хостинг оплачен в достаточном объеме, нужной конфигурации и на достаточный срок,
- Получите SSL-сертификат,
- Заранее заведите аккаунты разработчика в мобильных сторах,
- Заведите аккаунт на Github.
Ну и устройте вечеринку, если все пройдёт хорошо :) В следующий раз я чуть подробнее расскажу о внутренних процессах продуктовой команды, о работе с мобильными сторами и постараюсь показать свои наработки по экранам и описанию приложения.
Спасибо Appodeal за площадку и Марку Тену за эксперимент.