Навигация в золотой лихорадке ИИ: раскрытие скрытых затрат технического долга в корпоративных проектах

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

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

Что такое технический долг?

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

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

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

Как организации накапливают технический долг?

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

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

Дрейф модели: новый тип технического долга

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

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

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

Влияние технического долга на финансовые показатели

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

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

Как решить проблему технического долга

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

Первый метод, ре-платформирование, требует полного пересмотра систем и является огромным и дорогим риском. Аналогично крупномасштабному строительному процессу, любые задержки в графике могут сорвать сроки продукта и могут привести к провалу всей попытки. Однако этот метод может иногда сработать. Возьмите, например, LinkedIn – после их IPO в 2011 году компания заново платформировала сайт и теперь является крупным игроком на рынке.

Более безопасный вариант – внедрение небольших изменений, которые в конечном итоге приведут к значительным улучшениям, – это другой случай, который можно использовать. Поскольку разработчики уже взаимодействуют с данными на ежедневной основе, внесение корректировок может привести к тому, что системы будут очищены от технического долга. Это также приносит пользу навыкам разработчиков, поскольку требует от них оставаться в курсе последних стандартов кода и технологий, что в свою очередь готовит организацию к техническому успеху, поскольку у неё меньше пробелов в навыках. Реализация инициативы, возглавляемой инженерами, когда им выделяется 20% времени для планирования обновлений продукта, – это отличный способ начать. Хотя этот процесс намного медленнее, чем ре-платформирование, он менее рискован и всё равно приносит ценность бизнес-модели.

Оставьте технический долг позади в эру ИИ

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