Hogyan öli meg a mikromenedzsment a munkát (és az idegeinket is)?

"Pont most mentek kávézni?"; "Szerintem ez a feladat fontosabb, mint amivel pont foglalkoztok..."; "Mindegy, de péntekre legyen kész, jön az ügyfél!"; "Ezt BASIC-ben annak idején úgy csináltuk a számtech szakkörön, hogy..."
A fenti mondatok valószínűleg ismerősen hangzanak néhányunknak, a hozzá társuló viselkedésnek pedig neve is van: mikromenedzsment. Idegesítő, és ami talán még fontosabb, hogy kontraproduktív, ráadásul szinte teljesen összeegyeztethetetlen a szoftverfejlesztés folyamataival. Lássuk, hogy miért!

Mit mond a szótár?

Azt, hogy a mikromenedzsment nem más, mint amikor egy felettes egy adott folyamat, feladat, vagy projekt megvalósításába a kelletténél nagyobb mértékben belefolyik, ezzel gátolva annak előrehaladását.

Főnökként nem nehéz beleesni ebbe a csapdába, pláne, ha egy olyan projektről van szó, ami kezd kicsúszni az érintettek kezéből.

Hol a konkrét hiba?

Ott, hogy a szoftverfejlesztéssel foglalkozó cégek nem manufaktúrák! Egy szoftverfejlesztő manufaktúrában ugyanis úgy nézne ki a napi munka, hogy reggel megkapják a fejlesztők az előre kialakított alkatrészeiket (legyenek ezek a kódrészletek), hogy aztán a napi rutinnak megfelelően összeállítsák őket. A PHP-sok a PHP-s alkatrészeket, a C#-osok a C# elemeket, és így tovább... Nem meglepő, hogy aki egyetlen napot is dolgozott fejlesztőként, az tudja, hogy ez mennyire távol áll a valóságtól.

Ahogy az sem meglepő, hogy a menedzserek szeretnék, ha mégis így működnének a dolgok: tisztán, tervezhetően, olajozottan.

Hogyan mikromenedzseljünk?

• Jelentsünk be vállalhatatlan határidőket. Bizonyosodjunk meg róla, hogy a csapatunknak nem lesz elég ideje elvégezni a munkát. Plusz pont, ha a végén hibáztatjuk is őket ezért.
• Ad-hoc priorizáljunk feladatokat. Mindenki dobjon el mindent, most ez a másik feladat sokkal fontosabb! Plusz pont, ha a "fontosabb" feladat egy másik projekt része.
• Dobjunk be mindent felforgató üzleti igényeket. Koncepcióváltás, technológiaváltás, a készülő alkalmazás üzleti funkciójának újradefiniálása féltávnál.
• Merjünk nagyot álmodni! Aztán a rosszul specifikált igényeink kidolgozására lehetőleg később se hagyjunk időt
• Mindenkinek az aktuális elfoglaltságával legyünk képben! De ne az erre alkalmas eszközök (JIRA, Trello, Redmine, stb...) segítségével, hanem nap, mint nap kérdezzük meg a kollégákat, hogy "most épp min dolgozol?".
• A napi státusz nem elég. 2 óránként nyugodtan kérdezzük meg, hogy hogyan állnak a többiek a munkával!
• Szóljunk bele a munkamegosztásba, és lehetőleg az aljamunkát osszuk ki a legjobb fejlesztőknek! Ők sem alkothatnak mindig világmegváltó dolgokat, néha kell egy kis "pihenés"...
• Szabdaljuk szét a munkanapot ad-hoc megbeszélésekkel! Úgy sincsen jobb dolga a többieknek, nem árt néha egy 2 órás call, még a végén elkészülnének a határidőre.
• Beszéljünk technológiai kérdésekről jó hangosan! Nem baj, ha fogalmunk sincs róla, hogy mi az az MVC, vagy az execute plan, akkor is mi vagyunk a főnökök. Plusz pont jár a buzzword-ök gyakori említéséért. (Ha kérdeznek tőlünk a témában, akkor nyugodtan háborodjunk fel, hogy "ez a fejlesztők dolga"!)
• Becsüljünk időt mások megkérdezése nélkül. A login képernyő mindenhol ugyanolyan nem? Egy email, és egy jelszó mező. Erre vannak már kész megoldások, egyik implementálása sem tarthat tovább 4 óránál...

Haha, de akkor mi a jó gyakorlat?

Adjunk szabad kezet a fejlesztőknek. Nagyon rosszul hangzik, de annál nem lehet rosszabb, mint amikor kézi vezérléssel próbálunk működtetni egy szoftverfejlesztő csapatot.

Fogalmazzuk meg egyértelműen az elvárásainkat, de ezek legyenek magas szintűek, a részletek kidolgozását, és a munka felosztását pedig bízzuk a fejlesztésben jártasakra. Néha be fognak csúszni hibák, de ezekre soha ne úgy reagáljunk, hogy még több kontrollt erőltetünk a belső folyamatokra, hosszú távon sokkal jobban járunk ugyanis, ha gondolkodó, nyílt, kreatív emberekkel dolgozunk, mint ha droidokkal, akik elviselik az irányításnak ezt a fokát.

Forrás: Kamil Lelonek