Facebook — это известный бренд, и многим людям априори представляется, что работать в передовой, модной и прогрессивной компании интересно и сытно. Предлагаю укрепить или развенчать эту идею!
Как и Google, Facebook особо не распространяется на тему своей корпоративной культуры, предпочитая давать развернутые комментарии по релизам, а самые пикантные подробности оставляя за кулисами. Но кое-что я все-таки сумел найти — предлагаю вам статью об особенностях работы внутри FB по мотивам вот этого бурного обсуждения.
Колеса махины Facebook крутятся вокруг жизней разработчиков. К этому, в принципе, стремятся многие компании, где стоит поистине гамлетовский вопрос: как дать максимум свободы девелоперам и при этом не окунуться с головой в пучину анархии и хаоса? Тем более, в Facebook девелопмент наряду с операционным отделом составляет половину всего штата — в общей сложности около тысячи человек. Продукт-менеджеров здесь, к примеру, в 10 раз меньше, чем разработчиков.
До того как отправиться на передовую и запустить руки в Базу Данных, все девелоперы проходят
После обучения девелоперы получают доступ к Базе, предварительно прослушав лекцию на тему «с увеличением возможностей многократно возрастает и ответственность», при этом от них требуется зазубрить наизусть список деяний, за которые можно вылететь из компании, к примеру, разглашение личной информации пользователей.
В некоторых комментариях по поводу работы в FB говорится, что ввиду особенностей корпоративной культуры полезность менеджеров стремится к нулю и количество их уменьшается день ото дня, так как процесс управления отчасти выполняется самими разработчиками. Несомненно, эти мысли принадлежат девелоперам, так как у самих ПМ на этот счет имеется свое мнение: процесс разработки построен таким образом, что ответственность за конечный продукт чувствуют все: инициатива поощряется, дух стартапа царит, менеджеры не зверствуют.
Во время митингов апдейты по статусу разработки делают девелоперы, а не менеджеры. Последние наряду с маркетологами, как правило, помалкивают из вышеизложенных причин: главный посыл, что разработчики всегда должны чувствовать ответственность за продукт и быть центром команды, а не периферией.
Все полностью добровольно: менеджер агитирует разработчиков заняться проектом, расписывая все предстоящие прелести и плюшки. Когда набирается команда, девелоперы согласовывают с менеджером список тасков на неделю. В некоторых случаях менеджер может менять приоритет задач.
Но не всё коту масленица. Девелоперам приходится быть настоящими мастерами на все руки, по крайней мере, это от них это ожидается. К примеру, если им нужна помощь дизайнера, им приходится сначала так же подробно расписывать последнему прелести проекта, как когда-то делал менеджер. Получилось донести свою мысль — вот тебе дизайнерский макет, не получилось — рисуй сам. Вот вам и оборотная сторона стартап-подхода.
Front-end в FB считается непрестижным детским лепетом, так что набрать команду для проекта такого типа сложновато. В этом заключается отличие Facebook от большинства других компаний, где все хотят трудиться на фронте, чтобы было что-то наглядное для портфолио. Тут же самые лакомые кусочки относятся к back-end: усовершенствование алгоритмов новостного фида, таргетирование рекламы, работа с memcache и др. Почти каждый девелопер хочет работать именно над этими задачами.
С другой стороны, даже если вам повезло и вы попали на вкусный проект, вечно наслаждаться им не получится. Если вы уже год сидите на одном месте, вас обязательно поставят на пару месяцев на другой проект в новую команду, чтобы не обрастали мхом. Любимый лозунг руководства: каждому проекту — свежая кровь, вам — встряска.
Примечательно, что у Facebook нет своей QA-команды как отдельного подразделения. Тестированием занимаются сами девелоперы + весь остальной штат, который использует последнюю проапдейченную версию сайта ещё до того, как изменения распространятся на весь мир. С другой стороны, если апдейтится новостной фид или другие стратегически важные вещи, к тестированию может приложить руку сам Цукерберг, но это единичные случаи.
Некоторые члены команды Facebook простодушно объясняют отсутствие армии тестировщиков тем фактом, что их девелоперы в состоянии писать код без ошибок, просто у них нет никакого стимула, так как за ними все проверяется. С другой стороны — это мнение яростно опровергается самими разработчиками.
Все изменения собираются в релизы и выпускаются каждую неделю. Релиз требует, чтобы все девелоперы, которые работали над ним, были в момент запуска он-лайн, чтобы в случае чего сразу же начать «работу над ошибками».
Например, иногда процесс поэтапного запуска изменений может выглядеть так: 1-2-3-баги. Назад к 1. 1-2-3-4-5-баги. Назад к 1.
Что касается наказаний за оплошности в работе с кодом — если кто-то сплоховал и в релиз пошел некачественный материал, это необязательно повлечет за собой увольнение. Как утверждают старожилы, среди них самих немало тех, кто хоть раз, но «отличился». Что действительно может 100% вызвать увольнение, так это отсутствие девелопера на связи во время релиза. В случае форс-мажора он должен найти себе замену, чтобы его прикрыли. Иначе — «давай, до свидания».
И напоследок небольшая ложечка дегтя для тех читателей, кто уже видит себя в FB. Из всего вышесказанного складывается впечатление, что Facebook — это рай для разработчиков: занимаются только тем, что им нравится, наслаждаются полной свободой и их не увольняют за ошибки!
Однако не все так просто — все эти прелести жизни достаются только тем, кто может похвастаться высокой скоростью работы и производительностью.
Весь цимус в том, что те, кто не относятся к числу гениев или усердных тружеников, больше полугода там не задерживаются. Нравится вам это или нет, но у Facebook очень заметная текучка — попасть туда, ещё не значит удержаться и прижиться, став своим...
Ладно, о'кей. Ну что, пробуем?