Рус
Eng
Привет, меня зовут Миролюбов Владимир
Я очень интересуюсь продакт-менеджментом и бизнесом.
В своем блоге я делюсь разными идеями и мыслями на этот счет. Больше обо мне тут.
20 April, 2017 in Книга

Как запускать продукты

product-start

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

  1. Продукт и потребности пользователей
  2. Дизайна и графики
  3. Технический раздел
  4. Раздел начального маркетинга

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

Продукт и потребности

Итак, мы сформировали потребность в проблеме людей и вроде как нашли ее более удобный вариант решения. Что делать дальше? Далее необходимо прописать максимально подробно как и за счёт каких функций и механик будет решаться эта проблема для будущих пользователей. Помните я ранее писал про MVP? Мы снова пришли к пониманию того, что в основе первых версий продукта у нас должно лежать безукоризненное и более простое решение ключевой проблемы пользователей и только потом все то, что расширяет возможности продукта и предлагает его пользователям дополнительный сервис.

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

Указывайте всё: переходы по сайту, регистрацию, ключевые действия — вы должны видеть всю картинку и все пользовательские пути по сайту. Это позволит вам понять какой из этапов можно упростить ещё больше и сделать его более понятным для пользователя. Данный раздел также будет основной для раздела связанного с дизайном и технической реализацией и именно по нему будущие дизайнеры и разработчики будут оценивать фронт предстоящих работ и их объёмы.

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

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

Пока не убежали вперед – как правильно определить цену за продукт? Сломано немало копий, написано множество статей относительно монетизации продукта и правильном ценообразовании, но я скажу лишь одну простую вещь  —  пробуйте всё то, что считаете нужным. Изучите сколько люди платят за решение в настоящее время, изучите цены конкурентов или продуктов из схожих областей, в общем, пробуйте разные цены, пробуйте и совмещайте форматы работы продукта, в общем, не бойтесь экспериментировать не только с функционалом продукта, но и с его деньгами  —  ценовые A/B-тесты как нельзя лучше покажут вам готовность ваших пользователей платить вам деньги и помогут вам найти наиболее выгодный формат. И нет ничего страшного в том, чтобы менять и совершенствовать модели монетизации продукта на всем пути его жизни. Идем к следующему шагу.

Раздел дизайна

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

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

Кто рисует интерфейс и дизайн? Тут есть два варианта – либо это делает дизайнер на постоянной основе, работающий в вашей команде, либо это… вы. Да, да, продакт-менеджер работает с продуктом и пользователями, а это идеально укладывается в то, с чем работает UX/UI-дизайнер. На мой взгляд, наиболее подходящим решением служит следующая механика:

  1. Продакт-менеджер рисует будущий интерфейс (UI) работы продукта на основе его предположений и пользовательского опыта в виде прототипов.
  2. И отдает такие прототипы на полноценную отрисовку web-дизайнеру.

Разница между UX/UI и веб-дизайном, на мой взгляд, в том, что UX/UI это то, как работает или может работать продукт, а веб-дизайн – как он выглядит.

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

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

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

Работа любого продукт-менеджера – постоянно улучшать и оптимизировать процессы работы продукта

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

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

Технический раздел

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

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

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

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

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

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

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

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

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

Чтобы не вставать два раза, давайте сразу поделюсь своим опытом как отобрать нужного вам разработчика. На самом деле, то не сложно, даже если вы не разбираетесь в программировании. Например, я не разбираюсь в том, как работает Tornado или Docker, но я отчетливо слышу, когда кто-то пытается выдать мне желаемое за действительное. Уверен, что этот получится и у вас  —  будьте внимательны и спрашивайте кандидатов не о том, какие технологии они знают, а о том, ПОЧЕМУ он с ними работают и как они решают поставленные перед ними задачи.

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

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

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

Вообще, процесс поиска команды разработчиков очень увлекателен. Правда — это совсем не скучно и по зубам даже тем, кто имеет хотя бы минимальные познания втом, какие технологии могут использоваться для ваших задач. В чем увлекательность? Конечно же — в людях. Ища разработчиков вы можете познакомиться по истине с необычайными людьми. Например, как-то я искал senior python developer в один проект и случайно познакомился с российском разработчиком и, по совместительству, переводчиком книги о Python, на которой воспиталось и выросло не одно поколение джуниоров, мидлов и сеньоров в России. Это необычный человек (Руслан, привет!), который не только в совершенстве знает Питон, но и обладает кучей других интересных умений, например пайке плат и схем для лифтов :)

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

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

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

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

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

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

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

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

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

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

Не гонитесь за популярными технологическими брендами. Использование .NET или Ruby не сделает ваш продукт лучше и популярнее. Единственное, на что это повлияет – скорость разработки и ресурсы, которые придётся в неё вложить. Это тоже самое, что гнаться за модой — на это нужен реальный вкус и много денег, но не факт, что вы будете выглядеть красиво.

Не раздувайте штат разработчиков. Увеличение команды разработчиков в два раза на начальном этапе не означает, что продукт будет готов в два раза быстрее. Скорее наоборот — чем больше “голов”, которые ещё не притерлись друг другу и продукту, тем больше путаницы, мнений, неразберихи и больше времени на их обучение.

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

Закладывайте запасное время. Никогда не будет лишним заложить на реализацию продукта, какой-то функции или спринта чуток лишнего времени, например 30% от реально заложенного срока. Уложитесь раньше – честь вам и хвала, за то, что зарелизили раньше срока. Просядете по срокам – всегда будет немного времени в запасе.

Вернуться назад Читать далее