The PM: AI-інтерфейс для Jira та Confluence

1. Огляд продукту

The PM був моїм продуктом для команд, які живуть у Jira та Confluence, але не хочуть щодня пробиратися крізь фільтри, JQL, звіти й десятки вкладок

Ідея була проста: менеджер, лід або фаундер ставить питання людською мовою, а система знаходить потрібні дані в робочих інструментах і повертає коротку відповідь із контекстом

Це був не черговий dashboard заради dashboard. Я будував інтерфейс до вже наявної операційної інформації, який дозволяв питати про витрачений час, задачі, статуси, проєкти, ризики та рішення так, як людина формулює їх у розмові

2. Яку проблему вирішував продукт

•Jira містить потрібні дані, але відповідь на просте питання часто вимагає знати правильний фільтр, JQL або структуру звітів

•Дані про роботу команди розділені між Jira, Confluence і локальним контекстом проєкту

•Керівнику потрібна не ще одна панель, а відповідь на конкретне питання: скільки часу витратили, на що саме, хто працював над задачею і де є ризик

•Confluence зберігає рішення та документацію, але потрібний фрагмент не завжди легко знайти через звичайну навігацію

•AI-відповідь без доступу до джерел була б ненадійною, тому кожна відповідь мала спиратися на живі дані Jira, Confluence або локальний контекст

3. Що я спроєктував і реалізував

•Єдиний chat-first інтерфейс для запитів до Jira та Confluence

•Natural-language шар, який розуміє питання користувача, визначає намір і підбирає потрібний набір даних

•Запити по time tracking: загальні години, розбивка за проєктами, людьми й задачами, top-3 або top-5 за витраченим часом

•Пошук задач без складних фільтрів: In Progress, без трекінгу, із заданим порогом часу або за конкретним проєктом

•Read-only пошук по Confluence з короткими відповідями про рішення, ризики та контекст проєкту

•Синхронізація Jira та Confluence у локальну базу для швидких запитів, збереження метаданих і майбутньої офлайн-аналітики

•OAuth-авторизацію, збереження облікових даних користувача в зашифрованому вигляді та перевірку доступів перед роботою з даними

•Розділення MVP і наступних можливостей: спочатку read-only аналітика, потім синхронізація, scheduled questions, експорт і write operations

4. Архітектура і хід роботи

Запит людською мовою

Користувач міг написати щось на кшталт “скільки часу ми затрекали минулого тижня і на що”. Система розбирала намір, формувала запит до Jira API, рахувала результат і повертала компактну відповідь без зайвої звітності

Для списків задач відповідь містила issue key, назву, статус і витрачений час. Це дозволяло перейти від загального числа до конкретних робочих елементів

Гібридна модель даних

Я розділив дані на два контури. Частина метаданих синхронізувалась у локальну базу: проєкти, типи задач, ключі, summary, статуси, assignees, спринти, Confluence spaces і page metadata

Свіжі або важкі дані, зокрема worklogs, повні описи задач і вміст сторінок, отримувались через API тоді, коли вони були потрібні. Так продукт залишався швидким, але не втрачав актуальність

AI з опорою на джерела

LLM використовувалась для розуміння запиту, мапінгу наміру на Jira або Confluence і постпроцесингу відповіді. Самі факти мали приходити з підключених систем, а не з припущень моделі

Це було принципово: The PM мав бути інтерфейсом до робочих даних, а не генератором переконливих, але неперевірених відповідей

Безпечний MVP

У першу версію свідомо не включались створення й редагування задач, автоматизації та складні permission-схеми. Спочатку продукт мав надійно відповідати на питання, перш ніж отримувати право щось змінювати в Jira або Confluence

5. Що отримав користувач

•Один зрозумілий інтерфейс замість ручного перемикання між Jira, Confluence і звітами

•Відповіді на управлінські питання без знання JQL і внутрішньої структури Jira

•Швидкий огляд time tracking за проєктами, людьми й задачами

•Пошук рішень і ризиків у Confluence через звичайне питання

•Архітектуру, яку можна було розширити scheduled reports, Slack або Teams, експортом і контрольованими write operations

6. Технічний результат

The PM став повноцінним продуктом на TypeScript і Next.js із chat-first UI, Google authentication, Atlassian OAuth, Jira REST API, Confluence REST API, OpenAI-інтеграцією та Supabase для користувацьких даних і синхронізації

Найважливішим рішенням була не окрема AI-функція, а зв'язок між природним запитом, дозволами користувача, живими джерелами даних і короткою перевірюваною відповіддю

На ринку вже є подібні рішення, і саме тому цей проєкт цінний як інженерний досвід: я пройшов шлях від болю користувача та MVP-обмежень до робочої архітектури продукту, який робить складні операційні дані доступними без зайвої церемонії