Управління АІ-проектами: Чому створення АІ-сенсорів - це просто ще один ІТ-проект

Через кілька місяців після того, як генеративний ШІ став достатньо практичним для побудови, дещо цікаве почало відбуватися з нашого боку FlexiProject – з боку бізнес-команди, а не інженерної. Без написання коду у нас раптом з’явилися агенти, які спокійно виконували частину нашої щоденної роботи: готували пропозиції для клієнтів, заповнювали дані контрактів, витягували звіти з Search Console, оновлювали наш продуктовий беклог після зустрічей з клієнтами, допомагали нам керувати сайтом. Створити їх виявилося найпростішою частиною. Чого ми не очікували, так це того, що управління проектами ШІ, де кожен агент розглядається як справжній програмний проект, з планом, спільною гілкою, тестами та етапами доставки, матиме таке ж значення, як і все, що коли-небудь створювали наші інженери. Це історія про те, чого ми навчилися, в тому порядку, в якому ми це робили.

У цій статті ви дізнаєтеся:

Чому створення АІ-агентів на практиці – це просто ще один ІТ-проект
П’ять етапів, через які повинен пройти кожен проект зі створення АІ-агентів
Як MVP, Agile та Scrum підходять до роботи AI-агентів
Помилки, яких ми припустилися на цьому шляху, і як їх уникнути
Як запобігти паралельному відновленню одного і того ж агента двома людьми

Як бізнес-команда почала створювати АІ-агентів

Створюємо ШІ-агентів, навіть якщо ми не айтішники

Цікавий поворот останніх двох років полягає в тому, що вам більше не потрібна команда розробників, щоб створити працюючий штучний інтелект. Бізнесмен, який може описати, що має відбуватися, і скопіювати кілька прикладів вхідних даних, може створити агента, який виконує реальну роботу. Ми не планували ставати будівельниками. Ми продовжували натрапляти на завдання, де відповідь була очевидною: “Це може зробити агент”, тож ми почали будувати. Перше завдання зайняло день. Другий – після обіду. Потім почалися проблеми – не з будівлею, а з усім, що навколо неї.

Агенти, яких ми створили

Список зростав швидше, ніж ми очікували. У нас є агент, який автоматично заповнює дані клієнта в наших стандартних контрактах. Агент, який готує чорнові пропозиції на основі резюме розмови про продаж. Інтегратор, який імпортує список проектів клієнта з Excel прямо в його середовище FlexiProject. Асистент, який допомагає нам керувати окремими частинами нашого веб-сайту. Агент, який витягує дані з Google Search Console для нашого домену і перетворює їх на читабельні щотижневі зведення. Агент, який після зустрічей з клієнтами оновлює наш портфель продуктів тим, чого, на думку конкретних компаній, не вистачає, щоб ідеї не загубилися між дзвінком і наступною сесією планування. І десятки менших, однозадачних помічників, які хтось створив для себе, постійно вдосконалював і врешті-решт поділився з командою.

Коли один і той самий агент розширювався паралельно

Тертя виникало не через агентів, яких ми створили одного разу і забули про них. Вони виникали між агентами, які насправді мали значення. Двоє людей брали корисного агента, кожен з яких мав власну ідею, як його покращити, і починали розширювати його незалежно один від одного. Через тиждень у нас було дві версії: різні підказки, різні підключені інструменти, різні крайні випадки – і не було ніякого чистого способу об’єднати їх. Це була та сама проблема, яку розробники вирішили десятиліття тому за допомогою Git’у: ви не можете змусити двох людей працювати над спільною відправною точкою і покращувати її в різних напрямках без моделі розгалуження. Ми просто думали, що вона нам не потрібна. Агенти були “простими”. Словосполучення “управління AI-проектами” ще не увійшло в наш лексикон.

Чому розробка ШІ-агентів - це, по суті, управління ІТ-проектами

Будівельні суміші – це тривіально просто

