Блог Илхома Назарова

Заметки для начинающих продукт и проджект менеджеров о разработке и управлении IT-проектами

Оглавление

Про скорость работы мобильного приложения

Дисклеймер

Если речь идет о быстродействии, значит, мы говорим нативной разработке и исключаем посредников в лице многочисленных кросс-платформенных решений и готовых «движков».

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

Так вот

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

В реальном мире мы не знаем:
— мощности железа в смартфоне пользователя;
— количества запущенных на нем приложений;
— качества интернет-соединения.

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

Плюс, на скорость работы влияет объем информации от сервера — чем больше данных тем дольше их парсить перед передачей на отрисовку экрана.

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

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

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

Также стараемся использовать 1 источник данных (один эндпоинт), чтобы исключать проблемы с API или упростостить их диагностику. Если, грубо говоря, вы открываете в приложении экран со списком товаров и приложение идет за товарами в эндпоинт X, который вернул данные за 150 мс, а за рейтингом этих же товаров приложение пошло в эндпоинт Y, который вернул данные за 100500 мс, то все это время приложение будет ждать данных о рейтинге, так как мы не можем показать список, пока у нас не будет всех обязательных данных.

И вот если с этим у вас все Ok, тогда можно перечитать дисклеймер и поискать проблему там.

Разница между Scrum и Kanban доской

Недавно коллега сказал, что хороший проджект-менеджер должен различать Srum и Kanban доски.

Я не ортодоксальный приверженец Lean или Agile методологий и не придаю значения формальностям. Но этот вопрос из разряда навязчивых, которые и не дают спокойно жить, если случайно попали в голову.

Вот быстрый ответ: видимых различий между Scrum и Kanban boards — нет.

Зато, есть принципиальное отличие в подходах => в целях применения досок:

— Scrum оперирует спринтом, объем которого заранее известен и не меняется в процессе, основная цель доски — следить за сроками и производительностью, чтобы каждый спринт закончился вовремя и принес обновление с пуллом решенных задач;
KPI — производительность (velocity), объем задач, который команда способна реализовать в рамках спринта.

— Kanban рассчитан на поток производства, главная цель — пропустить как можно больше задач по стадиям от «to do» к «done» и предупредить появление узких, либо перегруженных мест в цепи производства, для этого в каждой колонке доски задается лимит WIP (work in progress, одновременно выполняемых задач), чтобы их не скпоилось слишком много на одной стадии; при необходимости в Kanban можно добавлять или останавливать задачи, корректировать приоритеты.
KPI — уменьшить среднее время цикла производства, сколько времени в среднем уходит на продвижение задачи по доске.

При этом не важно, как вы назовете столбцы на доске, будь то статусы готовности «to do», «in progress», «done» или конкретное флоу задачи («prototyping», «design», «development», «testing»). В обоих методологиях визуально доски выглядят одинаково.

Разница между скрам (scrum) и канбан (kanban) досками

Если интересно, как отличается матчасть методологий, можно за 10 минут прочитать у Atlassian.

Scrumban

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

Суть метода в том, что внутри классического Scrum-спринта с запланированным пуллом задач, используются Kanban-доска для визуализации прогресса и ограничения одновременно выполняемых задач.

В чем разница межу скрам-подходом и водопадом.

Впрочем, никто не мешает использовать Kanban-доску и для классческого водопада.

Итого

Есть ли разница между Srum и Kanban досками — нет, обе доски визуально идентичны. Различие по сути в том, что Scrum, как фреймворк, задает стратегию планирования и итерационного производства, а Kanban — тактический инструмент визуализации, поиска узких мест и балансировки этапов в производстве.

Приоритезируем функционал продукта для запуска MVP

Мини-конспект о том, как определить состав MVP и сделать первую версию продукта востребаванной.

Принцип MVP

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

Шкала Value vs Effort


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

Ровно также можно приоритезировать беклог для запуска MVP по принципу важно/сложно.

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

Собираем беклог

Оцениваем фичер-лист для MVP

Располагаем функционал на осях

Определяем приоритеты с ложность функционала для MVP

Так распределяются зоны продукта

Какой функционал является ядром продукта

Важные, но сложные задачи декомпозируем и перераспределяем

Декомпозируем сложные задачи
Перераспределяем сложный функционал

Aha-момент и функционал в красной зоне способны донести ценность продукта и подходят для MVP

Определяем что войдет в MVP

Фреймворк RICE


