Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Быстрое движение и дублирование работы
Еще одна проблема, часто возникающая при создании ПО, связана с дублированием работы вместо ее синхронизации. Позволяя командам работать автономно и предоставляя им относительную свободу в выборе методов создания ПО, вы даете им возможность работать быстро, как в стартапе. Но при этом возникает риск, что несколько команд потратят время на создание одинаковых продуктов. Они дублируют работу, решая одну и ту же проблему по-разному. Это расточительно, однако не сильно волнует меня.
Вернер Фогельс из компании Amazon отмечает, что подход, при котором вы сознательно допускаете дублирование работы, часто не подходит традиционным компаниям, неспособным контролировать его. «Это так нелогично для них, поскольку они думают только об эффективности, – объясняет он. – Они привыкли контролировать все сверху донизу. По сути, иерархия для них становится важнее, чем быстрая работа».
Это объясняет, почему меня часто спрашивают, как мы предотвращаем дублирование работы в нашей корпоративной культуре с небольшими, самостоятельными командами. Мой ответ: мы не предотвращаем дублирование.
И вот почему: представьте две компании, которые находятся в противоположных концах шкалы «эффективность-автономность». В одной компании все команды идеально синхронизированы таким образом, что дублирование работы отсутствует. Каждая команда знает свою роль, от каких команд она зависит, а там, где есть возможность дублирования работы, владелец продукта назначается. Это звучит здорово, но работа редко выполняется таким образом. На практике команду обычно ждут те, кто зависит от нее. Когда одна команда не выдерживает сроки, это сказывается на всех остальных участниках рабочего процесса, а вина ложится на того, с кого все началось. Да, здесь нет никакого дублирования, но также нет и ответственности за результат, поскольку слишком много тех, кого можно обвинить, когда что-то идет не так.
А теперь посмотрим на вторую компанию. Команды быстро переходят к обслуживанию своих клиентов, не особенно заботясь о том, дублирует ли их работу кто-то еще. Все, в чем команда заинтересована, – создание успешных продуктов, которые принимаются клиентами, удовлетворяют их и обеспечивают рост доходов. В этой компании разработчикам не нужно спрашивать разрешения или координировать действия с другими командами. Представьте, что каждая из этих команд работает в своем физическом пространстве, имеет свой домен электронной почты и т. д. С тем же успехом это могут быть разные компании. Они настолько несинхронизированы, насколько можно представить. Как и следует ожидать, здесь есть дублирование работы, поскольку команды в действительности не так уж много работают вместе.
Эти две воображаемые компании – примеры крайностей, но они показательны. Какую из них я предпочел бы создать? Конечно, вторую. Компания, в которой люди чувствуют себя самостоятельными и ответственными за результаты, – вот настоящая цель. Совершенная синхронизация неизбежно губит автономию и ответственность.
Вторая компания – это, в принципе, группа стартапов, каждый из которых обслуживает клиентов и получает доход. Прелесть ситуации заключается в том, что цели каждой команды заставляют их хотеть использовать работу других команд при возможности. Зачем изобретать новую систему сборки или инфраструктуру безопасности, если у другой команды уже есть такой продукт, который отвечает вашим потребностям? Это самый короткий путь к достижению целей – увеличению числа клиентов и росту доходов. Но когда нет чужих решений, удовлетворяющих их потребности, они изобретают собственные. По словам Вернера Фогельса, компания Amazon также предпочитает скорость и не зацикливается на дублировании. «Мы позволяем командам просто делать многое самостоятельно, даже если это дублирует некоторые функции. Мы готовы терпеть положение вещей ради быстрого прогресса в работе», – говорит Фогельс.
Другие компании, в первую очередь Microsoft, занялись было искоренением дублирования, но лишь обнаружили, что это съедает больше ресурсов, чем экономит. Дело в том, что слежение за дублированием и/или трата времени на устранение дублирования означает создание нового уровня контроля, который замедляет все. Искоренение дублирования обычно включает в себя рассмотрение дубликатов, выбор одного из них в качестве победителя, а затем навязывание победителя всем остальным командам.
Позволяя командам при необходимости дублировать работу, вы также позволяете им демонстрировать, куда нужно инвестировать. Это как в старой истории: архитектора просят спроектировать кампус колледжа. На презентации окончательного проекта кампуса руководство колледжа отмечает, что на нем отсутствуют пешеходные дорожки. Что ответил архитектор? «Пусть студенты решают своими ногами, где проложить дорожки. Через год это станет очевидно».
Мы разрешаем нашим командам идти вперед и прокладывать путь. Затем мы – технические лидеры и архитекторы – наблюдаем за тем, что появляется. Когда мы видим, что несколько команд создают похожие вещи, то можем вмешаться, выявить тенденцию и создать команду, которая решит эту проблему для всех и повысит эффективность работы. В этом и заключается суть платформ. Но вместо попыток идеально спланировать работу сверху позвольте командам естественным образом показать вам путь.
В конечном счете многое зависит от компромиссов между тем, что вы хотите получить, и тем, что готовы дать. В этом и заключается суть корпоративной культуры. Какие правила нельзя нарушать, если вы хотите, чтобы сотрудники распоряжались своими талантами по-своему? Корпоративные культуры, которые заходят слишком далеко в ту или иную сторону, не работают, а сбалансированность и компромиссы где-то посередине создают почву для создания инновационной организации.
В Twilio существуют решения, которые обязательны для каждой команды, поскольку они жизненно важны для компании. Команды, например, не могут сами решать, должно быть ПО безопасным или нет, – они обязаны выполнять правило безопасности. Наши клиенты и инвесторы, а также рынок требуют этого, и было бы безответственно отправлять небезопасный код. Так что это обязательно. Теперь команды могут использовать, по выражению Джейсона, готовые «проторенные пути», чтобы как можно проще добиться безопасности. Но пока команды соответствуют нашим требованиям, они могут использовать для защиты своего кода и другие механизмы.
То же самое касается надежности. Мы и наши клиенты требуем как минимум безотказной работы всех наших сервисов на уровне 99,95 %. Это означает не более 43 секунд