Перший урок – найнезручніший: створити агента дійсно легко. Будь-хто, хто читає цю статтю, може відкрити модель і отримати щось працююче протягом години. Демонстрація буде виглядати чарівно. Першим трьом користувачам вона сподобається. І це саме той момент, коли проект стає важким, тому що доставка демо-версії – це не доставка інструменту, на який компанія може покластися. Розрив між “працює на вхідних даних, які я спробував” і “працює на вхідних даних, які кидає на нього вся компанія” величезний, і модель сама по собі не робить нічого, щоб його подолати. Подолання цього розриву – ось для чого потрібне управління проектами зі штучного інтелекту.

Бізнес-команда, яка створює АІ-агентів, має навчитися управляти ІТ-проектами

Коли не-ІТ-команда починає створювати програмне забезпечення, а агент – це і є програмне забезпечення, він успадковує всі проблеми, на вирішення яких інженерні команди витратили п’ятдесят років. Вимоги повинні бути записані. Архітектура повинна бути спроектована. Код, або підказки, або визначення інструментів повинні знаходитись у спільному доступі. Тести повинні існувати. Зміни повинні бути піддані оглядам перед тим, як вони будуть запущені. Пропуск будь-якого з цих етапів не призводить до їх зникнення; це просто відсуває вартість у часі. Хороша новина полягає в тому, що правила гри вже існують. Дисципліни, які роблять ІТ-проекти успішними, застосовуються без змін, коли бізнес-команда створює агентів. Єдиним новим інгредієнтом є оцінка – специфічна для ШІ версія тестування.

Почати

Життєвий цикл проекту ШІ-агента

1. Початковий аналіз – яку проблему ми насправді вирішуємо?

Кожен агент, який варто створювати, починається з етапу аналізу, який не має нічого спільного зі штучним інтелектом. Хто буде цим користуватися? Що вони роблять сьогодні, крок за кроком? Який з цих кроків насправді завдає шкоди? Як виглядає “зроблено добре” у кількісному вираженні? Перш ніж створити агента з підготовки офферів, ми записали точну ручну послідовність, якої дотримується відділ продажів, відзначили, які кроки повторюються, а які вимагають судження, і лише потім вирішили, що агент повинен, а що не повинен робити. Аналіз зайняв більше часу, ніж створення. Таке співвідношення є нормальним.

2. Планування – обсяг, інтеграції, спільна гілка

Планування – це місце, де ви вирішуєте три речі: вхідні та вихідні дані, інтеграції, яких торкнеться агент, і, що найважливіше, де буде жити робота. Якщо двоє людей збираються зробити свій внесок, їм потрібно спільне визначення “головного”. Це може бути єдиний документ з канонічними підказками та визначеннями інструментів, репозиторій, папка навичок – формат має менше значення, ніж домовленість. Визначтеся з цим у перший день. Вирішіть, чого агент не буде робити, запишіть це і дотримуйтесь цього; scope creep – найпоширеніша причина, через яку агенти стають некерованими.

3. Розробка – оманливо легка частина

Сама збірка відбувається швидко. У цьому і полягає пастка. Ви напишете свої підказки, підключите інструменти, запустите кілька прикладів і відчуєте, що все зроблено на 80%. Насправді ж, швидше за все, ви зробили 30%. Решта 70% – це все, що ви ще не перевірили: дивні вхідні дані, довгі вхідні дані, вхідні дані іншою мовою, випадки, коли один інструмент повертає порожній результат, випадки, коли користувач передумує посеред розмови. Нічого з цього не видно зсередини збірки.

4. Тестування – а потім повторне тестування

Саме тут агенти найбільше відрізняються від класичного програмного забезпечення, і саме тут більшість команд зрізають кути. Сьогодні агент проходить тест, а завтра може його провалити, бо ви змінили один рядок у підказці або оновили базову модель. Дисципліна, яка вам потрібна, – це оцінка регресії: збережений набір вхідних даних з очікуваною поведінкою, що виконується автоматично або, принаймні, систематично після кожної зміни. Без цього ви дізнаєтеся про регресії лише тоді, коли користувач перечепиться через них.

5. Доставка та передача

Агент, який ніколи не був офіційно переданий, – це агент, який стає застарілим у перший же день. Здача означає написання призначеної для користувача документації, визначення того, як виглядає успіх у виробництві, і налаштування способу моніторингу того, чи все ще корисний агент через три місяці. Ми навчилися цьому повільному способу – див. наступний розділ.