В продуктовых компаниях используют алгоритмы приоритезации (RICE, ICE, WSJF, GIFT итд).

Чаще других встречается RICE, который популяризирует тот же Intercom.

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

  1. Reach (Охват): на какое количество клиентов повлияет изменение, лучше ввести коффициент
    (например, 1000 человек в квартал — 5 ... 100 человек в квартал — 0,5);
  2. Impact (Эффект): тоже коэффициент (например, 5 — максимальное влияние ... 0,5 — минимальное), этот коэффициент замеряет любой эффект: насколько увеличится конверсия или вырастут доходы или улучшится жизнь пользователя по вашему мнению;
  3. Confidence (Уверенность): это % уверенности в том, что гипотеза окажется верна
    (например, 100% — высокая вероятность, ее подтверждают опросы или исследования или аналитика ... 50% — низкая вероятность, это ваша гипотеза, не подтвержденная данными);
  4. Effort (Усилия): сколько времени в человеко-часах или человеко-днях или просто в днях уйдет на реализацию.

Как считать:

ОХВАТ x ЭФФЕКТ x УВЕРЕННОСТЬ / УСИЛИЯ = ПРИОРИТЕТНОСТЬ функции или гипотезы для продукта

Собираем беклог в таблицу, чем выше получился RICE Score, тем приоритетнее задача:

Пример из блога Intercom

Набор стикеров для тех, кто ставит задачи

2 года назад я писал про парадигмы Фридмана и про то, как они влияют на постановку и выполнение задач в компании.

Тогда мы нарисовали плакаты для офиса, а теперь сделали стикеры «Управление проектами» для Телеграм.

Стикеры управление проектами для телеграм

Добавить стикеры в Telegram.

PS
Если ссылка не открылась, вот альтернативная.

Коверсионная воронка «AАRRR» — выбираем метрики для продукта

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

Правильно подобранные метрики показывают:

  • в каком месте конверсионной воронки клиенты отваливаются;
  • сколько стоит привлечение нового потребителя;
  • сколько прибыли он приносит и, сооственно, сколько денег мы можем тратить на продвижение.

Чтобы построить конверсионную воронку, рассмотрим популярную схему «AARRR» Дэйва МакКлура (Dave McClure). Сам МакКлур называет свой фреймворк «пиратскими метриками» из-за аббревиатуры «AARRR», похожей на рычание.

Воронка состоит из 5 этапов: Привлечение (Aquisition) → Активация (Activation) → Удержание (Retention) → Рекомендации (Referral) → Доход (Revenue).

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

Коверсионная воронка "AАRRR" выбираем метрики для продукта

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

Привлечение (Aquisition)

Сколько людей и откуда пришли на сайт или установили ваше мобильное приложение.

Для приложений этап привлечения отвечает не только за то, как люди попадают на страницу App Store или Google play, но и за то, что мотивируют их загружать приложение (рейтинг, оформление страницы в магазине, отзывы итд).

Чем мерить

  • Site visits — количество посещений сайта за период.
  • Apps Store и Google Play product page views — количество просмотров страницы в сторе за период.
  • Downloads — количество скачиваний приложений.
  • Installs — в отличае от downloads считается количество скачиваний + запусков.
  • CPV (Cost per Visitor) — цена за посетителя для веба = затраты на рекламу / количество посещений (site visits)
  • CPI (Cost per Install) — цена за установку для приложения = затраты на рекламу / количество установок (installs).

Также работаем с метриками внутри каналов привлечения: CPC (cost per click), CTR (click through rate), Click-To-Install Rate итд.

Как влиять

Сегментируем аудиторию. Задача — выбрать целевую. Если не знаете как — читайте о Lean Canvas.

Выбираем каналы привлечения. Ищем каналы, которые охватывают нужные сегменты аудитории и попадают в ваш бюджет: контекстная и медийная реклама, контент-маркетинг, SEO, SMM, email-рассылка, конференции и вебинары итд.

Кстати, если для трассироваки переходов в вебе используют utm-метки, то в приложениях можно и спользовать deep links, например через branch.io.

App Store Optimization (ASO) и работа с отзывами. Для мобилок не забываем об оптимизации в сторах App Store Optimization — следим за релевантностью поиска по ключевым словам, используем ключи конкурентов, контролируем отзывы и рейтинг приложения, эксперементируем с оформлением страницы в магазине.

