Szerző: James Shore
Ez a cikk eredetileg James Shore Successful Software blogján jelent meg, és a szerző engedélyével jelenik meg újra itt.
Az egyszerű kérdés: gyorsabbá teszi az AI a szoftverfejlesztést? A legtöbb vezető és fejlesztő, akivel beszélek, azt mondja: igen. De mennyivel? Milyen értéket kapsz a befektetett pénzért, és vannak-e más AI-használati módok, amelyek jobb megtérülést (ROI) adnak?
Ez a cikk a sorozat második része, amely az AI hatásának mérésével foglalkozik. Az első részben a hatásértékelés fontosságáról és a kerülendő hibákról volt szó; itt a szállítási sebesség mérésének módszereit tárgyalom. A harmadik rész az AI nem szándékolt mellékhatásait vizsgálja, a negyedik pedig az üzleti eredményekre koncentrál. Egy epilógusban összefoglalom az ajánlásokat, amelyeket megoszthatsz a pénzügyi vezetőddel.
Mit mérünk pontosan?
Fontos különbséget tenni: a szállítási sebesség nem azonos a termelékenységgel. A szállítási sebesség a termelékenység egyik komponense — ha két, közel egyenértékű csapat ugyanazt a terméket készíti, az, amelyik előbb szállít, látszólag produktívabb. Ugyanakkor a szoftverfejlesztés valódi termelékenységét érdemi érték előállítása osztva a befektetett pénzzel határozza meg. Gyorsabban dolgozni még nem jelenti, hogy jó irányba haladsz.
A jelen cikk egyszerűbb kérdésre fókuszál: a csapatok gyorsabban végzik-e el az adott munkát (függetlenül attól, hogy az munka valóban hasznos-e).
Az alapötlet és a problémák
Rossz hír az első: nincs objektív, univerzális mérőszám a fejlesztési sebességre. A csapatok által előállított kimenetek nem szabványosak — sorok száma, PR-ek, story pointok és egyéb mutatók rosszak, mert a munkadarabok nagysága és jellege jelentősen eltér.
A logikus megközelítés, hogy az összehasonlítást belülről végezzük: hasonlítsd a csapatot saját magához. Ha korábban a becsült idő háromszorosát használták, most pedig másfélszeresét, akkor elméletben kétszeres javulás van. De a gyakorlatban több buktató van:
- A becslések nem állandóak: a tényleges/becsült arányok eloszlása S-görbéhez hasonló lehet, nem egyetlen fix érték.
- Az emberek különbözően dolgoznak: vannak pesszimistább, optimistább becslők, mások sokat kommunikálnak, mások „mélymunkában” dolgoznak. Ha mindenkit összevetsz mindenkivel, nagy zajt viszel be az adatokba — ezért jobb, ha egyénenként hasonlítunk.
- Az emberek megváltoztatják a becsléseiket, ha tudják, hogy AI-t fognak használni: ha valaki az AI-tól gyorsulást vár, kisebb becslést fog megadni. Ez könnyen torzíthatja az eredményt.
- A folyamatfejlesztések összezavarhatják a dolgokat: AI bevezetése gyakran együtt jár a munkafolyamatok egyszerűsítésével és a fejlesztők és üzleti szakértők közelebb hozásával — ezek önmagukban is javítják a hatékonyságot.
Hogyan kerülhetőek el a csapdák?
Négy konkrét tipp a torzítások minimalizálására:
- Gyűjtsd be a becslést még azelőtt, hogy a végrehajtó tudná, AI-t fog-e használni. Ez megakadályozza, hogy a becslés a várt AI-hatékonysághoz igazodjon.
- Végezzenek véletlenszerűsített kísérletet: minden feladathoz a végrehajtó húzzon egy „AI-s” vagy „nem-AI-s” feladatot véletlenszerűen. Ezzel csökkented az időbeni konfundáló változók hatását.
- Ha a bevezetés során a „with-AI” munkafolyamatokat gyorsító változtatásokat eszközölsz, vidd át ugyanazokat a változtatásokat a „without-AI” eljárásba is — különben nem fogod tudni, miért javult a sebesség.
- Összehasonlításokat mindig személyenként/típusonként végezz: mindenki saját magához képest legyen a kontroll.
A teljes mérési eljárás
A javasolt módszer egy randomizált, within-subject repeated-measures kísérlet: minden résztvevőre jut „with-AI” és „without-AI” feladat, és az egyén adatait egymáshoz hasonlítjuk, majd aggregáljuk.
Lépések röviden:
- Határozd meg egyértelműen a „with-AI” és „without-AI” megközelítéseket, és gyakoroltass mindkettőt a résztvevőkkel.
- Döntsd el, hogyan könyveled a reworköt (pl. kódreview-változtatások, hibajavítások), és hogyan kötsz vissza minden extra munkát az eredeti feladathoz.
- Adj minden személynek egy virtuális „zsákot” feladatokkal, fél-fele arányban AI-s és nem-AI-s feladatokkal. Minden feladathoz először adják meg a becslést, majd húzzák ki a feladatot véletlenszerűen.
- Rögzítsd a fő mérőszámokat: becsült idő, tényleges idő, feladattípus és költség. Előre határozd meg, hogy naptári időt (szünetekkel, megszakításokkal) vagy tiszta ráfordítást (megszakítások nélkül) mérelsz-e, és hogyan kezeled a párhuzamos munkavégzést.
- Fontold meg további információk gyűjtését (hibák, incidensek száma, mentális energia, fölösleges kódsorok stb.), amelyek a harmadik részben hasznosak lesznek a nem szándékolt következmények modellezéséhez.
A részletes kísérlettervezést és a statisztikai elemzést érdemes statisztikussal végeztetni. Általánosságban az egyén „with-AI” adatait összehasonlítjuk a saját „without-AI” adataival, majd az eredményeket aggregáljuk.
Ne feledd: a sebességnövekedés nem feltétlenül azonos a termelékenység növekedésével. Figyeld meg, hogy a mért feladatok milyen arányban állnak az összes munkához képest. Például ha a kódolási sebesség duplázódik, de a fejlesztők heti munkaidejük felét más tevékenységekre fordítják, az összesített sebességnövekedés kisebb lesz (a cikk példája szerint 40 óráról 30 órára csökkenés 40 ÷ 30 = 1,33-szoros javulást jelent, nem 2x-et).
Megéri-e ez az egész?
A mérés több munkát igényel, mint a „számláljuk a PR-eket” megközelítés, és ha ez csak egy szokványos folyamatjavítás lenne, valószínűleg nem érné meg a befektetést. De az AI bevezetése nem szokványos: a költségek és a potenciális megtérülések is nagyságrendi különbségeket mutatnak, ahogy a vezetőkkel folytatott beszélgetések is mutatják. El kell döntenie a cégnek, hogy több ezer dollárt költ-e személyenként ügynökszerű, „hands-off” kódfeladatokra, vagy inkább százakat ad-e jobb kiegészítő eszközökre.
Nem lehet jó döntést hozni anélkül, hogy ne tudd, mit kapsz a pénzedért. Egy METR tanulmányban a mérnökök az AI sebességnövelő hatását közel 50%-kal túlbecsülték. Mérés nélkül nincs más mód a valós hatás megismerésére.
Szerencsére nem olyan nehéz, mint amilyennek hangzik: ha az elvárt hatás kellően nagy és elegendő résztvevő áll rendelkezésre, nem kell túl sok minta minden személytől. A csapatok a normál munkájuk során gyűjtik az adatokat; a legnehezebb része annak meghatározása, hogyan használják pontosan az AI-t — és ez amúgy is megéri az erőfeszítést.
A szállítási sebesség csak a teljes képből egy szelet; a fenntarthatóság és a nem kívánt mellékhatások is fontosak. Ezekkel a kérdésekkel a következő rész fog foglalkozni.
Minden tartalmam 100% emberi aggyal készült, hacsak másként nincs jelezve. Ha tetszett ez a bejegyzés, nézd meg a legjobb írásaimat és előadásaimat, és fontold meg, hogy feliratkozol az értesítésekre. Konzultációval kapcsolatban írj a jshore@jamesshore.com címre.
