Что должен сделать Ларри Пейдж, чтобы вернуть Google на истинный путь

Я работал в Google на протяжении пяти лет (2005-2010), наблюдая за тем, как развивалась эта компания. Сначала инженеров воспринимали как надоедливых инноваторов, разрушающих устои компании. Потом нестандартный образ мышления («по типу Google») был принят за основу корпоративных целей и быстро стал доминирующим.

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

Дайте инженерам полную свободу и закройте глаза на все остальное.

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

Вот небольшой список основных поводов для недовольства инженеров Google (на момент, когда я покинул компанию):

• Компиляция кода и устранение багов для других сотрудников. Это была огромная проблема для всех разработчиков C++ в Google. Они тратили кучу времени на компиляцию и устранение багов кода просто для того, чтобы проект пошел в работу. Эту практику надо прекратить. Также как и распределение исходного кода среди других отделов компании. Различные проектные группы (bigtable, GFS, Stubby, Chubby) должны сами учиться работать с кодом и уметь презентовать его в читабельном виде.

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

• LCE & SRE «блокеры». Замечательно, что вас поддерживают отделы Координации запуска продукта и Обеспечения надежности сайтов. Но когда они заявляют, что «вы не можете начать реализацию проекта, потому-то и потому-то…», имейте в виду, что эти отделы прекратили решать проблему и превратились в нее сами.

• Встречи. На самом деле люди уже перегружены постоянными брифингами и отчетами о состоянии дел. Если ваша компания решила не проводить брифинги в четверг – это неправильно. Надо проводить встречи только в четверг, а в остальные дни работать. Только тогда проектная группа сможет завершать проекты в срок.

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

• Проведение собеседований и оценка их результатов. Старомодная модель, когда все собираются и обсуждают кандидата остается самой эффективной и на сегодняшний день. В этом процессе должен поочередно участвовать каждый инженер, так чтобы бремя собеседований не ложилось на одних и тех же людей. Не делегируйте процесс выбора инженеров для собеседований отделу кадров, потому, что последние всегда отбирают любимчиков и всегда неправильно мотивированы. Ограничьте количество собеседований до одного в неделю на одного инженера. Разработайте простую систему реагирования в случае ответов типа: «Мне не нравится это резюме и я не хочу беседовать с этим кандидатом», «Я не могу проводить собеседования».

• Неодобрение использования бесплатных исходных кодов. В мире бесплатного кода происходит столько разных событий. Например: Hadoop, MongoDB, Redis, Cassandra, memcached, Ruby on Rails, Django, Tornado (сеть разработчиков) и многие другие продукты, которые превосходят Google по удобству и эффективности. Инженерам запрещают пользоваться бесплатными наработками и все, что им остается – это только Bigtable/Spanner и GFS/Colossus для создания своих продуктов.

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

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

Создавайте новые «нестандартные» центры обработки данных (но не на основе старых систем) и сделайте так, чтобы у каждого инженера был доступ к этим новым центрам.
Самый большой недостаток кластерной системы заключается в том, что она требует для поддержания громадную экосистему и загоняет людей в очень узкие рамки просто для того, чтобы было легче управлять информацией. В данной среде невозможно постоянно хранить данные на локальных дисках, потому, что рабочие места могут быть удалены и перемещены в любой момент. Сервисы, используемые для постоянного хранения информации – Bigtable и/или Colossus – не совместимы ни с одной внешней базой данных (MySQL, например). Итак, кластерная система, на мой взгляд, является устаревшей и сковывающей моделью управления ресурсами.

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

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

Будьте похожи на базар, а не на церковный собор.

Забудьте мантру о «ненужном и ненадежном железе».

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

Избавьтесь от синдрома NIH (Not Invented Here – разработано не нами)

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

Google страдает от ярко выраженного синдрома NIH. Все альтернативные решения (Hadoop, MongoDB, Redis, Cassandra, MySQL, RabbitMQ, etc.) считаются технически несовершенными и плохо разработанными. Google должен освободиться от подобного отношения и наконец посмотреть на мир за пределами их организации. Многие масштабные сервисы, например, Твиттер, созданы исключительно на основе бесплатных кодов. Несмотря на это, вся система работает очень эффективно. Почему? Потому, что приложения, созданные на основе бесплатного кода, ориентированы на продукт. Именно этого так не хватает Google. Если вы хотите завоевать и удержать новые рынки, то надо ориентироваться на продукт и использовать любой доступный ресурс. И без снобизма.

Кроме прочего, Google должен дать доступ открытому софту в свой производственный процесс.Amazon и RackSpace удалось это сделать с помощью надежного виртуального хостинга, что придало этим сервисам гибкость, эффективность и конкурентоспособность.

Помните, что маленькие, но четкие цели достигаются быстрее, чем амбициозные, но размытые

