Milyen tényezők lassítják le az IT fejlesztéseket?
Döntésképtelenség, tanácstalanság, végeláthatatlan egyeztetések... Mindenki számára ismerős ezek közül legalább egy fogalom, na de melyek azok a tényezők, amik valójában ellehetetlenítik a fejlesztéseket?
Korábban egy olvasói levél is érintette már a témát, valamint feszegettük, hogy milyen rossz technológiai döntések tudnak tévútra vinni egy projektet, ezúttal azonban inkább a módszertani kérdéseket taglaljuk cikkünkben.
1. Multitasking
A multitaskinggal kapcsolatos legjobb tanács: NE CSINÁLJUK!
Különösen igaz ez a szoftverfejlesztésre, ahol tanulmányok is bizonyították már, hogy minden egyes megszakítás 15 perces időveszteséget jelent egy-egy fejlesztőnek.
A kulcs azonban nem az, hogy tudod, hogy kerülnöd kell a multitaskingot, hanem az, hogyan tudod ezt véghez vinni. Ez a fajta kulcs pedig inkább a menedzsmentnél lelhető fel, az ő feladatuk ugyanis, hogy egy adott projekten minden humán erőforrás rendelkezésre álljon a kellő pillanatban. Így minimális az abból adódó késedelem, hogy kollégák egymásra várnak, valamint az is elkerülhető, hogy kényszerből valaki emiatt több dologba fogjon bele egyszerre.
2. Gigaprojektek
A bevett szokás az informatikai cégeknél az, hogy a nagyobb módosításokat projektekbe szervezik, aztán ezek a projektek számos esetben - ha nem eleve óriásiak - elkezdenek hízni. Egészen addig, hogy elcsúsznak a határidők, átláthatatlan lesz a scope, és ezzel együtt a bevezetés kockázata is megnő.
Ezekre az esetekre sokszor nyújt megoldást, ha a gigaprojektek helyett kisebb release-ekben gondolkodunk. Így a folyamatos bevezetéssel felaprózódik, és legfőképp jobban kontrollálhatóvá válik a kockázat, valamint nem utolsó sorban a scope is tisztább egy-egy release-re nézve.
(Sőt, ha mindezt kicsit még átfaragjuk, és Scrumnak hívjuk, akkor trendik is leszünk ;) )
3. Túltervezés
Írtunk róla már korábban, hogy a kényszeres, "mindenre felkészülés" mennyire hátrányos hozzáállás tud lenni. Természetesen azt sem lehet elmondani erről az attitűdről, hogy felgyorsítaná a fejlesztéseket. Törekedni kell tehát első körben a minimum viable product definiálására, majd implementálására, és csak ezt követően belefogni az egyes funkciók priorizált kidolgozásába.
4. Adattárházak
Nyilván megvan az adattárházak alkalmazásának a helye, és ideje, de ettől még jellemző, hogy a tervezési fázisban úgy próbáljuk definiálni a struktúrájukat, hogy nem ismertek világosan a felhasználási céljaik, vagyis az, hogy mit, és hogyan szeretnénk majd kinyerni belőlük.
A NoSQL (akármennyire óvakodik tőle egyelőre a cégek nagy része) megoldást nyújthat ezekre a problémákra, hiszen elsősorban az adatok tárolására koncentrál, míg azok későbbi analizálásában, feldolgozásában rugalmasabb, és lényegesen gyorsabb, mint az OLAP rendszerek.
5. A megbízhatóság mindenek feletti erőltetése
A megbízhatóság nagyon fontos, de sosem állhat az innováció útjába. Nem arra kell gondolni, hogy kötelező ész nélkül fejest ugrani minden újdonságba (legyen szó akármekkora rendszerről, vagy alkalmazásról), de erre hivatkozva ragaszkodni elavult megoldásokhoz ugyanolyan öngyilkosság, legfeljebb hosszú távú.
Nem beszélve arról, hogy az innovatív kollégák lelkesedésének folyamatos letörése morálisan hátrányos a cégre nézve, és valószínűleg a fluktuációt is felpörgeti. Sokkal progresszívebb szemléletet képviselhetünk, ha az újítóknak biztosítunk időt, forrást, és biztonságos környezetet, ahol kedvükre kísérletezhetnek.