Какой продукт создать программу

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

Готовность Начать
Готовность Завершить
Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

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

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

КОМАНДА ОТКРЫТИЯ ПРОДУКТА
Product Discovery Team

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

ценности продукта для бизнеса
удобства продукта для пользователей
реализуемости продукта в рамках времени и технологий

Именно эти три параметра: ценность, удобство и реализуемость, команда открытия должна держать в постоянном фокусе. Первые примеры таких команд мне приходилось видеть на конкурсах вроде DOU Mixer и Garage48.

Минимальный “комплект” это хакер (технологии), хастлер (маркетинг) и дизайнер (юзабилити). Когда я говорила “никогда не экономьте на команде”, я имела в виду вот что: эти три роли — это “гены” вашего продукта. Вы никогда не знаете вначале, какой продукт вы “вырастите”, но профессионализм команды открытия, важен практически так же, как здоровые гены в физическом теле.

КОМАНДА ОТКРЫТИЯ: UX Дизайнеры
Из этих трех составляющих команды открытия, сложнее всего найти хорошего “дизайнера”. Дизайном эта функция называется условно — слишком большой метаморфозе подверглась профессия дизайнера за последние 10 лет. Здесь имеется в виду роль проектировщика архитектуры взаимодействия пользователя с продуктом. Так что хакеры в своем понимании дизайна как архитектуры, ближе к истине, чем люди бизнеса, которые представляют симпатичные картинки. Дизайн — это UX (архитектура взаимодействия), которая впоследствии дополняется Usability (удобством) и UI (красотой).

Многие владельцы продуктов, сталкиваясь со сложностью поиска хорошего дизайнера, решают аутсорсить эту функцию профессиональному агентству. Что ж, это может быть выходом, если вы создаете продукт “на заказ”. Но если речь идет о вашем, родном продукте, то аутсорсить проектирование UX и работу с пользователями, это все равно что аутсорсить отцовство.

КОМАНДА ОТКРЫТИЯ: Хакеры
Короткое отступление для читателей из мира аутсорсинга. Я противник разработки командой по готовой спецификации. “Требования” означает “Заткнись” (цитирую Алистера Коуберна). Если команда пишет продукт по «спущенным» требованиям, значит вы не используете ее исследовательский потенциал, это — ложная экономия.

Если хотите сэкономить на разработке — найдите людей, которые достаточно сыты самореализацией в корпоративном мире, гордостью за свои рейты на oDesk’е и экономическим благополучием. Несколько моих знакомых, ярких хакеров существенно опустились в гонорарах, потому что наступил период поверить в чей-то продукт и начать считать его своим. Это особенное чувство, вы знаете. Вам нужны такие люди, которые готовы пойти ва-банк, веря как в вашу идею так и в свое генетическое превосходство.

Если вы уже имеете дело с аутсорсингом, постарайтесь максимально включить команду в процесс открытия продукта. Под командой я имею в виду небольшие полнофункциональные составы “грабителей банков” (цитирую Максима Ткачука), в которых каждый хорош в своей специализации, при этом понимая суть и доверяя исполнению других ролей в своей “банде”.

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

Оптимальный состав такой “боевой команды” — 3-5 человек. Вовлечение большего числа участников влечет за собой накладные расходы на общение. Но вы можете овладеть искусством фасилитации и научиться работать в малых группах над параллельными задачами, затем объединяя их результаты.

КОМАНДА ОТКРЫТИЯ: Хастлеры
Эта роль (hustler) умышлено оставлена без перевода. На самом деле, самые приличные варианты перевода это “энергичный человек” и “пробивной делец”, но все из них явно указывают на качества, которыми должен обладать ее носитель. Что бывает, если в команде есть просто “человек с идеей”, без пробивных бизнес-качеств? Получается бизнес трусогномов .

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

золотоискателей

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

Итак, предположим, вы собрали команду открытия продукта. Что дальше?

Я опишу один из вариантов “дорожной карты”. Карта — это не местность. Как случалось с Колумбом и другими искателями приключений, привести она вас может совсем не туда, куда предполагалось. Но иметь карту крайне важно, если вы хотите не топтаться на месте и использовать обнаруженные искажения в своем начальном представлении о пути и цели.

ШАГ 1. Определяем цели и принципы создания продукта.

Это могут быть:

Личные цели основателей
Цели бизнеса или организации
Принципы функционирования продукта

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

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

ШАГ 2. Оцениваем возможности продукта

Это можно сделать используя такие инструменты, как Business Model Cancas или Lean Canvas. Или же ответив на вопросы оценки возможностей продукта по Кагану:

Какую конкретно проблему решает продукт? (предложение ценности)
Для кого мы решаем эту проблему? (целевой рынок)
Как мы будем измерять успех? (метрики бизнеса)
Насколько велики возможности? (объем рынка)
Какие есть альтернативы? (текущие конкуренты)
Почему наш продукт лучше подходит для решения проблемы? (наши отличия)
Почему сейчас подходящее время? (окно рынка)
Как мы будем запускать продукт? (стратегия выхода)
Какие факторы критичны для успеха? (требования и риски)
Беремся / не беремся?

