Олег Якубенков, ZeptoLab: «Никакого сакрального знания об управлении проектами не существует»

Создатель блога
Go Practice и ведущий аналитик компании Zeptolab Олег Якубенков опубликовал на своём ресурсе подробный
материал
о том, каким урокам он научился, пройдя путь от должности аналитика в «Яндексе» до продакт-менеджера в игровой студии ZeptoLab.

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

После прихода в Zeptolab моя деятельность изменилась достаточно сильно. Теперь я не только работал с данными, но и влиял на продукты. Спустя некоторое время я начал работать над новой для компании игрой в роли продакт-менеджера. Это была мобильная игра King of Thieves, которую в феврале 2015 года мы запустили на весь мир.

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

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

Урок 1. Принимать решения — это сложно

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

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

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

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

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

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

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

Возможность принимать решения — это круто, но как и во всём, у этого есть своя обратная сторона.

Урок 2. Сакрального секретного знания не существует

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

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

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

Урок 3. Лучше, когда над продуктом работают несколько человек

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

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

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

Урок 4. Должен быть понятный механизм принятия продуктовых решений

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

В случае King of Thieves у нас было три человека, которые принимали финальные решения по продукту. Если наши взгляды расходились, то решение принималось с помощью голосования.

Урок 5. Продакт-менеджер — это не придумыватель идей

Этот урок я выучил у геймдизайнера King of Thieves — Жени Яйленко. Ключевая польза человека, работающего над продуктом, вовсе не сводится к придумыванию идей. Идеи — это лишь базовый материал для построения и развития продукта. Очень важный материал, но лишь базовый. С этим материалом ещё надо хорошенько поработать, чтобы из него получилось что-то дельное.

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

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

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

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

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

Урок 6. Тестируйте ключевые вещи как можно раньше и как можно дешевле

Это очень очевидное утверждение, про которое вы, наверняка, читали в разных модных книгах вроде Lean Startup. Но когда дело доходит до реальной разработки, то часто об этом забываешь. Уж больно ты увлечён и уверен в своем продукте, чтобы что-то там тестировать (обычно эта уверенность быстро проходит после первого запуска, поэтому не тяните с ним). Давайте рассмотрим пару примеров.

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

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

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

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

Но проблема в том, что когда ты «творишь» продукт и несёшь за него ответственность, то трезвость мышления резко пропадает. Ты становишься уверен, что мелкие незначимые вещи могут кардинально повлиять на опыт пользователя и на ключевые метрики. За редкими исключениями, это не так.

Урок 7. Слова «lean», «data-driven» и «эксперимент» — не оправдание для бездумного тестирования всего подряд

«Эрик Райс как-то сказал, что самый популярный способ извратить метод Lean Startup — это беспорядочно бросать любое г…но об стену, надеясь что что-то прилипнет» — как-то написал в своем профиле на Facebook Аркадий Морейнис. Не знаю, говорил ли это Эрик Райс или нет, но фраза замечательно отражает суть пункта.

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

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

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

Мы долго разрабатывали King of Thieves, много итерировали и экспериментировали по пути, но:

Ресурсы разработки ограничены. Если делать и пробовать всё подряд, то ваша скорость будет минимальна, и вы никогда не доведёте свой продукт до хорошего состояния.
Приток новых пользователей ограничивает число экспериментов, которые вы можете провести. Для каждого эксперимента нам требовалось как минимум по 1000 пользователей (чаще больше) на каждый из альтернативных вариантов. При стоимости скачивания мобильного приложения на уровне $3-$4 на развитых рынках, вы можете оценить, во сколько обходятся эксперименты.
Если же у вас много трафика, то вашим ограничением будет время, требуемое на качественный анализ полученных результатов. Чтобы отличить шум от значимых результатов, понять, как изменения повлияли на разные аспекты вашего продукта, вам потребуется достаточно много времени, даже если у вас настроена инфраструктура для запуска экспериментов и их базового анализа.
Есть фичи, с которыми пользователь сталкивается спустя неделю или месяц использования продукта. Эксперимент для их проверки будет стоить вам слишком много времени и потребует очень много пользователей (ведь большая часть новых пользователей к этому моменту уже уйдут из продукта).

Data-driven-подход очень полезен, и, как аналитику, мне он очень нравится. Но если вы хотите от него получить максимум выгоды, то надо научиться повышать конверсию в удачные эксперименты. А для этого надо предварительно прорабатывать и фильтровать то, что хочется проверить.

Урок 8. Сначала машина должна поехать

Когда вы создаёте продукт с нуля, то главное испытание на первых этапах — найти что-то, что заработает (некоторое преддверие product/market fit). Представьте, что вы пытаетесь создать машину. В таком случае ваша ключевая задача — добиться того, чтобы ваше творение смогло управляемо ездить. Это ключевая ценность продукта, то, ради чего люди будут пользоваться им.

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

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

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

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

Урок 9. Продукт — это не набор фич

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

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

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

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

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

Урок 10. Ритм важнее

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

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

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

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

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

Поэтому если после того, как итерация запланирована, начинает разрастаться скоуп (всё равно почти никогда не получается всё предусмотреть), то новые и старые задачи надо заново приоритизировать и то, что не помещается в сроки, переносить на следующую итерацию.

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