Weblabor

Az Arkonnál februárban vezettünk be a dedikált kutatói pozíciót, melyhez azóta keresünk módszertanokat, melyek segítenek, hogy „tudományosan” történjen nálunk a kutatás. Ennek kapcsán találkoztam egy nagyon hasznosnak tűnő analitikai, döntéshozási keretrendszerrel, mely Cynefin (ejtsd „Kinevin”) névre hallgat. Segít megmondani, hogy egy problémára milyen megoldási módszert érdemes használni, s kiválóan alkalmazható a fejlesztés során felmerülő helyzetek kategorizálására is.

Másként megközelítve a kérdést, a Cynefin segítségével olyan felismerésekre juthatunk, hogy mikor tud működni a „vízesés” modell, mikor a Scrum, a kutatással, rendszertervezéssel megtámogatott fejlesztés, és hogy mikor kell azonnali cselekvéssel reagálnunk egy problémára, félredobva az egyéb módszereket.

Nem egy mai dologról van szó, még 1999-ben kezdték el kidolgozni. Nem is egy nagy ördöngösség, elég gyorsan megérthető, viszont annál hasznosabb lehet. Ebben a cikkben a fejlesztők kapcsán közelítem meg a kérdést, de amúgy egy általános módszertanról beszélünk, mely a cégeknél fellépő helyzetek megoldásában tud segíteni, bármely cégnél.

A Cynefin öt területet határoz meg: az egyszerű, a komplikált, a komplex, a kaotikus, és extraként a zűrzavar helyzeteket. Ezek olyan elnevezések, melyek mögé részletesebb definíció lehet szükséges, ugyanis nem teljesen a hétköznapi értelmüket használjuk. Íme a 4+1 terület magyarázata, meg hogy milyen módszert célszerű választanunk az adott helyzetben:

Egyszerű

Ahol a megoldási módszer teljesen nyilvánvaló, bárki meg tudja oldani a problémát, mert józan paraszti ésszel kitalálható a módszer. Rutinszerűen, bevált megoldáshoz nyúlva végezhető el a feladat. Létezik a „legjobb megoldás”. A megoldás menete: értelmezés, kategorizálás, majd válasz.

Ezek a feladatok olyan módszert igényelnek, melynek a lehető legkevesebb adminisztráció, a gyors és hatékony feladatvégrehajtás a sajátja. Ilyen feladatoknál a vízesés modell is hatékony lehet, a scrumot viszont lehet, hogy már túl soknak érezzük, ami például az „adminisztráció” részét illeti.

Komplikált

A megoldás elemzést vagy valamilyen más vizsgálatot, tudás alkalmazását igényli. Tervezhető, de tapasztalatot igényel. Szintén valamely már bevált, széleskörűen használt módszerrel oldható meg a probléma, de hogy mi a megoldás, ahhoz szakértőnek kell lenni a témában. Nem feltétlenül van egyedüli „legjobb megoldás”, inkább csak „jó megoldások” léteznek. A megoldás menete: értelmezés, elemzés, majd válasz.

Ezek a feladatok azok, melyek kiválóan illeszkednek a scrumos, vagy más agilis módszertanhoz. Hatékonyan taszkosíthatóak, hiszen ha megvan a tapasztalat, akkor könnyen kisebb részekre bontható rutinszerűen a feladat.

Komplex

A megoldás csak utólagosan visszatekintve állapítható meg, előre semmiképp. Esetlegesen sejtések fogalmazhatóak meg, melyek vagy beválnak, vagy nem. Ez egy első ránézésre is bonyolult, utánajárást igénylő helyzet. A megoldás valami új megalkotását jelenti. A megoldás menete: nyomozás, megérzés, majd válasz.

A nyomozás alatt több dolgot is érthetünk. Rendszertervezést, ha a feladatot már ismert eszközökkel, de időtállóan szeretnénk kivitelezni, és ki kell dolgozni, hogy az üzleti igények hogyan illeszkednek bele a rendszerünkbe. Kutatást, ha felmerül, hogy egy új technológiáról, vagy mélyebb utánajárást igénylő feladatról van szó. Ezek a feladatok nehezen illeszthetőek a scrum módszertanába, mivel az erőforrásigény előre nem tervezhető. Ez második lépésben, a tervezéssel vagy kutatással feltérképezett lépés után meghatározható.

Kaotikus

A káosz a gyors cselekvés helyzete, vészhelyzet. Az igazi problémát sem ismerjük, nem hogy a megoldást. A (gyors) cselekvés lép a középpontba, a kontroll megszerzése, hogy a megoldás felé lépjünk. Ebben a helyzetben a megoldás a cselekvés, értelmezés, majd válasz.

Kaotikus a helyzet, ha az éles rendszerben egy nagyobb hiba lép fel, és arra nem tudunk rutinszerű megoldást kínálni. Ekkor kell az egyéb módszertanokat félredobva gyorsan és hatékonyan kezelni a problémát. Adott esetben ez a scrum leállításával is járhat, hiszen az új fejlesztéseknél prioritásosabb a már működő üzleti folyamatok fenntartása.

Zűrzavar

Ez az ötödik helyzet, ami igazából arról szól, hogy nem tudjuk felismerni, hogy melyik helyzet van az előzőleg felsoroltak közül. Ebben a helyzetben a szereplők azt a megoldási módszert válasszák, mely számukra a legkényelmesebb, melyben komfortosan mozognak. Innen származik a keretrendszer elnevezése, mivel ebben a helyzetben döntünk gyökereinkhez visszanyúlva így, vagy úgy, korábbi tapasztalatainkra, gyakorlatunkra építve. Képzeljük el a fentiek közül bármelyik helyzetet, majd azt, hogy mi történik, ha valaki egy másik helyzet szerinti módon próbálja megoldani. Ez tényleg zűrzavar lesz.

Határok

A zűrzavar állapot felléphet szimplán rossz helyzetfelismerés eredményeképpen, de okozhatja kevés (valós) információ a problémáról, esetlegesen külső nyomás hatására is történhet (egy komplex problémát kaotikusként kezelünk, mert azonnal meg kell oldani). A problémák azonban nem csak a zűrzavar állapot esetén merülnek fel. Nagyon könnyű átlépni a határokat, melyek szintén problémát okozhatnak.

Egy gyakorlott szakember hajlamos például elbagatellizálni egy-egy problémát, egyszerűnek gondolva a bonyolultabbakat is. A Cynefin ábráján ezt jelzi is a határvonal az egyszerű és a kaotikus között. A rossz kategorizálás ilyenkor azt eredményezheti, hogy a fejlesztő hirtelen egy kaotikus helyzetben találja magát. Szintén gyakori problémaforrás lehet az a helyzetet, amikor egy problémát komplikáltnak gondolunk, de aztán kiderül, hogy valójában komplex. Bár a Cynefin alapvetően egyértelműen választja szét a helyzeteket, a „gyökereink” miatt könnyű lehet hibázni, rosszul besorolni a problémákat.

További olvasni- és néznivalók

A Cynefinnel egy blogbejegyzés kapcsán találkoztam, mely Cynefin for Devs címmel jelent meg két hete. Néhány helyen bővebben, más szemszögből világítja meg a kérdést, kiváló olvasmány, csak ajánlani tudom.

Ha rákeresünk képekre a Cynefinről, akkor láthatjuk azt is, hogy a fentebb írtaknál sokkal mélyebben is alkalmazható ez a módszer.

Szintén egy jó anyag a témában a következő videó, mely röviden összefoglalja a témát, ezúttal nem a fejlesztés, hanem a szervezetek szemszögéből: