AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.
Az AI-ról szóló beszélgetésekben az egyik leggyakrabban elhangzó állítás, hogy mostantól sokkal gyorsabban tudunk szoftvert fejleszteni. Ezt nehéz is lenne vitatni, amikor az ember nap mint nap látja, hogy egy AI néhány perc alatt képes létrehozni egy komponenst, egy API-t vagy akár egy kisebb alkalmazást. Mégis van bennem ezzel kapcsolatban egy kis bizonytalanság.
Nem abban, hogy gyorsabb lett-e a kód előállítása. Abban egészen biztosan. Inkább abban, hogy ebből automatikusan következik-e, hogy gyorsabban készítünk el egy jó terméket.
A Compass egyik előadásán volt egy érdekes ábra arról, hogyan néz ki a szoftverfejlesztés különböző szakaszainak időigénye. A discovery, a prototyping, a development, a user testing és a release nem egyformán terhelte a folyamatot, és az előadó azt mutatta be, hogyan változhat ez az AI hatására. Ez azért volt érdekes számomra, mert könnyű az AI hatását egyszerűen úgy elképzelni, hogy ugyanazt a folyamatot csináljuk, mint eddig, csak a development része lett sokkal rövidebb.
A development eddig a folyamat egyik legdrágább része volt
Hagyományosan egy ötlettől egy működő termékig elég hosszú út vezetett. Először megpróbáltuk megérteni, hogy pontosan mit kellene építeni, majd jött a discovery, a tervezés, a prototyping, aztán maga a development, a tesztelés, végül pedig a release. Ezek között persze rengeteg átfedés volt, de a sorrend és az egyes lépések költsége alapvetően meghatározta, hogyan dolgoztunk.
Ha egy feature fejlesztése hetekig vagy hónapokig tart, akkor érthetően szeretnénk már a fejlesztés megkezdése előtt elég biztosak lenni abban, hogy valóban erre van szükség. Nem túl jó érzés három hónapot eltölteni valamivel, hogy aztán a user testing során kiderüljön, hogy a felhasználók valójában teljesen mást szerettek volna.
Ezért is volt fontos a megfelelő specifikáció, az előzetes tervezés, a technikai döntések és az architektúra. Minél drágább volt a development, annál inkább megpróbáltuk csökkenteni annak a kockázatát, hogy rossz dolgot építünk meg.
Az AI viszont ezen a ponton egészen érdekes módon változtatja meg a helyzetet.
Mi történik, ha egy MVP már szinte semmibe sem kerül?
Ha egy ötletből néhány óra alatt lehet működő prototípust készíteni, akkor egyre kevésbé van értelme heteket tölteni azzal, hogy előre megpróbáljuk eldönteni, biztosan jó lesz-e. Egyszerűen megépítjük, odaadjuk a felhasználóknak, és megnézzük, mi történik. Ha működik, továbbfejlesztjük, ha nem, eldobjuk, ha pedig csak egy része működik jól, akkor arra a részre koncentrálunk. Ez szerintem az AI egyik érdekesebb hatása annál, mint hogy egyszerűen gyorsabban ír kódot: nem feltétlenül ugyanazt a fejlesztési folyamatot tesszük gyorsabbá, hanem maga a folyamat kezd átalakulni. A development annyira gyors és olcsó lehet, hogy a prototyping, a user testing és a release sokkal közelebb kerül egymáshoz.
Ennek a release-re nézve is van egy nagyon érdekes következménye. Korábban egy release általában egy hosszabb fejlesztési ciklus lezárása volt. Ha valamivel hónapokat dolgoztunk, akkor természetes volt, hogy óvatosak voltunk a kiengedésével, hiszen egy rossz döntés, egy komolyabb hiba vagy egyszerűen csak az, hogy a felhasználók nem úgy reagálnak rá, ahogy elképzeltük, meglehetősen fájdalmas tudott lenni. Emiatt a release sokszor önmagában is eseménynek számított: előkészítettük, teszteltük, ellenőriztük, majd végül kiengedtük élesbe, és reméltük, hogy minden rendben lesz.
Most viszont egyre természetesebb, hogy amit délelőtt legeneráltatunk az AI-val, az délután már a felhasználók előtt van. Nem azért, mert kevésbé érdekel minket, hogy működik-e, hanem éppen azért, mert sokkal olcsóbb lett kipróbálni. Ha valami nem működik, nem feltétlenül egy hónapos fejlesztés eredményét kell kidobni, hanem egy néhány órás próbálkozást. Emiatt a release fokozatosan elveszíti azt a korábbi szerepét, hogy egy hosszú fejlesztési folyamat végén álló, kockázatos nagy pillanat legyen. Sokkal inkább a user testing része lesz: kiadjuk, megnézzük, hogyan használják, tanulunk belőle, módosítunk rajta, majd újra kiadjuk.
És talán pont ezért lesz érdekesebb az AI hatása a teljes fejlesztési folyamatra nézve. Nem egyszerűen az történik, hogy ugyanazt a munkát kevesebb idő alatt végezzük el, hanem az eddig egymástól viszonylag távol lévő discovery, prototyping, development, user testing és release szakaszok kezdenek összecsúszni. Ami korábban egy hosszú folyamat végén jutott el a felhasználóhoz, az most akár ugyanazon a napon eljuthat hozzá, és onnantól a felhasználói visszajelzés már a következő fejlesztési ciklus kiindulópontja lehet.
Lehet, hogy nem gyorsabban fejlesztünk, hanem hamarabb tesztelünk
Pont ezért volt érdekes az a bizonyos ábra is. Ha korábban a development volt az egyik legnagyobb idő- és erőforrásigényű szakasz, akkor az AI ezt a részt jelentősen össze tudja nyomni. De ettől még a discovery nem lesz automatikusan rövidebb, a user testing nem történik meg gyorsabban, és azt sem lehet néhány prompttal kiváltani, hogy megértsük, mire van valóban szüksége a felhasználónak.
Sőt, könnyen lehet, hogy ahogy a development egyre olcsóbbá válik, ezek a részek relatíve sokkal fontosabbá válnak.
Ha ma két hét alatt lehet elkészíteni valamit, amit korábban két hónapig fejlesztettünk, akkor nem feltétlenül az történik, hogy két hónap helyett két hét alatt elkészül a végleges termék. Lehet, hogy két hét alatt elkészül az első működő változat, amit aztán elkezdünk használni és tesztelni.
A különbség nem feltétlenül az, hogy két hónap helyett két hét alatt lett jó a termék. Hanem az, hogy két hét után már van valamink, amiből tanulhatunk.
Ez pedig szerintem nagyon fontos különbség.
Az AI-val valószínűleg nem azt a részt tudjuk leginkább felgyorsítani, ahol kiderül, hogy mit kellene építeni. Azt tudjuk felgyorsítani, hogy legyen valami, amit meg tudunk mutatni annak, akinek készítjük.
Mit kezdünk ezzel csapatként?
Ebből szerintem egy egészen másfajta fejlesztési folyamat is kialakulhat. El tudom képzelni például, hogy egy csapatban valaki kifejezetten arra koncentrál, hogy minél gyorsabban működő MVP-ket rakjon össze. Nem az a célja, hogy az első verzió tökéletes architektúrával készüljön, és az sem feltétlenül probléma, ha néhány hónap múlva ezt a kódot már senki nem akarja majd látni. A lényeg az, hogy legyen valami, amit minél hamarabb oda lehet adni a felhasználóknak, és amiből kiderülhet, hogy van-e egyáltalán értelme annak az ötletnek, amit megpróbáltunk megvalósítani.
Ha a user testing alapján kiderül, hogy nincs, akkor egyszerűen elengedjük. Nem kellett hónapokat tölteni a fejlesztésével, és nem kellett egy olyan architektúrát felépíteni köré, amire végül soha nem lesz szükség. Ha viszont azt látjuk, hogy a felhasználók tényleg használják, akkor megváltozik a helyzet. Innentől már érdemes lehet egy másik szemlélettel hozzányúlni: átnézni, mi maradjon meg az eddigi megoldásból, mit kell újratervezni, hol vannak az architekturális problémák, milyen tesztekkel és milyen alapokra építve érdemes továbbvinni a fejlesztést. Az első MVP ebben az esetben tulajdonképpen nem a végleges termék első verziója volt, hanem egy viszonylag olcsó kísérlet annak kiderítésére, hogy érdemes-e egyáltalán terméket csinálni belőle.
Ezért szerintem a gyors MVP és a jó architektúra nem feltétlenül egymás ellentétei, csak nem biztos, hogy ugyanabban a pillanatban van szükség rájuk. Régebben sokszor azért próbáltuk már az első verziót is alaposan megtervezni, mert drága volt újrakezdeni. Ha egy feature hónapok alatt készül el, akkor érthető, hogy szeretnénk előre minél több döntést jól meghozni. Ha viszont egy működő változat néhány óra vagy néhány nap alatt elkészíthető, akkor sokkal könnyebb először azt megvizsgálni, hogy egyáltalán jó irányba indulunk-e, és csak utána befektetni az időt abba, hogy hosszú távon is jól működő rendszert építsünk köré.
Talán ez az egyik legfontosabb változás: nem feltétlenül az történik, hogy mostantól minden szoftvert gyorsabban és tökéletesebben készítünk el, hanem az, hogy sokkal olcsóbban tudunk kísérletezni. És ha a kísérletezés olcsóbbá válik, akkor megengedhetjük magunknak, hogy bizonyos dolgokat ne akarjunk rögtön véglegesre építeni.
A borítóképre (Image by John Howard from Pixabay) külön szeretném felhívni a figyelmeteket, főleg a címmel összevetve. A hosszú záridő miatt az egész autópálya úgy néz ki, mintha minden elképesztő sebességgel haladna rajta, miközben természetesen egyik autó sem közlekedik fénysebességgel. Valójában nem az autók lettek gyorsabbak, csak máshogy látjuk a mozgásukat. Talán valami hasonló történik most a szoftverfejlesztéssel is.
AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.