Hi-Tech

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

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

В закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Understand, Identify, Execute

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And, in its first moments, it’s often far from pretty. Originality is fragile. They are not beautiful, miniature versions of the adults they will grow up to be. This is why I call early mock-ups of our films "ugly babies".

They need nurturing — in the form of time and patience — in order to grow. They are truly ugly: awkward and unformed, vulnerable and incomplete.

Our job is to protect our babies from being judged too quickly. But the natural impulse is to compare the early reels of our films to finished films — by which I mean to hold the new to standards only the mature can meet. Our job is to protect the new.

Эд Кэтмелл

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть