Як АІ змінить підходи до розробки (SDLC)? Поділіться думками
Вітаю товариство
Зараз багато розмов про те як АІ змінить світ розробки, але накидайте як ви бачите як зміниться SDLC, як процес розробки. Я знаю що багато з вас вже щось пробували, щось виходило, а десь просто отримали досвід.
Дозволю собі почати. Що залишиться незмінним:
- Ітеративний підхід — ми не хочемо чекати поки готовий весь проект і тільки потім показувати його людям. Може змінитися час ітерації, але самі ітерації залишаться.
- ПМський трикутник (час-гроші-скоуп) не пропаду і ми далі маємо зважати на ці обмеження
- Jira & Confluence (або подібні інструменти) — так деколи ми їх ненавидимо, але показувати що робить команда, уточнювати деталі для нетехнічних стейкхолдерів все ще потрібно. Чим більше Бос тим менше він буде лізти в git
- Середньо і довгострокове планування — бо бюджети, очікування і оце все
- Пріоритизація залишається критичною — теоретично ми можемо зробити більше з АІ але чи треба і чи саме це треба зараз. Ми можемо в травні зробити акції до Різдвяних свят, але чи саме вони зараз актуальні? (насправді для великих ретейлів можливо — все залежить від бізнесу)
Що зміниться:
- Зменшиться вартість створення прототипу, тому заміться детальних вимог від product owner перейдем на варіант спроб і помилок (такий собі Lean AI). Зробили базовий прототип — показали — отримали фідбек — поправили фідбек — інтегрували в фінальне рішення
- Зменшення розміру команд — якщо скрам команди це
5-9 осіб, то при активній колаборації з АІ, треба оптимізовувати час на комунікацію, тому як варіант більша кількість менших за розміром команд (наприклад 2 команди по 3 людини замість однієї на6-7) - FinOps прийде і до АІ — оптимізація запитів і АІ інфраструктури прийде одразу за великими чеками від компаній розробників LLM
- Крос-функціональні ролі — все більше будемо бачити взаємо проникнення ролей: БА він де і тестувальник, він же і кусочок дизайнера, full stack engineers з навиками автоматизованого тестування і трохи devOps. При цьому думаю залишаться фазівці з глибокою профільною експертизою, наприклад DevOps.
А що ви накидаєте?
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівОсь вже ж розписували github.com/.../uncertainty-architecture
Загалом погоджуюсь із рамкою. Я б сформулював так: AI не скасує SDLC, а змінить вартість, швидкість і ризики окремих кроків усередині нього.
Що залишиться незмінним.
Ітеративність точно залишиться. Може скоротитися час ітерації, може стати дешевшим прототип, але потреба показувати проміжний результат, отримувати фідбек і уточнювати напрям нікуди не зникне. Я б навіть сказав, що з AI ітерацій стане більше, просто вони будуть дрібнішими.
PMський трикутник також не зникне. Час, бюджет і скоуп залишаться. Просто до них сильніше додасться ще один практичний вимір: доказовість. Тобто не тільки «ми це зробили», а «чим підтверджено, що це працює, покриває вимогу, не ламає інтеграцію і не створює неприйнятого ризику».
Jira, Confluence і подібні інструменти теж нікуди не подінуться. Можна скільки завгодно жартувати про любов до трекерів, але бізнесу, менеджменту, аудиторам, суміжним командам і нетехнічним стейкхолдерам усе ще потрібна зрозуміла картина: що робиться, чому, ким, у якому статусі, з якими ризиками і коли чекати результат. Не кожен керівник буде читати git, логи CI або diff у merge request.
Середньо- і довгострокове планування також залишиться, бо бюджети, закупівлі, контракти, лабораторії, найм, релізні вікна, маркетингові кампанії й очікування клієнтів не живуть у режимі «ми зараз швидко згенеруємо». AI може допомогти швидше перерахувати сценарії, але саму потребу планувати він не прибере.
Пріоритизація стане ще важливішою. Якщо AI дозволяє зробити більше, це не означає, що треба робити більше всього. Навпаки, ризик розфокусу може зрости. Команда може швидше створити прототипи, фічі, тести, документацію, але питання «чи це зараз найцінніше?» залишиться людським і бізнесовим.
Що зміниться.
Так, вартість прототипу зменшиться. Але я б не сказав, що це повністю замінить детальні вимоги підходом «спроб і помилок». У простих продуктах — можливо, частково. У складних інженерних або регульованих середовищах прототип радше стане способом швидше уточнити вимогу, а не заміною вимоги.
З власного досвіду: в одному embedded-напрямі нам треба було рухати драйвер, сценарії перевірки і тестовий контур раніше, ніж у команди з’явився стабільний доступ до повного апаратного стенду. Прототипування, локальна симуляція і AI-аналіз допомогли швидше знайти частину логічних, форматних та інтеграційних проблем. Але це не означало «залізо вже не потрібне» або «вимоги вже не потрібні». Це означало: ми раніше підготували перевірки, раніше зібрали докази і зменшили кількість сюрпризів перед реальною інтеграцією.
Тому я бачу не просто Lean AI, а evidence-driven Lean AI: швидко спробували, але потім зафіксували, яку вимогу уточнили, який сценарій підтвердили, який ризик зняли або який дефект знайшли.
Щодо менших команд — частково погоджуюсь. AI може підвищити продуктивність окремої людини, і певні команди справді можуть стати меншими. Але тут є пастка: AI зменшує вартість створення артефактів, але не скасовує інтеграційну складність. Якщо кілька малих команд швидко генерують зміни без чітких меж компонентів, контрактів, архітектури й правил погодження, то комунікації може стати не менше, а більше.
У складних програмах я не раз бачив ситуацію, коли локально все виглядає добре: задача закрита, статус зелений, зміна «невелика». А потім виявляється, що тест покриває стару поведінку, залежна команда не отримала оновлений інтерфейс, ризик релізу не переоцінений, а погодження після зміни базової версії немає. AI тут корисний не тим, що пише ще один статус, а тим, що допомагає знайти такі розриви.
FinOps для AI — повністю погоджуюсь. Після першої хвилі захоплення неминуче прийде питання вартості: які моделі використовувати, які запити кешувати, що запускати локально, що віддавати в зовнішній сервіс, які дані взагалі можна передавати, як міряти користь від AI, а не тільки рахунок за токени. Я б додав, що це буде не лише FinOps, а ще й AI governance: безпека, приватність, класифікація даних, аудит рішень і межі відповідальності.
Щодо крос-функціональних ролей — теж погоджуюсь, але з важливим уточненням. Ролі стануть ширшими, але глибока експертиза не зникне. Бізнес-аналітик зможе краще працювати з тестовими сценаріями, тестувальник — з вимогами й ризиками, розробник — з інфраструктурою та документацією. Але хтось усе одно має глибоко розуміти архітектуру, безпеку, продуктивність, DevOps, домен або регуляторні обмеження.
AI добре допомагає людині рухатися в суміжні області, але він не робить усіх однаково сильними в усьому. Навпаки, цінність експерта зростає, бо треба відрізняти якісну AI-підказку від правдоподібної, але технічно слабкої.
Мій головний висновок: AI переносить вузьке місце SDLC зі створення матеріалів на їх перевірку, інтеграцію і доказовість.
Раніше багато часу йшло на те, щоб написати вимогу, задачу, тест, код, документацію або статус. З AI це буде швидше. Але новим вузьким місцем стане інше: чи правильний цей матеріал, на які джерела він спирається, який має вплив, який ризик створює, хто його перевірив і чим підтверджено готовність.
Тому майбутній SDLC я бачу не як «AI замість процесу», а як швидший, більш ітеративний, але й більш вимогливий до доказів процес: ідея → прототип → фідбек → вимога → рішення → реалізація → тест → ризик → погодження → доказ готовності.
AI може прискорити майже кожен крок у цьому ланцюжку. Але відповідальність за рішення, пріоритети, реліз і наслідки все одно залишиться в людей.
Автор мовчить — жодних коментарів за місяць. Із тобов думками поділіли, чого сам це мовчеш?
Я би сказав що буде наступна хвиля мікросервісів. Тобто якісний системний дизайн, а під ним сервіси, які АІ може переписувати хоч повністю кожен раз. Головне щоб тести норм написані були.
Доречі це може також відновити наявність окремого тостера в команді, бо тепер одна людина цілком може написати тестів на покриття роботи цілої команди.
Про розмиті ролі в команді — думаю що фронт дев і бек дев стануть ближче, а от в BA які пишуть код не вірю. BDD існує роками, і якийсь cucumber давно давав можливість BA бути ближче до коду, але найчастіше ті сценарії писали деви для левів, в кращому випадку QA
Як на мене, пришвидшення — це опція. З АІ можна покращити якість, при цьому швидкість може бути не сильно змінена (якщо говорити про time to market наприклад)
Також, як було сказано розумними людьми на Dou Day, чи встигатимемо ми приймати рішення так само швидко/якісно, як того буде треба в AI-first team/organization? (А рішення — це дуже близько до обовʼязків БА)
Згоден з автором що SDLC просто прискориться. З мого досвіду ітерації просто прискорюються, але однозначно залишаються, щоб скоріше отримувати зворотній зв’язок. Щодо зміни розміру команд, то можливо вони так і залишаться великими — ШІ прискорює виконання технічних задач та, одночасно, примушує «шкіряні мішки» приймати більше рішень. Я думаю, що всі ролі в команді залишаться через те, що просто збільшиться кількість роботи. Тепер манагемент буде вимагати більше і більше фіч та продуктів, тому роботи буде багато. А наскільки вона буде цінна — це вже інше питання :)
Думаю, зміни будуть радикальні — у абревіатурі S буде означати не Software, а Slop.