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

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

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

В Twilio существуют решения, которые обязательны для каждой команды, поскольку они жизненно важны для компании. Команды, например, не могут сами решать, должно быть ПО безопасным или нет, – они обязаны выполнять правило безопасности. Наши клиенты и инвесторы, а также рынок требуют этого, и было бы безответственно отправлять небезопасный код. Так что это обязательно. Теперь команды могут использовать, по выражению Джейсона, готовые «проторенные пути», чтобы как можно проще добиться безопасности. Но пока команды соответствуют нашим требованиям, они могут использовать для защиты своего кода и другие механизмы.

То же самое касается надежности. Мы и наши клиенты требуем как минимум безотказной работы всех наших сервисов на уровне 99,95 %. Это означает не более 43 секунд простоя в день. Самый простой способ достичь этой строгой цели – полагаться на инфраструктуру, платформы и методы, которые мы разработали для внутреннего пользования. Но если у команды есть уникальное требование или способ, который они считают лучшим и могут доказать это, то они вправе пойти своим путем. Но они по-прежнему несут ответственность за время безотказной работы. Понятно, что у команды должен быть очень сильный мотив для принятия такого решения. Но это иногда приводит и к серьезным инновациям! Только представьте, что команда создает программу, которая помогает повысить безотказность до 99,999 %, т. е. допускает всего 26 секунд простоя в месяц! Держу пари, что другие команды тоже захотят воспользоваться ею! На самом деле мы уже близки к этому показателю – немного соперничества нередко приводит к отличным результатам.

Принять трудное решение

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

Вот пример. В 2018 г. нашим разработчикам потребовалось 40 дней, чтобы разработать новый Java-сервис. Мы хотели ускорить процесс. Теоретически можно нанять вдвое больше инженеров, и они будут создавать вдвое больше сервисов в год, так ведь? (На самом деле удвоение числа разработчиков не удвоит производительность, но ради аргументации давайте представим, что это так.) Но это означало бы прием на работу сотен новых разработчиков. Вместо этого Джейсон с двумя платформенными инженерами автоматизировал массу этапов нашего процесса разработки. С их помощью время разработки сократилось вдвое – с 40 до 20 дней. Эффект усиливается еще и в результате того, что мы разрабатываем около 200 новых Java-сервисов в год. Да, мы потратили деньги на этих двух платформенных инженеров. Но их работа экономит нам 4000 человеко-дней в год. Это аргумент в пользу вложения денег в инфраструктуру, а не в увеличение числа разработчиков продукта. Вместо того чтобы концентрировать внимание на том, сколько стоит создание платформенной команды, думайте об отдаче, которую она может принести. Однако не забывайте, что эти инвестиции окупятся не сразу. Мало того, что нужно сформировать команду и создать инфраструктуру – другие команды должны принять ее. Этот процесс требует времени, но он полностью окупается. Такой подход реально становится источником конкурентного преимущества.

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

Но какими бы огромными ни были наши достижения, мы полагаем, что платформа может еще больше повысить скорость работы. Джейсон хочет, чтобы процесс развертывания Java, сокращенный с 40 до 20 дней, занимал один день или даже всего несколько часов. Одна из его 13 команд полностью занята оптимизацией самой платформы. Она изучает, как разработчики используют продукт, выясняет, где разработчики испытывают трудности или замедляются, и устраняет проблемы. Чтобы измерить время, которое разработчики тратят на возню с инструментами, Джейсон создал показатель под названием «Время, проведенное вне кода». Он, возможно, никогда у нас не достигнет нуля, но цель состоит в максимальном приближении к нулевому уровню.