Miro Reframe: от идеи до готовой к разработке истории с Джошем Гайсом
Джош Гайс, технический директор по работе с клиентами в Liatrio, говорит, что обычно уже через несколько первых разговоров понимает, действительно ли внедрение ИИ у клиента работает. Два или три человека тихо делают с его помощью что-то впечатляющее. Все остальные застряли, тратя на борьбу с инструментами больше времени, чем они раньше тратили на работу, которую эти инструменты должны были заменить.
Он сравнивает это с установкой новой видеокарты в старую материнскую плату. Сама карта в порядке. «Эта видеокарта больше не подходит к вашей материнской плате», — говорит он, и никакое ускорение за счет ИИ внутри неизменной команды не изменит результат, который эта команда выдает.
Гайс потратил два десятилетия на то, чтобы заранее приходить к следующему этапу: DevOps до того, как у него появилось название, облачные технологии до того, как они стали стандартом, а теперь — ИИ на полную ставку. В Liatrio, консалтинговой компании из 200 человек, которая большую часть времени помогает крупным предприятиям действовать больше как «стартап, который вот-вот их вытеснит», он профессионально работает именно в этом разрыве между внедренным ИИ и ИИ, который действительно изменил способ выполнения работы. Он советует клиентам исправлять размер команды и спецификации, а не модель.
Паттерн, который он постоянно находит
На почти каждом проекте проявляются три признака:
- Команда и структура организации остаются совершенно нетронутыми,
- Внедрение сосредоточено в руках нескольких человек, и
- «Внедрение» ИИ якобы присутствует, но скорость выпуска продукта не улучшилась.
Структура команды и архитектура программного обеспечения, как отмечает Гайс, имеют тенденцию отражать друг друга, поэтому организация, которая никогда не переосмысливает форму своей команды, обычно не может переосмыслить и форму своего продукта.
Есть доказательства того, что это характерно не только для списка клиентов Liatrio. Последнее исследование McKinsey о состоянии ИИ показало, что использование ИИ на предприятиях достигает 88%, но только 37% компаний смогли указать на какое-либо измеримое влияние на прибыль. Фактором, который наиболее четко разделял эти две группы, было то, переработали ли они рабочий процесс, а не то, сколько они потратили на сами инструменты.
Для консультантов и агентств это палка о двух концах. Это то, что многие ваши клиенты втайне пытаются вернуть: ощущение небольшой, энергичной команды, которое у них было до того, как они масштабировались до нынешнего состояния. Велика вероятность, что тот же паттерн существует и внутри ваших собственных команд доставки: пара человек значительно продвинулись в использовании ИИ, в то время как остальная часть фирмы почти не сдвинулась с места.
Насколько маленькой должна быть команда
Если надавить на Гайса с цифрами, его ответ будет меньше, чем ожидают большинство людей: максимум 3–5 человек, которые полностью отвечают за один реальный поток создания ценности. Переосмысление размера команды вместе со структурой организации открывает возможности, которые никогда не даст просто установка более совершенных инструментов. Пилотному проекту не обязательно быть успешным, чтобы его стоило запускать. Если он дает знания о том, как нужно сформировать команду или процесс, то это не пустая трата усилий.
То, что делает такую маленькую команду работоспособной на этапе разработки, — это то, что Гайс называет разработкой на основе спецификаций. Этот подход требует написания четкого, подробного плана перед написанием любого кода. Это позволяет всем быть на одной волне, чтобы разработчики не создавали не то, что нужно, а также помогает ИИ избежать догадок и иметь более четкое определение готовности. Он продемонстрировал это на намеренно негламурном примере: небольшая ветеринарная клиника Emerald Grove хочет принимать платежи онлайн.
Владелец продукта берет расшифровку встречи, а затем формирует результаты проекта и необходимые требования. Затем это сопоставляется с другими контекстно-зависимыми источниками информации, такими как Confluence (для базы знаний/вики), Jira (для отслеживания работы) и Github (для контроля исходного кода), чтобы составить контекстный бриф — резюме, которое цитирует свои источники построчно, а не просто делает утверждения. На протяжении всего процесса ИИ помогает консолидировать и структурировать информацию в нечто понятное для команды.
Для Emerald Grove это означало обнаружение старого, отложенного пулл-реквеста, комментарии к которому стали единственной реальной записью о том, почему данные карт никогда не должны попадать в собственные системы клиники, плюс фирменный зеленый цвет, который технически не проходит по правилам контрастности на песочном фоне, на котором он должен располагаться. Любой член команды, инженер или нет, может вернуться и проверить каждую строку на соответствие источнику.
Оттуда она собирает то, что Гайс называет прототипом «из картона и скотча», грубым, но рабочим, и делится им в тот же день. Коллеги ломают его в течение часа: кто-то замечает отсутствие детализированного итога, кто-то другой указывает на состояние платежа, которое никогда не озвучивается для программы чтения с экрана. Каждое исправление превращается в сценарий Gherkin, достаточно точный, чтобы инженер мог строить прямо по нему, а набор тестов мог проверять его автоматически.
Гайс перестроил весь этот поток внутри Miro, используя Flows и Sidekicks: поместив базу знаний во фрейм и запустив один промпт, чтобы получить нечто близкое к тому же брифу, и Kanban-карточку, несущую свои собственные сценарии.
Однако анекдот, который запомнился больше всего, был не совсем об инструментах. У одного из клиентов Liatrio в области генетики есть нетехнический владелец продукта, которая чувствовала, что отстает от своей инженерной команды, для которой, собственно, и предназначалось внедрение ИИ в компании. Она чувствовала себя застрявшей и брошенной и попросила Гайса о помощи 1:1. Через несколько сессий она создала свою собственную панель прогнозирования и валидации на основе системы отслеживания работы компании, используя ИИ для выполнения технически сложной работы по сбору исторических данных, в то время как она сама принимала решения о том, когда должны происходить важные релизы. В итоге это стало отчетом для технического директора.
Такая поддержка в безопасной среде и обмен знаниями бесценны, когда вы пытаетесь вовлечь всех в процесс внедрения ИИ — независимо от их скептицизма, технических знаний или уровня уверенности.
Три вещи, которые стоит попробовать, согласно полевым заметкам Liatrio
Запустите пилотную минимальную команду на одном реальном потоке создания ценности.
Максимум 3–5 человек, владеющих одним сегментом работы от начала до конца, а не комитет, консультирующий со стороны. Выберите что-то достаточно узкое, чтобы команда могла действительно это изменить. Если пилотный проект не удался, определите первопричину (например, структура, процесс или что-то еще) и поделитесь выводами со своей командой.
Найдите бизнес-пользователей, которых пропустило ваше внедрение.
Корпоративные клиенты Гайса регулярно обнаруживают, что их бизнес-подразделения работают на Windows, в то время как каждое руководство по настройке было написано для инженеров на MacOS. Вам нужно построить мост между инженерами и бизнес-пользователями. Часы приема и встречи 1:1 кажутся мелочью, но это самый быстрый способ помочь кому-то перестать «выпадать из процесса» и начать выпускать работу, которую действительно замечает технический директор.
Относитесь к внедрению как к привычке, которую вы постоянно подкрепляете, а не как к разовому проекту.
Самый распространенный сценарий неудачи при внедрении Guice заключается в том, что команда через пару попыток адаптации тихо возвращается к привычным методам работы. С самого первого дня закладывайте в план контрольную точку на восьмой неделе, и если реальным препятствием является соблюдение нормативных требований, направляйте трафик через AI-шлюз, построенный на уже имеющихся у клиента облачных связях, вместо того чтобы позволять опасениям остановить весь процесс.
Ничего из этого не сработает, если обсуждение будет ограничиваться только инструментами. Настоящий продукт здесь — это сама команда, структура, которая ее поддерживает, и то, приживется ли новая привычка. Если вы все сделаете правильно, AI перестанет быть статьей расходов, оправдание которой вы все еще пытаетесь найти.
Если вы хотите увидеть, как другая компания реализует нечто подобное — превращение заметок об исследовании в техническое задание без потери смысла при переводе — стоит обратить внимание на то, как Endava создала рабочий процесс доставки на базе AI внутри Miro.
