Впровадження AI Driven Development в команді. Що варто знати перед початком інтеграції

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Микита Мельник, я займаюся бізнес аналізом, зараз фокусуюся на впровадженні AI Driven Development в роботу бізнес-аналітиків, Product Owners, Product Managers, Scrum майстрів, UX-дизайнерів. Також консультую проєкти щодо впровадження технології. У цьому матеріалі розкажу, що варто знати про впровадження Generative AI у процеси розробки ПЗ.

Нова технологічна революція

Розвиток продуктів на основі LLM (Large Language Model) та Generative Artificial Intelligence (AI) за останній рік значно змінив вектор розвитку технологічних компаній. Постало питання, як в найближчому майбутньому функціонуватиме бізнес, як еволюціонуватимуть професії та виконуватимуться задачі, поставлені перед спеціалістами з розробки ПЗ.

Технологічні компанії, які надають послуги хмарних обчислень (Amazon, Google, Microsoft), отримали рекордні прибутки у 2023 завдяки використанню ШI-технологій їхніми клієнтами. Ледь не кожна організація досліджує, як технологія може впливати на бізнес, а окремі спеціалісти вже застосовують ШI-інструменти.

Синтетичні дослідження впливу ШI вказують на зростання ефективності роботи на десятки відсотків. Наприклад, дослідження SoftServe вказує на +45%, Harvard декларує +43% (залежно від задач та рівня спеціаліста). Деяким професіям уже прогнозують швидкий занепад, а враховуючи темпи еволюції LLM і ШI-продуктів суттєві зміни можуть відбутись скоріше, ніж ми очікуємо.

Реальна задача

У період глобальної кризи наш клієнт вирішив зайнятись оптимізацією шляхом пілотної інтеграції генеративного ШI в команди розробки.

Перед нашою командою консультантів постала задача впровадження генеративного ШI в роботу восьми команд розробки, які складали три стріми сумарною кількістю понад сотню спеціалістів. Це була наймасштабніша інтеграція ШI серед клієнтів ЕРАМ на той момент.

Для інтеграції були обрані інструменти EPAM AI DIAL (AI Chat), GitHub Copilot, внутрішні продукти для керування бібліотеками промптів. Забігаючи наперед зауважу, що Google Codey не був інтегрований і ефективність інструменту порівняно з GitHub не була перевірена, хоча спочатку ми хотіли це зробити.

Інтеграція ШI розповсюджувалась на бізнес-аналітиків, Product Managers і Product Owners, мануальних тестувальників і автоматизаторів, фронтенд- і бекенд-розробників, а згодом охопила також UX/UI-дизайнери. Клієнт хотів побачити реальний досвід використання замість синтетичних тестів. Це стало найскладнішою задачею, хоча це не очевидно для ШI-ентузіастів.

Наша команда консультантів складалася з керівника напрямку делівері (Delivery Lead), консультанта з якості інженерії (Engineering Excellence Consultant), консультанта з бізнес-аналізу (Business Analysis Consultant), консультанта з тестування (Quality Assurance Consultant), консультанта з розробки (Software Development Consultant).

Що ми мали зробити?

1. Провести аудит процесів і стану проєкту. Кожен консультант мав дослідити це в зоні власної відповідальності, виявити можливості для застосування ШI, виділити метрики для вимірювання впливу ШI, спрогнозувати ризики.
2. Розробити план самостійного вивчення Generative AI для спеціалістів і план воркшопів для парного або групового навчання. Забезпечити коучинг з використання ШI для проєктних спеціалістів.
3. Побудувати процес збору обʼєктивних і субʼєктивних метрик, регулярно їх збирати, впорядкувати кейси застосування ШI, рівень і фінальний результат впровадження ШI.
4. Побудувати шлях впровадження ШI на рівні всієї компанії замовника та згенерувати інші артефакти.

Не так склалося, як очікували

Знаючи результати синтетичних досліджень у +45% до продуктивності та простоту ШI-інструментів, ми очікували швидко та якісно їх впровадити, адже із цим «всім буде краще». Але так не сталося. Гірка правда полягає в тому, що високі показники зростання перформансу були отримані в лабораторних умовах, а тести виконували зацікавлені люди. Результати, які отримали ми, значно скромніші. Далі наведу декілька факторів, через які це сталося, і розповім, як ми з ними працювали.