MVP, Agile та Scrum в АІ-проектах

Спочатку MVP – почніть з найменшого корисного агента

Кожен агент, який ми створили, починався як найменша корисна версія самого себе. Одне завдання. Один вхід. Один вихід. Ми не піддавалися спокусі додати другий варіант використання, доки не побачили, що перший пережив контакт з реальними користувачами. Агенти, які зазнали труднощів, були протилежністю: амбітні з першого дня, з трьома можливостями, жодна з яких не працювала до кінця. Агенти великого вибуху зазнають невдачі з тих самих причин, з яких зазнають невдачі програмні проекти великого вибуху; форм-фактор не змінює математики. Якщо ви візьмете лише одне правило з цієї статті, візьміть це: MVP для ШІ-агента досить малий, щоб одна людина могла описати його в трьох реченнях і запустити на реальному прикладі наскрізь до кінця дня. Все, що після цього – ітерації.

Чому Agile ідеально підходить для AI-агентів

Агенти надзвичайно добре підходять для Agile-роботи, оскільки вони надзвичайно непередбачувані. Ви не можете повністю визначити агента заздалегідь, як ви визначаєте платіжну форму або звіт. Ви робите невелику версію, дивитеся, як вона працює в реальному світі, бачите, де вона не працює, і виправляєте наступну річ. Спроба спроектувати ідеального агента на папері, перш ніж створити його, – це найшвидший спосіб створити неправильного агента. Ітерації – це не перевага в управлінні проектами для ШІ; це структурна вимога – той самий ритм “Плануй, роби, перевіряй, дій”, який Демінг описав десятиліття тому для будь-якого процесу, що потребує постійного вдосконалення, просто застосований до агентів, чию поведінку ви не можете повністю передбачити.

Запуск роботи агентів у Scrum спринтах

Ми розглядаємо кожного важливого агента як невеликий потік роботи в стилі Scrum. Існує безліч можливостей, якими може володіти агент. Кожен спринт вибирає невелику кількість з них. Демонстрація спринту – це сам агент, запущений на реальних вхідних даних від команди, яка буде його використовувати. Якщо демонстрація не переконлива, робота продовжується; каденція змушує до реальної розмови між розробником і користувачами замість багатомісячної мовчазної збірки.

Помилки, яких ми припустилися

Побудова перед аналізом

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

Довіряючи моделі, щоб зрозуміти це

Це була наша найпоширеніша помилка, і її найважче було позбутися. Ми вважали, що якщо поставити перед моделлю завдання простою мовою, то вона знайде гарне рішення. Часто цього не відбувалося – не тому, що модель була слабкою, а тому, що ми самі не займалися проектуванням. Модель не має уявлення про контекст вашої компанії, наявні дані, неписані правила, систему, що оточує завдання. Чим більше цього ви дасте їй, реального аналізу, реальної архітектури, структури, якої ви хочете, щоб вона дотримувалася, тим кращий результат. Модель є чудовим інструментом у виконанні. Вона не є вашим архітектором.

Перейти до біг-бенгу замість того, щоб почати з MVP

Щоразу, коли ми намагалися запустити повнофункціонального агента в перший же день, результат займав більше часу на створення, його було важче налагоджувати, і від нього відмовлялися частіше, ніж від невеликих версій, які ми створювали цілеспрямовано. Великий вибух здавався швидшим. Але це не так.

Двоє людей паралельно розробляють один і той самий агент

Це був момент Git’у. Двоє людей, один і той самий агент, різні ідеї, різні гілки в головах, без спільного “головного”. Тиждень потому – дві версії, які ніяк не могли примиритися. Тепер ми ставимося до кожного значущого агента так само, як розробники ставляться до коду: одна канонічна версія, явна модель розгалуження, коли над ним працює більше однієї людини, і явний крок злиття. Або, якщо ідеї дійсно розходяться, свідоме рішення розділитися на два окремі агенти замість того, щоб вдавати, що вони все ще єдине ціле.

Відсутність початкової документації – користувачі не знали, що робить агент

