43. PM Műhely – Marhefka István : Önszerveződő csapatok a projektmenedzsmentben

Marhefka István : Önszerveződő csapatok a projektmenedzsmentben

 

A vállalati vezetőknek a legegyszerűbben a hatékonyságfokozás (gyorsaság és minőség javulásának) ígéretével lehet „eladni” az agilitás ötletét. Ha az üzletemberek, a fejlesztők és az üzemeltetők napi szinten beszélnek egymással, és gyakran szállítanak értéket (pl. kéthetente), akkor az eredmény hamarabb válik kézzelfoghatóvá, és jobb is lesz, mint ha három külön szervezetben dolgoznának, és felülről próbálnák összefogni őket projektmenedzsment révén, valamiféle közös terv alapján. Nagyjából így szokták megragadni az agilitás lényegét, és azt a fenti módon egy módszerként, eszközként leírni. A valóban agilis működés kulcsának középpontjában az önszerveződő csapatok állnak (más néven: agilis csapatok).

 

Mit jelent az „önszerveződő csapatok” kifejezés?

 

Az önszerveződő csapatok kifejezésnek nincs egységesen kiforrott definíciója. „Az önszerveződő csapat ideáltípusa egy olyan team, amelynek autonómiája van a működését érintő minden területen” (forrás: //coachszemle.hu/rovatok/hatter/852-oenszervezodo-csapatok-fejlesztese.html).

 

Az önszerveződő csapatokat meg kell különböztetni az együttműködő csoportoktól (co-acting groups), amiknek tagjai egymáshoz ugyan közel dolgoznak, de nem függnek a többiek munkájától. Egy valódi csapat négy ismérve a következő (forrás: https://www.infoq.com/articles/what-are-self-organising-teams):

1. Közös feladatok megléte, amiknek az elvégzése egy impozáns célhoz visz közelebb.

2. Világosan meghatározott határok. Pontosan meg kell határozni, hogy kik vannak a csapatban (és kik nem), és hogy mi a csapat felelősségi köre, ez alapján értelmezhető ugyanis az autonómiája is. Azt is szükséges tudni, pontosan hogyan illeszkedik a csapat a szervezetbe, mi az információáramlás menete, és a csapat hogyan hozza meg a döntéseit.

3. Rendelkezik az önszerveződésre való jogosultsággal

4. A csapat észszerű ideig stabil marad, azaz nem változtatnak az összetételén.

• A menedzser által vezetett csapatok esetében a menedzser határozza meg a feladatokat; a csapattagok felelőssége a feladatok végrehajtásában áll. A hagyományos projektmenedzsment-csapatok e modell szerint működnek. Ezek a csapatok nem önszerveződőek, mert egy menedzser irányítja azokat.

• Az önmenedzselő csapatok nemcsak a feladatok végrehajtásáért, de önmaguk munkafolyamatainak menedzseléséért is felelnek. Tipikus példa erre egy vállalaton belül működő, különálló SCRUM-csapat, amit a vezető állít össze.

• Öntervező csapat esetén a csapatnak lehetősége van a saját tagjait megválasztani, és a szervezeti kontextusát is meghatározni. Például egy többcsapatos (scaled) SCRUM-rendszerben a csapatok fel vannak hatalmazva arra, hogy egymás között a csapattagokat cserélgessék, és a csapatok számára kijelölt határokat és felelősségi kört megváltoztassák.

• Önirányító csapat esetén a csapat maga választja meg a szervezeti célokat és/vagy a missziót is.

Az önszerveződő csapatok a gyakorlatban a legtöbbször az önmenedzselő szinten működnek.

 

Miért jó az önszerveződés?

 

Az önszerveződésen alapuló működés lényegében három fontos előnnyel járhat a hagyományos működéshez képest :

 

1. Az önszerveződés mint a csoportos motiváció motorja

Az Agilis kiáltvány mögötti 5. alapelv kimondja: Építsd a projektet sikerorientált egyénekre (eredetileg angolul: Build projects around motivated individuals.). Biztosítsd számukra a szükséges környezetet és támogatást, és bízz meg bennük, hogy elvégzik a munkát.

 

Közismert, hogy az autonóm módon dolgozó egyén vagy csapat nagyobb motivációs szinttel bír. Erről Daniel Pink is írt bestseller Motiváció 3.0 című könyvében. A kutatások szerint a hagyományos külső motivátorok (pl. pénz) rendkívül rossz hatással vannak az egyének kreativitására, és helyette a belső motivációjukra szükséges építeni. Ha az egyéneknek a munkában szabadságot (azaz autonómiát, függetlenséget) biztosítunk, hogy azt a munkát végezhessék, amit élveznek, akkor belső motivációjuk fogja hajtani őket. Ha egy autonómiával rendelkező csapatnak közös víziója és világos célkitűzései is vannak, akkor a csapat tagjai jó eséllyel válhatnak elkötelezetté, ami pedig lehetővé teszi a csapaton belüli közös felelősségvállalást is.A jól működő önszerveződő csapatok tehát motivált és elkötelezett egyéneket jelentenek.

 

2. A kollektív intelligencia kiaknázása

Az agilis alapelvek 11. pontja megfogalmazza: A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.

James Surowiecki A tömegek bölcsessége. Miért okosabb a sokaság, mint a kevesek? című könyvében számos példával illusztrálja, hogy egy csoport sokkal jobb döntéseket tud hozni, mint az adott csoport legokosabb tagjai. Aki dolgozott már jól működő agilis csapatban, az minden bizonnyal tudja, hogy ez mennyire igaz. De nem kell ehhez még agilis csapatban szerzett tapasztalat sem, hiszen biztosan mindenkinek volt már olyan élménye, hogy egy ismerősével ötletelt, és együtt olyan megoldásra jutottak pillanatok alatt, amire korábban egyikőjük sem gondolt. Ez a jelenség nagyobb csapatokra hatványozottan igaz. A csapatot alkotó egyének különböző nézőpontokat képviselnek, valamint különböző ismeretekkel rendelkeznek és meglátásaik vannak a világról és a projektről is. Az egyének tipikusan vakfolttal rendelkeznek, egy diverz csapatra ez kevésbé igaz. A tagok nyitott légkörben együtt egy új egységet alkothatnak, és új, váratlan ötletek pattanhatnak ki a fejükből, amik egy pillanat alatt teljesen más irányba terelhetik az együtt gondolkodás folyamatát. A manapság komplex szoftverfejlesztési projektek megkívánják a komplex gondolkodást is, amelyet egy jól működő csapat könnyen „hozhat”.

 

3. Az alkalmazkodás kulcsa az önszerveződés

A Cynefin-modell a különféle döntéshozási helyzeteket 5 típusba sorolja: egyszerű/nyilvánvaló, komplikált, komplex, kaotikus, zűrzavaros (ld https://en.wikipedia.org/wiki/Cynefin_framework ). Mind az 5 típusú helyzetben más a döntéshozatal leghatékonyabb módja. Egyszerű/nyilvánvaló helyzetekben pl. jól működnek a best-practice-ek, komplex helyzetekben viszont más döntéshozási stratégiára van szükség.

 

A szoftverfejlesztési projekteket komplex adaptív rendszereknek (complex adaptive systems) tekintik. Az ilyen rendszerek közös jellemzője, hogy nem lehet megjósolni a rendszer viselkedését pusztán annak alkotóelemeinek vizsgálata útján. Szoftverfejlesztési projektek esetében az egyének (fejlesztők, felhasználók stb.) az alapján cselekszenek, ahogyan a többiek cselekednek az adott rendszerben. Ez a nem szűnő együttműködés folyamatos visszacsatolást eredményez a teljes rendszerben, ami pedig folyamatos alkalmazkodásra készteti a résztvevőket és így a teljes rendszert is, aminek eredményeképpen a projektek – eltérő bizonytalansággal – előre meg nem jósolható módon haladnak előre.

 

Komplex adaptív rendszernek tekintik még az éghajlatot, a városokat, cégeket, piacokat, kormányokat, ökoszisztémákat, a társas hálózatokat, a közlekedési forgalmat, a hangyakolóniákat, magát az emberi agyat, az immunrendszert és még sok minden mást is. A komplex adaptív rendszerek – elnevezésüknek megfelelően – képesek az alkalmazkodásra, és közben stabilak. Ha nem lennének stabilak, káoszba zuhannának, azaz szétesnének. Ha pedig túlzottan stabilak lennének, nem lennének képesek alkalmazkodni. Egy ilyen rendszernek tehát folyamatosan a káosz és a rend határán kell tudnia lavíroznia.

 

Maga az élet példája azt mutatja, hogy a komplex adaptív rendszerek önszerveződő alapon működnek, és ilyen keretek között alkalmazkodnak, miközben stabilak is tudnak maradni (amennyiben túlélnek). Ezek alapján úgy tűnik, egy szoftverfejlesztési projektben is az önszerveződő csapatok tudják a projektet fenntartható módon, hatékonyan kezelni, amit a gyakorlat gyakran igazol is. A best-practice-ek gyakran nem működnek, egyedi, előre nem megjósolható megoldásokra van szükség, amelyeket kísérletezésre biztonságos környezet megteremtésével próbálnak ki, ezzel „puhatolják ki”, „merre az előre”. Az utat azzal hozzuk létre, hogy elkezdünk járni rajta.

Az agilis módszertanok fokozatos (iteratív) megközelítése erre az elvre épül.

 

Mitől működnek az önszerveződő csapatok?

 

Ahhoz, hogy jobban megérthessük, mitől is működhetnek az önszerveződő csapatok, érdemes egy magasabb perspektívából vizsgálni őket.

Frederic Laloux Reinventing organizations (magyarul: A jövő szervezetei) c. könyvében egy átfogó kutatást végezve a ma létező szervezeteket különféle fejlettségi szintekbe sorolja (nem kifejezetten IT-szervezetek szerepelnek a kutatásban):

• vörös: a szervezet egy nagyon erős vezető köré csoportosul, aki mindenki felett hatalommal rendelkezik. Az alárendeltek folyamatosan versengenek egymással, mint a farkasok egy alfa hím körül. Manapság így szerveződnek az utcai bandák és a maffiák.

• borostyánsárga: szigorú hierarchiapiramis, pozíciók, munkaköri leírás, „command-and-control” vezetési stílus – ezen kifejezések jellemzik ezt a szintet. A katonaság tipikusan így szerveződik, felülről lefelé végrehajtva a parancsokat, de ez alá a megítélés alá esik pl. a katolikus egyház és a legtöbb kormányzati szerv.

• narancs: még mindig a piramis az alapvető struktúra, de ahhoz, hogy elősegítsék az innovációt és a konkurencia legyőzését, egyre magasabb fokú szabadságot adnak a munkavállalóknak. A projektcsapatok és más keresztfunkcionális kezdeményezések lyukat fúrnak a hierarchiába, és összekapcsolják az embereket az innováció érdekében. „Management by objectives”, „profit és növekedés”, command-and-control az elérendő célokon (általában profitelvárás). A „hogyan” rá van bízva a szervezetre. Ez a ma uralkodó menedzsmentszemlélet, kiváló példái a multinacionális vállalatok.

• zöld: még mindig létezik a hierarchia, de a vezetők támogató vezetői stílust alkalmazva feladják hatalmuk egy részét felhatalmazva az embereiket a döntéshozásra és végrehajtásra.

• türkiz (teal): a ma ismert legmagasabb szint, amelyben a piramist (általában) felcseréli a teljes önszerveződés. Gyakori, hogy egyáltalán nincsenek főnökök a szervezetben, és a struktúra folyamatosan változik (csapatok hálózata).

(Ld. még részletesebben: //pragmaticscrum.info/what-colour-is-your-organisation/, ennél még részletesebben: //www.reinventingorganizations.com/uploads/2/1/9/8/21988088/140305_laloux_reinventing_organizations.pdf )

Az agilitás és ezzel együtt az önszerveződő csapatok koncepciója is a narancsszintű struktúráktól felfelé jelenik meg. Az agilitás legmagasabb pontját jelenleg a türkiz (teal) szervezetek jelentik. Ahhoz hogy megértsük, miért is működhetnek ezek, érdemes „felnézni” a legmagasabb, türkiz szintre. Itt lényegében az önszerveződő csapatok hálózata az alap szervezési mód.

 

Teal-történetek

 

A Corporate Rebels egy kis csapat, akik azt tűzték ki célul, hogy felkeresik a világ legprogresszívebb szervezeteit. Bakancslistájukon több mint száz cég szerepel világszerte. Számos türkiz (teal) szinten lévő szervezetet (akikre Laloux is hivatkozik a könyvében) meglátogattak, és blogjukon beszámoltak a tapasztalataikról.

A leginspirálóbb cégek történetei magyar fordításban is olvashatók:

• A FAVI, francia autóalkatrész beszállító története: gyári környezetben is működik az önszerveződés.

• A Buurtzorg forradalmasította a betegellátást: 14 000 munkavállaló, 0 menedzser és elképesztően nagy fokú elkötelezettség

• Se főnökök, se titulusok, se szervezeti hierarchia: a Morning Star paradicsomfeldolgozó sikertörténete

• Önmenedzselés a kormányzati szektorban: a Hollands Kroon példája

• A brüsszeli bürokrata lebontja a command-and-control struktúrát: a brüsszeli társadalombiztosítás és az önmenedzselés esete

• Centigo: így építs egy menő, önmagát menedzselő tanácsadócéget!

 

A Corporate Rebels konklúziója szerint a fenti cégek egy világméretű forradalom kezdetére utalnak, ami a munka világának megújulását jelzi. A munkavállalók világ szinten jelenlegi alacsony elkötelezettsége (több mint 80%, földrésztől függően) már gátja a termelékenység további növekedésének, ezért a munkavállalókat sokkal jobban kell bevonni.

 

„Az élenjáró szervezetek nagyon jól tudják, hogy a hierarchikus piramis idejétmúlt, és egyszerűen nem képes megfelelni a mai gyorsan változó környezet jelentette kihívásoknak. A command-and-control vezetés rugalmatlansága nem mozdítja elő az agilitást, a gyors reagálást és a munkavállalói elköteleződést. A progresszív szervezetek inkább alternatív struktúrákban gondolkoznak, és a rugalmatlan piramist általában egy csapatokból álló agilis hálózattá alakítják át. Fontos körülmény még, hogy mindegyik csapatot érdekeltté teszik, így a csapattagok is a saját bőrükön érzik az elkövetett hibáik, de a(z anyagilag elismert) sikereik következményét is. Ezáltal a munkavállalók nagyobb felelősséget vállalnak magukra, javul a vállalkozói szellemük, a kommunikációjuk, könnyebben és gyorsabban alkalmazkodnak, és szívesen segítik és támogatják egymást.” Ahhoz, hogy az önszerveződő csapat (vagy azok hálózata) megfelelően működjön, a benne dolgozó tagoknak rezonálniuk kell a csapat és a szervezet céljaival. Az önszerveződő csapatok egyértelmű kereteinek meghatározása (felelősségi köre és célja) látványos változásokat hoz. (Ld. még az A hierarchiapiramis lebontása és hatékony csapathálózat kiépítése c. cikket.)

 

Kultúra, mint előfeltétel

 

A fenti példákból is tisztán látszik, hogy ahhoz, hogy az önszerveződő csapatok (és ezzel együtt az agilis működés) sikeresek lehessenek, megfelelő környezet, kultúra szükségeltetik. Pusztán a menedzsment keretrendszerek és módszertanok alkalmazásával (pl. SCRUM), csupán az előírt ceremóniák betartásával (betartatásával) nem érhető el, hogy az emberek kis csapatokban elköteleződve dolgozzanak egy cél érdekében (Ld. még Understanding Fake Agile)

 

Vissza a jelenbe: a műszaki kiválóság és együttműködés mint a siker tényezője (a DevOps-kultúra)

 

Manapság a narancs színű szervezetek a leggyakoribbak (Laloux-terminológiában). Itt már fellelhetőek az önszerveződő csapatok, de ezek ugyanúgy egy piramis szervezet részei, és nem feltétlenül hálózatban működnek együtt. A menedzsment célokat (objectives) fogalmaz meg, és a megvalósítás módját a szervezetre bízza.

 

A Continous Delivery, azaz folyamatos szállítás egy műszaki megközelítés, amelyben szoftveres csapatok képesek gyorsan, biztonságosan és fenntartható módon szállítani. Ennek megteremtésének feltétele az ún. DevOps-kultúra, amelyben a fejlesztők és üzemeltetők szoros együttműködésben dolgoznak együtt. Ez a gyakorlati és műszaki megközelítés átmenetet képez a különböző területek összefogásában anélkül, hogy tényleges csapathálózatot működtetnének. A „State of DevOps” egy Google által támogatott kutatás, amelyet Jez Humble a Continuous Delivery atyja vezetett. A világszintű kutatás a jelenleg legátfogóbb DevOps kutatás: 5 évet ölel át és több mint 30.000 IT-s szakembert kérdeztek meg benne. A kutatás célja az volt, hogy kiderítsék, kik a leghatékonyabb szervezetek, és mitől hatékonyak ezek a cégek. A kutatás erősen technológiai megközelítésű, vizsgálta az alkalmazott technológiákat, módszertanokat, ill. ezeknek az üzleti eredményességre gyakorolt hatását.

 

A szoftverfejlesztő csapatokat - teljesítményüket tekintve - 4 fő kategóriába sorolták tisztán statisztikai adatok alapján: elit, high performers, medium perfomers és low performers.

• 48%-uk a csúcsteljesítők (high performers): ők kb. napi rendszerességgel deployálnak élesbe, egy fejlesztői commit 1 héten belül kikerül élesbe.

 

• 15%-uk az alacsonyan teljesítők (low performers): ők heti 1 és havi 1 éles telepítés közötti telepítéssel „büszkélkedhetnek”, és 1-6 hónap közötti időtartamot fog át, amíg egy fejlesztői commit kikerül élesbe.

 

Az elit csoport mutatja az utat az iparban, ők kísérletezik ki az újabbnál újabb technikákat és eszközöket. Ők naponta sokszor deployálnak, 1 órán belül kikerül a commit, és ha a szolgáltatás meghibásodik (leállás vagy bug miatt), 1 órán belül javítják azt. Jó hír, hogy a csúcsteljesítők egyre többen vannak. Viszont az alacsonyan teljesítők egyre jobban leszakadnak a többiektől. Az eredmények szektortól függetlenek: ugyanúgy igazak a startupokra, a multikra és az erősen szabályozott kormányzati és pénzügyi szektorra is.

Világosan látható, hogy a csúcsteljesítményű csapatokat az különbözteti meg az alacsonyabb teljesítményű csapatoktól, hogy naponta deployálnak éles környezetbe. Első hallásra hihetelennek tűnhet, hogy valakik üzemszerűen napi többször is élesítenek, pedig ez a valóság.

 

A leggyakrabb felmerülő kérdések a következők szoktak lenni:

1. Hogyan képesek ezek a csapatok ilyen tempó mellett biztosítani a stabilitást?

2. Hogyan képes az ilyen tempójú változást az üzlet és a felhasználók lekövetni?

3. Mi miért nem tudjuk ezt jelenleg elérni?

4. Van-e értelme egyáltalán napi rendszerességgel deployálni, ahhoz képest, hogy mondjuk heti vagy havi vagy még ritkább rendszerességgel deployálnánk?

 

1. Hogyan képesek ezek a csapatok ilyen tempó mellett biztosítani a stabilitást?

Ennek a rendkívüli sebességnek az eléréséhez elengedhetetlen, hogy az üzemeltetés és a fejlesztés (és persze az üzlet is) szoros együttműködésben dolgozzon (ezt hívják devops-kultúrának, ami a gyakori félreértéssel ellentétben nem csak nagyfokú automatizálást jelent, hanem egy kultúrát is). Ha a fejlesztőknek mindig install lapokat kell írni, és egy formális, bürokratikus rendszeren átvezetni a változtatásokat mindenféle jóváhagyásokkal (tesztelés, UAT, üzemeltetés stb.), akkor ez nem fog menni. Természetesen a fejlesztőknek is garantálniuk kell a kód megfelelő minőséget. A kódnak mindig release-elhető állapotban kell lennie (Continuous Delivery: https://istvanmarhefka.com/continuous-delivery-1/ ). A CD eléréséhez a technikák megfelelő alkalmazása szükséges (ugyancsak tartalmazza a kutatás). Ezen technikák legfontosabb alapkövei a Continuous Integration és trunk-based development. Röviden: Napi 1x legalább mindenki becommitál a masterre(!), nincsenek 1 napnál tovább tartó branchek, minden build után lefutnak az automata tesztek, amik úgy vannak megírva, hogy jó eséllyel meg tudják jósolni, hogy az adott commit mehet-e élesbe. A tesztek pedig olyan gyorsak (commit stage), hogy ha el is törik a build, 10 percen belül újra stabil masterünk lehet (vagy revertálnak vagy kijavítják a hibát). További információ: https://istvanmarhefka.com/continuous-integration-01/

 

A csúcsteljesítményű csapatok egyszerre képesek a nagy sebességre és a stabilitásra. Tehát az csak egy mítosz, hogy ha gyorsan szállítunk, akkor instabilak leszünk, és a megfelelő minőség/stabilitás fenntartásához le kell lassítani a dolgokat. Miért?

 

Ha gyorsak vagyunk, bármilyen problémát nagyon hamar javíthatunk. Ellenben ha nem vagyunk gyorsak, akkor bármilyen minőségi problémát, hibát csak lassan tudunk javítani. A gyorsaságot csak megfelelő stabilitás megteremtésével lehet fenntarthatóan kezelni. És meg lehet teremteni, ahogy mutatják a példák. Ezen szervezetekben nem jár stresszel és kiégéssel az élesítés (kutatási adat). Valójában a nagyon kis változtatások élesbe telepítése összességében sokkal kisebb kockázattal jár (ha jól van előkészítve minden). Vö. azzal, amikor egy nagy release kerül élesítésre, amit utána hetekig, hónapokig fixál a szervezet. Ilyenkor minden élesítés előtt „retteg” a szervezet, mi fog majd történni az élesítés után. Péntekenként nem mernek deployálni, nehogy hétvégén gond legyen, vagy éppen leállítják a teljes rendszert a hétvégére rendszerfrissítés miatt.

 

2. Hogyan képes az ilyen tempójú változást az üzlet és a felhasználók lekövetni?

Egyalán nem okoz problémát. Az új feature-öket ún. feature toggle-ök mögé rejtik, és folyamatosan aktiválják a feature-öket egy egyre növekvő felhasználói bázis számára (Canary Releasing). Ez azt jelenti, hogy az élesben is ott a feature (vagy feature-kezdemény), de nem mindenki számára érhető el. Tesztelők láthatják, vagy az üzlet láthatja, de az éles felhasználók nem. Ehhez a tempóhoz bizalom is szükséges az üzlet és az üzemeltetés részéről, hogy megbízzon a delivery csapatban. A bizalom csak nagyon szoros együttműködéssel valósítható meg. A különböző szereplők általában fizikailag is közel dolgoznak egymáshoz.

 

3. Mi miért nem tudjuk ezt jelenleg elérni?

Kiszervezés (outsource-ing) esetén az alap felállás az, hogy a beszállító és a megrendelő szét van választva. (Szerződés, két külön entitás, ami pszichológiailag is szétválasztja a szereplőket. Az egyiknek a célja az üzleti eredményesség, a másiknak a szállítás/fejlesztés sikeres befejezése határidőre, vagy ha nincs határidő, akkor minél tovább „eladni az embereket”.) A szoros együttműködés így nem tud megvalósulni. Az üzemeltetés pedig szinte mindig a megrendelőnél van. Nem tud megvalósulni a devops-kultúra. Belső fejlesztésnél is ugyanúgy probléma lehet ez, ha bürokratikus, ha szigorúan szétválasztott szervezet működik (üzlet, üzemeltetés, fejlesztés külön).

 

4. Van-e értelme egyáltalán napi rendszerességgel deployálni, ahhoz képest, hogy mondjuk heti vagy havi vagy még ritkább rendszerességgel deployálnánk?

Tipikusan nem arról van szó, hogy valaki napi szinten változtatja az üzleti igényeket, és ezt kell napi szinten lekövetni. Hanem hogy a csapat képes napi szinten deployálni azt, amit épp megcsinált, és ez sokkal hatékonyabb, mintha hetente vagy havonta deployálna. Bármilyen változást vagy meghibásodást képes sokkal hamarabb lereagálni, nem kell annyit fejbentartani, nyomkövetni, váltogatni félbehagyott feladatok között stb (lean wastes). Bármilyen változtatás azonnal lemérésre kerül a rendszerben és a felhasználókon, és ez egy nagyon rövid visszacsatolási hurkot eredményez. Ezek a mérések a teljes szervezetben megosztásra kerülnek. Az ilyen fajta működés végül szervezeti szinten is komolyan mérhető teljesítménynövekedést eredményez, ami komoly hatással van az üzleti eredményességre (profit, piaci részesedés, termelékenység). Bizonyított tény, hogy azok a fejlesztő csapatok, akik képesek naponta deployálni, sokkal magasabb szintet képviselnek műszakilag a többiekhez képest, és nyugodtan lehet őket elitnek hívni. Sokkal kifinomultabbak a módszereik, sokkal fegyelmezettebbek és szervezettebbek, sokkal hatékonyabbak. Képesek a napi deployt stabilan hozni stressz nélkül. Sebesség és stabilitás együtt jár, ha a csapat elit/csúcsteljesítő. A tanulmány leírja, hogy ez minden szektorban így van, az erősen szabályozott szektorokban is (pénzügy, kormányzati). Akik lassan szállítanak, lemaradnak.

 

A tanulmány egyik fontos következtetése az, hogy az üzletnek a stratégiailag fontos területeket nem szabad kiszervezéssel megvalósítania, mert mérhetően jelentős üzleti hátrányba kerül a jelentősen alacsonyabb szállítási teljesítmény miatt. Azok a szervezetek, akik csúcsteljesítők, 2x nagyobb valószínűséggel múlják felül saját szervezeti teljesítmény céljaikat (profit, piaci részesedés, termelékenység). Amíg az üzlet nincs rákényszerítve a fejlődésre, addig az alacsonyabb teljesítmény is megfelelő. A hatékonyságnövelés viszont csak szoros együttműködésben tud megvalósulni a műszaki oldallal, akinek műszaki kiválóságra kell törekednie.

 

A másik fontos következtetése a kutatásnak, hogy a műszaki kiválóság eléréséhez használt műszaki gyakorlatok kritikus fontosságúak a csúcsteljesítmény elérésében (pl. Continuous Integration, Trunk-based development, Version Control). Mivel ezek a szereplők szoros együttműködését igénylik, végül maguk a műszaki módszerek szervezetfejlesztő hatással fognak bírni, amennyiben sikeresen alkalmazzák őket. Tehát nem szabad csupán a menedzsmentmódszertanok (pl. SCRUM) kereteire bíznunk magunkat, el kell érnünk, hogy a megfelelő műszaki gyakorlatok is használhatban legyenek. Csupán felülről lefelé nem tervezhető és szervezhető meg egy jól működő szervezet, a különböző területeken dolgozó embereknek (üzlet, fejlesztés, üzemeltetés) meg kell találniuk a módját, hogyan tudnak szorosan jól együtt dolgozni. Ebben jó mankót ad a kutatás, hogy tudjuk, milyen gyakorlatokat alkalmazzunk.

Összefoglaló gondolatok

 

Manapság az önszerveződő csapatok képesek hatékonyan megoldást adni a komplex problémák megoldására. Kihasználják a csapatban lévő kollektív intelligenciát (a csapat döntése jobb mint a legokosabb tagjának döntése), és képesek megfelelően alkalmazkodni az előre nem látható változásokhoz (komplex adaptív rendszerek). Az önszerveződő csapat tiszta határai, felelősségi köre leválasztja őt a szervezet többi részéről, így autonómiában saját döntési jogkörrel hatékonyan tud döntést hozni az őt érintő kérdésekben elkerülve a folyamatos megszakításokat és a bénulást okozó állandó meetingeket a szervezet többi részével. (Egyeztetések továbbra is kellenek.)

 

Mivel az önszerveződésben a csapattagok maguk döntenek a megvalósítás módját illetően, motivációjuk jelentősen megnő, ami hatással van az elkötelezettségükre. Az elkötelezettség viszont hosszú távon csak akkor tartható fenn, ha a csapattagok számukra is értelmes célokért dolgozhatnak. Az önszerveződés (és ezzel együtt az agilitás) legmagasabb fokát a teal szervezetek mutatják. Az ő példájukon keresztül perspektívát és inspirációt nyerhetünk, milyen a jó önszerveződés, és miért működik (profit helyett magasztos célok és értékek, hierarchiapiramis helyett csapatok hálózata, szabályok és kontroll helyett szabadság és bizalom, titkolózás helyett radikális transzparencia stb.). Ezáltal felismerhetjük és elkerülhetjük az álagilitást (fake agile) is.

 

Csúcsteljesítményű IT-szervezetek működésében elengedhetetlen a DevOps-szemlélet, amely a műszaki kiválóságot és a szoros együttműködést (fejlesztés-üzemeltetés-üzlet) teszi kötelezővé. Kutatások bizonyítják, hogy azon szervezetek, akik nem valósítják meg ezt, jelentősen kisebb eséllyel lesznek üzletileg sikeresek, és lemaradnak a piacon. Ennek elkerülése pedig ismét az emberek szoros együttműködését és önszerveződését követeli meg.

 

Összegzés

A Műhely célja, hogy felhívja a figyelmet a munkahelyi kultúra fejlesztés önszerveződést érintő feltételeire, lehetőségeire. A közös beszélgetés során a résztvevők meggyőződhetnek arról, hogy az önszerveződés

A Műhely beszélgetés, a közös gondolkozás elősegítheti a menedzsment szakmai tudás fejlődését, az elméleti eredmények gyakorlatba ültetését.

 

A 43. PM Műhely (2019. november 21. 16:00-18:00, BME Infopark I. B. 110) témájához kapcsolódó, megbeszélendő kérdések:

1. Projektmenedzserként hogyan alakítható ki egy új projekt esetén a megfelelő projekt struktúra ? A jelenlegi helyzetben milyen korlátai vannak ennek a feladatnak ?

2. Milyen esetekben segíthetnek az önszerveződő csapatok a projektekben ? Miben látható az önszerveződő csapatok legfőbb előnye ?

3. Mi a gátja napjainkban, hogy a projektekben önszerveződő csapatok kerüljenek kialakításra ? Hogyan lehetne elérni, hogy egy önszerveződő csapat bizalmat keltsen ?

4. Teljes szabadság esetén milyen felkészültségű coachot választana a munka támogatására ? Miben tudná a coach és a coaching szemlélet alkamazása segíteni a projekt szervezetet ?