HWSW podcast!

Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)

· PT46M16S

Összefoglaló

A HWSW podcast 69. kraftie adásában a fejlesztői produktivitás mérésének témáját járják körül. Mivel a téma ciklikusan kerül elő, most az AI elterjedésével újra reneszánszát éli. A vendégek, Böle Gyuri, Zero Aliance Batis Peti és Vaslavik Marci (Clear Street VP of Engineering)…

Röviden

Műsor
HWSW podcast!
Megjelenés
2025. 11. 21.
Hossz
46 perc
Szereplők, említett nevek
Böle Gyuri, Vaslavik Marci, Batis Peti, Zero Aliance Batis Peti
Témák
ai produktivitás, fejlesztői produktivitás, szoftverfejlesztés
Átirat
Az epizód beszélt szövege alapján indexelve

Ebben az epizódban

Crafti a Highfi Labs állandó támogatásával.

Én Böle Gyuri vagyok, a műsor egyik házigazdája. szokás szerint itt van Zero Aliance Batis Peti.

Van egy vendégünk is, Vaslavik Marci, aki fejlesztőkét kezdte a karrierjét, dolgozott startup közekben is, nagyvállalatoknál is, jelenleg pedig a Clear Street nevű cégnek a VP of Engineeringje. ma a fejlesztői produktivitásról fogunk beszélgetni, sőt egész pontosan a fejlesztési produktivitás méréséről fogunk beszélgetni, aminek az ad aktualitást, hogy ez a téma így ciklikusan előkerül, és erre majd kitérünk, hogy miért ciklikusan.

És ugye most pont a az AI-nak a terjedésével ismét egy ilyen reneszánszam van ennek a témának.

Mielőtt azonban nekikezdünk, elmondanék egy-két közérdekű információt.

Szabadságról leszünk zéróval december 19-én, úgyhogy akkor lesz a leállásunk, akkor nem lesz crafty, és aztán majd a tehát legközelebb lesz még egy crafty.

December 19-én nem, és akkor majd az égnyitó jóslós adással fogunk visszatérni valamikor január elején. kövessetek be minket mindenhol, ahol éppen vagytok, vagy csatlakozzatok a a közösségünkhöz, a Discord csatornánkhoz, a discord.hws.hu.

Na és akkor vissza erre a témára.

Egyszer előzetesen azért elmondanám, hogy ez egy elég nehéz téma volt nekünk.

Bár egyébként papíron egyszerűnek tűnik, és egész egyszerűen azért, mert amikor vendégeket kerestük, akkor belefutottunk abba, hogy erre a té erről a témáról mindenkinek van véleménye, csak az nem egészen esik egybe azzal a véleménnyel, amit a cégében képvisel.

Tehát számos vezető ugye elmondta, amikor Zero itt beszélgettünk, inspirálódtunk a témával kapcsolatban, hogy ők hogy csinálják az egészet.

És by the way hozzáfűzte, hogy egyébként ő ezt az egésszel abszolút nem érte egyet, és szerintem baromira nem jó.

Így ugyanez lement x alkalommal, pepitába satöbbi, és ugye arról beszélk, hogy hogy hívjunk el valakit, aki egy olyan álláspontot képvisel, amiről egyébként nincs meggyőződve.

És nyilván azt meg nem, ha saját véleményét meg nem mondhatja el, mert különben a kollégá hallgatják a podcastot, és azt mondják neki, hogy de hát itt a cégben egészen mást szoktál mondani.

Úgyhogy Marcival futunk neki a témának.

Nehéz volt olyan vezetőt találni, aki munka nélkül és szívesen beszél arról, hogy mi történt korábban.

Ez kicsit megnehezítette a dolgokat. >> Így van.

Talán neked most egy viszonylag szerencsés helyzetben van, hogy most fogsz kezdeni a a >> Így igaz.

Vagyis hát egy hónapja dolgozok a a Clear Street-nél.

