Новый отчет CircleCI «2025 State of Software Delivery» показывает, что лучшие инженерные команды увеличивают скорость разработки в три раза и экономят миллионы на расходах благодаря оптимизации рабочих процессов и внедрению искусственного интеллекта, сообщает портал The New Stack.
По словам Роба Зубера, технического директора поставщика CI/CD-платформы CircleCI, среди лидеров в области разработки ПО существует странное противоречие, касающееся производительности. Им приходится соизмерять удовольствие от создания продуктов, которыми могут пользоваться другие компании, с необходимостью убедиться, что это делается так, чтобы принести пользу их собственному бизнесу.
«Большинство инженерных руководителей росли как инженеры и ценят личное вознаграждение и удовлетворение от действительно продуктивной работы, потому что никому не нравится „пахать“, возиться с инструментами и прочими вещами, — говорит Зубер. — Им нравится создавать продукт. Неважно, занимаются ли они масштабированием бэкэнд-систем, ставят ли фронтенды для клиентов или делают что-то еще, — инженеры действительно ценят именно это».
Но когда дело доходит до оценки их труда, у инженеров возникает «своего рода странная аллергическая реакция», им кажется, что их постоянно «измеряют», отмечает он. Организациям необходимо решить эту проблему, поскольку руководители инженерных подразделений и другие руководители сталкиваются с необходимостью сравнивать две вещи: достаточно ли хорошо с точки зрения эффективности то, что они получают, и достаточно ли быстро они продвигаются вперед по сравнению со своими коллегами.
Важность показателя окупаемости инвестиций
Именно по этой причине компания CircleCI в своем исследовании использует расширенный подход. В шестом ежегодном выпуске отчета по-прежнему рассматриваются ключевые показатели, используемые для определения производительности — продолжительность рабочего процесса, пропускная способность, среднее время восстановления (MTTR) и коэффициент успешности (расшифровку этих показателей см. ниже), — но исследователи также измеряют окупаемость инвестиций, которая связана с ростом производительности и которая является ключевым инструментом измерения для бизнес-руководителей и заинтересованных сторон.
Этот показатель также становится все более важным по мере того, как ИИ проникает практически на все уровни разработки ПО, а также по мере того, как растет его присутствие во всех других аспектах ИТ и бизнеса. «Безусловно, ИИ оказывает влияние на нашу способность выполнять задачи, и нам важно знать, добиваемся ли мы успеха? Идем ли мы в ногу с конкурентами? — говорит Зубер. — Такие вопросы волнуют инженерных руководителей, и мы хотим предоставить им как можно больше информации, чтобы они могли понять, где находятся и на что могут направить свои усилия».
Отчет основан на анализе почти 15 млн. рабочих процессов команд, создающих ПО на платформе CircleCI. В нем также рассматривается значение для создания ПО таких передовых технологий, как автоматизация CI/CD, инфраструктура как код (IaC) и ИИ.
Скорость — это ключ
Выводы на высшем уровне свидетельствуют о том, что 25% лучших команд продолжают отделяться от остальных, во многом благодаря скорости. Например, они отправляли обновления в три раза быстрее, чем команды из нижних 25%, что дает им преимущество на рынке по скорости разработки.
Они сэкономили миллионы на ежегодных затратах на разработку, опять же благодаря скорости: выполняли критически важные рабочие процессы в пять раз быстрее, чем менее эффективные подразделения, что высвобождало ресурсы для стратегических инициатив, и отлаживали продукты за минуты, а не за дни, высвобождая больше времени разработчиков.
«На протяжении многих лет мы не перестаем повторять, что скорость обеспечивает преимущество на рынке, но она зависит от качества систем, процессов и подходов», — говорит Зубер.
Именно здесь на помощь приходят передовые технологии — в частности, ИИ и автоматизация. Они повышают скорость разработки ПО, и те организации, которые находятся на вершине рейтинга, адаптируются к быстро меняющемуся характеру разработки и обеспечивают ценность для своих пользователей.
«Исторически сложилось так, что нам всегда приходилось выбирать между скоростью и качеством, и наконец-то стало ясно, что скорость — это то, что неразрывно связано с качеством, потому что вы просто не сможете делать что-то быстро, если не будете действительно хороши в обеспечении качества», — говорит Зубер.
Другие показатели
Однако он предупреждает, что это не единственный показатель. Команда разработчиков может быстро выпускать продукты, но это не принесет пользы, если продукт дефектный или если организация медленно исправляет ошибки. В этом случае важны другие показатели, от продолжительности рабочего процесса до скорости восстановления и коэффициента успешности.
Цель исследования — предоставить разработчикам и руководителям команд подробную информацию, которую они смогут проанализировать с учетом всех нюансов. По словам Зубера, полученные данные позволяют людям лучше увидеть себя на фоне других и сказать: «О, эта смесь показателей немного похожа на нас. О чем это говорит? У нас все получается быстро, пока... что-то не сломается, и тогда нам требуется очень много времени, чтобы это исправить. Это потому, что наши системы сложны? Говорит ли это о нашей культуре?». Вопросы могут возникать по поводу множества разных вещей. И задавать вопросы должны и команды, и руководители.
Оценка окупаемости инвестиций
Данные исследования включают в себя показатели рентабельности инвестиций. В отчете исследователи оценивают его на примере вымышленной компании под названием «RecurShip», состоящей из 500 разработчиков по всему миру, которые отвечают за три фиксации в неделю — обновления и оптимизацию — и которым платят 180 000 долл., или 1,50 долл. за минуту работы разработчика.
Продолжительность — время с момента запуска рабочего процесса до завершения всех его этапов — является важным показателем. Данные отчета показывают, что средняя продолжительность составляет 2 минуты 43 секунды, при этом 25% команд завершают свои рабочие процессы менее чем за 38 секунд. Остальные 75% завершают процессы за 8 минут или менее. Самые короткие сроки могут быть результатом более легких рабочих процессов с меньшим количеством шагов проверки или других факторов. Однако у некоторых команд время выполнения работ составляет 25 минут и более.
Применительно к RecurShip оптимизация рабочего процесса и сокращение времени выполнения работ с 20 до 10 минут позволили бы компании высвободить 750 000 минут времени разработчиков в год, что при цене 1,50 долл. за минуту означает 1,1 млн. долл. в год прироста производительности.
Другой показатель — пропускная способность, которая измеряет среднее количество запусков рабочего процесса в проекте в день. В проектах, работающих на платформе CircleCI, средняя пропускная способность составляет 1,64 прогона в день, а у 25% разработчиков она достигает 2,7. Среди 20 наиболее продуктивных организаций ежедневная пропускная способность достигает 3762. «Дельта между средними и лучшими показателями что говорит о значительном неиспользованном потенциале большинства команд разработчиков ПО», — говорится в отчете.
В RecurShip добавление к 500 разработчикам (выполняющим 300 рабочих нагрузок в день, или 0,6 на одного разработчика) 25 инженеров, занимающихся устранением трения в конвейерах разработки, увеличило бы пропускную способность до 394 ежедневных рабочих процессов, или 0,75 на одного разработчика в день.
При увеличении численности персонала на 5% компания получит 25%-ное повышение производительности на одного разработчика, что равносильно добавлению 156 штатных разработчиков. Эти инвестиции в оптимизацию и улучшение опыта разработчиков принесли бы компании 28,4 млн. долл. в виде прироста производительности.
ИИ принесет надежды и перемены
Потребность в скорости будет только возрастать по мере того, как ИИ и автоматизация будут становиться все более распространенными. Инженеры и разработчики понимают, что новые инструменты, используемые для создания ПО, изменят их работу, создав много неопределенности. Учитывая это, задача руководителей инженерных подразделений заключается не столько в предсказании будущего с ИИ, сколько в создании команд, которые смогут адаптироваться к изменениям, когда они наступят.
«Нужно уметь быстро адаптироваться к ИИ, поэтому это помогает нам думать о том, как мы строим, как мы поставляем системы, которые мы создаем, — говорит Зубер. — С этим сейчас сталкиваются все».
По его словам, людям очень важно подумать о том, как подготовиться к множеству возможных исходов и быть готовым к адаптации и перестройке, потому что именно такие люди действительно добьются успеха. «Фактор успеха в условиях неопределенности — это гибкость, и если вы не думаете о том, как эффективно доставлять ПО и как собирать обратную связь, то вы не настроены на такой уровень изменений», — отмечает Зубер.
Стратегии, большие и малые
Тем временем CircleCI определила шаги, которые компании могут предпринять уже сейчас, чтобы стать быстрее и эффективнее в разработке и доставке ПО. Небольшим компаниям необходимо создавать отказоустойчивые конвейеры, которые могут работать автономно, когда их команды заняты другими задачами, а также снизить нагрузку по отладке ПО, инвестируя в автоматизированное тестирование.
Для компаний среднего размера задача состоит в том, чтобы поддерживать быстрое восстановление, стандартизировать процессы и распространить по всей организации практику, используемую командами, демонстрирующими высокую производительностью. Более крупным организациям необходимо упорядочить управление изменениями и потоки их утверждения, а также сбалансировать оптимизацию скорости сборки с процессами, масштабируемыми на все бизнес-подразделения, пишут авторы отчета.
Размер (команды) имеет значение
Кроме того, всем компаниям следует обратить внимание на размер своих команд.
«Маленькие команды, как правило, работают быстро и с меньшими затратами на координацию, в то время как большие команды должны ориентироваться в зависимостях, стандартизации и сложности процессов по мере их масштабирования, — пишут авторы. — Понимание этих компромиссов — ключ к оптимизации скорости и надежности разработки».
Рекомендуемые стратегии включают создание автономных команд разработчиков, состоящих из
По словам Зубера, компании с
