Взгляд изнутри: про продуктовую культуру Facebook

Олег Якубенков в своём блоге GoPractice — о том, как ставятся цели в продуктовых командах, почему между сотрудниками отсутствуют ожесточённые споры, и возможных минусах работы в крупной компании.

Два с половиной года назад после покупки MSQRD я присоединился к команде Facebook. Тогда я сомневался, что смогу научиться чему-то новому в крупной корпорации. И сильно ошибался.

Недавно был мой последний день в Facebook, поэтому самое время порефлексировать о полученном опыте и поделиться интересными наблюдениями.

Делиться конкретными кейсами я не могу, поэтому речь пойдет о продуктовой культуре Facebook. Если вам интересны более прикладные знания, то добро пожаловать в «Симулятор». Значительная его часть формировалась под влиянием опыта работы в синем социальном гиганте.

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

Мой опыт основан на работе в продуктовой команде, которая выводила на рынок новый сервис — Workplace. В Facebook есть много технических команд, опыт там будет отличаться. Есть много команд, которые развивают давно состоявшиеся продукты — опыт будет в чём-то другим.

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

Продуктовые команды в Facebook работают иначе — ответственность за цель лежит на всех. Работа разработчика оценивается не по качеству и скорости реализации фич, а по тому, как запущенные им проекты повлияли на продвижение к цели ( #impact). Если ты пишешь идеальный код, но эффект в плане метрик и инсайтов от твоих проектов нулевой, то на ревью возникнут сложности.

Главный плюс такого подхода — интересы всех участников команды синхронизированы и сонаправлены. Больше не надо уговаривать разработчика сделать дешевую костыльную первую версию, чтобы проверить идею. Он сам в этом заинтересован.

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

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

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

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

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

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

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

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

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

Миссия — это одно предложение, где доносится, зачем существует команда. Важный момент — миссия формулируется не с точки зрения интересов бизнеса, а с точки зрения интересов пользователя. Вырастить time spent и долгосрочный Retention — это интересы бизнеса. Помогать людям поддерживать и укреплять связи с важными людьми в их жизни — это интересы пользователей.

На основе миссии выбирается цель — это точка, куда команда хочет попасть в обозримом будущем. Цель обычно имеет числовое выражение, то есть состоит из метрики и её целевого значения. Иногда цель может быть бинарной — сделать возможным X. Иногда целью может быть изучение потребностей какого-то сегмента аудитории, специфичной задачи или рыночной возможности (такие цели называют Understand goals).

Приборы — ключевая метрика и опережающие индикаторы, протянутые на дешборды и в экспериментальную платформу.

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

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

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

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

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

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

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

Предлагаемые активности должны базироваться на понимании задач пользователей, сильных и слабых сторонах продукта, текущей ситуации на рынке, который формируются через анализ данных и качественные исследования (user research). Поэтому существенная часть ресурсов и времени продуктовых команд в Facebook тратится на этапы Understand и Identify, которые являются фундаментом для этапа Execute.

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

Этап Identify — это генерация идей, как можно достичь цель, оценка их потенциала и приоритизация.

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

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

На выходе получается список идей с примерной оценкой влияния на цель команды.

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

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

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

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

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

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

Подгонкой продуктовые команды грешат очень часто. Facebook не исключение, но там это происходит относительно редко.

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

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

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

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

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

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

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

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

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

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

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

Это делает задачу анализа экспериментов доступной не только для аналитиков, но и для всех остальных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате в компании получилось создать открытую, творческую и безопасную обстановку. Думаю, что цитата Эда Кэтмелла из Pixar неплохо передает ощущения от происходящего в Facebook.

Facebook — уникальная компания, близкая мне по духу и взглядам на многие вопросы. Мне повезло попасть в команду Workplace еще до публичного запуска продукта. Было интересно прожить ранние этапы формирования и становления сервиса, который теперь стремительно растет.

Но когда продукт доказывает свою состоятельность и интересность для Facebook (а для компании стоимостью $500 млрд число потенциально интересных продуктов невелико), то инвестиции в него начинают стремительно увеличиваться. А главная форма инвестиций в рамках Facebook — это количество людей, работающих над сервисом.

Я был вторым Data Scientist в Workplace. В момент моего ухода аналитическая команда уже была больше 20 человек. Рост команды привёл к тому, что сфера ответсвенности постепенно сужалась и углублялась.

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

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

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

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

Такой итерационный процесс с чётким обратным циклом обратной связи будет эффективнее, чем прямое копирование.