Az egyik cikkhez kapcsolódóan gpinter felvetett egy problémát, ami igen tipikus és igen tanulságos, ezért érdemes vele egy külön cikkben foglalkozni.

Az egyik cikkhez kapcsolódóan gpinter felvetett egy problémát, ami igen tipikus és igen tanulságos, ezért érdemes vele egy külön cikkben foglalkozni.

Az eredeti hozzászólás az Antipattern: a külsős Architect cikk alatt olvasható. Az egyszerűség kedvéért idemásolom az információkat.

Sok évig egy külső kkv csinálta az architekt részt. Az elején nagyon jó volt, mert lesték minden gondolatunkat, full belsősként viselkedtek, bent is töltötték idejük nagy részét, megismerték az üzleti folyamatainkat. Minden szakmai kérdésben a kkv döntött, csak üzleti szereplőkkel tartottak kapcsolatot, vállalati IT-vel nem. IT-s szemmel nem lett átvéve az elvégzett feladat, annyi volt csak a teljesítés ellenőrzése, hogy működik-e a képernyőn az új funkció vagy nem. Architekt jellegű információk nincsenek a rendszerekről.

Időközben megromlott a kapcsolat, nem járnak már be hozzánk, nem követik az üzleti folyamatokat, úgy lehetnek vele, hogy amit tudnak pénzt még kiszednek, nem gondolkoznak hosszú távra. A korábbihoz képest sokkal passzívabb achitect szerepet játszanak, jövőkép nélkül, csak az adott feladattal törődve, minél nagyobb teret engednek az önjelölt belső architekteknek. Ezek a belső emberek pedig az ismeretek hiánya miatt nem tudnak alapos döntéseket hozni és a végén meg kénytelenek benyelni az újabb problémás szoftvert, merthogy így lett kérve.

Gondolom ez a vegyes külső-belső architekt egyszerre sem jó.

Az a kérdésem, hogy ilyen helyzetből milyen lépésekkel lehet átmenni rendes belső architect felállásba?

Nem ehhez a bejegyzéshez tartozik szorosan, de hogy kell elindulni, van-e rá valami gyári módszer, feltérképezni a meglévő rendszereket, felépíteni egy tudásbázist a kapcsolatokról, architektúráról? Mi erre a best practice? Vagy vmi bevált case eszköz?

1) Ki fizeti a külső architekt-et, az üzlet vagy az IT?"

Ezeknek a projekteknek a költsége teljesen az üzleté.

"2) Kivel áll a kkv szerződéses kapcsolatban?"

A közös céggel magával, esetleg azon belül a beruházási osztállyal, de lehet nem jól értem a kérdésedet.

Ezeket a dolgokat annyira nem ismerem. Én üzemeltető melós vagyok, nem manager. Eddig csak 1 nagyprojektet láttam belülről, amikor érkeztem, ott manager szerepet töltöttem be, és a továbbiakban ebbe az irányba menne automatikusan a karrierem, ha el nem megy a kedvem..

"3) Ki végzi a fejlesztést?"

A kkv.

"4) Ki végzi a minőségbiztositást?"

Nem tudok arról, hogy lenne ilyen.

"5) Az egész produkció az IT jóváhagyásával vagy az IT háta mögött történik?"

Nem háta mögött, egyszerűen ki vannak hagyva. Vannak olyan hagyományosan üzlethez kötődő alkalmazások, amiknél az IT szóba sem kerül. Ennek a hátterét nem ismerem. Régóta így megy, ezért nem feltűnő. ITnek van elég dolga, néha azért átvesz pár alkalmazást az üzlettől hogy onnantól fogva ők üzemeltetik. Ezek szerint valakik foglalkoznak ott ilyesmi kérdésekkel, de én nem ismerem még őket.

"6) Kié a forráskód és a szoftver jogai?"

Amit láttam, hogy a szerzősédben benne volt, hogy a forráskód is átkerül, de mégsem adja oda a kkv. Aki átveszi az nem kéri el. Amikor ezt láttam és szóvá tettem, akkor félreállítottak. (ez pont egy csókos ember) A szoftver jogát sajnos nem tudom, meg kell nézzem majd.

