Árszóródás
Miért szóródnak ennyire az ajánlatok
Egy fejlesztőcég ára korábban három tényezőből állt össze. Mennyi ember, mennyi ideig, mekkora óradíjjal. A becslés mögött évtizedes tapasztalati számok álltak, egy bejelentkező felület ennyi nap, egy integráció annyi. Ezek a számok az AI kódgeneráló eszközökkel egy év alatt elavultak. Ugyanazt a funkciót az egyik csapat a régi tempóban, a másik harmadannyi idő alatt rakja össze, és mindkettő őszintén becsül, csak más eszközkészlettel dolgozik.
Ehhez jön a piac zűrzavara. Nagy Géza, aki maga is fejlesztőcéget vezet, az október közepén megjelent írásában két végletet ír le. Az egyik tábor úgy áraz, mintha az AI nem létezne, és a régi óraszámokat kéri a régi módszertannal. A másik tábor cowboy módra vállal, gyorsan, olcsón, és nem felel azért, ami a leszállítás után történik. Ezek között áll a megrendelő, és az ajánlat számaiból egyik tábort sem ismeri fel első olvasásra.
Egy tatabányai hűtéstechnikai cégnél, idén tavasszal ugyanezt éltem végig a műszaki igazgatóval. Szervizmenedzsment rendszert akartak, ami a terepi szerelők munkalapjait, az alkatrészraktárt és a számlázó programot köti össze. Két ajánlat érkezett. Az egyik 46 millió forintról és kilenc hónapról szólt, a másik 21 millióról és négy hónapról. A műszaki igazgató első mondata az volt, hogy a második cég nyilván nem értette meg a feladatot. Néhány hét múlva kiderült, hogy értette, csak másképp dolgozik.
Két reflex
A két megrendelői reflex
Nagy Géza az ügyfeleket két csoportra osztja, és ezt a felosztást a saját tanácsadói munkámban is látom. Az egyik vezető megkönnyebbül, mert olyan projekt vált megfizethetővé, amire három évvel ezelőtt nem volt pénze. A másik gyanakszik, és azt kérdezi, hogy a gyors becslés mögött van-e elég átgondolt komplexitás, és mi lesz a kóddal két év után.
Mindkét reflex jogos, és mindkettő félrevisz, ha egyedül marad. A megkönnyebbült vezető hajlamos a legolcsóbb ajánlatot elfogadni, és nem kérdez rá, mi hiányzik belőle. Aki gyanakszik, hajlamos a drágát választani, és azt hiszi, hogy a magasabb ár biztonságot vásárol, miközben lehet, hogy csak egy lassabb módszertant fizet meg. Azt tapasztaltam, hogy a jó döntés a kettő között születik, és abból indul ki, mit tud a megrendelő a becslés mögötti munkáról.
Összevetés
Hogyan olvassunk két eltérő árú ajánlatot
Amikor a cégnél a két ajánlatot egymás mellé tettük, az első dolgom az volt, hogy az árat letakartam. Komolyan, egy papírlappal. Az árral kezdeni ugyanis azt jelenti, hogy minden további sort az ár igazolásának vagy cáfolatának olvasunk, és így a terjedelemről szóló oldalak észrevétlenül átsiklanak.
Helyette négy dolgot néztünk meg. Hány funkciót sorol fel az ajánlat, és azok közül hány van tételesen becsülve. Mi szerepel a kizárásoknál, vagyis mit nem tartalmaz az ár. Milyen architektúrát ír le, és ír-e le egyáltalán. Végül mit mond a leszállítás utáni időszakról, a garanciáról, a karbantartásról, a kód átadásáról.
Az eredmény tanulságos volt. A drágább ajánlat tíz oldalon keresztül sorolta a funkciókat, de a számlázó program integrációját egy sorban intézte el, pedig a cégnél ez volt a legnagyobb kockázat. Az olcsóbb ajánlat rövidebb volt, viszont külön fejezetet szánt az integrációnak, és leírta, milyen köztes réteget épít hozzá. A drágább cég ugyanakkor két év karbantartást ajánlott fix díjjal, az olcsóbb a leszállítással befejezettnek tekintette a projektet. Így már látszott, hogy két különböző terméket áraztak, és az árkülönbség nagy része a terjedelemből jött, a hatékonyságból csak kisebb hányada.
Ezt a módszert azóta minden megrendelőnél ugyanígy alkalmazom. Két ajánlat csak akkor hasonlítható össze, ha előbb közös nevezőre hozzuk a terjedelmét, és a hiányzó tételeket mindkettőben beárazzuk. Ha ezt megtesszük, a kétszeres különbség jellemzően harmadára zsugorodik, és ami marad, az már tényleg a két csapat eltérő munkamódszere.
Módszertan
Mit kérdezzünk a becslés módszertanáról
Nagy Géza írásának egyik állítása, hogy a presales átalakult. Már az első beszélgetésen meg kell mutatnia a szolgáltatónak, hogyan becsül és milyen architektúrális válaszai vannak. Ezt a megrendelő oldaláról úgy fordítom le, hogy jogunk van megkérdezni, és aki nem tud válaszolni, annál ez intő jel.
A kérdések, amiket az ügyfeleim kezébe adok, egyszerűek. Melyik lépéseket gyorsította fel az AI a csapat munkájában, és melyeket nem. Egy jó válasz megnevezi, hogy a sablonos kódot, a teszteket, a dokumentációt generálják, az adatmodellt és az integrációs logikát viszont ember tervezi. A rossz válasz annyit mond, hogy mindent AI-val csinálnak, ezért gyorsak. Rákérdezek arra is, hogy az ajánlatban szereplő óraszám hány százaléka tervezés, hány százaléka kódolás, és hány százaléka tesztelés meg javítás. Ha a tesztelés aránya három év alatt nem nőtt, miközben a kódolás ideje harmadára esett, akkor valaki nem gondolta végig, hogy a generált kód több ellenőrzést kér, nem kevesebbet. Végül azt is tudni akarom, ki készítette a becslést, és dolgozott-e már ez az ember ugyanilyen rendszeren, mert a becslés annyit ér, amennyi tapasztalat mögötte áll.
A cégnél az olcsóbb cég vezetője erre a kérdéssorra egy óra alatt válaszolt, és a válasz nagy részét ábrán mutatta be. Ugyanerre a drágább cég egy hét gondolkodási időt kért, majd azt írta, hogy a módszertan belső tudás, amit nem osztanak meg. A műszaki igazgató véleménye ezen a ponton változott meg.
Karbantartás
Az olcsó és karbantarthatatlan kód csapdája
Leggyakrabban azt a félelmet hallom megrendelőktől, hogy gyorsan generált kódot vesznek, ami működik az átadáskor, aztán két év múlva senki nem mer hozzányúlni. Ez a félelem megalapozott, mert a generált kód mennyiségben sokszorosa lehet annak, amit egy ember írt volna, és a mennyiség önmagában karbantartási költség.
Ettől a drágább cég kiválasztása sem véd meg. Védelmet a szerződésbe írt feltételek adnak. Három ilyet szoktam javasolni. A kód a megrendelő tulajdonába kerül, forráskóddal, dokumentációval és a fejlesztői környezet leírásával együtt, úgy, hogy egy másik csapat át tudja venni. Az átadás előtt egy független fejlesztő, akit a megrendelő fizet, egy napot tölt a kóddal, és írásban mondja el, mit lát. Egy 46 milliós projektnél ez néhány százezer forint, és többet ér minden referencialevélnél. A harmadik feltétel, hogy a szállító meghatározott időszakra fix áron vállal hibajavítást, mert aki tudja, hogy a saját kódját kell majd javítania, az eleve gondosabban generál.
Tatabányán az olcsóbb cég mindhárom feltételt elfogadta, és a karbantartási díjat is beárazta utólag, így az ajánlat 21 millióról 27 millióra nőtt. Még így is a drágább ajánlat alatt maradt, és a műszaki igazgató egy ellenőrzött terméket vett, nem zsákbamacskát.
Haszon
Kinél marad a megspórolt idő haszna
Nagy Géza azt írja, hogy az AI-val megspórolt időt az ügyfélnek kell átadni, és nem rejtett haszonként kezelni. Ezzel egyetértek, a megrendelő oldaláról viszont hozzáteszem, hogy ez a haszon nem jár automatikusan, ki kell kérni.
A rejtett haszon úgy keletkezik, hogy a szállító a régi óraszámokat árazza, a munkát viszont már az új eszközökkel végzi, és a különbség nála marad. Ezt ajánlatból nem lehet kiszúrni, mert az ajánlat csak a végösszeget mutatja. Két módon lehet ellene védekezni. Fix áras projektnél kérjük el az óraszámbontást, és hasonlítsuk össze egy olyan referenciával, ami két-három évvel korábbi. Amelyik szállító azt állítja, hogy az AI felgyorsította a munkáját, annál ennek az óraszámban is látszania kell, különben csak marketing. Óradíjas munkánál pedig kérjünk havi riportot arról, mely feladatokat végezték generált kóddal, és mennyi idő ment az ellenőrzésre.
Van azonban egy másik oldala is a megspórolt időnek, és ez a megrendelő saját felelőssége. A gyorsabb fejlesztés csak akkor hoz hasznot, ha cég oldalán is gyorsul a döntés. Az első két hónapban a cégnél a fejlesztők kétszer álltak, mert a számlázó program gyártójától nem jött meg az interfész leírás, és a cégen belül senkit nem jelöltek ki, hogy sürgesse. Négy hónapos projektnél egy hét állás a teljes idő hat százaléka. A megspórolt idő ott veszik el, ahol a megrendelő a régi, kilenc hónapos ritmusban válaszol a kérdésekre.
Közös tervezés
A közös tervezés megrendelői oldala
Az átalakult presales, amiről Nagy Géza ír, a megrendelőtől is mást kér. A régi modellben a vezető megírta a briefet, elküldte öt cégnek, bekérte az árakat és választott. Ez a modell ma rossz döntésekhez vezet, mert a brief alapján adott ár szinte semmit nem mond arról, hogyan dolgozik a csapat.
Amit helyette javasolok, az egy fizetett tervezési szakasz két vagy három kiválasztott szállítóval. Egy-két hét, ami alatt a szállító a cég valós környezetében dolgozik, megnézi a meglévő rendszereket, beszél a felhasználókkal, és a végén árat, architektúrát és becslési módszertant egyszerre tesz le az asztalra. Ennek a díja a projekt értékének egy-két százaléka, és a cégnél ez a két hét döntötte el a választást. Az egyik cég a tervezési szakasz végén ugyanazt az árat mondta, mint az első ajánlatban, mert nem tanult semmit a helyszínen. A másik tíz százalékkal emelt, mert megtalálta azt a két integrációs pontot, amit a brief nem említett, és ezt le is írta.
Ez a fajta közös tervezés a megrendelőnek is munka. Ki kell jelölni egy embert, aki a szállító kérdéseire napokon belül válaszol, oda kell adni a hozzáféréseket, és el kell viselni, hogy a tervezés végén kiderül, a saját brief hiányos volt. Cserébe a vezető látja, hogyan gondolkodik az a csapat, akire a következő egy évet bízza, és ez többet mond, mint bármelyik papír.
Hitelesség
Hitelesség kiszámlázott órák nélkül
Nagy Géza úgy zárja a gondolatmenetét, hogy a hitelesség ma nem a kiszámlázott órákon múlik, hanem az átlátható közös gondolkodáson. A megrendelő oldaláról ez azt jelenti, hogy az óraszám elvesztette a bizonyító erejét. Egy ajánlat, ami sok órát mutat, már nem jelenti azt, hogy alapos, és ami keveset mutat, az nem feltétlenül felszínes.
Ami helyette hitelesít, az megfigyelhető viselkedés. A szállító elmondja, mit csinál az AI és mit az ember. Megmutatja az architektúra ábráját, és meg tudja indokolni, miért ezt választotta. Elfogadja a független kódátnézést. Beárazza a karbantartást. Nem ijed meg attól, hogy a tervezési szakasz végén a saját becslését módosítania kell. Ezek mind olyan jelek, amiket egy nem informatikus vezető is felismer, ha tudja, mit keres.
A projekt szeptemberben élesedett, négy és fél hónap után, 27 millióért. Három hét alatt átálltak a terepi szerelők, a számlázó integráció az első hónapban kétszer hibázott, és a szállító mindkettőt a fix díjas karbantartásból javította. Azóta a műszaki igazgató a két eredeti ajánlatot példaként mutatja a kollégáinak, mert a kettő közül az egyik hajlandó volt megmutatni a munkáját, és ezt a hajlandóságot vették meg, nem az árcédulát. Az ár szétesett, a döntés módszere viszont összeállt, és ez a módszer a megrendelő kezében van.
Ez az írás Nagy Géza 2026. október 20-án megjelent LinkedIn Pulse cikkére reflektál a megrendelői oldalról, a cikk címe „Az új szabály, hogy nincs szabály. Hogyan forgatta fel az AI nemcsak a kódolást, hanem az ajánlatadást és az árazást is?”.