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

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

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

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

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

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

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

«В будущем платформы позволят разработчикам думать только о функциях и клиентах, а не о базовых системах, которые необходимы для превращения программ из задумки в облачное приложение, доступное клиенту», – утверждает Джейсон.

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

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

Эпилог

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

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

Другими словами, спросите своего разработчика.

Когда я заканчивал работу над книгой, произошло нечто, сделавшее эту трансформацию еще более насущной. Пандемия коронавируса, разразившаяся в начале 2020 г., заставила мир перестроиться: города закрывались, дети учились дома, компании отправляли работников домой, больницы захлебывались от пациентов… Проекты цифровой трансформации, которые планировалось осуществить за несколько лет, внезапно стали реализовываться в течение нескольких дней или недель. Это было великое цифровое ускорение, вызванное не выбором, а жизненной необходимостью. Из-за снижения экономической активности реализация принципа «Создать или умереть» стала жизненной необходимостью для компаний во многих отраслях.

К счастью, разработчики сумели претворить этот принцип в жизнь. Всего за несколько недель в марте и апреле 2020 г. многие отрасли осуществили более масштабную цифровую