Клиенты и заинтересованные стороны не хотят сюрпризов
Чего они ожидают — так это ясности, последовательного общения и прозрачности. Они хотят результатов, но также хотят, чтобы вы оставались сосредоточенными на целях проекта в качестве разработчика или менеджера по продуктам. Не менее важно, чтобы они имели полную прозрачность процесса.
В этом сообщении блога я поделюсь практическими принципами и советами, которые помогут поддерживать проекты в сфере искусственного интеллекта (ИИ) в нужном русле. Эти идеи основаны на более чем 15-летнем опыте управления инициативами в области ИИ и являются продолжением моего блога «Советы по установлению ожиданий в проектах ИИ».
При работе с проектами в области ИИ неопределённость — это не просто побочный эффект, она может как сделать инициативу успешной, так и разрушить её.
В разделах блога я включу практические советы, которые вы сможете применить немедленно.
Давайте начнём!
ABU (Always Be Updating)
В продажах существует известное правило под названием ABC — Always Be Closing (Всегда закрывайте сделки). Идея проста: каждое взаимодействие должно приближать клиента к заключению сделки. В проектах ИИ у нас есть другой девиз: ABU (Always Be Updating) (Всегда обновляйте).
Это правило означает именно то, что написано: никогда не оставляйте заинтересованные стороны в неведении. Даже когда прогресса мало или нет, нужно быстро сообщать об этом. Молчание создаёт неопределённость, а неопределённость убивает доверие.
Простой способ применить ABU — отправлять короткое еженедельное электронное письмо каждому заинтересованному лицу. Делайте это последовательно, кратко и сосредоточьтесь на четырёх ключевых моментах:
- Прорывы в производительности или ключевые вехи, достигнутые за неделю;
- Проблемы с результатами или изменения в плане прошлой недели, которые влияют на ожидания заинтересованных сторон;
- Обновления о команде или задействованных ресурсах;
- Текущий прогресс в соответствии с согласованными показателями успеха.
Такой ритм позволяет всем оставаться в курсе событий, не перегружая их шумом. Ключевой вывод заключается в том, что люди на самом деле не ненавидят плохие новости, они просто ненавидят плохие сюрпризы. Если вы будете придерживаться ABU и управлять ожиданиями неделю за неделей, вы завоюете доверие и защитите проект, когда неизбежно возникнут трудности.
Покажите продукт пользователям
В проектах ИИ легко попасть в ловушку, создавая продукт для себя, а не для людей, которые будут его использовать.
Слишком часто я видел, как команды воодушевляются функциями, которые важны для них, но мало что значат для конечного пользователя.
Поэтому не стоит ничего предполагать. Показывайте продукт пользователям как можно чаще и как можно раньше. Реальная обратная связь незаменима.
Практический способ сделать это — использовать лёгкие прототипы или ограниченные пилотные проекты. Даже если продукт далёк от завершения, демонстрация его пользователям поможет вам проверить предположения и расставить приоритеты в функциях.
Начиная проект, определите дату создания прототипа как можно скорее.
Не попадайтесь в технологическую ловушку
Инженеры любят технологии — это часть страсти к своей роли. Но в проектах ИИ технологии — это только средство, а не конечная цель. То, что что-то технически возможно (или выглядит впечатляюще на демонстрации), не означает, что это решает реальные проблемы ваших клиентов или заинтересованных сторон.
Поэтому правило очень простое, хотя и трудное для выполнения: начинайте не с технологий, а с потребностей. Каждая функция или код должны быть связаны с чёткой проблемой пользователя.
Практический способ применить этот принцип — проверять проблемы до поиска решений. Проводите время с клиентами, сопоставляйте их болевые точки и спрашивайте: «Если бы эта технология работала идеально, имела бы она значение для них?»
Бизнес-метрики важнее технических
Легко потеряться в технических метриках — точность, F1-оценка, ROC-AUC, прецизионность, отзывчивость. Клиенты и заинтересованные стороны обычно не заботятся о том, насколько ваша модель точнее на 0,5%, их интересует, сокращает ли она отток клиентов, увеличивает ли доход или экономит время и затраты.
Хуже всего то, что клиенты и заинтересованные стороны часто считают, что технические метрики имеют значение, хотя в бизнес-контексте они редко важны. И ваша задача — убедить их в обратном.
Если ваша модель прогнозирования оттока достигает 92% точности, но маркетинговая команда не может разработать эффективные кампании на основе её результатов, эта метрика ничего не значит. С другой стороны, если «менее точная» модель помогает сократить отток клиентов на 10%, потому что она объяснима, это успех.
Практический способ применить это — определить бизнес-метрики в начале проекта:
- Какова финансовая или операционная цель? (пример: сократить время обработки звонков на 20%)
- Какие технические метрики лучше всего коррелируют с этим результатом?
- Как мы будем сообщать о результатах нетехническим заинтересованным сторонам?
Иногда правильная метрика — это вовсе не точность. Например, в обнаружении мошенничества поймать 70% случаев мошенничества с минимальными ложными срабатываниями может быть более ценным, чем модель, которая выдаёт 90%, но блокирует тысячи законных транзакций.
Владение и передача
Кто владеет решением после его запуска? В случае успеха будет ли у клиента надёжный доступ к нему в любое время? Что произойдёт, когда ваша команда перестанет работать над проектом?
Эти вопросы часто упускаются из виду, но они определяют долгосрочное влияние вашей работы. Вам нужно планировать передачу с первого дня. Это означает документирование процессов, передачу знаний и обеспечение того, чтобы команда клиента могла поддерживать и управлять моделью без вашего постоянного участия.
Внедрение модели машинного обучения — это только половина работы. Пост-деплоймент часто является важным этапом, который теряется в переводе между бизнесом и технологиями.
Видимость затрат и бюджета
Сколько будет стоить запуск решения? Используете ли вы облачную инфраструктуру, LLM или другие технологии, которые несут переменные расходы, о которых клиент должен знать?
С самого начала вы должны предоставить заинтересованным сторонам полную прозрачность по вопросам затрат. Это означает разбивку затрат на инфраструктуру, лицензионных сборов и, особенно в случае с GenAI, расходов на использование, таких как потребление токенов.
Практический способ справиться с этим — настроить чёткие панели мониторинга затрат или оповещения и регулярно просматривать их вместе с клиентом. Для LLM оцените ожидаемое использование токенов в разных сценариях (средний запрос против интенсивного использования), чтобы позже не было сюрпризов.
Клиенты могут принять затраты, но они не примут скрытые или масштабируемые затраты. Прозрачность бюджета позволяет клиентам реалистично планировать масштабирование решения.
Масштабирование
Говоря о масштабировании…
Масштабирование — это совсем другая игра. Это этап, на котором ИИ-решение может принести наибольшую бизнес-ценность, но также и где большинство проектов терпят неудачу. Создание модели в блокноте — это одно, а развёртывание её для обработки реального трафика, данных и пользовательских запросов — совсем другое.
Поэтому чётко определите, как вы будете масштабировать своё решение. Здесь на помощь приходят data engineering и MLOps. Рассмотрите вопросы, связанные с обеспечением надёжности и экономической эффективности всего конвейера (приём данных, обучение модели, развёртывание, мониторинг) при растущем спросе.
Некоторые важные области, которые следует учитывать при общении о масштабировании:
- Практики разработки программного обеспечения: контроль версий, конвейеры CI/CD, контейнеризация и автоматизированное тестирование, чтобы гарантировать, что ваше решение может развиваться без сбоев.
- Возможности MLOps: автоматическое переобучение, мониторинг дрейфа данных и концептуального дрейфа, а также системы оповещения, которые поддерживают точность модели с течением времени.
- Выбор инфраструктуры: облако или локальная инфраструктура, горизонтальное масштабирование, контроль затрат и необходимость специализированного оборудования.
ИИ-решение / проект, который хорошо работает изолированно, недостаточно. Реальная ценность появляется, когда решение может масштабироваться до тысяч пользователей, адаптироваться к новым данным и продолжать приносить бизнес-эффект спустя долгое время после первоначального развёртывания.
Вот практические советы, которые мы видели в этом посте:
- Отправляйте короткое еженедельное электронное письмо всем заинтересованным сторонам с информацией о прорывах, проблемах, обновлениях команды и прогрессе по метрикам.
- Возьмите на себя обязательство создать ранний прототип или пилотный проект, чтобы проверить предположения с конечными пользователями.
- Проверяйте проблемы в первую очередь — не начинайте с технологий, начните с потребностей пользователей. Интервью с пользователями — отличный способ сделать это (если возможно, выйдите из-за своего стола и присоединяйтесь к пользователям во время их работы в течение одного дня).
- Определите бизнес-метрики заранее и привяжите к ним технический прогресс.
- Планируйте передачу с первого дня: документируйте, обучайте команду клиента и обеспечьте чёткость владения.
- Настройте панель мониторинга или оповещения для отслеживания затрат (особенно для облачных решений и решений на основе токенов GenAI).
- Стройте с учётом масштабируемости: CI/CD, мониторинг дрейфа, модульные конвейеры и инфраструктура, которая может расти.