Google: битва за хранение данных
В начале 2006 года старшему вице-президенту Google по техническим вопросам Биллу Кафрану необходимо было принять решение и положить конец противостоянию, возникшему между двумя группами исполненных энтузиазма инженеров. В течение двух лет эти группы разрабатывали два альтернативных пути удовлетворения ненасытного и быстрорастущего аппетита Google в отношении объема хранилища данных. Назрела необходимость внедрить новую систему хранения данных, и вместе с ней пришло время принять решение.
Потребности Google в ресурсах для хранения данных были не только важны для компании, но и уникальны для того времени. Было очевидно, что без подходящей емкости хранилища данных компания не сможет выполнить свою миссию — организовать информацию, имеющуюся в мире, и сделать ее «доступной и полезной для всех». При этом потребности компании, которая на тот момент существовала лишь несколько лет, уже превосходили все имеющиеся в наличии ресурсы. До этого никто никогда даже не пытался создать хранилище такого объема и масштаба, как требовалось Google. Компания задавала тон в области технологий хранения данных и своей деятельностью поднимала планку все выше и выше.
История двух команд по хранению данных
Когда Кафран выразил инфраструктурной группе свою обеспокоенность по поводу необходимости увеличения объема хранилища данных, было предложено несколько решений, вокруг которых самостоятельно и спонтанно начали формироваться разные команды. В подобных ситуациях Кафран и его руководители обычно изучали возникающие альтернативы и помогали разрозненным группам объединиться вокруг нескольких перспективных подходов. В данном случае они поспособствовали созданию двух команд из числа заинтересованных сотрудников.
Первая, по словам Кафрана, «хотела добавлять новые системы поверх уже существующей файловой системы Google GFS. Добавление таких программных стеков, или „связующего ПО“, было обычным делом в мире программного обеспечения. Верхние слои были спроектированы так, чтобы предоставлять услуги, которые не обеспечивались нижними слоями. Идея была в том, чтобы этот программный стек поддерживал Gmail». Эту команду назвали «Большой стол» (Big Table).
Вторая группа объединилась вокруг трех ведущих инженеров по системам хранения данных, которые работали над серверной инфраструктурой Gmail. Эти молодые и менее опытные инженеры полагали, что требования к хранению данных из приложений настолько отличаются от требований к хранению данных поиска, что бессмысленно пытаться адаптировать систему GFS — ее необходимо заменить. Они хотели создать совершенно новую систему с учетом требований и поиска, и приложений. Из-за этого вторая команда получила название «Создание с нуля» (Build from Scratch).
Кафран дал обеим командам возможность полностью сосредоточиться на разработке своих идей, хотя и знал, что этот процесс, даже несмотря на высочайшую скорость работы, скорее всего, займет год, а то и два. Он объяснял свои действия так: «Я видел, что у обеих команд есть несколько очень интересных идей, которые стоит изучить, поэтому убедил их создать прототипы». У Кафрана было предчувствие, основанное на огромном опыте, что подход команды «Большой стол» имел больше шансов удовлетворить потребности Google, а команде «Создание с нуля» будет очень сложно воплотить свои идеи в необходимых компании масштабах. «Но я не был до конца уверен, — рассказал Кафран. — Я знал, что у нас еще нет всех данных. Никто в организации не мог знать наверняка, какая система лучше всего подойдет в будущем. Инженеры из «Создания с нуля» были в восторге от возможности разработать еще одну классную технологию, но… они должны были сами ощутить и осмыслить все проблемы своей системы. Здесь я не хотел вмешиваться и давать указания».
Практика управления: технический просмотр
Одним из ключевых методов управления в группе инфраструктуры был технический просмотр. Такие встречи проводились еженедельно — лично или в форме видеоконференции, — и обычно на них присутствовали Кафран и ряд руководителей Google. Однако для всех остальных команд такие просмотры проводились гораздо реже. На этих важнейших собраниях команды обсуждали свою работу и отвечали на вопросы, критику и идеи других инженеров, что помогало отшлифовывать творческий процесс.
Для каждой из команд по разработке ресурсов для хранения данных («Создание с нуля» и «Большой стол») Кафран отдельно проводил технические просмотры примерно каждые шесть недель или два раза в квартал. Фактически эти команды очень мало контактировали друг с другом. Отчасти причиной тому было физическое расстояние между ними (одна команда находилась в Калифорнии, а другая — в Нью-Йорке), но в большей степени повлияла специфика их задания: они должны были исследовать отдельные, конкурирующие подходы, что исключало совместную работу. А поскольку каждая из команд кое-что знала о работе другой, неизбежно возникло чувство здоровой конкуренции.
Во время просмотров каждая команда сообщала о текущем состоянии своей работы и некоторых проблемах, с которыми она столкнулась. В ответ Кафран давал советы, а не прямые указания. Если бы он или его руководители знали, что команды должны сделать, или какое именно решение они должны выработать, не было бы никакого смысла в создании команд. Потому данным командам предоставили большую свободу в разработке конкурирующих идей по хранению данных.
Время принимать решение
После двух лет работы команд над идеями настало время «прийти к какому-то решению». К тому времени Кафран сделал два вывода: во-первых, ни одна из команд не нашла долгосрочного решения; во-вторых, в краткосрочной перспективе подход «Большого стола» (программный стек поверх GFS) представлялся лучшим решением. Однако он также считал, что команда «Создание с нуля» совершила много интересных открытий, которые пригодятся в будущем, даже несмотря на то, что их подход еще не был готов к реализации.
В конце 2006 года во всей компании была реализована концепция стеков для хранения данных поверх системы GFS, разработанная командой «Большой стол». После реализации этого решения Кафран столкнулся с другой задачей: необходимо было определить дальнейшее будущее команды «Создание с нуля». Ее можно было присоединить к другим проектам, которые уже осуществлялись в нью-йоркском офисе, или найти проекты за пределами инфраструктуры хранения данных. Но Кафран выбрал третий вариант: он превратил «Создание с нуля» в команду по разработке системы следующего поколения.
Роль лидера в творческом решении
С одной точки зрения, это история о борьбе между взаимоисключающими подходами, из которых только один мог привести к появлению новой системы хранения данных. С такого ракурса эта история вообще не имела отношения к интеграции. Но, если рассматривать ее шире (учитывая задание Кафрана, очевидно, что именно это и необходимо), — эти исследования носили подлинно интеграционный характер. Хотя команда разрабатывала важные идеи, которые не применяли сразу в следующей системе хранения данных, Кафран увидел их потенциальную ценность и учел их при выработке решений в дельнейшем. Как отметил один из руководителей: «Билл всегда помнил о том, где мы должны оказаться в определенный момент в будущем».
Придерживаясь такого курса, Кафрану удалось добиться трех важных результатов. Во-первых, компания нашла лучшее краткосрочное решение для проблемы. Во-вторых, она продвинулась вперед в разработке систем хранения данных, более эффективных в долгосрочной перспективе, то есть заготовила новые технологии на тот случай, когда они понадобятся. В-третьих, благодаря Кафрану организация приобрела способность и желание разрабатывать и совершенствовать одновременно несколько конкурирующих идей.
Если посмотреть на подход Кафрана более внимательно — на ход его мыслей и действий при решении срочной и важной для Google проблемы — может возникнуть мысль: «Это, конечно, интересно, но чему можно научиться у компаний вроде Google, у которых денег куры не клюют?» Действительно, Google располагала значительными финансовыми ресурсами, но у нее не было избытка первоклассных инженеров в области хранения данных. Это очень ценные специалисты, и Кафран полностью осознавал значение их опыта и знаний для компании. Он также понимал их потребность в независимости и желание использовать свои таланты, знания и опыт для решения сложных проблем. Многим из них вообще не было необходимости работать, и практически все они могли найти другую работу в Google или в любой другой компании. Задача Кафрана состояла в том, чтобы создать в Google такую среду, в которой они могли бы заниматься тем, чем хотели, и так, как хотели.
Блестящие решения не появляются спонтанно, особенно когда дело касается таких сложных проблем, какие мы наблюдали в Google. Они рождаются в процессе разработки идей, вариантов, альтернатив, даже неудач и ошибок и комбинирования их по-новому в поисках наилучшего решения. Действительно, способность видеть проблему целиком, а затем интегрировать различные точки зрения и идеи является важнейшей частью инновационного процесса. Это было одной из основных забот всех лидеров, ситуации которых мы изучали.
К сожалению, настоящие творческие решения встречаются редко. Большинство решений — не более чем простой выбор одного из вариантов с исключением всех других или своего рода компромисс между альтернативами. На самом деле, вместо этого необходим полноценный процесс принятия решений — такой, который мы наблюдали в инфраструктурной группе Google.
Действия такого лидера, как Кафран, очень легко истолковать неверно: его подход может показаться слишком мягким, слишком беспечным, слишком либеральным. Да, Кафран не выкрикивал приказы и не принимал решения задолго до их обсуждений, а тщательно создавал и формировал среду, в которой его инженеры могли и хотели работать над инновациями.
-----
Источник:
L. A. Hill, G. Brandeau, E. Truelove. Collective Genius: the Art and Practice of Leading Innovation. Harvard Business Review Press, 2014.
Перепечатано с разрешения Harvard Business Review Press. Все права защищены.
