Як стати продакт-менеджером. Частина 2

В середині листопада наші друзі з Sports.ru запустили курс для тих, хто хоче стати продакт-менеджером мобільних додатків. Серед лекторів – співробітники Sports.ru, AppFollow, Aviasales, Uber і інші класні хлопці. Весь грудень студент курсу kirillkobelev розповідає, як проходить навчання. Сьогодні – інсайди з лекції про етапи розробки програми.

–… от тільки, братці, дістатися б дотемна. С. Галанін.

минулій статті я розповів, навіщо потрібні продуктові менеджери, звідки вони беруться і з чого починають роботу над дизайном програми. Моя неточність вивищили Антона Байцура до директора з продажу 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 за майданчик і Марку Тену за експеримент.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.