Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [88]

Глава 11 Инвестируйте в инфраструктуру

Двигайся быстро и сокрушай.

МАРК ЦУКЕРБЕРГ, 2009 Г.

Двигайся быстро со стабильной инфраструктурой.

МАРК ЦУКЕРБЕРГ, 2014 Г.

Знаменитый слоган Марка Цукерберга «Двигайся быстро и сокрушай» был блестящим, но в конечном счете неискренним. Поэтому неудивительно, что в конце концов он сменил его в 2014 г. на гораздо менее запоминающийся «Двигайся быстро со стабильной инфраструктурой». Эта глава повествует о противоречиях между этими двумя утверждениями.

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

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

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

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

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

В Facebook, как и во многих других компаниях, принято тратить на инфраструктуру и платформы более 30 %, а иногда и более 50 % от общего бюджета развития. Учитывая, что клиенты на самом деле не видят результата этих дорогостоящих инвестиций, руководители часто ставят их под сомнение. Эта глава посвящена пониманию важности ваших платформенных команд и тому, как они превращают другие команды в лучшие и более эффективные. В компании Facebook все началось с парня по имени Чак Росси[11].

Чак пришел в Facebook в 2008 г. в качестве первого «релиз-инженера». Его работа состояла в управлении внедрением ПО в производственную среду и заботе о том, чтобы ничего из внедряемого не обрушило сайт. Он управлял очень жестким процессом, который включал еженедельные обновления с крупными изменениями, причем в течение рабочего дня, когда инженеры могли прийти на помощь при возникновении проблем, а также ежедневные обновления для устранения мелких проблем. На нем лежал учет того, какие разработчики пишут беспроблемный код, и ведение репутационного рейтинга разработчиков в компании. Обрушивший Facebook получал предупреждение. Три предупреждения – и вам на какое-то время запрещали поставлять код. (Заметьте, не навсегда – ошибки допускались, предполагая, что вы учитесь на них, хотя и ходите в штрафниках.) Выступая в роли сторожевой собаки, Росси внедрял лучшие практики тестирования, проверки кода и многое другое.

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

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

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

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

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