19 часов, 16 команд и один агент по имени Авиад

Автор: Асаф Гольдштоф

В 4 часа утра, после 19 часов непрерывной работы, последняя группа все еще находилась в офисе. Мы начали предыдущим утром, и когда свет снова залил окна здания, 16 команд уже завершили проекты. В мероприятии приняли участие более 60 сотрудников, причем команды включали не только инженеров, но и сотрудников HR и финансовых отделов, которые представили готовые сквозные рабочие решения.

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

Так как же превратить хакатон из суток деятельности в место, где рождаются реальные решения, которые будут служить нам еще долго после?

1. Подготовка команд (задолго до того, как они садятся писать код)

Никто не пришел на хакатон без подготовки. За недели до мероприятия мы провели базовые семинары по инструментам ИИ и изучили реальные кейсы использования (Use cases), чтобы даже те, кто никогда не писал промпты, знали, с чего начать. Параллельно мы попросили каждую команду прийти со списком рутинных и утомительных процессов из их повседневной работы — не абстрактная идея, а конкретная проблема, которую они хотят решить.

В нашем случае большинство участников не были разработчиками, поэтому мы сосредоточились на обучении работе с Claude и инструментами Vibe Coding. В ходе семинаров мы представили лучшие практики (Best Practices) работы с инструментами и вместе создали продукты, навыки и первичных агентов — чтобы каждый участник и участница испытали успех еще до хакатона.

За две недели до мероприятия каждая команда представила свою идею на утверждение. Цель состояла в том, чтобы убедиться в ее осуществимости и реальной ценности, чтобы мы не тратили 24 часа на создание чего-то, что не будет использоваться на практике. Еще до дня мероприятия каждая команда уже точно знала, что она пришла решать.

Вот три основных параметра, которые стояли за каждым «зеленым светом», который мы давали идее:

• Реальная возможность вывода решения в продакшн.

• Доказанный потенциал экономии как минимум одного рабочего дня в месяц — по времени или затратам.

• Правильный способ реализации решения (чтобы убедиться, что команды не создают хорошие решения неэффективными способами).

---

2. Создание инфраструктуры, которая объединяет проекты и сохраняет их

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

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

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

• Готовность решения к использованию остальными пользователями в организации.

• Информационную безопасность и управление правами доступа.

• Возможность масштабирования решения в будущем.

---

3. Вопрос, который необходимо задать уже при регистрации

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

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

---

4. Твист: нечеловеческий судья

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

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

По окончании презентаций мы собрали расшифровку каждого демо и передали ее Авиаду, убедившись, что он знает, к какой команде и к какому демо он относится. Авиада попросили оценить каждое демо по пяти параметрам, с оценкой от 1 до 5 по каждому параметру, точно так же, как это было предложено сделать судьям.

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

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

---

5. День после

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

Цель двухнедельных встреч — пройтись по статусам, задокументировать открытые задачи, которые нужно решить для реализации идей, и убедиться, что все продвигается по плану. Мы распределили проекты между несколькими ответственными лицами, которые отвечают за продвижение решений, за которые они были назначены. На встречах с ними иногда всплывают технические пробелы, требующие поддержки со стороны R&D и DevOps, и для этого у нас есть CTO, который сопровождает нас и заботится о предоставлении соответствующих ресурсов. Операционные проблемы при подключении к другим продуктам в организации требуют поддержки отдела RevOps, а для пробелов в правильном использовании возможностей ИИ группы обращаются к моей команде, AI Operations.

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

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

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

Автор — директор по операциям ИИ (Director of AI Operations) в Agora.