Vezető vagy Főnök?

Vezető vagy Főnök?
Hagyjuk most az összehasonlító listákat, nézzük meg, hogyan is néz ki a téma a mindennapi életben.

Nem tudtam megállni, hogy ezt a divatos témát ne dolgozzam fel. A cím inkább úgy értendő, hogy "Vezető vagy-e, Főnök?" Ez jobban árnyalja, hogy valójában miről is van szó. Nem fogok bedobni egy érdekes 10-es összehasonlító listát, hogy ki mit csinál, vagy kinek mit kellene csinálnia. Azt már megtették sokan, máshol, sokféle formában. Helyette inkább leírom, hogy én hogyan élem ezt meg a teendőim során.

A kezdeti felállás
Adott egy emberek halmaza, ami még nem csapat. Vagy készen kaptad, vagy összeszervezted magadnak. Az utóbbihoz elvárás, hogy legyen HR-es döntési jogod. Az én esetemben volt ilyen is, olyan is. Leírom, hogy milyen volt, amikor szépen, fokozatosan duzzadt fel a körülöttem lévő létszám. Először jött egy munkatárs, aztán hamarosan megjelent a következő. De álljunk meg itt, mert ez egy fontos mozzanat. Amikor fejlesztőként egyedül dolgoztam, és a senior munkatársamhoz "kölcsön-tanácsért” jártam, az egy egészen más helyzet volt, mint amikor már másik két emberrel osztozni kellett a projekten.

Az első pár hét? Nos, természetesen nem ment minden simán. Ki, mit fog hozzátenni a napi haladáshoz? Milyen szinten vannak a srácok? Mi érdekli egyáltalán őket? Ezek fontos kérdések, mert alapjaiban határozzák meg a viszonyunkat. Ki vagyok én, vagyis ki lettem most? Kell egy megmondó ember, nem? Ez lettem én. Emellett érdekelt az ő szakmai meglátásuk, hogy hogyan látják az előttünk álló feladatot. Gondoljuk át közösen! Beszéljük át, hogy hogyan lesz jobb?

Ha 1 órát töltesz azzal, hogy magad kitalálod, és megcsinálod a feladatot, akkor hátrébb vagy ahhoz képest, mintha fél órát beszélnétek róla közösen, és 1 óra alatt megcsinálod. A második esetben optimálisabb lesz a megoldás, és rajtad kívül más is tud róla. Ez nagy különbség!

A munkamorál
Szeretek jegyzeteket készíteni, listákat (Google Sheet). Tapasztalom, hogy ha leírom, akkor magamnak is megfogalmazom. Nem lóg a levegőben. Tudom könnyen formálni, rendszerezni. Egy pillanat alatt megosztható mással az, ami eddig csak a saját gondolatom volt. Persze a túl sok jegyzet, a különféle doksikban sem jó. Nehéz fejben tartani, káosz az egész. (El sem merem mondani a csapatnak, hogy még miféle listáim vannak :) )

A fejlesztésekhez használtam a verziókövető feladat listáját. Ezt az elejétől fogva magamnak ugyan úgy vezettem, mintha csapatban lettem volna. A projekt elején feldaraboltam a részeket, beszórtam őket (a listába :) ), tudtam követni magamnak, hogy mi van kész, mivel van még feladat.

Aztán amikor betoppantak az új munkatársaim, könnyen tudtam nekik adni ebből. Delegáltam, átvállalták a feladataim egyes részeit. Ezután az történt, hogy a fejemben megvolt a nagy kép, a nagy cél, és tudtam ellenőrizni, hogy az elvégzett feladat hozzátett-e ehhez? Arra kormányozta a projektet, amerre gondoltam? Tehát én voltam a végső megmondó, elkezdtem irányítani a munkákat.

A vezetés művészete
Idővel persze jönnek egyéni érdekek, kérdések, amiket kezelnem kell. Úgy mint:

 

  • Nem csináltam még ilyet
  • Szabin leszek a következő 3 napban
  • "Nem szeretném ezt a részt én megcsinálni" - kérés
  • Húzós határidő, mi férjen bele a következő verzióba?
  • A tesztelést ki végzi?
  • A forráskód olyan minőségben készült el, hogy azt a munkatárs utána szívesen nézegeti (Code Review)
  • Minden infót kiderítettem a sikeres feladat végrehajtásához?
  • Értelmetlen dolgot kér a megrendelő, és ezt a rossz hírt valahogy közölni kell a csapattal.
  • Stb., stb.

Valakinek a piszkos munkát is el kell végezni
Van itt még egy nézőpont. A csapatod, és a Megrendelő között egy kapocs vagy. Egyfajta villámhárítóként, vagy szűrőként viselkedsz

Esetek...

Az igény nincsen kellően technikailag megfogalmazva, ezt tálalnod kell olyan formában a csapatnak, hogy ebből egy megvalósítható valami legyen.

Magyarázd el a megrendelőnek, hogy a hiba miért jött elő, milyen esetekben fordul elő? Mikorra lesz meg a javítás (egy SW mindig bug-os, hibák vannak benne. Így születik, és sosem növi ki.)? Csütörtök van, pénteken lesznek beígért szabadságok, de van egy súlyos hiba. Ki fogja megoldani? Mikorra? Hogyan? Mi lesz, ha nem sikerül megoldani? Szerencsés lehetsz, hogy a csapatod oly' mértékű már, hogy az End-to-end tesztelést külön személy végzi, aki nem fejleszti a Sw-t. Ha talál egy hibát, az a fejlesztőnek olyan, mintha a saját gyermekét löknék bele a sárba. Ezeket a személyes helyzeteket is kezelni kell, észre kell venni.

A (köz)hangulat szívverésén folyamatosan rajta kell tartanod a kezedet. Tudnod kell, hogy kivel mi történt a napokban, ami esetleg befolyásolja a véleményét, a munkavégzését. Ki kell egyensúlyozni a csapaton belüli különbségeket. De ezt csak finoman lehet. Néha bölcs hallgatással, néha biztatással. Vagy rávezető kérdésekkel. Napi szinten meghozott közös megegyezésekkel. Akár feladatonként. Egy bizonyos csapatméretig ez tud működni. Én így élem meg a napi munkámat, aki egy csapatot irányít a cél felé, felelősséget vállalva.

Gondolkodni hosszú távon érdemes
A csapat sosem egy projektre áll össze, hanem az évek során többre. Akkor is ott van, amikor nem meló van, hanem csak egy jó beszélgetés. A céges csapatépítésen látszik, hogy kik tartoznak össze, vállvetve tolják a szekeret egymásért. Lehet bármilyen nehéz a helyzet, az ilyen közösségek jobb túlélők lesznek a kósza lelkeknél.

(foto: Ryan Mcguire/pixabay

 

Kövesd az oldalunkat a Facebook-on és a Twitteren is!


Borbély Viktor

Borbély Viktor vagyok, senior Szoftver fejlesztő. A Pannon Egyetemen végeztem Veszprémben 2007-ben, Programozó Matematikus BSc szakon. Az elmúlt másfél évtizedben több cégnél dolgoztam, és szereztem …