Kívülről megnézem, mi lassítja a szállítást — és megmondom, mit javítsatok először
Ahogy nő a kódbázis és a csapat, a szállítás lassul, a release-ek kockázatosnak érződnek, és senki nem tudja biztosan megmondani, melyik változtatás hozná a legtöbbet. Ilyenkor nem újabb belső vélemény kell, hanem valaki, aki kívülről nézi meg a rendszert, a pipeline-t és a döntéseket. Távolról dolgozom: videóhívások közös képernyővel a ti kódbázisotokon, a végén írásos anyaggal.
Amit tipikusan látok
Ismerős helyzetek
- A release-ek egyre kockázatosabbak, ezért egyre ritkábbak — és ettől még kockázatosabbak.
- Mindenki tudja, hogy lassú a CI, de senki nem tudja megmondani, pontosan hol megy el az idő.
- Az architekturális döntések nincsenek leírva, aki meghozta őket, már nincs a csapatban — az újaknak a kódból kell visszafejteniük a szándékot.
- Két csapat két külön konvenciót követ, és a review-n dől el, melyik nyer.
- Van egy refaktorálási terv, ami két éve nem indult el, mert sosem jön el a jó pillanat.
- A vezetés fejlesztési ütemet vár, a csapat előbb technikai adósságot törlesztene — és nincs közös nyelv, amin ezt el lehetne dönteni.
- Az infrastruktúra és a deployment törzsi tudáson múlik: egy ember tudja, hogyan megy ki élesbe.
Szállítási és architektúra-felmérés
- Végigmegyünk a jelenlegi architektúrán, a deployment környezeten és a mérnöki gyakorlatokon — arra fókuszálva, mi akadályozza ténylegesen a szállítást, és mitől kockázatos a változtatás.
- Azonosítjuk a szűk keresztmetszeteket és azokat a pontokat, ahol kis változtatás nagy hatást hoz, hogy tudjátok, hol kell először cselekedni.
- Írásos összefoglaló és konkrét, sorrendbe rakott következő lépések, amelyekre a csapat és a vezetés is tud építeni.
Döntéstámogatás
- Facilitált sessionök technikai döntések strukturált rögzítésére ADR-ek formájában, hogy az indoklás túlélje a jelenlegi csapatot.
- Segítség architekturális opciók összevetésében, kimondott trade-offok mentén — nem megérzés alapján, hanem úgy, hogy fél év múlva is védhető legyen.
- Second opinion arra, amit a csapat vagy egy szállító javasol: kívülről, érdek nélkül.
- Segítség abban, hogy a kockázatokat és korlátokat a nem technikai érintettek is érteni tudják.
Mentorálás tech leadeknek
- 1:1 vagy kis csoportos mentorálás tech lead-eknek és senior fejlesztőknek — arról, ami éppen a kezükben van, nem elméleti anyagból.
- Gyakorlati beszélgetések arról, hogyan lehet új gyakorlatokat valóban bevezetni és fenntartani: ADR-ek, határok, CI/CD — a ti kódbázisotokban, a ti csapatotokban.
- Visszajelzés architekturális javaslatokra, RFC-kre és bevezetési tervekre, mielőtt élesben derül ki, mi hiányzott belőlük.
Belépő együttműködés
Felmérés — 2–3 hét, a végén írásos anyag
Három darab 90 perces videóhívás. Az elsőn átbeszéljük, hol tartotok és mi fáj. A másodikon közösen végigmegyünk a kódbázison, a pipeline-on és az architektúrán — nem prezentációt nézünk, hanem a ti rendszereteket. A harmadikon átadom, mit érdemes javítani és milyen sorrendben. A hívások között írásban elérhető vagyok.
A végén kapsz egy írásos anyagot: mi lassítja a szállítást, mit érdemes először megfogni, és mi az, amihez most ne nyúljatok. Vezetőségnek is bemutatható formában — ugyanaz a logika, mint egy ADR-nél, csak üzleti olvasónak.
Hogyan dolgozom távolról
Minden session videóhíváson zajlik, közös képernyővel. Ahol engeditek, belenézek a kódbázisba, a CI-konfigba és a deployment scriptekbe is — read-only hozzáférés bőven elég hozzá. A sessionök között e-mailben elérhető vagyok, és ha a csapatnak úgy kényelmesebb, közös Slack csatornán is. Nem kell utaznotok, és nem kell egy teljes napot kiszakítani a csapat naptárából.
Ha ezután is kell külső nézőpont
A felmérés önmagában is kerek: a végén nem maradtok félbehagyva egy ajánlattal. Ahol viszont a bevezetés folyamatos külső szemet igényel, ott havi kerettel dolgozunk tovább — havi két session, köztük írásos elérhetőséggel. Ez nem feltétele semminek, és a felmérés után dől el, van-e értelme.
Mire mondok nemet
A tanácsadásban az a jó üzlet, ha minél tovább tart. Nálam nem ez a cél.
- Nem írok stratégiai anyagot, amit a következő tervezési körben senki nem vesz elő.
- Nem javaslok újraírást, ha a meglévő rendszer megjavítható — az újraírás a legdrágább válasz a legtöbb kérdésre.
- Nem viszek be folyamatot csak azért, mert egy nagyobb cégnél működött. A ti korlátaitokhoz igazítom, vagy nem csinálom.
- Nem veszem át a döntéseiteket. Segítek meghozni és leírni őket, de a rendszer a tiétek marad.
- Ha az jön ki, hogy nálatok most nem tanácsadás kell, hanem egy felvétel, egy eszköz vagy egyszerűen idő, ezt egyenesen megmondom.
Riport · 2026
State of AI Dev 2026
Mennyit ír már a gép, mit vett át az agent, ki ellenőrzi, és mennyi governance van mögötte? Magyar fejlesztők és mérnöki vezetők válaszai alapján.
Miért tőlem
Papp Krisztián vagyok. Tizenöt éve tervezek és építek rendszereket — kódbázisokon, pipeline-okon és architektúrákon, hands-on, nem prezentációkban. Konferenciákon és meetupokon rendszeresen beszélek ADR-ekről és arról, mibe kerül, ha a döntések nincsenek leírva. Közvetlenül velem dolgoztok: nincs mögöttem csapat, akire a munkát leadom.
Önálló fókuszterület
AI-alapú mérnöki transzformáció
Az AI eszközök azoknak a csapatoknak segítenek igazán, akiknek már szilárd mérnöki gyakorlataik vannak — a többieknél jellemzően csak gyorsítják a technikai adósság felhalmozódását. Ez külön fókuszterület: AI readiness assessment, döntéstámogatás konkrét AI-döntésekben és csapat szintű gyakorlatok.
Többet segít egy rövid leírás a jelenlegi rendszereitekről és arról, hol akadtatok el, mint egy hosszú brief.
És ha inkább képzés kell?
Ha a csapatnak nem külső nézőpont kell, hanem közös gyakorlás egy konkrét témán, arra külön workshopok vannak.
Képzések megtekintése