A fejlesztői onboardingot rendszerint azzal mérik, meddig tart a formális beléptetés, ez viszont a probléma rossz vége. Az a szám számít, hogy mennyi idő telik el addig, amíg egy új mérnök meg tud változtatni valamit úgy, hogy biztos lehet benne: semmi mást nem tört el. A legtöbb csapatnál ez hónapokban mérhető, nem napokban.

A késés ritkán az emberen múlik. Azon múlik, hogy a rendszerből mennyi létezik kizárólag mások fejében, és hogy az első két hétből mennyi megy el arra, hogy ezt egyenként, megszakításról megszakításra kiszedjék onnan.

Az egyetlen mérőszám, amit érdemes követni: mennyi idő telik el az első változtatásuk éles indulásáig. Nem az első commit, ami lehet egy elgépelés javítása is, hanem egy olyan módosítás, ami számított, és élesbe került. Ha ez több mint egy hét, az akadály szinte soha nem a képesség. Hanem egy telepítési folyamat, amit senki nem futtatott végig nulláról mostanában, vagy egy kódbázis, amelynek a belépési pontjai kalauz nélkül megtalálhatatlanok.

Mivel versenyez a fejlesztői onboarding

Három költség, és ezek közül csak az egyik az új ember ideje.

Az ő ideje, a látható, amit mindenki optimalizálni akar. A csapat ideje, mert minden kérdés félbeszakít valakit, aki éppen mást csinált, és ez a tétel nagyobb az elsőnél. És a soha fel nem tett kérdések ára, amikor egy új mérnök inkább tippel, mint hogy aznap délelőtt ötödször is zavarjon, a tipp pedig úgy rossz, hogy az csak két hónappal később derül ki.

Ez a harmadik tétel az, amit a jó onboarding valóban megszüntet. A dokumentációt nem azért érdemes megírni, mert az olvasás gyorsabb a kérdezésnél, hanem azért, mert így este tizenegykor is ki lehet deríteni a választ anélkül, hogy bárkinek mérlegelnie kellene egy újabb kérdés társas árát.

Először a környezetet hozza rendbe

Az első hetet leginkább az dönti el, hogy a projekt elindul-e egy tiszta gépen, külső segítség nélkül.

A csapatok ezt következetesen alábecsülik, mert mindenkinek van már működő környezete, és két éve senki nem épített újat. Közben a telepítési leírás egy olyan verzióra hivatkozik, ami azóta továbblépett, kihagyja azt a környezeti változót, amit valaki tavasszal vett fel, és feltételez egy szolgáltatáshoz való hozzáférést, amit az új ember soha nem kapott meg.

A megoldás látványtalan. Kövesse a következő belépő a leírást pontosan, változtatás nélkül, és jegyezzen fel minden pontot, ahol az elakad. Ez a lista a valódi telepítési folyamata. Még jobb, ha egyetlen parancsra szűkíti, ami futó rendszert állít elő használható tesztadatokkal, mert minden kézi lépés olyan lépés, ami el fog csúszni.

A hozzáférések a környezet részei. Aki megkapta a kódot, de nem kapta meg a repository jogosultságait, a staging belépési adatait vagy a feladatkövetőt, az nincs beállítva. A fiókokat a kezdés napja előtt készítse elő, ahelyett hogy a hiányokat az első reggelen fedezné fel.

Adjon azonnal valódi feladatot

Az az ösztön, hogy az új embert két hétig meg kell óvni az igazi munkától, jó szándékú és visszafelé sül el. Egy kódbázist cél nélkül olvasni nagyon keveset tanít, mert nincs mihez kötni az olvasottakat.

Egy kicsi, valódi, kiszállítható módosítás a második vagy harmadik napon a teljes szállítási utat megtanítja: hol van a kód, hogyan futnak a tesztek, hogyan zajlik a review, hogyan történik a deploy, és kinek kell szólni. Éppen erre az útra van a legnagyobb szüksége egy új mérnöknek, és éppen ez az, ami a legkisebb eséllyel van leírva bárhol.

Olyat válasszon, amire tényleges felhasználó vár, ne kitalált gyakorlatot. Az emberek érzik a különbséget, és a különbség dönti el, komolyan veszik-e a visszajelzést.

Utána üljenek neki közösen. Egy óra valaki mellett, aki ismeri a rendszert, többet ad át, mint egy nap olvasás, és aki a párban a tapasztaltabb, rendszerint maga is felfedez valamit a saját kódbázisáról.

Mit írjon le, és mit ne

