Kővári Zoltán
-
Director, Rapid Software Development
Ismerős helyzet? A projekt késik, az új termék nem készül el határidőre, mert... És a következő meetingen elkezdődik az üzlet és az IT egymásra mutogatása. Az IT nem szállított határidőre, ráadásul, amit késve átadott, használhatatlan – vádol az üzlet. Igen, replikázik a fejlesztési vezető, de az üzlet ezt rendelte. A fejlesztők egyébként is csak hozott anyagból tudnak dolgozni, de nem kaptak pontos specifikációt, és vagy hetvenszer változott a projekt scope-ja, amit már agilis módszertannal sem tudtak lekövetni. Arról nem is beszélve, hogy az egész fejlesztési részleg elképesztően túlterhelt, háromszor annyi fejlesztési projektet visz, mint amennyit elbír, és a legnagyobb hajrában mindig érkezik a vezértől egy "extra sürgős" kérés.
Az érdekellentétek és feszültségek egyik következménye, hogy az üzlet elkezd saját szakállára egyedi adatbázisokat építeni, Excelben bűvészkedni stb. Így hamarosan létrejön egy olyan kiterjedt árnyékinformatika, amire az IT-üzemeltetésnek lényegében semmi ráhatása nincs, nem érvényesítheti rá a vállalati policykat, emiatt IT-biztonsági (és GDPR-) kockázata is óriási.
Mi sem egyszerűbb, mondják a menedzsmenttankönyvek: a feleket össze kell hozni, hogy ne érdekellentét, hanem érdekközösség legyen közöttük, ami még a feladatok megosztására is pozitívabban hathat. Ez egy csapásra felgyorsítja és agilissá teszi a fejlesztést és az üzleti lépéseket: csökkenti a tévutakat, pontosabb és gyorsabb lesz a visszacsatolás a fejlesztési folyamatban. A siker pedig közös lesz, ezért mindenki érdekelt benne.
Már csak az a kérdés, hogyan lehet ezt kivitelezni. A fejlesztő legtöbbször kódsorokban gondolkodik, az üzlet pedig az üzleti folyamatokban, üzleti adatokban, egy eredményt szeretne látni, az kevéssé érdekli, hogy az elvárt végeredmény hogyan áll elő. Pedig nagyon is kézenfekvő az érdekközösség. Az üzlet ismeri a piaci igényt, az IT pedig a lehetséges digitális megvalósításait. Ennek az érdekközösségnek megteremtéséről szól több éve minden: az agilis nagyvállalat eszméje, a DevOps vagy a low-code/no-code fejlesztési eszközök.
Kézenfekvő megoldás, hogy átadjuk a fejlesztés bizonyos területeit az üzletnek. Azt megnézem, amikor az üzleti elemző fejleszteni kezd! – mondja erre a fejlesztési vezető. A közös platform megtalálása azonban egyre égetőbb. Az IDC (International Data Corporation) például azt prognosztizálja, hogy a vállalati IT egyik fontos középtávú trendje a vállalati alkalmazások számának robbanása lesz. A vállalatok néhány éven belül szoftver vezérelt "digitális innovációs gyárrá" alakulnak, 2025-re pedig a vállalkozások közel kétharmada elképesztő mennyiségű szoftvert fog gyártani, naponta fog kódot telepíteni – írják egyik elemzésükben. Ez az ipart is erősen érinti: az elkövetkező néhány évben, 2023-ig annyi ipari alkalmazást fejlesztenek, mint amennyit az elmúlt negyven évben összesen. Az IDC kb. 500 millió alkalmazással és szolgáltatással számol.
Fejlesztőből, különösen jó fejlesztőből ma is hiány van. Így könnyen belátható, hogy ezt a szoftverigényt még akkor sem lesz képes az IT egyedül kielégíteni, ha beválik az IDC jóslata, és az évtized közepére másfélszer annyi fejlesztő ontja magából a kódokat, mint ma.
Ha el akarjuk érni, hogy ne a fejlesztési kapacitás legyen a szűk keresztmetszet, be kell vonni a fejlesztésbe az üzletet is. Olyan eszközt kell az üzleti felhasználók kezébe adni, amely alkalmas az üzleti folyamatok leírására, az elvárt képernyők, felületek vázlatának felrakására stb. Pontosan erre alkalmasak a low-coding platformok: olyan eszközök, melyeket használva egy üzleti elemző projektvezető, termékmenedzser szakértő is kicsit fejlesztővé válhat anélkül , hogy egyetlen kódsort le kellene írnia. Ők lesznek az ún. citizen developerek, a civilek a pályán. Igen, civilek, mégis tudnak az IT nyelvén beszélni, mert lesz egy automatikus tolmácsa – a low-coding platform – az általuk leírt, elképzelt üzleti logikát átfordítja részben kóddá, részben az IT által értelmezhető nyelvre.
Persze az IDC rajzolta trenddel együtt a fejlesztési vezetőnek is igaza van. Nem minden potenciális citizen developer lesz civilfejlesztő.Kellenek bizonyos előismeretek és skillek. Az algoritmikus gondolkodás például nélkülözhetetlen, de némi Excel-programozásban szerzett tapasztalat sem hátrány.
1. A fejlesztő azzal foglalkozik, amihez ért. Fentebb már említettük, jó programozóból hiány van. Magyarországon az IVSZ rendre több tízezerre becsüli az informatikushiányt, amit független kutatások is megerősítenek, de a szakmában világszerte extrém alacsony a munkanélküliségi ráta. Ha van egy jó low-coding platform, az üzleti oldalt aktívan bevonva a projektbe gyorsan összerakhatnak olyan üzleti alkalmazásokat, amiket a utána már csak véglegessé kell csiszolni, és integrálnia kell az IT-infrastruktúrába.
A low-code létjogosultságát még a kódoláshoz egyébként ragaszkodó fejlesztők is hajlandók elismerni. Hogy azonnal hozzá is tegyék: mint mindenben, a low-code platformok használatában sem árt a mértékletesség. Azaz fel kell mérni, mire alkalmas, mire nem. Nem low-code platformon kódolják le a világmindenség problémáit. A low-code platformoknak is meg vannak a korlátai. Ez egy célszerszám, adott helyen, adott feladatokra.
2. Csökken a shadow IT veszélye. Mivel az üzleti felhasználók a vállalat által kezelt, az IT-üzemeltetés által támogatott eszközzel is bármilyen egyéni fejlesztést el tudnak indítani, csökken a szervezet kitettsége a shadow IT kockázatának.
De könnyen az ellenkezője lehet igaz, ha a low-code platformot rosszul vezetik be, használatára nem alakítanak ki megfelelő belső szabályokat, melyeket aztán számon is kérnek az érintettektől.
3. Nő a vállalat agilitása, csökken az üzleti alkalmazásoknál a deployment ideje. Mivel a fejlesztők az üzleti logikát, az alkalmazás-képernyők vázlatát stb. együtt rakják össze az üzleti oldallal, radikálisan rövidül a projektek átfutási ideje, miáltal a szervezet sokkal gyorsabban tud reagálni a piaci változásokra. Mindez ráadásul csökkenti a projektek költségeit is. De ebben sem árt a mértékletesség, nehogy elszabaduljon a költség. Ha hirtelen minden civil fejlesztő "programozó jedinek" képzeli magát, az könnyen szétverheti a projektet (lásd a 3.pontot a shadow IT-ról).
4. Ismét összehozza az IT-t és az üzletet. A legfontosabb érték, hiszen egy közös platformot ad mindkét félnek a kommunikációra. Az üzlet egy vizuális IDE-n (Integrated Development Environment) meghatározza a folyamatot, létrehozza az UI-t (User Interface) a low-coding platform segítségével. Meghatározza az alkalmazáshoz szükséges adatok körét és formai követelményeit stb. Ez alapján az IT elvégzi a végső simításokat, szükség esetén hozzáfejleszt, és integrál. Amikor a citizen developer elakad, ott van mögötte a fejlesztő, aki segít.
Ez az ideális állapot. Ám lássuk be, az üzlet és az IT, különösen annak a fejlesztéssel foglalkozó egysége a legritkább esetben lesznek országos cimborák. Az üzletet sürgeti az idő, minél rövidebb time-to-marketet szeretne, az fejlesztés pedig olyan kódot akar kiadni a kezéből, ami a lehető legkevesebb hibát tartalmazza, az időtényezőre kevésbé fogékony.
El kell fogadtatni az üzlettel, hogy fejlesztőre szükség van, és az most sem az üzlet ellen, hanem az üzlet érdekében munkálkodik – és viszont: az üzlet nem a fejlesztés ellensége. Sok múlik azon, hogy a low-code platform bevezetésekor sikerül-e kialakítani az érintettek érdekközösségét, ami megteremtheti a közös munka alapját, ezáltal az ellentéteket is oldhatja. Ez olyan hosszú távú beruházásnak tekinthető, ami a vállalat megítélését is javítja a jobb employer branding révén.