Ez ugye itt még nem vagyok bevonva ezekbe a folyamatokban, illetve nyilván nincs is innen még annyi tapasztalatom, amiről tudnék beszélni.

A múltból meg nyilván több fajta környezetbe, több méretű cégbe láttam már ezeket.

Szóval arról meg nagyon szívesen. >> És jelenleg még abban a szerencsés helyzetben vagy, hogy őszintén elmondhatod a véget. >> Így van.

Igen. >> És ugye itt a az elején azt mondtam, hogy ez a téma ciklikusan előkerül.

Ez csak az én benyomásom, hogy ennek van egy ilyen ciklikus visszatérése.

Elmondom, mire gondolok, hogy hogy amikor először ilyen nagyon nagy báz volt ez a téma körül, az úgy nagyjából egybeesett az agilitásnak a az eljövetelével, agilitás terjedésével, az agulis transzformációk korával.

Akkor utána amikor ez egy kicsit holdpontra jutott, akkor megint előkerült akkor, amikor a fejlesztők meg az IT csapatok már huzamosabb ideje homeofice-ban voltak, és hirtelen felmerült az, hogy úristen, nem látjuk őket, mérni kéne őket nagyon, akkor tehát megint nem lehetett hallani róla, és most ugye megint előkerül, merthogy eddig ment ez az AI hype, hogy nagyon jó, meg hatalmas siker van, és nagyon jó eredményeket érünk el vele.

Csak most úgy el kéne jutni az, hogy ezt be is kéne bizonyítani, hogy ennek van érdemi haszna, mérhető produktivitásnövetkedés érhető el vele.

És ugye a témának most megint lett egy ilyen aktualitása.

Ugye kezdjünk azzal, hogy Marci, hogy hogy szerinted milyen motivációk vannak maga a mérés mögött, vagy egyáltalán kell lemérni a fejlesztőket?

Ez most egyébként kifel egy laikus kérdés, hogy nyilván erről az a válasz, hogy igen, de benne felmerült, hogy kell-e egyáltalán mérni őket.

Szerintem ez is önmagában egy egy teljesen jogos kérdés, hogy milyen motivációk vannak.

Szerintem rengetegféle motiváció lehet emögött.

Nyilván ahogy egy cég elkezd növekedni, pláne, hogyha már mondjuk struktúraisan egy kicsit szofisztikáltabb, akkor ott már előadott, hogy hogy a cégek odafigyelnek arra, hogy legyen karrierlehetőség, legyen előremeneteli lehetőség a cégen belül.

Máskülönben az egyetlen karrier előremeneteli lehetősége az maradna, hogy hogy elmennek az ott dolgozók, kifejezetten valószínűleg a jók, akik találnak más lehetőséget, ami előrelépést jelent.

Ebből fakadóan szerintem nagyon sok cég foglalkozik azzal, hogy hogy ajánljon valamilyen karriermodellt, és ehhez nyilvánvalóan hozzákapcsolódik az, hogy mérjünk és határozzunk meg különböző szinteket.

Tehát ez lehet az egyik alapvető motiváció.

A másik vagy picit a másik irányból, hogy egy cégvezető vagy vagy menedzser vagy tulajdonos nyilván tudni szeretné azt, hogy hogy milyen teljesítménnyel üzemel éppen tulajdonképpen a az egész fejlesztés.

És tehát olyan, mint ahogy a autónál is, nem tudom ránéz az ember a műszerfalra, hogy akkor most nem tudom hány ezret pörög éppen a motor.

Úgyhogy e ez egy ez egy teljesen másik aspektus.

Talán az agilitásnál, amikor bejött az, hogy velocity, akkor ugye szerintem pláne az elején minden minden szinte mindenhol elkövették azt a hibát, vagy vagy mindenkinek felcsillant a szeme, hogy hát akkor itt rögtön lehet mérni a csapatoknak a teljesítményét, és ha az leesik, akkor az miért van, és hogy lehet amúgy másfélszeresre felvinni.

