Több fejlesztő, lassabb fejlesztés?

Az elmúlt években több olyan rendszerrel találkoztam, ahol a fejlesztés lassulását elsőre kapacitásproblémának látták.

A vezetőség azt érzékelte, hogy egyre tovább tartanak a módosítások, a fejlesztők pedig folyamatosan túlterheltek. A kézenfekvő megoldás ilyenkor az, hogy fel kell venni még néhány embert.

Ez néha valóban szükséges.

De több alkalommal azt láttam, hogy a plusz fejlesztők önmagukban nem oldották volna meg a problémát. Nem azért, mert a csapat nem dolgozott elég keményen, hanem azért, mert a rendszerben és a fejlesztési folyamatban voltak olyan szűk keresztmetszetek, amelyek mindenkit lelassítottak.

Amikor minden változtatás nehezebb a vártnál

Az egyik visszatérő helyzet az, amikor egy elsőre egyszerűnek tűnő módosítás meglepően sokáig tart.

Egy új mező. Egy üzleti szabály megváltoztatása. Egy kisebb képernyőmódosítás.

A feladat kívülről nem tűnik nagynak, mégis hetek telnek el vele. Közben sok az egyeztetés, a visszakérdezés és a bizonytalanság. A fejlesztő nem tudja rögtön, hol kell módosítani a rendszert, milyen más részeket érinthet a változás, és hogyan lehet megbizonyosodni arról, hogy nem romlik el valami máshol.

Ilyenkor könnyű azt mondani, hogy a fejlesztők lassúak.

A valóság gyakran az, hogy a rendszer vált nehezen változtathatóvá. A kód működik, de már nem könnyű megérteni. Egy döntés hatása nem látszik egy helyen. A tesztek nem adnak elég biztonságot. A kiadás előtt sok mindent kézzel kell ellenőrizni.

Egy ilyen rendszerben az új fejlesztő sem tud azonnal érdemi sebességet hozni. Először ugyanazt a nehézséget kell megértenie, amellyel a meglévő csapat már naponta küzd.

Amikor a csapat ideje nem fejlesztésre megy el

Egy másik rendszerben azt láttam, hogy a fejlesztők jelentős része nem új funkciókkal foglalkozott, hanem azzal, hogy működésben tartsa a meglévő rendszert.

Hibákat kerestek, amelyek csak éles környezetben jelentek meg. Kézzel indítottak újra folyamatokat. Olyan adatokat próbáltak visszakeresni, amelyekről nem volt megfelelő naplózás. Egy-egy incidens után gyors javítás készült, de arra már nem maradt idő, hogy a kiváltó okot is megszüntessék.

Kívülről ez szintén úgy nézhet ki, hogy kevés a fejlesztő.

Valójában azonban a csapat egy része folyamatosan a korábbi technikai döntések következményeit kezeli. Nem új értéket épít, hanem ugyanazokat a problémákat oldja meg újra és újra.

Ezek a feladatok nem mindig látványosak, de nagyon is valós költséget jelentenek. Elmaradnak miattuk a fejlesztések, nő a bizonytalanság, és a csapat egyre kevésbé tud előre tervezni.

Amikor senki nem látja át teljesen a rendszert

Sok érett rendszerben nem az a legnagyobb gond, hogy nincs dokumentáció, hanem az, hogy a rendszer működéséről nincs közös, megbízható kép.

Egy adott részt egy ember ismer igazán. Egy másik folyamat működését még az a csapat építette, amelyik azóta már nincs a cégnél. Egy korábbi döntés okára senki nem emlékszik pontosan, ezért minden változtatás előtt újra meg kell fejteni a múltat.

Ez a fajta bizonytalanság lassan épül fel. Nem feltétlenül okoz azonnal hibát, de minden későbbi módosítást drágábbá és kockázatosabbá tesz.

A fejlesztők ilyenkor nem azért dolgoznak lassan, mert nem tudják, mit kell csinálni. Sokszor éppen ellenkezőleg: túl sok mindent próbálnak előre megérteni ahhoz, hogy biztonságosan merjenek változtatni.

