Продуктовая культура Facebook — «взгляд изнутри» Олега Якубенкова

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

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

Иллюстрация Chris Phillips

Мой субъективный опыт

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

Каждый член команды отвечает за общую цель

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

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

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

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

Иллюстрация Chris Phillips

Функция проджект менеджмента размазана по команде

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

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

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

Вы можете спросить, что же делает продакт-менеджер.

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

Иллюстрация Chris Phillips

Миссия, цель, приборы

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

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

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

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

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

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

Иллюстрация Chris Phillips

Культура работы с данными

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

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

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

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

Иллюстрация Chris Phillips

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

Facebook тратит много ресурсов на поддержание высокого качества ключевых датасетов.

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

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

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

Иллюстрация Chris Phillips

Отсутствие ожесточенных споров – побочный эффект data-driven культуры

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

За время работы в Facebook я практически не участвовал и не был свидетелем ожесточенных споров.

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

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

Иллюстрация Chris Phillips

Культурные особенности

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

Возможности vs проблемы.

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

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

Оптимизм и открытость к новому.

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

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

Иллюстрация Chris Phillips

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

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

Иллюстрация Chris Phillips

Минусы работы в продуктовых командах в Facebook

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

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

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

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

Иллюстрация Chris Phillips

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

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

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

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