"7) Mi volt a kezdeti megállapodás a kkv és az architect szerepéről?"

Ilyen részletességű megállapodások nem voltak.

"8) Mekkora szoftverről van szó, mennyire kritikus az üzlet számára és mennyi idő alatt lehetne újrairni?"

A felesleges túlbonyolítások (komplexitások, amiről a bejegyzésben is szó van) miatt nagynak és bonyolultnak tűnik, nem igazán átlátható, nem jól strukturált, összefolyik minden mindennel. Darabra a kisebbekkel együtt közel 100 különálló alkalmazás, több mint 10 év alatt. Vannak benne nagyon kritikusak is, de olyanok is, amik nélkül meg lehet lenni. Újraírás idejére nem tudok saccolni, sok helyen nincs is letisztult üzleti igény, és olyan IT-s sincs a látóhatáron, aki képes lenne átlátni, ez lenne talán a több idő.

Nagyon szép és tipikus történet. Annyira tipikus, hogy nekem is fut most egy hasonló.

A trükk az, hogy a történetben van egy látszólagos hiba, amire gprinter választ keres, pedig valójában más a hiba és más a megoldás is. Meg kell keresni a valódi hibát, ami el van rejtve a sorok között!

Mi nem stimmel ebben a történetben? Sok dolog, de kiemelném a lényeget.

„Az egész produkció az IT jóváhagyásával vagy az IT háta mögött történik? Nem háta mögött, egyszerűen ki vannak hagyva.” – ez itt a kulcs. A hozzá nem értő üzleti felhasználók és menedzserek szoftvert fejlesztenek a szakértők (IT) kihagyásával.

Miért nem az IT fejlesztette ki – akár belső akár külső erőforrásból - a szoftvert? Mert nincs elég emberük/pénzük. Miért nincs elég pénzük? Mert nem kapnak. Miért nem kapnak? Mert az üzleti felhasználók lenyúlják, hogy szoftvert fejleszthessenek.

Nonszensz, nem igaz?

Mi lenne a normális? Ha a kkv-nek fizetett összes pénzt az IT kapta volna, és az IT fejlesztette volna ki – tisztességes minőségben – a szoftvert.

A magam részéről megkérném a könyvelést, hogy szedje össze a kkv által benyújtott összes számlát, összeadnám a szoftverért kifizetett összeget. Utána beszélnék a CFO-val, hogy a cég mennyi pénzt kidob feleslegesen, és hogy meg kellene állítani az árnyék projekteket. Esetleg megmutatnám neki a számlákat, és beszámolnék neki az „eredményről” (x millióért cserébe van egy rossz szoftver).

Másrészt beszélnék a Beszerzési Vezetővel, hogy a jövőben egyetlen informatikai jellegű megrendelést se hagyjon jóvá az IT vezető jóváhagyása nélkül. Mert az pont olyan, mint beszerzések lebonyolítása a beszerzés nélkül… ugye világos?

Harmadrészt pedig… nem aggódnék egy percet sem. Ezt a szoftvert az üzlet fejlesztette ki az IT jóváhagyása nélkül, tehát ez az ő problémájuk (most feltételezem, hogy gprinter az IT-n dolgozik). Oldják meg. Mivel a belső IT nem ismeri a szoftvert, nem állnak rendelkezésre a szükséges dokumentációk, és a szoftver nem a megfelelő minőségben készült, ezért én semmilyen garanciát nem nyújtanék az üzemeltetésére, és kisujjamat se mozdítanám. Ellenállnék minden olyan kísérletnek, hogy az IT vegye át a szoftver vagy bármilyen formában üzemeltesse/felelősséget vállaljon érte. Fontos azt látni, hogy minél inkább segíteni próbálsz annál rosszabb lesz, hiszen a segítséggel elfeded a hibákat és annál tovább tart a vergődés.

Szóval nem erőlködnék, hanem hagynám hogy a problémák a felszínre kerüljenek (rendszerösszeomlás, tovább nem fejleszthetőség), eszkalálódnak, és akkor majd mindenki nagyon együttműködő lesz.