A dokumentáció romlik, ezért csak azt írja le, ami igaz marad, és megtéríti a karbantartását.

Érdemes leírni: hogyan kell a rendszert telepíteni és elindítani, hogyan kell deployolni, milyen alakú az architektúra és miért ilyen, azokat a döntéseket, amelyeket egyébként újra és újra elővennének, és hogy ki miért felel. A technikai dokumentációról szóló útmutatónk részletesebben foglalkozik a karbantartás kérdésével.

Nem érdemes leírni: mindazt, amit a kód már világosan kimond, a havonta változó képernyők lépésről lépésre végigvezetését, és a kézzel karbantartott, teljes API-referenciákat. Ezek avulnak a leggyorsabban, és ezek vezetnek félre a legjobban.

A legtöbb csapatnál a legértékesebb dokumentum egy rövid architektúra-áttekintés, ami elmondja, mik a nagy darabok, és miért lettek szétválasztva. Egy délutánba kerül, ritkán változik, és megválaszolja azt a kérdést, amelynek rekonstruálásával minden új mérnök az első hetét tölti.

Az onboarding a csapat vizsgája

Minden, amivel egy új ember küzd, olyasmi, amit a csapat láthatatlanul elnyelt eddig.

Ha a telepítés három napig tart, ez a költség mindig is megvolt, kis részletekben fizette mindenki, aki valaha újrarakott egy gépet. Ha senki nem tudja megmondani, miért létezik egy komponens, ez a homály régóta döntésekbe kerül. Ha a deploy folyamathoz egy konkrét ember kell, ez a függés már korábban is kockázat volt, és ugyanez bukkan elő a technikai átvilágítás során és minden komoly helyreállítási tervben.

Kezelje tehát az első heteket ingyenes auditként. Kérje meg az új embert, hogy vezessen listát mindenről, ami összezavarta, és a listát backlogként olvassa, ne a képességeiről szóló véleményként. Ez a legőszintébb leírás a rendszeréről, amit valaha bárki elkészít, mert két hónap múlva már ő sem fogja észrevenni.

A Mecanik a szoftverfejlesztési munkánk részeként rendszeresen száll be meglévő kódbázisokba, vagyis ezt a vizsgát hivatásszerűen írjuk meg mások rendszerein. Azok a csapatok, amelyek gyorsan tanítanak be, nem a legjobb dokumentációval rendelkeznek. Hanem azok, ahol valaki nemrég újraépítette a saját környezetét, és megjavította, ami közben eltört.

Gyakran ismételt kérdések

Mennyi ideig tartson a fejlesztői onboarding? Azt mérje, mennyi idő telik el az első érdemi, élesbe kerülő módosításig, ne a beléptetés hosszát. Ha ez több mint egy hét, az akadály ritkán a képesség. Rendszerint egy telepítési folyamat, amit senki nem futtatott végig nulláról mostanában, vagy egy kódbázis, amelynek a belépési pontjai kalauz nélkül nem találhatók meg.

Mit csináljon egy új fejlesztő az első napokban? Egy kicsi, valódi, kiszállítható módosítást, amire tényleges felhasználó vár. A cél nélküli kódolvasás keveset tanít, mert hiányzik a kapaszkodó, míg egyetlen valódi változtatás megmutatja, hol van a kód, hogyan futnak a tesztek, hogyan zajlik a review, hogyan történik a deploy, és kinek kell szólni.

Miért tart ilyen sokáig a környezet beállítása? Mert mindenkinek van már működő környezete, és évek óta senki nem épített nulláról, így a leírás elcsúszik. A megoldás az, hogy a következő belépő pontosan kövesse, ne változtasson semmin, és jegyezzen fel minden elakadást. Ez a lista a valódi folyamat, egyetlen parancsra szűkítve pedig nem csúszik el újra.

Milyen dokumentációt érdemes karbantartani az onboardinghoz? Hogyan kell a rendszert telepíteni és elindítani, hogyan kell deployolni, milyen alakú az architektúra és miért, milyen döntések születtek, amelyeket különben újra elővennének, és ki miért felel. Hagyja ki, amit a kód már kimond, a havonta változó képernyők végigvezetését és a kézzel írt API-referenciákat.

Mit árul el a csapatról a lassú onboarding? Azt, hogy a láthatatlanul elnyelt költségek valósak. A három napos telepítést mindig is kis részletekben fizette mindenki, aki újrarakott egy gépet. Egy komponens, amit senki nem tud megindokolni, régóta döntésekbe kerül. Egy deploy, amit csak egyetlen ember tud végrehajtani, már az új belépő előtt is kockázat volt.