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

Бізнес-аналітики (БА) збирають вимоги у технічних проєктах і відповідають за їхнє розуміння, оцінку, документування та передачу.

Коли мова йде про відповідальність БА, то маються на увазі й проєкти, що передбачають редизайн або повну перебудову систем.

Тому бізнес-аналітики беруть участь у процесах збору інформації, щоб чітко зрозуміти, як працює поточна система, та пропонують зміни для розробки й впровадження нової. У роботі їм допомагає перегляд документації, зустрічі зі стейкхолдерами й експертами (SMEs), аналіз прогалин (gap analysis) та вивчення функціональності системи.  

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

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

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

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

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

Проблеми майже завжди з’являються наприкінці розробки, коли стейкхолдери дивляться на готовий продукт і запитують: “А чому тут немає [цієї штуки], яка була раніше?”.

Одне діло, якщо у вас є готова відповідь, наприклад: “Цей функціонал вирішили не реалізовувати” чи “На етапі проєктування вирішили, що цей функціонал більше не потрібен”. Але зовсім інша ситуація, якщо вас застали зненацька і ви навіть не знали, що попередня система мала [цю штуку], а нова — ні. І все це лише тому, що ви про неї не знали.

Часто трапляється, що команда розробників звертається до бізнес-аналітика зі словами: “А це хіба було в вимогах?” Така реакція досить типова, хоча й неправильна. У проєктах, де потрібно відтворити існуючу систему, ключовою вимогою є саме відтворення того, що вже є. Поточний функціонал системи створює так звані приховані або неявні вимоги, які теж треба враховувати.

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

Усі вимоги завжди відображено у коді

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

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

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

А де ж знаходяться ці вимоги? У ідеальному світі вони були б задокументовані у вимогах. Але в реальному світі вони знаходяться в коді.

Збір та «виявлення» вимог: чому бізнес-аналітикам варто аналізувати код.

Бізнес-аналітики будь-якого рівня технічної підготовки можуть значно розширити свою роль в аналізі коду, використовуючи інструменти генеративного штучного інтелекту, такі як ChatGPT.

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

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

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

Розробникам не обов’язково виконувати весь аналіз коду, і тим більше їм не потрібно робити це для виявлення вимог — адже це, зрештою, є прямою відповідальністю бізнес-аналітика.

Під час аналізу коду бізнес-аналітик має іншу мету, адже, зазвичай, він шукає зовсім інші речі, ніж розробники чи інженери.

Реальний приклад користі від аналізу коду з ChatGPT

Завдяки аналізу коду за допомогою ChatGPT, мені вдалося виявити пропущену юзер сторі, що стосувалася можливості для кінцевих користувачів роздруковувати копії своїх заповнених форм. Найцікавіше, що цю функцію ніхто не згадав — ні стейкхолдери, ні під час UAT.

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

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

Як так сталося? Хіба стейкхолдери не надали повний список вимог? Можу сказати, що вони були впевнені, що надали все необхідне. Але вони просто забули, що система взагалі підтримувала цей функціонал. Він був реалізований дуже давно, не задокументований ніде, крім коду. Тому ця юзер сторі була пропущена під час збору вимог.

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

Ось ще один приклад. Я виявив, що одна з форм показувала певну інформацію одній групі користувачів і зовсім іншу — всім іншим. У цьому випадку експерти з предметної області (SME), які брали участь у зборі вимог, відрізнялися від тих, які працювали під час тестування продукту (UAT). Друга група експертів вказала на відсутній функціонал, і я підтвердила це, використовуючи ChatGPT для аналізу коду. Перша група про це навіть не згадала.

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

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

Способи використання генеративних AI-інструментів для аналізу коду.

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

Вам потрібен інструмент для завантаження файлів та генеративний AI, який може читати й аналізувати код. Якщо не знаєте, які функції доступні, просто запитайте у самого AI.

Почати можна з такого запиту: «Проаналізуй цей код і сформулюй юзер сторі»    (“analyze this code and tell me the user stories”). Або більш конкретного запиту, наприклад: «Чи є щось у цьому коді, що свідчить про те, що сторінка/форма видима лише для певних користувачів?» (“Is there anything in this code that indicates that the page/form is visible only to certain users?”).

Ви можете звернутися до AI із запитом: «Проаналізуй коментарі в цьому коді та створи на їх основі технічну документацію» (“Analyze the comments in this code and document them for me”). Це швидкий спосіб отримати документацію з добре прокоментованого коду. Щоб піти далі, можна запитати: «Що в цьому коді не задокументовано в коментарях, але мало б бути?» (“What is not documented in the comments that should be?”).

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

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

Чи використовуєте ви генеративний AI для аналізу коду чи ні, обов’язково перевіряйте його у проєктах відновлення, щоб не пропустити важливі вимоги!

А ви користуєтесь ChatGPT чи схожими нейромережами, щоб зрозуміти код? Діліться своїм досвідом у коментарях!

Оригінальна стаття – Business Analysts Can Use Generative AI to Analyze Code від  Tia Loehnert, CCBA, переклад – Олександра Золотова, ревью – Іван Вільчавський. Зображення з оригінальної статті.