Úgyhogy nyilván ezek is, ezek is motivációk, de azt gondolom, hogy ezeken a külső faktorokon kívül amúgy egyénnek is akár egy tök jó visszajelzés lehet, hogy hogy teljesít az idő előrehaladtával, akár ő maga hogyan fejlődik, mi változik, egyebek.

És mi a mi az, amit egyáltalán lehet mérni?

Ugye ugye tehát a szakirodalma ennek azt mondja, hogy hogy a mondjuk egy fejlesztő esetében az egyént azt nem célszerű mérni, inkább a csapatban kell gondolkodni.

Ugye régebben még a hőskorban voltak a metriták, hogy amit már azért jelentősen meghaladtunk, hogy a kód hossza, a sorok hossza, satöbbi.

Ezzel már mindenki mosolyog, mert nyilván ebben nem lehet mérni az egyént, de hogy ezeken túl vagyunk, mert mit mér mit mérünk most, ha csak nyilván ennek van egy technológiai része, vannak olyan részei akár, hogy az üzletre milyen hatással van, satöbbi.

Tehát hogy mit le mit lehet egyen mérni egy fejlesztő eset?

Igen, azt valand nyúval kiegészíteném, hogy szerintem ha túl vagyunk az szerintem az nem teljesen igaz.

Tehát én elég sokat beszélgettem itt a podcastet megelőzően az utóbbi két-három hétbevezetőkkel is a túlvagyunktól, ezért szerintem ez viszonylag távol van.

Tehát azért tehát ilyenkor mindig el szoktam mondani, hogy van szerintem a technológiai szegmensnek egy ilyen viszonylag izolált része, ahol a startuperek meg a scaleupos arcok élnek.

Az szerintem az nem a teljes technológiai szegmensnek a leképezése.

Tehát, hogy itt nem egy két nem egy meg nem két olyan beszélgetés volt, ahol elmondták, hogy ott náluk konkrétan úgy mérnek, hogy tényleg ez a hát nagyjából mennyiség elven, és akkor nyilván vezetők felé megy egy mennyiségelvű matrika, meg van egy olyan, ami nem feltétlenül ezzel párhuzamosan valójában benchmarkolja az ember. hogy szakmailag már túl vagyunk rajta, de egyébként még ennek vannak nagy rés sajnos így van, >> de egyébként ez tényleg tényleg van ez, hogy egyébként el tudom képzelni egyébként, hogy van olyan speciális feladat, ahol ez egy ez egy jó metrika lehet, tehát hogy >> és az micsoda? >> Nem tudom. [nevetés] Igen, ilyen fej ilyen fejlettő favágás vagy nem tudom.

Hát amellett, hogy szerintem a nem tudom leütött billentyűk száma, vagy a kócsorok száma nagyon nehézen, vagy sehogyan sem korellál bármifajta ilyen igazán fontos outputtal.

Ö amellett biztos meg rá lehet nézni ezekre a számokra, de igen, ez ez tehát, hogy egyrészt attól, hogy sok kódot megírt valaki, az nem biztos, hogy jó lesz a cégnek.

A másik része meg az, hogyha ez egy szempont, akkor nagyon-nagyon könnyű sok sor kódban megírni valamit, amit kevésbé is meglehet.

És szinte biztos, hogy az a jó, hogyha az kevésben van megírva, amit kevésb meglehet.

Tehát innentől kezdve nagyon kontraproduktívvá válik ennek a metrikának a mérése, vagy az erre való optimalizálás.

És akkor ami ami igen az az eredeti >> kérdés >> kérdés Igen.

Hogy hogy mi mit szoktak mostanában mérni?

Hát amivel ugye én találkozok találkoztam szerintem nagyon gyakran ezek a metrikák nem is az egyént, hanem a csapatot próbálják a középpontba helyezni.

