Dev48
ЯЗЫК
  • О нас
  • Услуги
  • Индустрии
  • Технологии
  • Статьи
  • Контакты
Забронировать звонок
    Главная/Статьи/Nasha sistema znaniy dlya sozdaniya produktov
Dev48
info@dev48.org+375 29 320-40-96WhatsApp@isky_by

© 2026 · Все права защищены.

Наша система знаний для создания продуктов

Фото: Kranich17 (Pixabay) — https://pixabay.com/photos/pipe-system-tube-construction-site-7768312/

25 сентября 2026 г. в 03:01

Наша система знаний для создания продуктов

RM Роберт Мацуока (Robert Matsuoka), технический директор Duetto

Технический директор, Duetto

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

Это стало возможным благодаря APEX (Agentic Product Execution). В этой системе хранится всё, что нужно любому сотруднику Duetto для создания продукта: что мы создаем, зачем, кто это делает и находится ли функция на стадии релиза или все еще вызывает споры.

«Это появилось потому, что информация о продуктах в Duetto когда-то жила там же, где и в большинстве софтверных компаний: в репозиториях кода, JIRA, Confluence, Slack, электронной почте. Вся эта работа была реальной, но никак не связанной между собой. APEX — это активный репозиторий, в который пишут разработчики и продуктовые команды и который объединяет в себе все то, что содержится в остальных системах».

Я рассказываю вам об этом, потому что с проблемой отсутствия единой связи сталкиваются не только софтверные компании. Любой бизнес — отель в той же степени, что и наша компания, — держится на знаниях, которые хранятся в головах людей, в папках «Входящие», в инструментах, которые не взаимодействуют друг с другом. И любому бизнесу нужен способ, с помощью которого сотрудники, выполняющие работу, смогут находить эти знания, действовать на их основе и поддерживать их в актуальном состоянии. То, что мы создали для решения этой проблемы в Duetto, окажется полезным для каждого, кто сталкивается с подобными трудностями.

Как работает APEX.

Каждый документ представляет собой файл в обычном текстовом формате (markdown) с машинно-читаемыми метками в верхней части (владелец, статус, тип, дата), а его расположение указывает на то, какая команда отвечает за него. Изменения поступают в виде предложений и проходят проверку так же, как инженеры проверяют код. Для тех, кто хочет погрузиться в детали, мы описали техническую сторону работы APEX здесь: apex.duetto.ai.

Что это изменило для нас.

«Никаких догадок. Раньше любая идея начиналась с одностраничного документа, проходила через череду встреч и согласований, превращаясь в испорченный телефон. Теперь же любое изменение в APEX содержит информацию о том, кто и когда его внес, поэтому никто не переписывает обоснования прошлого квартала под результаты текущего».

Корпус (совокупность файлов внутри APEX) проиндексирован как для машин, так и для людей: семантический поиск, поиск по ключевым словам и граф взаимосвязей документов. Наша система автоматического ревью кода считывает изменения, а затем обращается к APEX, чтобы проверить, соответствует ли их замысел продукту.

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

Откуда появился APEX.

В мою первую неделю в Duetto проходил выездной семинар в Далласе, где руководство продуктового и инженерного отделов обсуждало будущее разработки. Бесконечные встречи, огромные документы и невозможность что-либо отследить были моим главным разочарованием на предыдущей работе в должности технического директора TripAdvisor. Использование репозитория git (с управлением исходным кодом) для хранения всех знаний по продукту и разработке — старая идея, которая постоянно терпела неудачу, потому что для работы с ней нетехнических специалистов требовались специальные инструменты, а раньше такие инструменты стоили дорого. Но теперь всё изменилось. Именно это и стало переломным моментом.

Я представил идею APEX в Далласе 29 января. Первый коммит был сделан 7 февраля под названием, которое никто бы не стал размещать на слайде: llm-supported-pdp-sdlc. Позже в том же месяце на выездном мероприятии по выходу на рынок в Канкуне наш директор по продукту (CPO) Картик, одна из наших вице-президентов по продукту Сабрина и я потратили три часа на доработку концепции. Я записал обсуждение, дома расшифровал его и превратил в требования. В марте я написал браузерное приложение, в апреле к нему подключились все остальные, а в июне мы перенесли в него всю базу Confluence.

Является ли APEX новой концепцией?

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

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

Как нетехнические специалисты используют APEX.

Инженеры работают в привычных для них инструментах. У всех остальных есть два пути. Любой сотрудник Duetto может зайти в APEX Companion и ознакомиться с хранящимися там знаниями о продукте и разработке. Прозрачность — часть моей философии, и я предпочитаю, чтобы люди видели то же, что и я. Второй путь — ассистент в Slack и в корпоративном Claude.ai.

По состоянию на 25 августа в APEX насчитывалось около 3255 документов, примерно две трети из которых составляют мигрировавшую библиотеку Confluence. Остальное, включая 194 инициативы, было создано непосредственно в APEX и функционирует по модели рецензирования.

Как это выглядело бы для отеля.

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

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

«Вам не нужно писать код. Начните с уже используемых инструментов для работы с документами, четкого распределения ответственности, уровней доступа под каждую роль и поиска, который помогает людям находить актуальные руководства».

Я воспринимаю этот тип базы знаний как световой меч джедая: инструмент, который вы подстраиваете под конкретные задачи. Вам не обязательно самостоятельно создавать программное обеспечение, но вы должны нести ответственность за то, как организуются, проверяются и поддерживаются знания.

Четыре правила, о которых стоит помнить при создании агентной системы знаний.

Управление

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

Ответственность

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

Интеграция систем

Репозиторий заслуживает доверия тогда, когда он заменяет что-то старое, а не просто увеличивает объем информации. Мы заморозили Confluence, вместо того чтобы использовать его параллельно с APEX, потому что существование двух систем в качестве источника истины приводит к тому, что люди перестают доверять обеим.

Защитные механизмы

Они важны не меньше, чем контент. ИИ галлюцинирует и будет продолжать галлюцинировать. Используйте проверки, которые не зависят от того, насколько модель считает свою работу правильной. Автоматизированные проверки навязывают явные правила; тесты проверяют ожидаемое поведение; ревью выясняет, соответствует ли изменение задуманному. Наше автоматизированное код-ревью возвращается к APEX, чтобы проверить изменение на соответствие спецификации. Люди по-прежнему несут ответственность за одобрение важных изменений.

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

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

← Все статьи

О чём эта статья

Ещё в разделе «Туризм и гостеприимство»

Все →
Достижение эффективности: как инструмент управления задачами экономит время и повышает уровень удовлетворенности гостей
Cloudbeds

Достижение эффективности: как инструмент управления задачами экономит время и повышает уровень удовлетворенности гостей

Airbnb заявляет, что запустит ИИ-турагента в первой половине 2027 годаПресса
Airbnb

Airbnb заявляет, что запустит ИИ-турагента в первой половине 2027 года

Старший менеджер по стратегии
Booking Holdings

Старший менеджер по стратегии

ИИ, мобильные заказы и персонализация: как сделать общественное питание более индивидуальным в массовом масштабе
Agilysys

ИИ, мобильные заказы и персонализация: как сделать общественное питание более индивидуальным в массовом масштабе

MCP в путешествиях: как ИИ меняет индустрию туризма
Amadeus Hospitality

MCP в путешествиях: как ИИ меняет индустрию туризма

Интеграция отельного PMS: API, POS, OTA и многое другое
Hotelogix

Интеграция отельного PMS: API, POS, OTA и многое другое

Ещё от Duetto

Сравнение отелей: каковы ваши результаты?
Duetto

Сравнение отелей: каковы ваши результаты?