Keresztfunkcionális csapatok

Megosztás

Keresztfunkcionalitás. Mit is értünk rajta? Mi a haszna és mikor érdemes ebben a szervezési formában gondolkodni. Legutóbbi meetupunkon is ez volt a téma.

Alapok

Általában ahogy egy vállalat növekszik, funkcionálisan kezd el szerveződni. Ha szoftverfejlesztésről beszélünk, akkor kialakulnak fejlesztői és tesztelői csapatok, majd a fejlesztők tovább tagolódhatnak technológiák (pl C++, Java, web) vagy komponensek szerint (frontend, backend). A legfontosabb érték a specializáció, hogy mindenki a saját területéhez mélyen értsen. Olyan ez, mint egy torta, melynek az egyes rétegeit a funkcionális csapatok adják. A vevő azonban legtöbbször nem egy piskótaalapot vagy csokimázat szeretne, hanem egy szelet tortát. Ekkor jönnek a projektvezetők, akik a különböző projektek és feature-ök rétegein igyekszenek átverekedni magukat. Közben azonban sokszor megakadnak, várakoznak, és priorizálják a feladatokat. Sok veszteséggel bír ez a folyamat, legfájóbb ezek közül az állandó várakozás.

Mit csinál egy funkcionális szervezet, ha mégis gyorsan kell valamire reagálnia? Órákon vagy napokon belül kell megoldást találnia, mert milliók múlhatnak rajta, például egy reklamáció esetén. A tipikus megoldás: fogja a feladat gyors megoldásához szükséges különböző tudású dolgozóit, bezárja egy szobába és addig nem engedi ki őket, amíg meg nem oldják. Kissé sarkítva ez lenne a keresztfunkcionalitás lényege. Mindenki, aki szükséges a feladat elejétől a végéig való megoldásához, egy helyen van és fókuszáltan együtt dolgozik, hogy minél gyorsabban haladhassanak.

A legtöbb cég induláskor keresztfunkcionálisan működik. Nincsenek élesen szétválasztott szerepek, sokszor mindenki csinál mindent, illetve amire épp szükség van. Mi a Unify Lab-ben azért tértünk vissza ezekhez a gyökerekhez, hogy ne csak időnként lehessünk gyorsak, együttműködőek és rugalmasak. 

Kell egy csapat

A keresztfunkcionális csapatok kialakítása egyszerűnek tűnik. A szakirodalom szerint. A valóság azonban ritkán alkalmazkodik a könyvekben leírtakhoz. Vegyük az első lépést, a csapatok kialakítását. Milyen összetételűek legyenek? Valóban kell minden csapatba minden tudás? Nem feltétlenül. Tekintsünk előre 6-12 hónapot az előttünk álló feladatokra és kezdjük el tortákká formálni őket. Lesz olyan tortánk, amihez 2-3 réteg kell, és lesznek olyanok, amihez 5-6. Ezek aránya is fontos, milyen tortából mennyit kell csinálni. Néhány iterációval egy közelítőleg jó képet kaphatunk arról, milyen összetételű csapatokat érdemes összehoznunk, hogy egyenletes legyen a terhelés eloszlása. Az is elképzelhető, hogy indulásnak meghagyunk egy-egy csapatot vagy szakértőt (pl speciális tesztek, infrastruktúra, security) és ők nem a csapatok részeként működnek, hanem aféle támogató egységként. Az agilis átalakulásunk során nekünk sokat segített a helyes struktúra felállításában a Sprint Consulting csapata. Az agilis coachok folyamatosan terelgették a helyes irányba a résztvevőket és a témát, így biztosak lehettünk, hogy jó úton haladunk.

Ha igazán hatékony csapatot szeretnénk létrehozni, akkor nem pusztán a feladataok mennyiségét és minőségét kell figyelembe vennünk, hanem hogy ki kivel szeret, tud vagy esetleg utál együtt dolgozni. Mivel a kémia szerepe meghatározó az együttműködésben és teljesítményben. Azonban a vezetőség nem feltétlen tudja a választ, hiszen még a gondolatrendőrség sem ismert minden gondolatot és érzelmet, Orwell utopisztikus regényében, az 1984-ben. Tehát érdemes az érintetteket is bevonni a döntésbe. Vezetőként a szemléletet és a kereteket határozzuk meg, a konkrét kialakítást már a kollégákra bízzuk. Egyébként is az a cél, hogy önszerveződő csapataink legyenek, miért ne kezdhetnénk így már a legelején? 

Beindul a csoportdinamika

Összeálltak a csapatok, hátradőlhetünk, mostantól olajozottan működik a gépezet. Vagy mégsem? Új környezetet és csapattagokat kell megszokni, beindul a csoportdinamika, formálódnak a közös értékek, alapelvek, munkafolyamatok. A kezdeti szakaszban többet vitázik a csapat, hogy mit miért és hogyan is kéne csinálni, ezért nem érdemes arra számítani, hogy rögtön csúcssebességre kapcsol a gépezet. Ilyenkor fontos a vezetői támogatás, a külső coachok jelenléte, a célok folyamatos kommunikációja, hogy a kezdeti nehézségeken átlendítse az új csoportokat.

