Túlórázni jó

A túlórát vagy a túlórázást sokan valami ördögtől való dolognak tartják. Jellemzően többségben azok, akik napi fix 8 órában dolgoznak. Pedig a túlórának vannak előnyei is. Mint minden jó dolgot persze, ezt sem szabad túlzásba vinni.Volt olyan része az életemnek, amikor ezt nagyon nem így láttam. Utólag belegondolva azért, mert nagyon rosszul esett az egész napos munka után még 2-3 hosszú órát bent maradni és későn hazaérni és ezért olyan nagyon jelentős plusz fizetést azért nem kaptam. Nekem abszolút nem érte meg a fáradtságot, hitelem nem volt (nem is lesz), így semmi értelmét nem láttam a dolognak.

Nézzük a jó oldalát szoftverfejlesztés szempontjából a plusz munkának. Az remélem tiszta, hogy ha egy projekt határideje nagyon közel van és a megrendelőnek menet közben jutott eszébe még pár dolog, amit “csak bele kell rakni” az alkalmazásába, a kezdetben gondosan kiszámolt és meghatározott fejlesztési idő valamelyest kinyúlik. Nem elsősorban az adott megrendelő kedvéért, hiszen ő volt ostoba ebben az esetben, hanem a naptárban utána következő megrendelő miatt. Erre az egyik megoldás a túlóra. Tehát rögtön a legelső előny az, hogy időben készen leszünk a munkával, amin dolgozunk. Itt még nem beszéltem a különböző fejlesztési módszerekről és a csapatban való munkáról.

Magyarországon a legelterjedtebb a klasszikus fejlesztési módszer, ahol a fejlesztés úgy folyik, mint egy vízesés. Elindulunk valahol (framework, toolkitek, stb), majd határidőre kész van a szoftver, közben mindenki, aki a projekten dolgozik, nagyjából a saját vízoszlopában marad és talán hozzá sem ér a többi fejlesztő kódjához. Például a grafikus elkészíti egy honlap külsejét, erre vár két programozó, majd az egyik nekiesik szétdarabolni a terveket, html-t készít, a másik pedig megtervezi hozzá az adatbázist, az előző elkezdi legyártani a tartalmak tárolásához a CMS-t. Megjegyzem, ez elég rossz stratégia. a klasszikus modell tehát a szoftver megfelelő sorrendben történő összerakására épít. Modern programnyelveken is lehet így fejleszteni, de elég nagy pocsékolás az idővel és erőforrásokkal, pedig mint írtam - és ez saját tapasztalat - a magyar fejlesztők 99.9%-a így fejleszt.

Hogyan kellene? Mindennak az alapja a tervezés. A grafikus kapjon egy gridet, amire dolgozhat, a projektmanager tervezze meg előre az osztályokat, a használni kívánt keretrendszert, a különböző technikákat határozza meg, ossza szét a munkát a programozók között (tudnia kell, ki, mit csinál jobban). Látható eredményt ez a módszer később hoz, mivel kezdetben csak az osztályok leprogramozása folyik és mint tudjuk, az öndokumentáló programozás első lépései hosszabbak és kevesebb a látható eredmény, mint a klasszikus módszereknél. De amint ezeket elkezdik összegyúrni, pillanatok alatt felépül a kívánt eredmény. Nem is akármilyen minőségben és hatékonysággal. Senki ne képzelje, hogy ezeket a zseniális dolgokat én találtam ki, mert én is más példáján tanulom ezeket.

Aztán jön a megrendelő és minden tervet lesöpör az asztalról :) Ilyenkor kell túlórázni. Miért? Ugyan az öndokumentáló forráskód megengedi, sőt leegyszerűsíti más programozók beletanulását a projektünkbe, de ez is időt vesz el a fejlesztésből és az ilyenkor nem jó. Ráadásul ha a kódban nem egyértelmű a dokumentáció, egyéb problémák és veszteségek is felmerülhetnek. Ne felejtsük el azt sem, hogy munkaidő után nyugodtan hagyhatjuk másnapra az emaileket, nem fontos rájuk azonnal válaszolni, skype-on elrejthetjük magunkat a munka idejére és az irodában sem lesznek olyan sokan, akik megzavarhatnának. Már ha irodában dolgozik valaki és nem a saját lakása a munkahelye, mint nekem.