Невимірюваний проєкт

Маючи проєкт в зеленій зоні, за необхідності інтегрувати ШI і виміряти його ефективність ви зіштовхнетесь з багатьма речами, які необхідно виправити або покращити. Це має надважливе значення для обʼєктивних вимірювань впливу технології порівняно із суб’єктивним впливом.

Як мінімум переконайтесь, що члени команд сумлінно дотримуються вашого Jira-flow. Інакше як ви зрозумієте, скільки часу задача провела в кожному зі статусів?

А як щодо спеціалістів, чиї задачі не потрапляють у спринт? Досить часто для них відсутні навіть Kanban-дошки. Подумайте про те, як ви будете вимірювати вплив ШI.

Упереджене ставлення до ШI

Більшість спеціалістів вашого проєкту будуть ставитись до ШI нейтрально, деякі — скептично та негативно. Їхні очікування або сильно перебільшені, або сильно недооцінюють технологію. У більшості випадків вони зводяться до того, що ШI має «виконувати роботу за мене».

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

Для ефективного розвʼязання проблеми необхідно зробити аналіз стекхолдерів і на основі нього створити індивідуальний підхід до кожної з груп. Задача — конвертувати всіх нейтральних і детракторів у промоутерів.

Якщо робота зі скептиками і детракторами низькорезультативна, не марнуйте час. Фокусуйтесь на нейтральних спеціалістах, їх легше перевести в промоутерів, вони стануть прикладом і пасивно впливатимуть на скептиків.

Матриця стекхолдерів з прихованими іменами, Looker screenshot:

«У нас немає часу на ШI»

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

У комбінації із завищеними очікуваннями від технології, члени команд не бачили практичного застосування ШI в їхній роботі. Варто зазначити, що особливості проєктних задач і процесів можуть зменшити потенціал технології. Як може не бути часу на те, що має економити час? Безумовно, це скептичне ставлення і не розуміння технології.

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

Враховуючи результати стекхолдер-менеджменту варто впровадити воркшопи, де ви продемонструєте нові підходи. Найкращим рішенням буде розробка end-to-end-сценаріїв використання ШI. Їх можна безпосередньо брати й застосовувати на проєкті без адаптації, такі сценарії мають найбільшу ефективність, їхнє використання може забезпечити результати навіть кращі, ніж отримані в синтетичних тестах.

Ентузіазм і рівень впровадження

Очікуйте, що швидкість впровадження ШI не буде високою: люди важко сприймають зміни, а в деяких випадках враховуйте ще і блокери. Наприклад, замовлення й активацію ліцензії на GitHub Copilot.

Одним з методів прискорення впровадження штучного інтелекту став «День ШI»: всі спеціалісти мали виконувати проєктні задачі за допомогою цих інструментів. Після першої половини дня ми не отримали результатів, які б нас влаштовували, необхідно було щось змінювати в нашій роботі. Адже навіть «День ШI» був створений не через класні результати впровадження.

«Як прискорити швидкість впровадження?» — неправильне питання. «Хто швидше впровадить ШI?» — саме це питання створює конкуренцію як серед окремих спеціалістів, так і певних дисциплін, команд, стримів. Просте повідомлення зі статистикою членів команд кардинально змінило ситуацію. Зʼявилась конкуренція, бажання вийти в лідери, спеціалісти почали застосовувати технологію.

Створення здорової конкуренції з нагородами стало для нас одним з дієвих методів підвищення рівня впровадження ШI. Ми ввели змагання в загальному, командному і неконкурентному заліках. У неконкурентному заліку ми поповнювали благодійний рахунок однієї з організацій в Україні, що зрештою принесло понад $1000 доларів внесків.

Як будемо міряти

Velocity, capacity, time to market, lead time... Скоріш за все навіть на дуже зеленому проєкті є висока вірогідність забути про ці метрики. Протягом пари місяців впровадження технології ви не зможете встановити статистично значущі зміни. Й ось чому.

Ваш проєкт, скоріш за все, перебуває в постійній трансформації. Ротації спеціалістів, відпустки й лікарняні, різкі зміни пріоритетів не дозволяють зібрати вихідні дані для порівняння надалі. Безперечно, спробувати їх зібрати необхідно.

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

