Основы цикла разработки продукта от основателя Twitch

Прежде чем Justin.tv превратился в Twitch и Socialcam, у нас много лет было неправильное понимание того, как создавать продукт. Мы проводили несвязные совещания по продуктам, и не записывали наши решения.

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

Мы редко делали аналитику новых продуктов, поэтому мы не знали, как они работают после запуска.

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

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

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

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

На цикл разработки влияет сам продукт. Мы разрабатывали Socialcam для iOS, поэтому выбрали двухнедельный цикл, во время которого мы успели тщательно протестировать приложение, прежде чем выложить его в App Store.

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

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

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

Зачастую просто дать возможность озвучить идею и записать ее на доске, даже если её разработка ещё не начиналась, помогает значительно увеличить заинтересованность разработчика.

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

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

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

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

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

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

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

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

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

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

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

Мы не занимались последними, если у нас оставалось мало времени. Когда с этим было закончено, мы фотографировали интерактивную доску со всеми записями, а затем всё с неё стирали.

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

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

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

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

Но в итоге Socialcam не воплотил нашу мечту, так и не став «Инстаграмом для видео». Более того, то, что нам нужно было сделать, куда больше похоже на Snapchat. Но этот проект всё же помог нам делать итерации невероятно быстро.

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

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

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

9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня.

Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

#twitch