Google хорошо известен своим талантом создавать огромные инфраструктуры и решать колоссальные проблемы. GFS & Colossus – для хранения файлов, Bigtable, Blobstore и Spanner – для хранения структурированных данных, Caffeine – для хранения документов и индексации.

Но каждый раз, когда возникает препятствие или проблема, то Google действует по одной и той же накатанной схеме – впихивает все проекты в рамки одной из своих систем или взыскивает менеджеров за то, что они «все делают не так». Когда инфраструктура перестает соответствовать потребностям приложения, все просьбы об усовершенствованиях теряются в системном шуме. Это значит, что маленькие проектные группы оказываются погребены под глупостью огромного монстра.

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

Создайте собственный инкубатор.

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

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

Покажите людям, что их маленькие, но удачные идеи высоко ценятся вами.

Это важный момент. Я много раз слышал фразу: «Если ваша идея не сможет принести нам прибыль в миллиард долларов, то она не стоит того, чтобы Google тратил на нее время». Это полная ерунда. Вы хотите этим сказать, что «ваша чудесная идея, которая может помочь заработать миллион долларов в год, менее важна, чем небольшой хак в контекстной рекламе или поиске». Даже если это правда, вы все равно должны взращивать пусть маленькие и незначительные, но инновационные идеи.

Приобретенные Google компании в размере от пяти до пятидесяти миллионов долларов должны обозначать, что малый бизнес тоже важен и нужен. Дайте это понять людям. Очень плохо, если кто-то говорит: «ваша идея на $5 миллионов не заслуживает моего внимания», а потом покупает компанию стоимостью в $5 млн. Так делать неправильно.

Искорените внутренний язык и структурное кумовство.

Я имею в виду, что надо прекратить заставлять людей вести себя так, как хотите вы. Несколько раз я был свидетелем того, как системные разработки в стиле не-Google закрывались только потому, что не использовали Bigtable, GFS, Colossus, Spanner, MegaStore, BlobStore и другие внутренние системы.

Возьмем, к примеру, языки типа Python, который отодвигается на задний план, потому, что является «слишком медленным для интерфейса». А я говорю, дайте инженерам использовать те инструменты и те языки, которые они хотят и которые в данном контексте являются наиболее эффективными. Не судите инфраструктуру, судите Продукт. Если кто-то запускает хорошую систему, основанную на Oracle или нескольких скриптах Perl CGI, работающих на Sun Sparc 5, то это надо поощрять. Если система не выдерживает нагрузки из-за наплыва пользователей, то такое надо поощрять еще больше. Это успех.

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

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

Amazon EC2 намного быстрее и лучше справляется с задачами итерации и новаций, чем внутренняя кластерная система менеджмента, разработанная Google. EC2 не только более надежна, но и с ее помощью намного легче начать и закончить целый цикл, а не только управлять отдельными рабочими местами. Для создания EC2 были использованы давно и хорошо работающие процессы, а также открытый код. Запуск реплицированной MongoDB на базе EC2 происходит легко и просто. Google должен сконцентрироваться на создании такой системы, которая бы работала в любой среде открытого кода.

Признайте, что принцип 20% времени – это ложь.

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

Я думаю, сама идея – замечательная, но ее надо немного доработать. Тратить на что-то один день в неделю – не рационально (можно сделать много за один раз, но довольно сложно продолжать в том же духе все время). Одна неделя в месяц – отлично. Но если брать за точку отсчета «основной» проект, то ничего не получится. Есть инертная масса, которую надо расшевелить, а инженеров простимулировать на новые идеи и новые направления (для этого тоже нужно время). Поэтому, надо сконцентрироваться на взращивание внутренних ресурсов и сотрудничестве. Может, вообще, лучше наплевать на все это и повысить всем зарплату на 20%. Ах, черт побери, они это уже сделали.

Наступайте дважды на одни и те же грабли.

Пусть инженеры учатся чему-то, действуя и совершая ошибки. Написание правил о том, как должна выглядеть система, создает ненужную нагрузку на мыслительный аппарат и мешает созданию продукта. Неправильно говорить, что «Google не допустит еще одного Orkut». Orkut был и остается большим успехом. Проблемы с инфраструктурой не играют в данном случае никакой роли. Инженеры должны быть вознаграждены и за недавние просчеты тоже (Wave и т.п.). Такие ошибки можно и нужно повторять.

“Масштаб Google” – это миф.

Да, я убежден в этом.

Google Search (продукт) пожирает огромные ресурсы. Никакой другой продукт не является таким ресурсозатратным. Но Google настаивает на том, чтобы этот сервис продолжал работать в «масштабе Google», несмотря на то, что в этом нет необходимости.

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

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

Маленькая система, которая загибается от нагрузки, свидетельствует об огромном успехе.

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

Источник: www.searchengines.ru