Az új emberek néha először tovább növelik a terhet

A létszámbővítésnek van egy gyakran alábecsült költsége: az új kollégákat be kell vezetni a rendszerbe.

Ha a rendszer jól strukturált, a felelősségi körök tiszták, és a fejlesztési folyamat kiszámítható, ez természetes része a növekedésnek.

Ha azonban a működés nagy része néhány ember fejében van, a dokumentáció hiányos, és az éles rendszer kockázatosan változtatható, akkor a betanítás jelentős terhet rak a meglévő csapatra.

Ilyenkor az új fejlesztők eleinte nem feltétlenül gyorsítják a munkát. Kérdéseket tesznek fel, kontextust kérnek, döntéseket próbálnak megérteni — és ez teljesen rendben van. Csak közben a meglévő csapatnak kevesebb ideje marad a saját feladataira.

Ezért a csapat bővítését nem önmagában érdemes vizsgálni. A kérdés az, hogy a rendszer és a működés képes-e fogadni az új kapacitást.

Mit nézek meg ilyenkor először?

Amikor egy ilyen helyzetet próbálok megérteni, nem azzal kezdem, hogy hány fejlesztő dolgozik a rendszeren.

Először azt nézem meg, hogyan telik el egy változtatás teljes ideje.

Mennyi idő a tényleges fejlesztés? Mennyi a várakozás? Hol kell újra információt kérni? Mennyi időt vesz igénybe a tesztelés és a kiadás? Milyen hibák térnek vissza rendszeresen? Mely részekhez nyúl mindenki óvatosan, és miért?

Ezekből általában gyorsabban kirajzolódik a valódi probléma, mint egy újabb kapacitástervezésből.

Azt is fontos megérteni, hogy a lassulás minden területen jelentkezik-e, vagy csak bizonyos modulokban, folyamatokban vagy termékrészekben. Gyakran nem az egész rendszer rossz állapotú. Lehet, hogy csak néhány kritikus rész akadályozza a teljes csapat munkáját.

Ilyenkor sokkal értelmesebb lehet ezeket a részeket célzottan rendbe tenni, mint általános megoldásként embereket vagy új technológiát hozzáadni.

Mikor van valóban szükség több fejlesztőre?

Természetesen vannak helyzetek, amikor a létszámbővítés a helyes döntés.

Például ha:

• a termék és a prioritások világosak;
• a rendszer működése megfelelően érthető;
• a fejlesztési folyamat kiszámítható;
• a kiadás és a tesztelés nem jelent állandó akadályt;
• az új kollégák betanítása tervezhető;
• a csapatnak valóban több végrehajtási kapacitásra van szüksége.

A létszám akkor tud érdemben segíteni, ha már tudjuk, milyen munkát kell elvégezni, és mi akadályozza jelenleg annak elvégzését.

Ha ezt nem tudjuk, akkor a bővítés könnyen csak nagyobb csapatot eredményez ugyanazzal a problémával.

Nem az építéssel kezdünk

A fejlesztés lassulása fontos jelzés, de önmagában nem mondja meg, mi a megoldás.

Lehet, hogy több ember kell. Lehet, hogy a kiadási folyamatot kell rendbe tenni. Lehet, hogy egy kritikus modult kell átalakítani. Lehet, hogy a rendszer működését kell jobban láthatóvá tenni. És az is lehet, hogy ezek közül többre van szükség, de nem mindegy, milyen sorrendben.

Ezért nem az építéssel kezdem, hanem a megértéssel.

Először azt kell feltárni, hogy a rendszer, a folyamat vagy a kapacitás hol akadályozza a munkát. Csak ezután lehet felelősen dönteni arról, hogy mi legyen a következő lépés.

A cél nem az, hogy mindenáron változtassunk. Hanem az, hogy a legkisebb indokolt változtatással újra kiszámíthatóbbá és biztonságosabbá tegyük a fejlesztést.