Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

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

Глава 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нередко крупные софтверные компании направляют более 50 % средств, выделяемых на исследования и разработки, на развитие инфраструктуры. Однако всегда есть соблазн поставить эти инвестиции под вопрос. Вы видите крупные расходы на инфраструктурные команды в каждом бюджетном цикле, и их необходимость начинает вызывать вопросы. Зачем мы нанимаем инженеров для поддержания внутренней инфраструктуры вместо того, чтобы увеличить штат команд, создающих продукты для клиентов? Да затем, что софтверная инфраструктура делает всех других разработчиков более продуктивными и успешными. Откажитесь от этого, и вы быстро поймете, какой выигрыш дают инфраструктурные команды. Большинство компаний обнаруживают, что рост производительности оказывается намного больше, чем 20–30 %-ные инвестиции в инфраструктуру.

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