Вітаю, зараз переклад в розділі Більше: uabaconf.info

Згоден з автором що SDLC просто прискориться. З мого досвіду ітерації просто прискорюються, але однозначно залишаються, щоб скоріше отримувати зворотній зв’язок. Щодо зміни розміру команд, то можливо вони так і залишаться великими — ШІ прискорює виконання технічних задач та, одночасно, примушує «шкіряні мішки» приймати більше рішень. Я думаю, що всі ролі в команді залишаться через те, що просто збільшиться кількість роботи. Тепер манагемент буде вимагати більше і більше фіч та продуктів, тому роботи буде багато. А наскільки вона буде цінна — це вже інше питання :)

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

З мого досвіду ШІ якраз потребує чіткі бізнес-вимоги та аналізу запропонованої архітектури рішення. А технічну частину від дуже добре робить (як мінімум в продуктах, де архітектура вже визначена)

Генерація коду ШІ займає години, тому ітеративний підхід дозволяє швидко отримувати зворотній зв’язок і вносити зміни у вимоги, на основі яких ШІ буде вносити зміни в продукт. І так поки не отримаємо ідеальний продукт :)

Тому стаття і є запрошенням до розмови. Також згоден, що значення терміну дуже залежить від контексту. Я базувався на визначенні від ІІВА.

Мої знайомі БА себе продають значно дорожче. Потрібно попрацювати над навичками та знаннями, щоб відповідати потребам ринку.

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

Це звжди двосторонній процес — БА теж повинні напрацьовувати потрібні знання, щоб бути корисними

Ось повний цикл вебінарів, всі 12 випусків: youtube.com/...​CcIqt&si=4wajGprlt5r5yWzq

Прошу вибачення — тільки побачив запитання. Наразі я будую систему вимог в новому проекті на Google Docs — трохи незвично і не так зручно, як в Confluence, але працювати можна. Якщо говорити саме про управління вимогами, то однозначно потрібно використовувати версії документів та взаємозв’язки з ними, а також єдину архітектуру документації. А далі все залежить від контексту проекту.

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

Так, виділяються кольором тільки зміни в даній версії відносно попередньої

Це зробили ще в 2017 році — деталі в dou.ua/...​ening-with-1c-in-ukraine

Помилку 404 поправив

Для першого кроку — визначити список альтернатив — опису було достатньо. Наступний крок — це аналіз функціональності на тестових прикладах. Надіюсь що получиться :)

Дякую ) Щодо заміни комплексу систем, то альтернативи є. Я ще не аналізував функціональність, але якщо орієнтуватись на опис функціональності на сайті — це АБ:Офіс (ab.biz.ua), MASTER:Бухгалтерію та їх продукти (masterbuh.com), Інфо-Підприємство (uvelirsoft.com.ua) А5 (a5buh.com) та інші. З західних систем це Odoo (www.odoo.com), MS Dynamics 365 (dynamics.microsoft.com/en-us), SAP Business One (www.sap.com/...​roducts/business-one.html), ORACLE APEX тощо. Я планую розширювати список альтернатив на сайті www.stoprussiansoft.info, тому переглядайте періодично відповідні розділи

Саме так — спеціально перечитав класика ВА :) Історії та сценарії використання у нього описують однаковий рівень вимог.

так, тест кейси теж робляться по сценаріях використання. А UAT — по критеріях приймання юзер сторі

Реальні показати не зможу, можливо буду готувати якісь тестові матеріали — скину.