То як міряти обʼєктивні метрики? Зверніть увагу на дані з Jira і час перебування задачі в кожному зі статусів. Саме тому важливо мати якісні флоу та дотримуватись їх, своєчасно оновлюючи таски. Картина, яку ви отримаєте, не буде якісною — це буде хаос. Треба очистити дані й згрупувати за кожним окремим типом задач, статусу, окремому розміру задачі, будь то два чи три storypoints. Не забудьте відфільтрувати неправдиві дані, наприклад, час у розробці — пʼять секунд.

Субʼєктивний вплив ШI, за ролями:

Субʼєктивні вимірювання: Daily impact і Proficiency:

Субʼєктивні вимірювання: Performance і Work coverage:

Результати, негативний вплив на початку, негативний вплив на почуття

Попри завищені очікування приросту ефективності, інтеграція нової технології — це інвестиція часу та нові задачі для команд, тому очікуйте просадку ефективності в перші тиждень-два застосування ШI. З плином часу ефективність почне зростати. Внаслідок роботи ми визначили такий приріст показників ефективності:

• на 21% менше часу задачі перебувають в аналізі;
• на 11% менше часу задачі перебувають в розробці;
• на 17% менше часу задачі перебувають в тестуванні.

Можна помітити, що приріст ефективності аналізу більший, ніж приріст ефективності тестування і розробки, де зазвичай малюють кращі показники. Тут варто ввести термін AIDD — AI Driven Development (стаття про це вже чекає апруву на Вікі). Причиною такого розподілу ефективності є відсутність того самого AIDD.

Нетехнічні спеціалісти (BA, Product, Designers) адаптують власні робочі процеси під застосування нових технологій і інструментів. Технічним спеціалістам (інженерам, тестувальникам й іншим) для підвищення ефективності технології також необхідні зміни процесів і вхідних артефактів, але для цього необхідно запропонувати трансформації в попередні етапи й артефакти.

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

То чому ж все-таки не +45%? Спеціалісти не працюють вісім годин, тим паче не весь час виконують задачі. По-перше, дзвінки й обговореннях займають левову частку робочого часу багатьох фахівців, і ці дзвінки ще недостатньо автоматизовані за допомогою ШІ.

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

Варто додати, що зібрані субʼєктивні метрики — заощадження часу на виконання задачі, денна економія часу — можуть вказувати на ефективність у декілька сотень відсотків. Пʼять хвилин замість чотирьох годин, але такі задачі не є регулярними в робочій рутині більшості фахівців.

Обʼєктивні вимірювання: час у розробці. Looker screenshot:

Обʼєктивні вимірювання: час перебування задачі в статусах підготовки вимог.

До:

Після:

Обʼєктивні вимірювання: час перебування задачі в тестуванні.

До:

Після:

Цінний досвід

Унаслідок інтеграції клієнт залишився задоволеним і дав зелене світло на її розширення на всі команди, а це, своєю чергою, створило новий виклик нашій команді. Чому? Перш за все необхідно усвідомити, що буде означати успішна інтеграція. Коли інтеграційна команда працює поруч з командами розробки і допомагає у використанні ШI — процес працює.

А що буде, коли команда інтеграції зникне: чи будуть працівники використовувати технологію? Саме тому на першому етапі інтеграції ми створили ШI-гільдію з ентузіастів, задачею яких стала підтримка та розвиток культури використання штучного інтелекту на проєктах.

Але сама собою гільдія не запрацювала, тому що задача не виникла всередині організації — її надали ззовні. Тому надважливо створити гільдію на етапі пілотної інтеграції, щоб супроводжувати її на надалі. Після впровадження технології на рівні всієї компанії існування самодостатньої структури, яка буде розвивати культуру ШI, є скоріш за все єдиним гарантом того, що після закінчення роботи консультантів використання штучного інтелекту не припиниться.

Подібний досвід був унікальним для ЕРАМ, тому ми створили ґайд для консультантів щодо впровадження ШI, скринінг-критерії для відбору проєктів, придатних до ефективного впровадження технології, та AIDD-фреймворк, який допоможе збільшити ефективність технології на проєкті.

Назву деякі з них:

• відсутність значних трансформацій на проєкті;
• задачі всіх типів спеціалістів відстежуються в системах трекінгу задач;
• флоу задач якісно прописаний і спеціалісти сумлінно його дотримуються.

А що далі з ШІ

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

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