Перші внутрішні користувачі наших навичок продовжували ставити одні й ті ж питання: що ця штука насправді робить, що я маю ввести, як виглядає результат, коли я маю використовувати його порівняно з попередньою версією. Ми думали, що з агентом все зрозуміло. Але це не так. Тепер ми пишемо короткий користувацький опис для кожного агента при передачі – що він робить, чим його годувати, чого очікувати, чого він не робить. Це коштує десять хвилин і запобігає тижневому заплутаному використанню.

Почати

Поширені запитання про управління проектами зі штучного інтелекту для керівників проектів

Чи відрізняється управління АІ-проектами від управління звичайними ІТ-проектами?

Дисципліни ті ж самі – аналіз, планування, створення, тестування, доставка, ітерації. Відмінності полягають у фазах побудови та тестування: результати не є детермінованими, поведінка може змінюватись, коли змінюється модель або підказки, а “тестування” перетворюється на “оцінку за збереженим набором кейсів”. Все навколо цих фаз виглядає як звичайний ІТ-проект.

Чи потрібен мені інструмент управління проектами для управління розробкою ШІ-агентів?

Вам потрібне місце, де кожен агент живе як проект: з планом, поточною версією, власником і станом виконання. Неважливо, чи це система управління проектами, чи вікі, чи структура папок, але наявність такого місця має менше значення. Для команд, які працюють з багатьма агентами паралельно, справжня PM-система швидко окуповується.

Наскільки великим повинен бути MVP-агент?

Достатньо невеликий, щоб одна людина могла описати його трьома реченнями і виконати на реальному прикладі до кінця дня. Якщо ви не можете, то сфера застосування занадто велика, а MVP – це щось вужче всередині неї.

Як не дати двом людям паралельно створювати одного і того ж агента?

Ви не заважаєте двом людям робити внесок – ви чітко вказуєте, де живе канонічна версія, кому належить злиття, і коли розбіжні ідеї повинні стати свідомим розгалуженням на два окремі агенти. Урок з програмної інженерії застосовується один до одного: спільна гілка з узгодженим процесом злиття.

Коли агент стає спадщиною?

Момент, коли ніхто не відповідає за оцінку того, чи допомагає він і надалі. Агент, який ніхто не перевіряє, потихеньку деградує, світ навколо нього змінюється, змінюються вхідні дані, змінюється базова модель, і одного дня вона стає неправильною, а ніхто цього не помічає. Спадщина – це не вік, це стан занедбаності.

Висновок

Захоплююча частина створення ШІ-агентів, модель, підказки, момент, коли демонстраційна версія працює вперше, – це найменша частина роботи. Нецікаві частини – це те, що перетворює демо-версію на інструмент, на який може покластися вся компанія: чіткий аналіз, реальний план, спільна гілка, регресійні тести, документація і ритм ітерацій, який робить агента корисним ще довгий час після першої відправленої версії. Нічого з цього не є екзотикою. Це саме та дисципліна, яка десятиліттями забезпечувала успіх ІТ-проектів, застосовуючись без розбавлення до дещо новішого типу програмного забезпечення. Команди, які запроваджують цю дисципліну на ранній стадії, в результаті отримують агентів, яким довіряють. Команди, які пропускають її, в кінцевому підсумку відновлюють одного і того ж агента двічі. Ставлення до кожного агента як до справжнього проєкту, з планом, який ви можете викласти, переглянути та вдосконалити, – ось що означає управління проєктами зі штучного інтелекту на практиці. Ми робимо це у FlexiProject, де кожен агент отримує власний проектний запис з чітко прописаним планом дій; яку б систему ви не обрали, ставтеся до кожного агента як до проекту, а не як до експерименту.

Dominik Wrzosek

General Manager at FlexiProject

Домінік є експертом у сфері управління проєктами та випускником Варшавської політехніки. Він керує розвитком системи FlexiProject, перетворюючи бізнес-потреби на практичні рішення для підтримки команд проєкту. Має досвід впровадження FlexiProject в організаціях різного масштабу, поєднуючи технічні знання з бізнес-орієнтованим підходом до ефективного планування та реалізації проєктів.