Внедрение искусственного интеллекта без четких целей по повышению производительности может принести лишь незначительную пользу процессу разработки ПО в организации, пишет на портале The New Stack Эмилио Сальвадор, вице-президент GitLab по связям с разработчиками и сообществом.

Организации с понятным воодушевлением воспринимают потенциал ИИ-помощников по кодированию для повышения производительности разработчиков. В ходе недавнего опроса, проведенного GitLab, 83% респондентов заявили, что внедрение ИИ в процессы разработки ПО необходимо, чтобы избежать отставания.

Обещание, что ИИ может автоматизировать большую часть разработки ПО или, по крайней мере, сделать разработчиков значительно более продуктивными, поднимает вопрос о том, как собственно измеряется производительность разработчиков. Подсказка: дело не в объеме кода.

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

Задачи: обманчивое измерение

Измерение выполнения задач отражает наиболее прямой показатель индивидуальной производительности разработчика — эффективное выполнение поставленной задачи в установленные сроки. Однако, несмотря на кажущуюся простоту, измерение выполнения задач в качестве показателя производительности может быть ошибочным по двум причинам.

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

Во-вторых, выполнение большего количества задач не всегда является самым разумным способом решения проблемы. Так, менее квалифицированные программисты или ИИ-помощники по кодированию могут создавать большое количество шаблонного кода. Например, в одном недавнем исследовании разработчики смогли с помощью ИИ закончить кодирование веб-сервера на JavaScript на 90 минут быстрее. Это впечатляющий результат, но они могли бы использовать существующую абстракцию веб-сервера для получения такого же результата за несколько минут.

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

Индивидуальная эффективность разработчика, требующая сочетания технических навыков, критического мышления и креативности, является более оптимальной метрикой, чем количество выполненных задач. В одном известном примере Билл Аткинсон, главный дизайнер и разработчик графического пользовательского интерфейса компьютера Lisa компании Apple, оптимизировал процедуру вычисления областей в Quickdraw, чтобы сделать ее в 6 раз быстрее и на 2000 строк кода короче. Его вклад опроверг принятую в Apple метрику производительности, которая заключалась в отслеживании отдельных инженеров по количеству кода, который они пишут каждую неделю, в пользу более простого, быстрого и эффективного решения.

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

Время: измерение скорости

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

Временные метрики — это объективное измерение. В системе Google для измерения производительности разработчиков, созданной группой DevOps Research and Assessment (DORA), три из четырех показателей напрямую зависят от времени:

  • частота развертывания (часы/дни/недели/месяцы);
  • время выполнения изменений;
  • время восстановления сервиса.

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

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

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

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

Команда: измерение, ориентированное на человека

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

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

Еще одна система метрик — SPACE (satisfaction, performance, activity, communication, efficiency — удовлетворенность, производительность, активность, коммуникация и эффективность). Она была разработана для того, чтобы отразить некоторые из более тонких и ориентированных на человека аспектов производительности. Показатели SPACE в сочетании с показателями DORA могут восполнить пробелы в измерении производительности, соотнеся показатели продуктивности с бизнес-результатами.

McKinsey обнаружила, что сочетание метрик DORA и SPACE с метриками, ориентированными на возможности, позволяет получить всестороннее представление о производительности труда разработчиков. Это, в свою очередь, может привести к положительным результатам, которые приводит McKinsey: 20-30%-ное сокращение количества дефектов продукта, о которых сообщают клиенты, 20%-ное улучшение показателей опыта сотрудников и 60%-ное улучшение показателя удовлетворенности клиентов.

Что вы пытаетесь оптимизировать?

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

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

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