Только 10% рабочего времени разработчика уходит на написание нового кода, поэтому сосредоточьте свои усилия на сокращении узких мест в других областях, пишет на портале The New Stack Сурадж Шах, директор по контент-маркетингу компании Port.

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

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

А как же все остальное время? Остальные 90% времени разработчиков приходится на управление существующим кодом (30%), а также на задачи, не связанные с написанием кода, такие как дизайн, архитектура, планирование проекта и документирование. И в рамках этого большого куска времени есть много возможностей для сокращения узких мест.

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

1. Метрики разбросаны по самым разным местам

Несмотря на то, что существующие фреймворки, такие как DORA и SPACE, часто предоставляются на платформах для интеллектуальной разработки ПО и предлагают ценные инсайты о производительности, они не рассказывают всей истории и часто ограничиваются рудиментарными показателями, взятыми из Jira и инструментов контроля исходного кода. Например, основанные на стандартах показатели инженерной деятельности помогают руководителям следить за расходами, уязвимостями в системе безопасности, соблюдением SLO (соглашения об уровне обслуживания), владением, документированием, внедрением новых инструментов или практик, готовностью к производству и многим другим.

Кроме того, существует множество других инженерных показателей, которые могут служить косвенными метриками для DORA, но они разрознены по многим инструментам, используемым в жизненном цикле разработки ПО (SDLC). Они не унифицированы и не собраны в одном месте. Хотя каждый из них может дать ценные инсайты, попытка консолидировать, отследить и осмыслить их может оказаться сложной. И часто такое отношение к консолидации говорит о том, что инженерные команды не доверяют данным.

Отсутствие интеграции по всем метрикам означает, что, хотя вы и видите ваш уровень отказов при изменениях или среднее время восстановления (MTTR), вы не сможете понять причину этого, а значит, вам будет сложно внести коррективы.

2. Добавление настроения в набор

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

Отчасти это связано с тем, что системные данные необходимо очистить, прежде чем использовать их. Измерение времени CI-сборки на основе данных конвейера звучит просто, но организациям все равно приходится фильтровать фоновые задачи и делать поправку на параллельность, прежде чем они смогут получить надежные метрики. Системные показатели также не отражают человеческую сторону инженерной работы. Например, не дают понимания, удается ли разработчикам оставаться в состоянии потока, чтобы они могли выполнять работу, которая важнее всего.

Традиционные инженерные метрики также можно обмануть. Например, улучшение показателя частоты развертывания может побудить команды подтасовывать данные, развертывая простые и малозначимые изменения или разбивая крупные обновления на более мелкие и менее значимые только для того, чтобы увеличить количество развертываний, а не сосредоточиться на предоставлении реальной ценности или повышении стабильности.

Один из подходов к заполнению этих пробелов — опросы. Опросы помогут вам понять моральное состояние команды, степень удовлетворенности и точки трения, которые не отображаются в системных данных. В то время как метрики дают вам «что», опросы помогают ответить на вопросы «почему», а иногда и «как».

Руководители инженерных подразделений могут подумать, что платформа для опроса разработчиков решит эту проблему, и есть несколько отличных вариантов, но они обычно не интегрируются со всеми инструментами, с которыми работают разработчики (например, Microsoft Azure DevOps).

Кроме того, эти инструменты часто имеют крутую кривую обучения, требующую дополнительного времени и ресурсов для эффективного использования. Использование специализированной платформы также добавляет еще один инструмент в микс для инженеров, которые уже используют в среднем 7,4 инструмента для повседневных рабочих задач. Разрастание инструментов для разработчиков приводит к тому, что 75% разработчиков теряют от 6 до 15 часов в неделю.

Источник: Port

3. Использование метрик для реальных улучшений

Если у вас уже есть метрики, вам все равно нужно понимать их смысл для вашей организации. Но, скорее всего, вам придется ответить на несколько сложных вопросов:

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

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

Как преодолеть эти узкие места

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

Источник: Port

Например, на портале вы сможете увидеть взаимосвязи между всеми следующими факторами:

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

Портал также может предоставить дополнительный контекст: например, вызвало ли ваше недавнее развертывание отмеченный всплеск инцидентов?

Чтобы лучше понять, можно провести предварительный опрос, особенно такой, который можно настраивать и распространять на портале:

  • Отвлекаются ли инженеры от выполнения задач, предусмотренных дорожной картой, включая развертывание, поскольку им приходится сосредоточиться на управлении инцидентами?
  • Сколько времени это отбирает у кодирования?
  • Какие действия вызывают особую потерю времени?

Используя комбинацию метрик и данных о настроениях, вы можете разработать план по улучшению подхода к управлению инцидентами, например:

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

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

С помощью специальной панели на портале можно отслеживать, насколько эти усовершенствования и автоматизация влияют на MTTR и частоту развертывания.

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

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