Ugye mondjuk egy scr csapatnál is mindenki arra próbál fókuszálni, hogy a csapat, mint tényleg csapatként együtt dolgozva hogyan és hogyan tudja maximalizálni igazából a a a nem tudom sprint alatt leszállítandó értéket.

Isten igazából azért sem jó egyénekre fókuszálni, mert hogyha én nem segítek neked, te sem segítesz nekem, mert minden mindannyian a saját nem is tudom leszállított vagy leszállítandó feladatainkkal foglalkozunk, akkor a szumma valószínűleg kevesebb lesz, mintogyha mi ketten megbeszélnénk valamit a csapaton belül.

Tehát ez is nyilván az egyik oka.

A másik oka, hogy hogy egy ilyen igazából szinte mindegy milyen környezetben beszélünk erről.

A csapatban általában vannak feladatmegosztások, vannak specialisták, mindenki egy kicsit más részét viszi el a a közös leszállítandóknak.

Gondoljunk akár arra, hogy productoner, ha ő is mondjuk része a csapatnak, vagy akár csak egy olyan fejlesztő, aki sokkal inkább a producttal közelebb dolgozik, és azon dolgozik, vagy az az erőssége, hogy ezt megértse, leegyeztese satöbbi.

Ő nem feltétlen fog sok kódot megírni.

Ö van aki mondjuk az az erőssége, hogy rengeteg mindent, ha le van specifikálva, akkor nagy hatékonysággal fordített kódd, hogy megint lehet, hogy valaki a kurri reviewban vesz részt, sőt általában ugye a szennyior emberek gyakran errefelé tolódnak, hogy inkább revuzzák a kódokat, minthogy mintogy ők írnák meg azokat.

Úgyhogy ezért is talán a a csapatszintű metrikák azok nagyon jellemzőek. azt mondanám, viszont valószínűleg nem lehet mindent a csapatszintű metrikákkal minden ilyen igényt kielégíteni, mert megint hogyha visszakanyarodunk arra, hogy mi a motiváció, ugye vannak olyan motivációk, amik kifejezetten arra mennek, hogy meg akarjuk érteni, hogy egy adott fejlesztő hogyan teljesít, egy egyén hogyan teljesít, hogyan fejlődik.

Tehát ezekre nyilván az ilyen csapat szintű metrikák azok nem lesznek jók.

És akkor hogy itt milyen lehetőségek vannak.

Igen, itt itt szerintem manapság is rengeteg tooling van, amik talán leggyakrabban a git meg a klasszikus szoftverfejlesztési ciklusra alapszanak, amiket lehet egyén szinten mérni.

Mondjuk a nem tudom nyitott PR-ok száma, vagy akár a merchaok száma.

Az az egy jó mutató egyébként a pó requesteknek a száma. >> Azt azt mondanám, hogy valószínűleg nem, illetve nem szabad ezeket soha önmagába értelmezni, mert tudni kell azt, hogy ki milyen szerepet viszel egy csapaton belül.

Mindegyik lehet hasznos, azt gondolom, de ezekből bármilyen képlet alapján kiszámolni és azt mondani, hogy te most nem tudom, te neked ez a scórod, vagy vagy amaz, az szerintem már egy kicsit veszélyes ugrás.

Szerintek mi miatt lehet az, hogy hogy a legtöbb vezető, amikor így off the record beszélgesz vele, az egésszel kapcsolatban rettenetesen szkeptikus?

Tehát, hogy egy kicsit így ezt az egészet most nem azt akarom, hogy elvigyük abba az irányba, hogy szétfikázzuk, de az összességében nekem az volt a kép, hogy amúgy elég lesújtó véleménnyel volt az összes vezető ezzel a a méréssel kapcsolatban.

Tehát olyan, mintha ezt így rá rájuk raknák, mint egy ilyen elvárást, és valahol mindenki tisztában lenne, hogy az amit csinálnak mérészinten, az igazából ezer sebből vérzik.

És akkor sose nem értettem, hogy akkor akkor miért görcsöl mindenki ezen, amikor nagyjából mindenkinek az volt a véleménye, hogy hát ez így ezer sebből vérzik.

