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