Egy barátom, aki főállásban egy szoftverfejlesztő cégnél dolgozik, azt mesélte, hogy egy új, komplex államigazgatási projekt ajánlati fázisában járnak.
Egy másik céggel kell együtt dolgozniuk, akiknek szintén a szoftverfejlesztés a profilja. A két cég egymásnak konkurense, viszont mindkettő rendelkezik olyan ismerettel, referenciával, amelyet ha együttesen használnak fel, akkor a további ajánlatadóval szemben sokkal nagyobb eséllyel indulnak, mintha külön-külön indulnának (ráadásul akkor nem lesznek még egymás versenytársai sem).
A két cég vezetése eldöntötte: együttes ajánlatot adnak be.
Ki mit kap?
Többször is egyeztettek a vezetők, viszont nem tudtak előre lépni abban, hogy ki legyen a fővállalkozó, és abban sem, hogy ki milyen részeket kapjon a projektből.
Mivel az ajánlat beadási határideje még messze volt – egyfajta “időhúzásként” az a döntés született, hogy üljön össze a két cég szakmai vezető gárdája, és vízionáljanak közösen egy architektúrát. A közösen megalkotott architektúra a későbbre halasztott “osztozkodás” kiindulópontja lesz.
Az architektúratervezés
A szakértők összeültek. A légkör bizalmatlan volt, egyik gárda sem tudta, hogy mi van a másik fejében. Ki mire akar lecsapni, és azt magának megszerezni? A kialakult bizonytalanságban mindkét csapat tudat alatt amellett a munkamódszer mellett döntött, hogy a közös megbeszéléseken ad-hoc alakítják ki majd a közös architektúrát egymás reakciói és elképzelései alapján.
Az egyik szakértő először felrajzolt egy ábrát. Ránézett a “riválisokra”, akik nem nagyon szóltak hozzá a dologhoz. Azért nem volt válasz, mert a riválisoknak, azaz a barátoméknak nem igazán tetszett az elképzelés. Nem látták benne, hogy pontosan mik azok a részek, amiket magukénak mondhatnának a későbbiekben. Olyan érzésük volt, mintha egy olyan idegen megoldásba próbálnák terelni őket, amibe nekik igazából nincs beleszólásuk.
Folytatódtak az egyeztetések, de a bizalmatlan légkör ugyanúgy megmaradt. Mindenki a másikat figyelte, és a reakciók alapján próbálta alakítani az éppen aktuális elképzelés részleteit. Aztán amikor már jó bonyolulttá vált, és senkinek nem tetszett, új megoldásból “növesztettek” hasonló szörnyetegeket.
Két megbeszélés után sem hoztak döntést az architektúra lényegéről. Patthelyzet alakult ki, amiből nem látszódott a kiút.
A megoldás
A barátom végül úgy döntött, hogy kezébe veszi az irányítást, és egy belső megbeszélést szervez a kollégájával, akivel kialakítanak egy saját álláspontot. (Már közöttük is volt egyfajta érdekellentét a technológiai platformok különbözősége és a későbbi szerepvállalásuk, felelősségük tekintetében.) A barátomnak volt egy elképzelése, ezt a kollégájával gyorsan meg is beszélte. Tetszett neki is a megoldás.
A következő közös megbeszélésen (ami immáron már a harmadik volt) sikerült együttesen elfogadni a koncepciót. A koncepció lényegében egy olyan megoldást vázolt fel, amely – függetlenül attól, hogy végül ki melyik részét csinálja majd a projektnek – egy technológiailag megfelelő megoldás, ami nem határozza meg azt, hogy ki min kell, hogy dolgozzon a későbbiekben (nyitva hagyja tehát a kérdést), így végül a vezetők későbbi döntését sem fogja tudni megkönnyíteni.
A két szakértői csapat tehát meghozta a legjobb szakmai döntést, és felülkerekedett azon, hogy a két cégnek mi állna az érdekében. Olyan megoldást találtak, amelytől nem származik hátránya egyik félnek sem.
Conway törvénye
A közös egyeztetéseken az látszódott, hogy mindenki próbálja a saját érdekei, a számára legjobbnak tűnő részmegoldások hozzá toldozgatásával, foldozgatásával előresegíteni a koncepciót. Ha valami nem tetszett a másiknak, akkor közösen csavartak egyet rajta, és úgy rakták hozzá a modellhez.
Tetten érhető volt Conway törvénye a folyamat közben:
“Azon szervezetek, amelyek rendszereket terveznek, olyan tervezési döntéseket kényszerülnek hozni, amelyek lemásolják az egyes szervezetek közötti kommunikációs struktúrákat.”
A fenti esettanulmányon túl más példák is említhetők (Wikipediából).
1. példa. Megtörtént eset, hogy a NASA egy korábbi, a Marsot vizsgáló űrhajója azért semmisült meg, mert az egyik tervező csapat amerikai mértékegységekben számolt (hüvelykekben, lábakban stb.), míg a másik metrikus mértékegységekben. A probléma okát nem a konkrét hibában kell keresni, hanem a NASA rendszertervezési folyamataiban, amely képtelen volt ezt a hibát felismerni.
2. példa. Adott egy lefejlesztendő komplex rendszer. Egy cég elnyeri a fejlesztést, és 3 csapatára osztja szét a feladatot. Convay törvényének értelmében a kialakuló rendszer is jó eséllyel 3 főbb alrendszerből fog állni, az egyes alrendszereket a megfelelő csoportok készítik. Ami ennél sokkal érdekesebb, hogy az alrendszerek közötti interfészek is erőteljesen tükrözni fogják a csapatok közötti valós életbeli személyes kommunikáció minőségét és természetét.
3. példa. Újabb példaként említhető egy kétszemélyes (A-ból és B-ből álló) szoftverfejlesztő csapat esete, amelyben A elkészít egy X osztályt. A későbbiekben új funkciót kell implementálni X-be. Ha A végzi a munkát, akkor egyszerűen az osztályban valósítja meg az új funkciót, ha B csinálja a melót, akkor – attól tartva, hogy valamit elront X-ben – inkább származtat belőle egy X2 osztályt. (Tegyük fel, hogy nem írnak unit-teszteket J)
[Updated - közkívánatra alternatív befejezés]
Mi a tanulság?
Sokszor beleesünk abba a csapdába, hogy elfogadjuk a körülményeket, és azok áldozatává is válunk. A Conway-törvény csupán egy megfigyelés. Legyinthetünk is rá, hogy semmire nem jó. Viszont ha tudatában vagyunk valódi jelentésének, és képesek vagyunk kitekinteni aktuális problémáinkból, megérthetjük, hogy hogyan hat a projektjeink megvalósítására a különféle egyének, csoportok, szervezetek tömörülése és az ezek között lévő kapcsolat, kommunikáció.
Ha megvan a felismerés, talán változtathatunk is, és olyan megoldást alkothatunk, amely szakít a megszokott felállással, és egy hatékonyabb, jobb csapatot, szoftverterméket eredményez.