A legpuhább vélemény az volt, hogy figyelj, igazából ez Gyurics ez csak egy ilyen, ez csak egy ilyen érték, ez egy szám, ami ami egy jó mankó, így amivel így meg tudom támasztani a mondanivalómat cégen belül, meg egy jó mankó a teljesítmény értékelésnél, de az olyan túl nagy hangsúlyt nem fektetek erre.

Mégis mindenki mindenki tolja.

Hát szerintem gyakran tényleg az van emögött, amit mondasz, hogy hogy jön talán nem is tudom, menedzsment szintjéről egy olyan igény, hogy ezt mérni kell, látni akarjuk, tudni akarjuk és és ho a cég egy egy nem tudom keretrendszert, vagy megvásárol valamilyen terméket, és ott aztán elkezdődik ezeknek a különböző metrikáknak a nem tudom mérése, ami valószínűleg direkt vagy indirekt pont ilyen dolgokon alapszik, mint amiket most már többször említettünk.

A pool requestek száma, kódok száma satöbbi, jobb esetben mondjuk nem is tudom 1000 sorra jutó hibák száma.

Szóval, hogy nyilván lehet nagyon sokféleképpen közelíteni ezt, de de alapvetően azt gondolom, hogy leggyakrabban ilyen jellegű kódhoz vagy kódközeli metrikákról beszélgetünk ilyen esetben.

És nyilván azért azért is szokott persze szerintem ilyen ellenérzést kelteni akár nem tudom egy középvezetőben, mert mert nehéz ezt hogy mondjam, tehát hogy talán a a motivációt azt azt gondolom, hogy meg lehet érteni, hogy mit szeretne egy nem is tudom egy top menedzser látni, hogy 1000 főre lebontva egy objektív mérőszámot, adatot, pontot satöbbi. viszont ezt így nem lehet gyakorlatilag megbízhatóan előállítani, és nyilván ez, ahogy mondod segíthet, adhat egy mankót, de azt gondolom, hogy legalább ennyire ki is gáncsolhat.

Tehát, hogy lehet, hogy valaki egy nagyon érdekes, értékes csapatjátékos, mondjuk egy középmenedzser számára egy nagyon fontos támasz a…

Említett entitások

Témák

Személyek

Szervezetek, cégek

  • Zero Aliance
  • Clear Street

Hallgasd meg

Gyakori kérdések erről az epizódról: „Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)”

Miről szól ez az epizód: „Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)”?

A HWSW podcast 69. kraftie adásában a fejlesztői produktivitás mérésének témáját járják körül. Mivel a téma ciklikusan kerül elő, most az AI elterjedésével újra reneszánszát éli. A vendégek, Böle Gyuri, Zero Aliance Batis Peti és Vaslavik Marci (Clear Street VP of Engineering)… Az epizód a HWSW podcast! című magyar podcast egyik adása, megjelenés: 2025. 11. 21..

Kik szerepelnek vagy kiket említenek ebben az epizódban: „Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)”?

Az epizódban a következő nevek szerepelnek vagy hangzanak el: Böle Gyuri, Vaslavik Marci, Batis Peti, Zero Aliance Batis Peti.

Milyen témákat érint ez az epizód: „Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)”?

Fő témái: ai produktivitás, fejlesztői produktivitás, szoftverfejlesztés.

Mikor jelent meg és milyen hosszú ez az epizód: „Az AI produktivitás mértékegysége: a jó nagy kérdőjel (kraftie #69)”?

Megjelenés: 2025. 11. 21.. Hossz: 46 perc. Az epizód a Podiverzumon hallgatható meg: https://podiverzum.hu/podcast/hwsw-podcast/az-ai-produktivitas-mertekegysege-a-jo-nagy-kerdojel-kraftie-69

Több epizód a HWSW podcast!-ből

Hasonló epizódok más magyar podcastokból