Mérnöki esettanulmány
Egy működő éles rendszer megérkezik egy mappában. A készítői már nincsenek meg, specifikáció sosem létezett. Ez a beszámoló arról szól, hogyan lehet megérteni, újraépíteni, és úgy visszaadni, hogy az átvevő fél egyedül fel tudja állítani és le tudja ellenőrizni.
Egy biztosító termékkezelő és biztosításkötési rendszere — AngularJS frontend PHP backenden, nyilvános weboldalba illesztve — érkezett át modernizációra. Két fejlesztő, AI-asszisztáltan, 234 nap alatt, amiből 96 hordoz commitot. Az eredmény 125 769 sor forráskód és 991 137 sor dokumentáció.
Olvasd el még egyszer az utolsó két számot. Nagyjából nyolc sor dokumentáció minden sor forráskódra. Egy új rendszert építő projektnél ez az arány képtelenség lenne. Itt viszont ez a munka alakja.
Az ügyfél nem kódot vett. Kódja már volt — működő, éles, évek óta. Ami hiányzott neki, és ami miatt nem mert hozzányúlni semmihez, az a megértés. A megértésnek pedig nincs más formája: vagy dokumentációként létezik, vagy sehogy. Egy átvételnél a dokumentáció maga a szállítmány, és az arány egyszerűen ennek az ára.
Mindezek előtt volt egy felvonás, amivel senki nem tervez. Az örökölt rendszer nem volt konténerizálva, és üzembehelyezési dokumentáció semmilyen formában nem létezett hozzá — így az első munka nem a megértése volt, hanem az, hogy reprodukálhatóvá tegyük: nulláról felállítani, kísérletezéssel, amíg kétszer megfigyelve ugyanazt nem adta.
Aztán három felvonás, és a legtöbb legacy-projekt épp az egyik kihagyásán bukik el. Megismerni a rendszert, és bizonyítani, hogy megismerted. Úgy újraépíteni, hogy az újraépítés az eredetihez mérve ellenőrizhető legyen, ne csak szebb. Aztán úgy visszaadni, hogy az átvevő nélküled is futtatni és ellenőrizni tudja — ami önálló mérnöki feladat, nem az utolsó commit utáni pillanat.
Az ügyfél rendszeréből semmi nem szerepel ezen az oldalon: se képernyő, se sémaobjektum, se üzleti szabály, se pénzügyi adat. Az eredeti dokumentálása közben készült felvételek meg vannak számolva — 539 darab —, és egy sem látható. Az ügyfél nincs megnevezve, és a piaci szegmense sem.
A kiindulópont egy mappa volt. Benne: a legacy adatbázis a szerkezetével és az adataival, az eredeti alkalmazás forráskódja mindkét oldalról — egy AngularJS egyoldalas frontend és egy PHP backend, WordPress shell-oldalon kiszolgálva —, az inicializáló és seed szkriptek, és a díjtáblák két formátumban.
Ami nem volt benne, az többet számít. A rendszer semmilyen formában nem volt konténerizálva, és üzembehelyezési dokumentáció egyáltalán nem létezett — semmi arról, hogyan kell felállítani, mitől függ, hogyan van a környezete konfigurálva. Egy futó éles rendszer létezett valahol; a reprodukálásának módja nem.
Mielőtt egyetlen viselkedést dokumentálni lehetett volna, az örökölt rendszert reprodukálhatóvá kellett tenni. Ez azt jelentette: nulláról konténerizálni, és kísérletezéssel kideríteni a környezetét, a karakterkódolását és az inicializálását — nagyjából 400 fájlnyi környezeti munka, amiből se dokumentáció, se termék nem lett.
Ez az, amit egy átvételnél a legkönnyebb kihagyni a tervből, és ami nélkül minden más lehetetlen. Nem lehet olyan viselkedést dokumentálni, amit nem tudsz kétszer megfigyelni.
Mindezzel együtt sem volt specifikáció. Egy futó rendszer a forrásával együtt megmondja, mi történik; azt nem, hogy minek kellene történnie — és végképp nem azt, hogy a viselkedéseiből melyik döntés, és melyik olyan véletlen, amihez évek óta senki nem mert hozzányúlni.
Az adatmodell alatta rétegzett volt: alul a törzsadatok, fölötte a termékszerkezet, azon a termékfüggő konfiguráció, ahol a díjszámítási és pótdíjszabályok élnek, legfelül az üzleti modulok. Ez a rétegzettség az oka, hogy egy ilyen rendszer érinthetetlenné válik. Egy alsó szabály módosítása olyan utakon ér fel a felszínre, amiket senki nem térképezett fel — így végül senki nem módosít semmit, és a rendszer kezdi diktálni az üzlet tempóját, nem fordítva.
Ez az egyik ára egy megmagyarázhatatlan rendszernek. Nem a karbantartási számla — hanem a döntések, amiket emiatt nem hoznak meg.
A kényelmetlenség nem szabadít fel büdzsét. Az szabadítja fel, amikor maga a stack válik kizáró okká: amikor az üzletet olyan követelmény köti, aminek a rendszer nem körülményesen, hanem egyáltalán nem tud megfelelni.
| Aminek a régi stack nem tudott megfelelni |
|---|
| Támogatási életciklusukon túllépett futtatókörnyezetek és keretrendszerek |
| Biztonsági és megfelelőségi kötelezettségek, amiket a stack nem tud teljesíteni |
| Üzemeltethetőség — semmi nincs konténerizálva, semmi nem reprodukálható |
| Illesztés olyan rendszerekhez, amelyek mai interfészeket várnak |
| Egyre szűkülő kör, aki hajlandó karbantartani |
Ezek nem preferenciák. Egy támogatás nélküli futtatókörnyezet nem „régi", hanem olyan komponens, ami soha többé nem kap biztonsági javítást — egy rendszerben, ami mások adatait kezeli. Ez az az érv, amit aláírnak, és érdemes kimondani, mert az a modernizációs javaslat, ami fejlesztői kényelemre épül, megérdemli, hogy alulmaradjon ezzel szemben.
A „gyorsabban megírja-e az AI" rossz kérdés, és a legtöbb beszámoló épp erre válaszol. Egy átvételnél nem a kódírás sebessége a szűk keresztmetszet. Az első napon nincs is mit biztonságosan írni, mert semmi nincs annyira megértve, hogy egy változtatásról bizonyíthatóan tudni lehessen: nem árt.
Az igazi kérdésnek két fele van, és a második a nehéz:
Hogyan ismersz meg egy rendszert, amit már senki nem tud elmagyarázni — és hogyan bizonyítod, hogy megismerted, magadnak és annak, aki fizet?
A bizonyítás azért számít, mert a megértés láthatatlan. Az a fejlesztő, aki elolvasta a kódot, magabiztosnak érzi magát — és ez az érzés megkülönböztethetetlen attól, amit egy félreértő fejlesztő érez. Az egyetlen különbség, ami túléli a valósággal való találkozást: le volt-e írva olyan formában, amit valaki más ellenőrizni tud.
Ezért készültek az első felvonásban dokumentumok kód helyett — és ezért lettek auditálva, nem csak megírva.
A reverse engineering termékként futott, nem előkészületként. Minden terület kapott pontos hatókört, és készültségre lett követve — több esetben átlagos auditpontszámmal, nem pipával.
| Terület | Dokumentálva |
|---|---|
| Adatbázis-táblacsoportok | 32 / 32 |
| Önálló adatbázis-auditok | 33 |
| Képernyő-dokumentumok | 142 / 142 |
| Funkció-dokumentumok | 25 / 25 |
| Frontend-dokumentumok | 25 / 25 |
| Backend-dokumentumok | 14 / 14 |
A viselkedést nem csak leírták, hanem rögzítették is. Ahol egy képernyő szöveges leírása kétféleképpen olvasható, ott egy felvétel a futó eredetiről eldönti a kérdést. Ezek a felvételek az újraépítést végző számára bizonyítékok, nem az olvasónak szánt illusztrációk — ezért számolja meg őket ez az oldal, és ezért nem mutat egyet sem.
Az arány egy átvétel őszinte mércéje. Az a projekt, amelyik egy dokumentálatlan rendszer átvétele után vékony dokumentációról számol be, nem csinálta meg az első felvonást; átugrott a másodikra, és most fog újraimplementálni olyan viselkedéseket, amelyeket sosem értett meg — a véletleneket is beleértve.
Az újraépítés a díjszámító motorral kezdődött, amit a projekt saját terve a rendszer szívének nevez. Ha a magot építed meg először, önállóan, akkor az a rész, amitől minden más függ, készen és tesztelhetően áll, mielőtt bármi ráépülne. Ráadásul a legnehezebb üzleti logika egyetlen, még átlátható komponensbe sűrűsödik.
Aztán a két fél — és itt jön az a mechanizmus, amitől az egész újraépítés ellenőrizhető, és ami ebből a beszámolóból a leginkább átvehető.
A tesztkészlet készült el először, a még futó eredetire írva. Ez az invariáns. Mindegyik felet külön cserélték, és minden így keletkező konfiguráció ugyanahhoz a változatlan készlethez mérődött.
Az eredeti AngularJS-t futtatott PHP-n, egy WordPress shell-oldalon belül. A végállapot React Node-on, ugyanabban a shellben. Mindkét köztes konfiguráció is megépült és tesztelve lett — AngularJS Node-on, illetve React PHP-n —, és ez az, ami egy ugrásból két külön, ellenőrizhető lépést csinál. A szabály egyszerű: soha nem cserélni mindkét felet egyszerre. Amikor egy konfiguráció pirosra vált, egy lehetséges oka van, nem kettő.
Egyik köztes sem állványzat. Mindegyik fut, átmegy a készleten, és úgy, ahogy volt, szállítható is lett volna — ettől lesz biztonságos félúton megállni, ami egy ügyfélprojektnél nem elméleti tulajdonság. A keretek és a prioritások mozognak.
Egyszerre egy változót cserélni csak akkor jelent valamit, ha minden más tényleg állandó. Három dolog volt rögzítve az egész útvonalon: az adatbázis, amit soha nem migráltak; egy fizetési szolgáltató-emulátor a valódi fizetési szolgáltatás helyén; és egy levélfogó élő SMTP-szerver helyett.
Az utóbbi kettő nem kényelmi kérdés. Az a teszt, ami valódi fizetési szolgáltatóhoz nyúl, nem megismételhető, és nem is szabadna lefuttatni; az, amelyik valódi e-mailt küld, még rosszabb. Minden külső függőség kiváltása valami kiszámíthatóval a nulladik felvonás második fele — és ez az oka, hogy a készlet felügyelet nélkül, bármelyik környezetben, akárhányszor futtatható volt.
Egy újraírásnak rendesen nincs orákuluma. A régi és az új közti minden eltérés vagy javítás, vagy regresszió — és eldönteni pont azzal a tudással lehetne, ami az induláskor hiányzott.
Ha a készletet az eredetire írod, azzal az orákulumot még akkor hozod létre, amíg az eredetit meg lehet kérdezni. Ez fogyó eszköz: azon a napon, amikor az eredetit lekapcsolják, a „mit kellett volna csinálnia" kérdésre örökre elérhetetlenné válik a válasz. Írd le a kérdéseket, amíg van, ami válaszol rájuk.
Az újraépítés meg lett tervezve, mielőtt megíródott volna, számozott fázisokban, fázisonkénti auditpontszámmal: 17 fázis a motor első generációjához, 13 a másodikhoz, és 15 javítási terv a kettő között. Ezen felül készült egy teljes rendszerterv a későbbi teljes újraíráshoz, auditálva: 16 dokumentum, 13 fázis, 5 mérföldkő, egy modern szerver-keretrendszerre, React-alapú frontendre és PostgreSQL-re.
Egy technológiai stack megnevezése senkit nem azonosít, és épp ez az a rész, amit az olvasó használni tud. A terv pénzügyi adatai az ügyfélé, azok itt nem szerepelnek.
Ezt a felvonást a legtöbb projekt egy délutányi fájlmásolásnak tekinti — pedig ez dönti el, hogy az összes többi megérte-e.
Az átadás nem publikálás. Az átadás az, hogy az átvevő fél a saját környezetében fel tudja állítani a rendszert, és le tudja ellenőrizni — anélkül, hogy az építője a szobában lenne.
Ennek van alakja, és az alaknak valódi munka az ára.
| Artefaktum | Darab |
|---|---|
| Önállóan átadható csomag | 8 |
| Megépített és tesztelt stack-konfiguráció | 4 |
| Elfogadási kör, mindegyik teljes átfutás | 5 |
| Átadási issue | 139 |
| Átadási implementációs terv | 92 |
| Környezeti konfigurációs fájl | 44 |
| Átadási tesztszkript | 52 |
| CI-pipeline fájl | 23 |
| Átadási koncepció és riport | 54 |
És az átadás ott zárult, ahol kellett: az ügyfél saját verziókövetőjébe mergelve és ott tagelve. Nem zip-fájl, nem megosztott meghajtó. A munka abba a rendszerbe került, amit az átvevő fél amúgy is használ, olyan állapotban, amit meg tud nézni, vissza tud vonni és folytatni tud.
Két hibafolyam futott, és nem ugyanott végződtek. Erről a különbségről érdemes pontosan beszélni, mert az őszinte változat hasznosabb, mint a szép.
A kívülről jelzett hibák — amiket a leszállított rendszert tesztelők találtak — mind javítva lettek, és mind vissza is lettek jelezve. Ez a hurok le van zárva. Az a hiba, amit kijavítottak, de sosem erősítettek meg annak, aki jelezte, nincs lezárva; csak elcsendesedett.
A projekt saját belső tesztelése által talált hibák nincsenek mind javítva. Néhány nyitva áll annál a pontnál, ahol ez a beszámoló készült. Ezt kimondani semmibe nem kerül, és megveszi az egyetlen dolgot, ami egy ilyen jelentésben számít: hogy a többi állítás elhihető legyen.
Az auditkörök megmutatják az alakzatot. Az újraépített backenden egy első kör 50 felvetett tételt vizsgált meg, és ebből 17-et erősített meg és javított — vagyis a felvetések kétharmada nem bizonyult hibának. Egy későbbi revalidációs kör újravizsgálta ezt a 17-et, és 0 nyitottal zárta. A frontend négy ilyen körön ment át.
Ezen felül egy lefedettségi kampány 604 alkalommal futtatta a végponttól végpontig tesztkészletet 12 környezeti konfiguráción, és 12 hibát hozott felszínre. Az a tesztkészlet, ami mindig ugyanabban a környezetben fut, ezt a hibaosztályt egyáltalán nem tudja megtalálni.
A munka két gépen futott, szándékos határvonallal közöttük.
A munkameneten belül a munka felokosított subagentekre bomlott, feladatonként egyre. Ami nem létezett: állandó, egymással egyeztető szerep-munkamenetek, amelyek mindegyike rögzített felelősséget visz hosszabb távon.
Ez nem preferencia volt. Amikor ez a projekt futott, az ügynökök még nem tudtak egymással egyeztetni anélkül, hogy egy ember állt volna középen üzenetbuszként — egy emberi üzenetbusz pedig körülbelül háromnál nem skálázódik tovább. Amíg ez így volt, az elérhető egység a gépszintű szétválasztás plusz a subagentek volt, és pontosan ez épült meg.
Sosem az ambíció volt a szűk keresztmetszet. Az eszköz volt.
Ez a beszámoló ezért dátumozott pillanatkép, nem általános érvényű állítás. A projekt 2025 novemberében indult, és azóta elmozdult, hogy egy ilyen felállás meddig juthat. Nézd meg a mérés dátumát, mielőtt következtetsz belőle.
A gyakorlati tanulság túlmutat ezen az eszközkészleten: amikor egy módszer megakad, a szűk keresztmetszet gyakran nem a fegyelem, hanem az, amit az eszközök koordinálni engednek. Érdemes tudni, melyikkel van dolgod — mert csak az egyik javul attól, ha jobban igyekszel.
Első commit 2025-11-20, utolsó 2026-07-12: 234 eltelt nap, ebből 96 hordoz commitot, 482 commit és 28 tagelt kiadás mentén.
A két üres hónap annak számít, aki tervezni akar. Az eltelt idő az ügyfélmunkában nem ráfordítás; az ráfordítás plusz az ügyfél elérhetősége, és a második rendszerint a nagyobb tag. A 234 napot úgy idézni, mintha 234 munkanap lett volna, számtani hazugság.
Szándékosan rövid: ez a beszámoló bizonyítéka, nem maga a beszámoló.
| Mérés | Fájl | Sor |
|---|---|---|
| Dokumentáció | 2 490 | 991 137 |
| Forrás | 644 | 125 769 |
| Teszt | 223 | 50 262 |
| Adatbázis-szkript | 43 | 12 152 |
| Shell-automatizálás | 154 | — |
| Viselkedés-felvétel (nem látható) | 539 | — |
| Összes követett fájl | 4 597 | — |
A dokumentáció nagyjából három részre oszlik: az újraépítés specifikációi, az eredeti rendszer reverse-engineering feljegyzései, és az átadási anyag — utóbbi önmagában több száz dokumentum.
| Készlet | Eredmény |
|---|---|
| Újraírt frontend, unit | 96 / 96 |
| Portolt backend, unit | 67 / 67 |
| Kötési varázsló, végponttól végpontig | 8 / 8 |
| Validációs készlet | 20 / 20 |
| Bejelentkezési folyamat, végponttól végpontig | 47 / 56 |
Ezek a készletek nem mellékesek. A végponttól végpontig tesztek ugyanazok, amiket az eredeti AngularJS–PHP rendszerre írtak, változatlanul — ettől jelent valamit egy olyan szám, hogy 8 / 8. Nem azt jelenti, hogy „az új kód átmegy a saját tesztjein", hanem azt, hogy „az új kód ugyanúgy válaszol azokra a kérdésekre, amikre a régi válaszolt".
Az utolsó sor az érdekes. Azért szerepel itt, mert ott is szerepelt — a projekt saját státuszsorában, a saját README-je tetején, ahol bárki, aki megnyitja a munkaterületet, először találkozik vele. Az a csapat, amelyik a legrosszabb számát oda teszi, ahol nem lehet nem észrevenni, olyan csapat, amelynek a jó számai érnek valamit.
A helyesség három lábon állt, nem egyen: unit tesztek az újraépített komponensek körül, végponttól végpontig futások a valódi folyamatokon, és auditkörök, amelyek az eredményt attól függetlenül vizsgálták, aki előállította — beleértve azt a kétharmadot is, ami végül nem bizonyult hibának.
Az örökölt rendszerhez nulla automata teszt tartozott. Most 50 262 sor van belőlük, 223 fájlban.
Ezt senki nem vette meg. Melléktermékként keletkezett abból, hogy orákulumra volt szükség — és mivel a készlet az eredetire íródott, azt a viselkedést írja le, amire az üzlet ténylegesen támaszkodik, nem az újraírásét. Túléli az összes implementációt, amit ellenőrizni használtak, azokat is, amik még csak ezután jönnek.
A projekt fázishatáron állt meg, és a nyilvántartás ezt nyíltan ki is mondja.
A megértés, a minimálisan működő mag, a frontend újraépítése és a backend portolása elkészült, ahogy a későbbi teljes újraírás rendszerterve is. Magának a tervnek az implementációja és a mögötte álló adatmigráció tervezettként van rögzítve, nem késznek. El sem kezdődtek.
A hibák terén a helyzet aszimmetrikus, és érdemes pontosan kimondani:
Kívülről jelezve: mind javítva, mind visszajelezve. Ez a folyam le van zárva.
Belső teszteléssel találva: nincs mind javítva. Néhány nyitva áll.
Az aszimmetria döntés, nem mulasztás. Az a jelzés, ami a szállításra támaszkodó emberektől jön, az ő munkájukat akasztja meg, és csak akkor záródik, ha megtudják, hogy kész. Az a jelzés, amit a csapat saját maga ellen vet fel, ugyanazokért az órákért verseng, mint minden más — és néhány veszít. A kettőt egyetlen számként jelenteni épp azt a különbséget rejtené el, amire az olvasónak szüksége van.
Ebből semmi nem mentegetőzés. Az a projekt, amelyik pontosan meg tudja mondani, melyik felvonást fejezte be, melyiket tervezte csak, és milyen jelzéseket cipel még, ugyanazt a fegyelmet mutatja, mint az, amelyik bizonyítani tudja, mit szállított.
Ebből kevés specifikus a biztosításra vagy erre a stackre. Négy dolog átvihető.
Megérteni, újraépíteni, átadni — ebben a sorrendben. Hagyd ki az elsőt, és hűségesen újraimplementálsz olyan hibákat, amiket sosem ismertél fel hibaként, mert belülről nézve egy véletlen és egy döntés ugyanúgy néz ki. Hagyd ki a harmadikat, és az ügyfélé lesz egy kód, amit nem tud futtatni — ami az ő oldaláról megkülönböztethetetlen attól, mintha semmije nem lenne.
Számíts a forrással összemérhető dokumentációra — átvételnél pedig arra, hogy jelentősen meghaladja: itt nagyjából nyolcszorosan. Ha a tervedben a „dokumentáció" sor a ráfordítás öt százaléka, akkor a terved egy zöldmezős projekté, ami átvételnek öltözött.
Fel tudja állítani az átvevő fél a saját környezetében, abból, amit adtál, úgy, hogy te nem vagy elérhető? Hozza minden csomag a saját konfigurációs sablonját és a saját tesztjeit? Bizonyítottad egynél több kombinációban? A munka az ő verziókövetőjükbe kerül, tagelve? Ha bármelyikre nem a válasz, akkor az átadás remény, nem mérnöki artefaktum.
Amíg az eredeti még fut, olyasmid van, ami egy zöldmezős projektnek soha: egy referencia-implementáció, ami minden kérdésre válaszol a szándékolt viselkedésről. Ez fogyó eszköz.
Tehát tedd el. Írd meg a tesztkészletet az eredetire, mielőtt bármit megváltoztatnál, aztán cseréld a rendszer egyik felét egyszerre, és minden köztes állapotot ugyanahhoz a készlethez mérj. Két független csere egy egyidejű ugrás helyett; egyetlen lehetséges ok, valahányszor elromlik valami; és egy szerződés, ami túléli az összes eldobott implementációt.
Ha egyetlen dolgot viszel el ebből a beszámolóból, ezt vidd. Két hetet kóstál az elején, és kiveszi a „ez most eltérés vagy hiba?" kérdést a projekt egész hátralévő részéből.
Nagyjából nyolc sor dokumentáció soronként nem kerekítési hiba egy költségvetésben. Az a költségvetés nagy része. Aki átveszi ezt a megközelítést, tervezze be az első felvonást őszintén, és számítson rá, hogy meg kell védenie — mert épp ez az a felvonás, amiből nem lesz futó szoftver, tehát ezt a legkönnyebb kihúzni. És a kihúzása az, ami egy modernizációból félreértések nagyon drága újraírását csinálja.
Hogy egy rendszeren hatékony-e az AI-asszisztált munka, az nem a modelltől függ. A rendszer három tulajdonságától:
| Feltétel | Örökölt | Újraépített |
|---|---|---|
| Reprodukálható környezet — felállítható igény szerint, és ugyanúgy viselkedik | nem | igen |
| Leírt megértés — amit csinál, dokumentumként létezik, nem csak egy fejben | nem | igen |
| Tesztekbe zárt viselkedés — egy változás megmutatható, nem csak érvelhető | nem | igen |
Az örökölt rendszernek egyik sem volt meg. Az újraépítettnek mind a három — nem célként, amit valaki kitűzött, hanem annak következményeként, hogy a három felvonás rendesen megtörtént.
Ez válaszolja meg a kérdést, amit az arány felvet. A dokumentáció nem egyszeri költség, amit a szállítás megtérít. Az az alapréteg, amitől minden későbbi változtatás olcsó lesz — bárki, vagy bármi végzi is.
Ezt érdemes megérteni, mielőtt valaki eldönti, megfizethető-e az első felvonás. Az a rendszer, ami dokumentálatlanul, tesztek nélkül és reprodukálhatatlanul érkezik, örökre drága lesz megváltoztatni, és minden halasztott év tovább súlyosbítja. Ugyanaz a rendszer ezzel a három tulajdonsággal ugyanúgy karbantartható és továbbfejleszthető, ahogy újraépült — ugyanazon a tempón, bárki jön utána. A modernizáció a látható szállítmány. Az, hogy mennyibe kerül ezután megváltoztatni, a maradandó.
A módszer megállapítja, mit csinál egy rendszer, és ellenőrizhetően újraépíti. Azt nem dönti el, hogy az üzlet még akarja-e azt a viselkedést. Minden hűségesen reprodukált szabály egyben egy hűségesen reprodukált, évekkel ezelőtti döntés is — és néhányat inkább megkérdőjelezni kellene, mint átportolni. Ez a beszélgetés az ügyfélé, és a második felvonás után van a helye, amikor végre van valami mérhető, amin változtatni lehet.
Az ítélőképességet sem váltja ki. Az első auditkörben felvetett tételek kétharmada nem volt hiba. Valakinek el kellett döntenie, melyik harmad a valódi.
A legtöbb cégnek nincs zöldmezős projektje. Van egy rendszere, ami működik, amit senki nem ért teljesen, és ami csendben eldönti, mit tud és mit nem tud legközelebb megcsinálni az üzlet. Ha ez ismerős — vagy ha te is vittél már ilyet, és másképp mesélnéd el — érdekel az összevetés. Erb Ferenc a LinkedInen
Két fejlesztő: Erb Ferenc és Villányi László.