Ne áltassuk magunkat: a helyzet rossz. A legrosszabb opcióból indulnék ki (teljes újraírás), ez lenne mindennemű költségbecslés alapja. Ha szerencséd van, akkor ezt-azt fel lehet még használni, esetleg a kód is megőrizhető valamilyen formában. De bármi is lesz a megoldás, pénzbe fog kerülni. Tulajdonképpen csak arról beszélgetünk, hogy a végösszeg sok vagy nagyon sok lesz-e.

Mi az ideális megoldása a helyzetnek? Ha a szoftvert a belső IT üzemelteti, belső az archietkt, rendelkezésre áll a dokumentáció, a szoftver megfelel a belső IT előírásoknak, és az IT megfelelő tudással/erőforrásokkal rendelkezik az üzemeltetéshez. Ehhez 4 dolog kell:

1) Forráskód és jogok

2) Megfelelő minőség

3) Dokumentáció és oktatás – tudásátadás a kkv-től

4) Megfelelő erőforrások

A legszűkebb keresztmetszet a forráskód. Ha ez nincs a cég birtokában, akkor felejtős az egész, marad az újraírás. (Hallottam már olyan kkv-ről, amelyik ilyen esetben – jó üzleti értékkel - trillió-millió eurót kért a forráskódért)

(Ha a forráskód nem a cégé, akkor fenékbe rúgnám a jogi és a beszerzési vezetőket, miért hagynak jóvá a cégre nézve kedvezőtlen szerződéseket…)

De a forráskód még nem elég, szükséges az, hogy érthető, világos és olvasható legyen. Egy spagetti kódolással irt szoftvert nem biztos, hogy átvennék.

Ami mindenképpen szükséges, az együttműködés a kkv oldaláról. A tipikus „legjobb gyakorlat” az, hogy a fejlesztésben résztvevő kulcsemberüket át kell csábítani belső architekt-nek (és ez a válasz a feltett kérdésre).

És itt jön képbe az erőforrások, illetve az anyagiak kérdése. Mivel ez elég nagy szoftver, az üzemeltetési, tervezési és fejlesztési feladatok ellátásához szükség lesz extra emberekre – akiket valamiből fizetni kell. Ennek költségét vagy a pénzügy (megnövekedett üzemeltetési költség) vagy az üzlet (belső ügyfél-belső beszállító) fedezze.

„Ki végzi a minőségbiztosítást? Nem tudok arról, hogy lenne ilyen.” – nem kell mondanom, hogy ez mennyire nem helyes. Ha a fejlesztés tényleg nagy, akkor szükség van rá. Ez a cég belső IT előírásainak követését jelenti, illetve azok ellenőrzését.

Ugye nálatok is minden szerződésben benne van, hogy „… és a beszállító köteles megfelelni a megrendelő belső szabályainak.”? Meg hogy „a beszállító köteles legjobb minőségben, az iparági szabványoknak megfelelően dolgozni”? Ha nem, fenékberúgós meeting megszervezése az ügyvédeknek…

"Kié a forráskód és a szoftver jogai? Amit láttam, hogy a szerzősédben benne volt, hogy a forráskód is átkerül, de mégsem adja oda a kkv.” – Mi az, hogy nem adja oda? A forráskódot minden release-nél elkérném, hiszen ez jelenti tulajdonképpen az átadás-átvételt.

"Mi volt a kezdeti megállapodás a kkv és az architect szerepéről? Ilyen részletességű megállapodások nem voltak.” – kellett volna, sün az ügyvédnek. (Félreértések elkerülése végett: a szerepek tisztázása nem csak a multit védi, hanem a kkv-t is, mindkét félnek érdeke)

Nem aggódnék azon ebben a fázisban, hogy milyen eszközt használnék a szoftver feltérképezésére, mert sokkal súlyosabb problémák vannak.

(Csak a teljesség kedvéért: mi MEGA-t használunk, illetve az Enterprise Architect egy jól bevált eszköz)

Mind mondhatnék így a végére? Sok sikert, nem lesz egyszerű! A részletekkel kapcsolatban szívesen segítek.

A többi Kedves Olvasót pedig arra biztatom, hogy ha megoldhatatlannak tűnő problémája van, nyugodtan ossza meg.