Я больше не верю в организации, которые внедряют ИИ для ускорения разработки ПО, пишет на портале The New Stack Стив Фентон, специалист по работе с сообществом Octopus Deploy.
В юности у меня был метис лабрадора и уиппета по кличке Баркли. Мы делали почти всё вместе. Если я копал яму в саду, он тут же начинал её обнюхивать. Если я читал книгу, он ложился мне на колени, пока у меня не начинало неметь всё тело. Когда мы с семьёй гуляли в лесу, он разведывал местность и мчался обратно, чтобы проверить нас, в возбуждении пробегая в десять раз большее расстояние, чем мы проходили.
Одно из лучших качеств собак — это то, что с ними можно поговорить, когда тяжело. Они отличные слушатели и понимают вас, когда никто другой не понимает.
Если бы я завёл ещё одну собаку, главной причиной была бы ее роль компаньона. Есть много других причин завести собаку, но для меня это главная.
Теперь представьте, что я пришел в приют для животных и попросил показать мне их собак, а они захотели, чтобы я забрал домой гепарда, потому что он намного быстрее собаки. Вот что я слышу, когда организация заявляет о внедрении ИИ с близоруким упором на скорость.
Скорость — не цель и никогда ею не была
Мы уже проходили это. Нам всем следует сожалеть о том, что от движения Agile осталась лишь сухая шелуха, предлагающая только «скорость». Скорость никогда не была целью. Главная причина повышения производительности — получение обратной связи как можно раньше.
Когда вы обнаруживаете, что ваша потрясающая новая функция не вызывает восторга у пользователей, вы можете сразу же прекратить работу над ней. Вы потратите гораздо меньше ресурсов, если сможете остановить плохую идею на ранней стадии и сразу же перейти к лучшей идее. Никому не стоит пытаться создавать ПО с наибольшим количеством функций и самой быстрой скоростью изменений. Когда у вас слишком много функций, и все постоянно меняется, чтобы соответствовать постоянно расширяющемуся списку того, что делает ваше ПО, люди начинают ненавидеть то, что вы создали.
Microsoft Word — самый мощный и многофункциональный текстовый редактор на сегодняшний день, но им уже мало кто пользуется. Вместо него используют Google Docs, у которого гораздо меньше функций. Это означает, что выбранные Google функции оказались более привлекательными или же меньшее количество функций делает ПО проще в использовании. В действительности, все определяет сочетание множества мелких факторов, подобных этим. Иногда одна действительно привлекательная функция затмевает все остальные, и простота совместной работы над документом Google Docs в веб-браузере, возможно, была именно такой.
Если бы вы спросили кого-нибудь двадцать лет назад, вам бы сказали, что Microsoft Word является неоспоримым лидером в своей категории, но сейчас, по данным 6sense, его доля на рынке составляет 3,9%, по сравнению с 9,6% у Google Docs. Если вы считаете, что этот сдвиг на рынке — исключительно вопрос ценообразования, вы, вероятно, работаете в организации, которая стремится только к высокой скорости, потому что вы уже перестали верить в идею создания ПО, которое ценят пользователи.
Внедрение ИИ для ускорения не внушает доверия
У лидеров в сфере разработки ПО накоплен немалый опыт, и это следует учитывать, когда они заявляют о внедрении ИИ для ускорения работы. Очень часто за последние десять-двадцать лет они объявляли о трансформации в сторону Agile для ускорения работы, внедряли DevOps для ускорения работы и запускали инициативы по созданию платформ для ускорения работы.
Тот факт, что они исчерпали все эти инициативы, не добившись значительных результатов, является убедительным свидетельством того, что скорость им не так уж и нужна, как они утверждают. Конечно, они хотят добавить в свою послужную запись титул «DORA Elite Performance». Тем не менее, у них нет реальной причины работать быстрее, потому что они не заинтересованы в таком фундаментальном результате более частых поставок, как обратная связь.
Любой руководитель, который столько раз подвергал свои команды испытаниям во имя скорости и теперь заявляет, что ИИ наконец-то принесет ее, заблуждается.
Метроном обратной связи
Когда обратная связь важна для вас больше, чем скорость, вы позволяете циклу обратной связи задавать темп всего процесса разработки ПО. Настройка этого темпа дает вам необходимое пространство для обработки обратной связи и выполнения того, чего требует от вас Agile, — быстрого изменения направления.
Организации и команды, которые используют обратную связь в качестве метронома, задающего ритм всему оркестру, скорее всего, будут искать и устранять работу, нарушающую ритм. Они создают команды для выполнения работы с минимальными (и хорошо продуманными) зависимостями. Они упрощают процедуру утверждения изменений. Они следят за тем, чтобы команды могли решать, когда нажать на кнопку для развертывания их ПО, и чтобы они могли наблюдать за тем, что происходит, когда они это делают.
Модель DORA с ее генеративной культурой, трансформационным лидерством, бережливым управлением продуктом и процессом непрерывной доставки не была создана случайно. Это результат десятилетий работы. Команды, применяющие эти концепции, обладают скоростью, но не поэтому они принимают эту культуру и практики. Им нужна частая высококачественная обратная связь, чтобы они могли обнаруживать, что действительно нужно создавать.
Практический пример
В одной крупной медицинской компании была сильная команда разработчиков ПО. Организация предоставляла ПО для управления пациентами и экстренной сортировки. В критически важных с точки зрения безопасности отраслях результат работы этого ПО действительно мог означать жизнь или смерть.
Они выпускали свою систему управления пациентами раз в шесть месяцев, а цикл тестирования их системы поддержки принятия решений составлял две недели, плюс еще две недели, если обнаруживалась проблема. И так до тех пор, пока версия не проходила проверку!
Несмотря на эту историю, в этой компании удалось в течение шести месяцев развернуть программу работы, которая создавала развертываемую версию ПО каждые три часа. Развертывание следовало набору очень строгих технических практик, но то, что было удалено, вероятно, было важнее того, что было добавлено. При этом удалось достичь баланса, реализовав подход к определению требований к ПО, при котором требования формулируются через конкретные примеры, а затем преобразуются в исполняемые спецификации и автоматизированные тесты, и устранив бюрократические этапы проверки, которые были медленными и малоэффективными.
Если ваша организация не пересмотрит путь к внедрению в производство и не внесет аналогичные изменения, ничто не обеспечит желаемой скорости. Вы внедрите ИИ, как и Scrum, DevOps и Platform Engineering, и это не принесет никаких результатов, как и прежде.
Самое важное, что вы можете сделать прямо сейчас, — это составить карту потока создания ценности, особенно от фиксации кода до развертывания в производственной среде, и начать исправлять неисправные части. Нет никакого секрета в том, что нужно изменить. Дейв Фарли и Джез Хамбл раскрыли его в своей книге «Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation».
Зачем вы внедряете ИИ?
Возможно, вы думаете, что внедряете ИИ, чтобы ускорить процесс. Если вы всерьез занимаетесь разработкой ПО, я надеюсь, вы скорректируете свой ответ и дадите понять окружающим, что частая обратная связь и гибкость принятия решений занимают важное место в вашем списке приоритетов.
Команды, которые уже решили проблему компромисса между производительностью и стабильностью с помощью таких практик, как непрерывная доставка, будут меньше тяготеть к скорости. Они с большей вероятностью будут искать более ценные возможности. В заключение я хотел бы предложить пару таких моментов.
Небольшие команды лучше. Мы идем на компромисс в этом вопросе, потому что нам нужно все быстрее, чем может справиться очень маленькая команда. Мы можем удвоить размер команды, даже зная, что это не сократит время вдвое. В модели COCOMO (COnstructive COst MOdel) есть сложный расчет этого убывающего эффекта, хотя Фред Брукс выразил это более запоминающимся образом: добавление людей в опаздывающий проект отдаляет срок его завершения.
В результате большинство команд разработчиков ПО, которые понимают сложность коммуникации и координации, попадают в диапазон
Небольшие команды с высокой степенью автономии, работающие над слабо связанным компонентом, могут стать мощным инструментом для раскрытия ценности разработки ПО с помощью ИИ.
Мое последнее заключение состоит в том, что вместо того, чтобы создавать то же самое ПО быстрее, ИИ может позволить вашим командам создавать более амбициозные программы. Вы могли бы заняться той работой по глобализации, которую всегда не решались начать. У вас может быть идея функции, которую всегда было невозможно достаточно четко определить, и прототип ИИ позволит провести исследование, которое вы не могли предпринять раньше.
В любом случае, начните с более агрессивного улучшения процесса разработки ПО и конвейеров развертывания. Убедитесь, что вы подключили обратную связь и используете ее как метроном для установки ритма. После того, как вы это сделаете, вы будете стремиться к чему-то более креативному, чем «скорость» благодаря внедрения ИИ.