Tegyük fel, elindultak a csapataink és már nem sokat beszélnek a munkáról, hanem hatékonyan csinálják. Vajon ez így marad mindig? Ha még abban a szerencsés helyzetben lennénk is, hogy épp az igényekhez illeszkedő tudású csapataink vannak, akkor sem kell aggódni, ez gyorsan elmúlik :) Változik a környezetünk, a vevők és a projektek jönnek-mennek, változnak a prioritások. Ekkor a következő dilemma elé kerül a csapat és a vezetés. Egyfelől, a rövid távú célokat követve gyorsan akarunk szállítani. Másfelől, ahhoz, hogy rugalmas termékfejlesztésünk legyen, azaz fenntartható legyen a sebesség hosszabb távon, új dolgokat is kell tanulni. Például úgy látjuk, hogy több frontend fejlesztőre lenne szükségünk, de a backend fejlesztők képzése rengeteg idő. A tradicionális szemlélet azt mondaná, hogy ez túl sok ráfordítás, nem engedhetjük meg magunknak és amúgy sem éri meg belevágni. A saját működési keretén belül talán igaza is van ennek a megközelítésnek. Azonban nem oldja, meg, hanem konzerválja a problémát. Megmarad az egyedi specializáció, a szűk keresztmetszetek és a fejlesztési folyamat rugalmatlansága.

Tanulni, tanulni, tanulni...

Ezzel szemben az agilis szemlélet egyik legnagyobb előnye az, hogy ösztönzi a tanulást. A csapattagok fejlődhetnek, az elsődleges specializáció mellet másod- és harmadlagos specializáció is kialakulhat, a folyamat rugalmasabb lesz. 

Lássuk, milyen sajátosságok és eszközök segítenek ebben

  • A különböző tudású emberek egy helyen ülnek, közös célokon dolgoznak. Ez rögtön egy hatalmas előny, ami a más területeken járatos kollégáktól való tanulást könnyebbé teszi.
  • A csapatok önszerveződéssel működnek, azaz csak a célt határozzuk meg számukra. Azt, hogy ki mit csinál a cél érdekében, azt ők maguk alakítják ki. Ez a szabadság teret enged a csapattagoknak, hogy más területen is kipróbálják magukat.
  • A közös munka alappillére az együttműködés. Ilyen környezetben ugrásszerűen megnő a párbeszéd a csapattagok között. A nyílt és gyakori kommunikáció segíti a tanulást.
  • A vizualizáció segíti a tanulást. A szoba falait, a táblákat ellepik a vizuális szemléltető eszközök. Mindenki látja, hogy mi a közös cél, ki mit csinál épp, hogyan teszi ezt, és hol tart. 
  • A lean szemlélet és a kanban rendszer egyik fontos eleme a Work In Progress korlátozása. Azaz ha a csapat dolgozik x darab feladaton, nem kezdhet bele egy újba, amíg egyet le nem zár. Ez arra kényszeríti a csapattagokat, hogy egymásnak besegítsenek. Például a frontend fejlesztő ha már kész a saját részével, beül a backend fejlesztő mellé, vagy besegít a tesztelőnek. Ezáltal tanulnak egymástól. Minél kisebb a limit, annál többet.
  • Egy külső coaching csapat mindig emlékezteti a csapatot, hogy időnként tegyék fel a "távolra látó szemüveget" és fektessenek a tanulásba is.
  • A pair programming nálunk hatékony eszköznek bizonyult, nem csak a tanulás elősegítésére, hanem a kódminőség javításában is.
  • A TDD és unit testing nagyban megkönnyítik a tanulást. A unit tesztelt kód gyakorlatilag olvashatóvá válik, melyik egységnek mi a feladata. A refaktorálással az átláthatóság javulhat. A meetupon elhangzott beszámolók szerint a TDD pingpong-gal nem csak magát a TDD-t lehet jól megtanulni. Akár teljesen új technológiákban vagy modulokban is meglepően rövid idő alatt komfortosan kezd mozogni egy újonc.
  • Megszűnik az "ez az én kódom, az a te kódod" szemlélet és felváltja helyét a "mi kódunk". Ez a kollektív felelősség azt eredményezi, hogy egy kód ne csak egyetlen csapattag számára legyen átlátható, érthető, hanem másoknak is. Reflektálnak egymás munkájára, review-zák egymást, tanulnak egymástól.

Ezeket szem előtt tartva a csapatok bátrabban és könnyebben vágnak bele új területek megismerésébe. Mit nyer ezzel a cég? Gyors és rugalmas termékfejlesztést. Mit nyernek a csapattagok? Kihívó célokat, lendületes munkát, inspiráló környezetet, ahol tanulni és fejlődni lehet. Kell ennél több? Igen :) de erről majd egy következő posztban.