Пожалуй, целью всей этой активности является ответ на последний вопрос. Насколько команда готова “пойти” в реализацию продукта? Насколько основатели верят в то, что создание этого продукта является лучшей из возможных точек для приложения усилий?

ШАГ 3. Идентифицируем ключевых клиентов и пользователей

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

Будте внимательны к тому, являются ли ваши будущие пользователи вашими “избирателями”? Будут ли они использовать ваш продукт по собственной воле или в его внедрении будет заинтересованы над-структуры? Например, если вы разрабатываете банковский сервис, то удобство пользователя будет не самым главным критерием выбора и всегда будет уступать место надежности и безопасности решения.

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

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

ШАГ 4. Проводим исследования пользователей

Это этап предварительного интервью с целевой аудиторией продукта. Цели этой активности:

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

Как готовиться интервью, выбирать аудиторию, задавать вопросы и анализировать ответы — я опишу в следующей части. Шаги с 4-го по 6-й могут быть выполнены несколько раз в цикле, еще до написания первой строчки кода.

ШАГ 5. Строим карту опыта пользователя “как есть”

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

ШАГ 6. Строим карту взаимодействия с продуктом

Отличный инструмент для этого — User Story Mapping от Джеффа Паттона. По сути, карта историй пользователя — это высокоуровневая, многомерная модель требований, описывающая сценарии использования продукта.

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

ШАГ 7. Выбираем минимальный ценный продукт (MVP)

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

1. Уже на этом этапе вы можете проверить свою идею о ценности, попросив обратной связи на несуществующий продукт. Это занимает время.

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

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

Тема метрик крайне важна и заслуживает отдельной статьи. Предваряя разговор о разных системах и подходах в их создании (например, AARRR, или NSP), скажу довольно банальную вещь, которая лишь может натолкнуть на размышления.

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

Думаю, этого для Начала, этого достаточно. В следущей части постараюсь пройтись по важным деталям шагов 4-6 и обсудить Готовность начать разработку.

Источник

Привет, Хабр! Сегодня мы начинаем публикацию серии практических материалов для продакт-менеджеров, основателей стартапов и всех остальных, кто хочет приобрести навыки менеджера по разработке программных продуктов. Этот и последующие посты былы подготовлен на основе лекций курса «Создание программного продукта и управление его развитием», который был организован с помощью компании Acronis.

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

Оглавление курса

1. Роль менеджера по продукту и фреймворк < — Вы здесь
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта

Меня зовут Василий Рудоманов, и я отвечаю за развитие продуктов в компании Acronis. Я долгие годы занимался инжиниринговой или технической стороной создания продуктов и решений. Однако полученный технический опыт в итоге привел меня к специализации в области развития программных продуктов. За годы работы в этой сфере я убедился, что умение работать со своим продуктом, понимать, как идея превращается в готовый продукт, выбирать рыночные ниши, позиционировать его и планировать развитие может быть полезным и разработчикам, и инженерам, и основателям стартапов, и сотрудникам отделов продаж и многим другим специалистам в ИТ-компаниях, а не только менеджерам по продукту.

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

Основатель стартапа де-факто является главным продакт менеджером компании и поэтому полностью определяет ее развитие. Впоследствии эту функцию владельцы бизнеса передают продакт-менеджерам. Поэтому последние должны выполнять огромное количество задач, контролировать процесс разработки, анализировать потребности рынка, решать проблемы клиентов и многое-многое другое. Для этого нужно обладать целым спектром важных знаний и навыков, а также уметь работать со специализированными фреймворками. Но сегодня мы начнем именно с идеи… с того «единорога», который возникает в голове каждого человека, когда он решается подарить миру новый продукт.

Как обычно создается продукт? Обычно возникает идея, и группа людей начинает ее воплощать. В головах менеджеров возникают светлые мысли о том, как именно продукт должен развиваться. Свое мнение есть у топ-менеджеров, директоров, советников, президентов компании или владельцев. Они формируют стратегию развития бизнеса, а также самого продукта.

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

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

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

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

Многие разработчики уже знакомы с книгой Фреда Брукса «Мифический человеко-месяц». Очень рекомендую почитать ее, если вы этого еще не сделали. Фред Брукс участвовал в создании IBM 350. В свое время его команда провела большую работу по созданию программного обеспечения для мейнфреймов. В своей книге он очень хорошо описал, в чем заключается отличие программы от продукта или программной системы.

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

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

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

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

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

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

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

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

Работа с фреймворком очень важна для всех категорий сотрудников современной ИТ-компании.

Сегодня мы поговорили об общих подходах к продакт-менеджменту, которые будут полезны как непосредственно продактам, так и СEO стартапов, которые действительно должны выстрелить (по крайней мере, по мнению основателей). В следующем посте мы обсудим как определить, на какой сегмент рынка вы ориентируете свой продукт и как провести конкурентный анализ этой рыночной ниши. Если вам важна и полезна эта тема, не забудьте подписаться на наш блог.

→ Видео-запись всех лекций курса доступна на YouTube

Первая лекция:

Хотите стать продакт-менеджером? Собираетесь запустить свой стартап? Нужна обратная связь со стороны? Пишите в личку, обсудим.

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

Источник