Лого vc.ru

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

Олег Якубенков, 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, много итерировали и экспериментировали по пути, но:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи по теме
Как создавать продукты, формирующие у пользователей привычки27 апреля 2015, 14:12
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

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

Спасибо
Это будет во второй части - там и обсудим :)

0

"Если ты что-то упустил или о чём-то не подумал, то, скорее всего, никто больше об этом не подумает."

Звучит так, будто все работники лишь выполняют указания и никак не ощущают собственный вклад в проект :)


Интересно еще почему поставили пм человека, который раньше работал с аналитикой? Принимать решения - человеком, который раньше рекомендовал :)

king of thieves отличная игра, то есть результат получился у вас шикарный)

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

0

тут бы коммент Олега, о том как в ZL пересекается (может полностью) - продакт-менеджер и проджект менеджер.

0

у нас проджект менеджер и продакт менеджер - два разных человека

0

Хорошая статья.
Если бы, лет 5 назад, кто-нибудь всё так рассказывал...но те же грабли уже и сам собрал!

Вот вы мне как гуру ответьте пож. Почему у ровио после обновлений перестают работать игры и причем годами не исправляется. Это фича? Типа наигрался и вали... Ровио вроде не мелочь.

0

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

Полезная и хорошая статья, спасибо.
Жду продолжения

0

Отличная статья, спасибо Олег.

0

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

Сейчас обсуждают
Дмитрий Трипалюк
hyper weapon

Идея неплоха. Я бы поюзал, если бы мне это дало N единиц новой лояльной аудитории ;)

«ЧатКвест» — инструмент для создания маркетинговых квестов в мессенджерах
0
Татьяна Бочкарева

Есть мысли о тезисе номер два. Очень скоро грядет революция в области перевозок людей. Люди будут перемещаться на воздушном метро, стоимость строительства которого в 100! раз дешевле подземного, а скорость до 500 км/ч при цене строительства путевой структуры в $5 млн за 1 км. Причем перемещаться люди будут почти бесплатно, так же как мы сейчас бесплатно звоним через Скайп. Окупаемость будет за счет попутных грузов. Как вам такое - ездить на каждые выходные на свою дачу с Москвы до Анапы за 3 часа?
Уже сейчас можете увидеть этот транспорт в движении (он запущен 29 ноября 2016г). Поддерживайте этот проект воздушного метро (струнный транспорт). Ещё можно успеть стать инвестором данного проекта. Увидеть его в движении и подписаться на новости можно на сайте проекта: goo.gl/qlfD2z

«Через 50 лет стран не будет — останутся только города»: основные тезисы лекции Кьелла Нордстрема о будущем
0
조냐 박

Если я пользуюсь только этими бесплатными 15 ГБ, то мне не о чем волноваться?

Google предупредила российских пользователей о повышении цен с 2017 года из-за «налога на Google»
0
Amar Ak

500-200? И даже не принято? В какой развитой стране такое есть? Так проще всем онлайн магазинам перенестись в юрисдикцию Гонконга и торговать, никаких пошлин, никакого НДС, раб сила по 200usd/месяц... и цены будут хорошие, правда в россии будет еще меньше рабочих мест и налоговых сборов...

Власти России намерены снизить беспошлинный порог для ввоза интернет-посылок до 500 евро с середины 2018 года
0
Johnny Vorony

Мне очень стыдно, коллеги, но до этой статьи я не знал кто такая Алена Владимирская.

Алёна Владимирская и оператор Wi-Fi в московском метро запустили проект с бесплатными карьерными советами
0
Показать еще