Задача — повысить значение product page views и улучшать отношение этой метрики к downloads.

Активация (Activation)

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

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

Задача продукта на этапе активации — показать пользователю ценность, за которую он готов будет платить.

Чем мерить

Выбираем колличественные метрики, которые означают конверсию в вашем продукте: registration, orders, bookings, n-days active users, total users, trial-subscriptions итд.

  • CR (Conversion Rate) — % коверсии в покупку = количество целевых действий / количество посетителей *100%.
  • CAC (Customer Acquisition Cost) — стоимость привлечения нового платящего клиента = стоимость маркетинга + затраты на рекламу за период времени / количество новых клиентов за тот же период времени.
  • CPA (Cost per Acquisition) — цена за конверсию = расходы на привлечение (CPV или CPI) / кол-во целевых действий
  • CPA (Cost per Action) — стоимость целевого действия = затраты на рекламу / количество действий (любых, которые хотите измерить, например CPO (Cost Per Order)

Как влиять

Тестируем гипотезы на пользователях. Разумеется, custdev (сustomer development), разбираемся с пользовательскими сценариями, проводим опросы целевой аудитории, делаем A/B тесты.

Аналитика и устранение протечек. Устанавливаем аналитику (Яндекс Метрика, Google Firebase, Amplitude итд), изучаем поведение людей на сайте и в приложении, чтобы:

  1. найти узкое место, где пользователи отваливаются: изменить онбординг, упростить регистрацию итд;
  2. найти способ сократить шаги до целевого действия в воронке.

Удержание (Retention)

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

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

Максимальное внимание к этой метрике также уделяют в продуктах:

  • с активацией через демо, триал-период, freemium, так как от вовращаемости людей зависит конверсия пользователей в платящих клиентов;
  • с моделью окупаемости, предполагающей большой LTV (суммарным объемом денег, который приносит клиент за весь жизненный цикл в продукте).

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

Чем мерить

  • N-day retention rate — % клиентов, которые продолжают пользоваться продуктом спустя день, неделю, месяц итд.
  • MAU и DAU (Monthly и Daily Active Users) — сколько людей заходят на сайт или запускают приложение в период времени.

— Sessions frequency per user — сколько раз пользователь запускает приложение или заходит на сайт в течение периода времени.

  • Paying Users — количество платящих клиентов (не путать с количество покупок) за период времени.

— Сhurn Rate — отток за период времени, % клиентов, которые сделали заказ, но больше не вернулись = количество клиентов на начало периода — количество клиентов на конец периода / количество клиентов на начало периода * 100%

Кстати, для приложений это не означет удаление приложения.

  • Uninstall rate — показатель удалений за период = количество удалени / количество установок в период времени.
  • RPR (repeat purchase rate) — % повторных покупок = количество повторных клиентов / общее количество клиентов в период времени *100%

Как влиять

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

Скажем, CPI для вашего приложения 500 руб. Вы привлекли 1000 пользователей за месяц и потратили 50 000 руб, а показатель ретеншена говорит о том, что 80% пользователей не вернутся спустя неделю, а 95% — спустя месяц.

Таким образом вы потратили за месяц 50 000 руб, из которых 40 000 ушли на пользователей, которые отвалятся через неделю, а 47 500 руб на тех, кто уйдет от вас через месяц.

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

Подписываем на уведомления. Следим за эффективностью push- и e-mail-нотификации. Персонализуируем рассылки, проводим A/B тесты, чтобы рассылки и уведомления несли ценность получателю.

Система лояльности и ачивки. Классику маркетинга никто не отменял.

Ретаргетинг. Догонять тех, кто давно не заходил в приложение или не возращался на сайт можно не только уведомлениями, но и рекламой.

Рекомендации (Referral)

Речь о готовности клиентов рекомендовать продукт другим людям. Сколько действующие клиенты привлекают новых.

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

Часто этап рекомендации ставят в воронке AARRR и считаю после Revenue, а не перед ним.

Чем мерить

  • K-фактор или коэффициент виральности = органические установки или переходы на сайт в период времени / (активные пользователи в тот же период времени — 1).
    Если k-фактор > Сhurn Rate, то пользователей по рекомедации приходит больше, чем вы теряете.
  • NPS (net promoter score) — % клиентов, готовых рекомендовать продукт друзьям, в NPS методике их называют промоутеры = % промоутеров — % критиков.
  • Tone of mentions — количество негативных и позитивных отзывов или упоминаний о вас в интернете.
  • Apps Store и Google Play ratings and reviews — количество негативных и позитивных отзывов в сторах.

Как влиять

Виральность. Ищем способы встроить виральность в продукт, чтобы пользователи шарили контент и ссылки.

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

Улучшаем отзывы Apps Store и Google Play. Рейтинг приложения в сторах напрямую влияет на коверсию в установку приложения.

Доход (Revenue)

Последний уровень воронки AARRR измеряет доходы продукта.

Метрики дохода фиксируют успешные сделки (купленные товары и услуги, оплаченные подписки итд) и показывают, насколько успешно вы проработали предыдущие уровни.

Главные вопросы этапа:

  • Как и сколько продукт зарабатывает?
  • Сколько денег в среднем приносит клиент?
  • Сходится ли бизнес-модель продукта?

Чем мерить

  • Revenue — выручка от продаж товаров или услуг за период времени.
  • ROI (Return on Investment) — рентабельность, % возврата инвестиций в период = суммарный доход в период — суммарные затраты в период / сумманрные затраты в период * 100 %.
  • LTV (Customer Lifetime Value) — суммарная прибыль от одного клиента за весь жизненный цикл. Есть несколько способов подсчета, вот один варинт: средний чек (AOV) * среднее число заказов на одного клиента за период времени * среднее время удержания клиента за тот же период времени.
    Главное в LTV — он должен быть выше чем CAC, то есть клиент должен приносить больше, чем вы атратите на его привлечения, чтобы продукт приносил доход.
  • AOV (Average Order Value) — средний чек = суммарный доход (общая стоимость закзов) за период / количество заказов за тот же период времени.
  • ARPU (Average Revenue per User) — средняя выручка на пользователя за период времени = суммарный доход за период / количество пользователей за тот же период времени

Как влиять

Делаем «ABCD» сегментирование своих клиентов. Выясняем критерии и потребности A и B сегментов, развиваем продукт для них.

Допродаем, договариваемся о кросс-продажах. Ищем полезные для клиента сопутствующие услуги, товары, расширение возможностей у себя или партнеров. Увеличиваем средний чек.

Упрощаем воронку. Анализируем воронку от входа до сделки и пробуем убрать лишнее.

Системы контроля версий: Git, SVN, Mercurial для менеджеров

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

Для этого в производственный процесс принято внедрять ежедневные митинги, таск трекеры и системы контроля версий (СКВ или VCS — Version Control System), которые мы рассматриваем как инструменты для управления проектами.

Выбор СКВ лежит на плечах технического директора, тимлидов или воли случая (“так исторически сложилось”). Вопросы о преимуществах или недостатках конкретных систем вызывают священные войны в среде разработчиков, однако, наc они итересуют только в контексте организации работы над проектом.

Популярные решения

По опыту 9 из 10 команд разработки используют Git, хотя рейтинг Tagline говорит о меньшей его популярности.

Рейтинг систем контроля версий Git, SVN, Mercurial

После Git с большим отрывом идет SVN (Subversion) и Mercurial.

Синтаксис Git сложнее в изучении, однако, по отзывам программистов он функциональнее. Очков гиту добавили и популярные ресурсы для хранения репозиториев на всевозможных языках: GitHub и BitBucket.

Долю на рынке, сопоставимую с массой электрона, занимают осталные системы : CVS (Concurrent Versions System), Team Foundation Server, Bazaar, Darcs итд.

Все системы контроля версий по сути решают 4 задачи

Доступ к коду. Исходники кода хранятся в удаленном репозитории (хранилище данных), куда обращаются разработчики, чтобы забрать актуальную версию файлов или внести изменения. Так выстраивается командная разработка.

Логирование изменений в коде. Отслеживание коммитов (внесений изменений в код), помогает найти кто, что и когда менял, решить конфликты при модифицировании одних и тех же файлов, откатиться на любое предыдущее состояние.

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

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

Организация процесса разработки

Вам, как менеджеру проекта, стоит обратить внимание:

  1. Принят ли у разработчиков единый шаблон оформления комментариев к коммитам (commit message), из которых понятно, что делает коммит и зачем.
  1. Настроена ли привязка коммитов к конкретным задачам из таск трекера (traceability) для трассировки бизнес требований.
    В Mercurial это работает из коробки, а вот, например, в Git это обычно решают с помощью хука, который не дает ничего закоммитить без метки таска, а-ля “PROJECT-JIRA_ISSUE_NUMBER”
  1. Делают ли разработчики ежедневный пуш (выгрузку коммитов) в центральный репозиторий или работают локально не отдавая написанный за день код вовне.

Последний вопрос не актуален, если разработчики используют на проекте SVN, так как это централизованная СКВ и весь код хранится на сервере.

Распределенные и централизованные подходы к хранению кода

Git и Mercurial — распределенные системы, SVN — централизованная.

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

При этом Git, в отличие от Mercurial, работает не только с локальными коммитами, но и с локальными ветками, которые можно вовсе не заливать в удаленный репозиторий.

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

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

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

Как менеджеру освоить базовые функции Git

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

Матчасть:

Короткий видеокурс Geekbrains для старта за 2 часа.
Официальная документация для дотошных.

Программное окружение:

На Mac Git по умолчанию вшит в штатную консоль. На Windows первым делом скачайте и установите сам Git.

С гитом работают через консоль или графический интерфейс (GUI).

Графический интерфейс SourceTree для работы менеджера с Git

Для задач IT-менеджера рациональнее использовать графический клиент. Лично я использую SourceTree, хотя не всем нравится продукция Atlassian.

Выберите клиент по вкусу вот тут.

Вперед к первому $ git clone!

Lean Canvas для тех, кто запускает новые продукты

Lean Canvas — схема, которая отображает модель бизнеса или стартапа на 1 листе бумаги.

Эш Маурья (Ash Maurya) описал эту схему в книге «Running Lean».

Lean Canvas незаменим, когда есть идея продукта, но нет понимания его модели и плана выхода на рынок.

Однако, это не просто способ структурировать идеи и концепции для себя или презентации другим (коллегам, инвесторам, подрядчикам итд).

Цель Lean Canvas — определить гипотезы и требования для разработки и запуска MVP (minimum viable product).

Как заполнить Lean Canvas

Скачайте шаблон для печати на leanstack.com, хотя таблицу Lean Canvas можно также заполнять в простом Google Sheets.

Бланк Lean Canvas и инструкция по заполнению

1. Проблема (и существующие альтернативы решения)

Описываем 1-3 главные проблемы, которые мы решаем с помощью продукта. Расставляем их в порядке важности.

Именно с проблемы и начинается продукт.

Конкуренты и альтернативы:

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

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

2. Сегменты потребителей (и ранние клиенты)

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

Выбираем 1 сегмент потребителей, который станет «ранними клиентами». Это люди, которые по нашим расчетам будут релевантны для продукта, дадут обратную связь и принесут первые деньги. Для них и будем разрабатывать MVP.

Если стараться выпустить продукт «нужный для всех», вероятно, получится сделать продукт не нужный никому.

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

Обратите внимание, что потребители (customers), которые платят за продукт, могут не совпадать с пользователями (users), которые им пользуются. Например, для Яндекс или Google: потребитель — рекламодатель, пользователь — тот, кто ищет. В этом случае и проблемы и сегменты разделяем на 2 категории: customers и users. 

3. Уникальное торговое предложение (UVP)

Опишите в одном предложении ключевое отличие вашего продукта:

  1. Что такое ваш продукт?
  2. Кто ваши клиенты?
  3. Зачем им нужен ваш продукт? (Почему клиент захочет инвестировать свои деньги или время в вас?)

Разумеется, UVP (Unique Value Proposition) отвечает на главную проблему клиента, которую мы поставили первой в блоке «Problem» нашего Lean Canvas.

Если с ходу не удалось сформулировать свое уникальное предложение, переходим к заполнению следующего блока с решениями («Solution»), а затем возвращаемся снова к формулированию UVP. Если и теперь ничего не выходит, видимо, вы пытаетесь объять необъятное или задуманный продукт ничем не отличается от существующих альтернатив.

Как сконцентрироваться на результате и ответить на вопрос «зачем клиенту ваш продукт?» — пример для сервиса по составлению резюме:

«Профессиональные дизайнерские шаблоны для резюме» — лишь фича продукта. «Привлекательное резюме, выделяющееся на фоне других» — лишь промежуточный результат. «Работа мечты» — это конечный результат, который включаем в UVP.»
Ash Maurya «Running Lean»

Вот еще одна формула UVP:

«Конечный результат + Время его получения + Контраргумент возражению. Пример: «Горячая свежая пицца у вас за 30 минут, не успеем — достанется вам бесплатно.»
Дэйн Максвелл (Dane Maxwell)

Высокоуровневый концепт:

Это необязательная, но полезная опция — продающий концентрированный смысл. Это то, что клиент о вас запомнит (Ritter Sport: Quadratisch. Praktisch. Gut.)

4. Решения

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

5. Каналы привлечения пользователей и продаж

Как целевой сегмент потребителей (ранние клиенты) узнают о продукте и откуда они к нам придут?

Перечисляем каналы привлечения:

  • Inbound — потребители находят нас сами: вебинары, SMM, SEО итд
  • Outbound — мы находим потребителей: контекстная реклама, обзвоны, рассылки итд 

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

6. Источник дохода

Выбираем модель монетизации: подписочная, рекламная, транзакционная, freemium, free trial итд. Разбираемся в том, из чего будет складываться цена продукта и прибыль.

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

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

7. Структура расходов

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

8. Ключевые метрики (KPI)

Метрики выбираются исходя из специфики бизнеса и модели монетизации.

Например, отслеживаются: Downloads (скачивания), Installs (установки), Visits (визиты), Registrations (регистрации пользователей), RR (retention rate — процент пользователей, которые повторно вернулись на сайт или запустили приложение в течение n-периода времени), CAC (customer acquisition cost — цена привлечения одного пользователя), LTV (life time value —  средний доход с одного платного пользователя за его жизненный цикл), Bookings (заказы), Revenue (прибыль) итд

Главная задача — включить в KPI такие метрики, которые помогут:

  1. найти точку окупаемости проекта;
  2. проследить как изменения, которые мы вносим в продукт, влияют на результат (например, вы внедрили рекомендательную систему, и у нас есть метрика, фиксирующая результат — увеличение среднего чека).

В KPI продукта, как правило, включают метрики для отслеживания конверсионной воронки, от привлечения пользователя до конверсии и прибыли. Для этого идеально подходит воронка «AARRR» Дэйва МакКлура (Dave McClure).

Конверсионная воронка «AARRR» Дэйва МакКлура (Dave McClure)

Изображение с сайта startitup.co.

Подробнее о метриках фреймворка «AARRR» я напишу отдельно.

Итак, на основе блоков Lean Canvas № 6,7 и 8 мы сопоставляем доходы и расходы и планируем нужные показатели KPI, например, сколько платных пользователей нужно при текущей цене продукта, чтобы считать проект прибыльным.

9. Нечестное преимущество (скрытое)

То, что нельзя легко повторить: уникальная технология (желательно с патентом), ценная информация, редкие специалисты, экспертиза в узкой области, личности основателей или участников проекта, доступ к базе пользователей итд

Пример заполнения:

Lean Canvas и тестирование гипотез

Перед запуском стартапа или нового продукта компании, проведите customer development — тестирование идеи на потенциальных клиентах.

Главное, что мы подтвердим или опровергнем:

  1. у выбранного сегмента потребителей действительно есть проблема и наш продукт ее решает;
  2. наше решение — это продукт, за который клиент готов платить.

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

Риски разделяются на 3 категории:

Потребительские риски (Customer risk)

Ошибка в определении сегментов потребителей и ранних клиентов. Либо ошибка при выборе каналов связи с потребителями.

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

Продуктовые риски (Product risk)

Правильный ли продукт мы делаем? Выбрали реальные проблемы и нашли крутые решения.

Наиболее высокая цена ошибки при создании бизнес-модели — в постановке проблем. Например, если мы преувеличили их важность для потребителя, то все остальные части Lean Canvas окажутся уже не важны.

Чтобы проверить продукт — потребуется разработать MVP версию и провести интервью.

Рыночные риски (Market risk)

Будет ли работать наш бизнес? Возможно на рынке нет места или не получится отбить клиентов у конкурентов или допущена ошибка при планировании доходов и расходов.

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

PS

Lean Canvas по сути — упрощенная версия Business Model Canvas (автор Александр Остервальдер (Alexander Osterwalder).

Модели достаточно похожи, но Business Model Canvas включает описание ключевых партнеров, каналов сбыта, используемых ресурсов — того, чего пока нет у стартапа или нового продукта.

Разница между ними в том, что Business Model Canvas описывает уже устоявшиеся бизнес-модели для их анализа и поиска точек роста, а Lean Canvas подходит для запуска новых продуктов и стартапов.

Разница в планировании проекта по Scrum и Waterfall

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

Хочу коротко остановиться на принципиальной разнице в этих подходах.

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

Waterfall (инкрементная модель) — MVP + итерации

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

Scrum — MVP + итерации

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

Классификация менеджеров в digital агентствах и веб студиях

Виды менеджеров в digital агентствах и веб студиях

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

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

Договоримся на берегу, что я не буду касаться операционного менеджмента, который работает над процессами внутри студии (руководители отделов, директора и т. д.), а расскажу о тех менеджерах, которые работают с продуктами, проектами и клиентами.

Виды и роли менеджеров

Сейлз менеджеры (sales managers) ищут клиентов, обрабатывают и классифицируют входящие заявки. Главная задача — найти и привести клиента.

Нью биз менеджер (new business managers) изучают потребности, проблемы или точки роста в бизнесе потенциального клиента, предлагают решение, заключают сделки и стартуют проекты.

Аккаунт менеджеры (account managers) — менеджеры по работе с клиентами. Поддерживают контакт и выстраивают доверительные отношения. Продают и допродают, согласуют договора, следят за счетами, но главное — следят за тем, чтобы клиент оставался счастлив. Аккаунт менеджеры подключаются к проекту на этапе продажи и контролируют, чтобы проект рос и развивался максимально долго, но самостоятельно проекты не ведут.

Проджект менеджеры (project managers) отвечают за непосредственную работу над проектом: постановку задач, организацию процессов, управление командой, сроками и рисками. Проджект решает организационные и переговорные вопросы, чтобы команда (дизайнеры, разработчики, тестировщики) сосредоточились на любимом деле — разработке продукта.

Продюсеры (digital producers) — у продюсеров полномочия шире, чем у проджектов. Они отвечают за экосистему проекта целиком: сами компонуют проектные команды (привлекают внешние ресурсы, когда это нужно) и управляют всеми направлениями работ по проекту (креатив, маркетинг и реклама, производство и т. д.). Другими словами, продюсер обеспечивает условия для производства и запуска проекта.

Как я уже говорил, конкретный менеджерский состав и разделение ролей зависят от конкретного агентства.

Например, у нас в H&H работают два вида менеджеров: аккаунт менеджеры, которые продают, и проджекты, которые ведут проекты.

А как же продакт менеджер?

Продакт менеджер (product manager) управляет свойствами продукта и отвечает за беклог проекта. Главная задача продакт менеджера — удовлетворить рынок (или потребителя) с помощью продукта.

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

Продакт менеджер говорит о том, как сделать правильный продукт.

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

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

Разделяй и властвуй

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

Аккаунт vs проджект

Разница между аккаунт менеджером и проджект менеджером

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

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

Говоря метафорично, разница между ними в том, что проджект менеджер — зонтик проектной команды (маркетологов, дизайнеров, разработчиков, тестировщиков и т. д.). А аккаунт (как остроумно выразилась Лада Родзина) — зонтик зонтика! Он разрешает конфликтные ситуаций между тремя богатырями: клиентом, аккаунтом и менеджером проектов.

Центрирующие парадигмы Александра Фридмана

В своем курсе «Управление мышлением подчиненных» Фридман приводит 7 простых правил, известных как «центрирующие парадигмы Фридмана». Если вы с ними не знакомы, вот конспект с небольшими комментариями:

  1. Проанализируй задание перед началом работы
    У исполнителя должны быть все ресурсы для выполнения задачи
  2. Задание должно быть выполнено на 100%
    100% и по качеству и по содержанию
  3. Уперся — сообщи немедленно
    О препятствиях к 100% выполнению задания немедленно сообщи руководителю и всем заинтересованным
  4. Приходи с решением проблемы
    Предложение по решению проблемы предпочтительнее информации об ее возникновении
  5. Факты и аргументация предпочтительнее мнения
    Всегда подкрепляем речь доводами
  6. Расширенное толкование задания не допускается
    Все что не разрешено — запрещено
  7. Несогласие с параметрами задания — не повод их игнорировать
    Не согласен — сообщи и аргументируй. Не приняли аргументы — делай, как сказали

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

А еще каждый знает, что ежедневная зарядка является залогом бодрости и крепкого здоровья. Однако знать о пользе зарядки и систематически ее выполнять — это, как говорят в Одессе, «две большие разницы».

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

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

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

Например:

Плакаты у нас в студии «Heads and Hands»

Ранее Ctrl + ↓