Miért (nem) jó tanulni?
- További kérdése van?
április 11, 2023
Sokféle módszer létezik egy projekt megtervezésére, de számomra csak egy megközelítés van, ami igazán bevált.
Amikor belevágunk egy projektbe azt rendszerint azért tesszük, mert valami szebb, jobb, hatékonyabb, kényelmesebb dolgot szeretnénk elérni. Vágyunk egy olyan állapotra, amely túlmutat a jelenlegin és úgy gondoljuk, hogy az áhított cél érdekében hajlandóak vagyunk komoly áldozatokat is hozni. Még akár kockázatokat is vállalunk.
Rendszerint amíg a „projekt” a vágyak szintjén mozog, azaz válasszuk ki milyen színű legyen a honlap, milyen betűtípust használjunk és hasonló feladatok merülnek fel, minden jól halad. A megrendelő kiírja a tendert vagy meghirdeti a kickoff meetinget és a szebbnél-szebb ajánlatok közül válogat. A hangulat jó, aki eladni akar, kedves, figyelmes, mindent megígér. Ennek megfelelően az ár is kellően magas, de higgyük el, megéri.
A megrendelő pedig rendszerint el is hiszi, hogy érdemes volt belevágni a projektbe, jó érzéssel tölti el a sok-sok ígéret és a bemutatott demó alkalmazások minősége. Az ár beillesztésre kerül a büdzsébe, a szervezet pedig várja, hogy egyszer csak minden jobb lesz.
Ahogy a projekt halad előre, egyre sürgetőbb a kényszer, hogy a megoldás közeledjen a valósághoz. Hogyan kapcsolódunk x rendszerhez, hogyan oldjuk meg a dobozos szoftverben azt, amit mi nem úgy szoktunk csinálni. Természetesen mindent lehet módosítani, csak idő és pénz kérdése. Ugyanakkor a testre szabás nehéz és az olyan típusú mondatok, mint a „nem arra gondoltunk amire ti gondoltatok” egyre gyakoribbá válnak.
Sűrűsödnek a felhők, egyre feszültebbek a meetingek, a pénz és az idő pedig egyre csak fogy.
A megrendelő nem volt tisztában azzal, hogy pontosan mit is szeretne, ahogy a szállító sem látta előre, hogy az ő megoldása, az ő módszere megoldja-e azt a problémát, amiért a projekt létrejött.
Mindkét fél vágyott valamire, de a projekt előrehaladtával már csak reménykedik, később pedig már csak a csalódás marad.
Persze ilyenkor a legkönnyebb a felelőst keresni, elővenni a szerződést, a jegyzőkönyveket, az emaileket, de ha eljutunk idáig, az esélyeink már minimálisak arra, hogy a projekt sikeresen záruljon.
Legyen minden pontosan leírva, megfogalmazva, hangzik a magától értetődő válasz. Ez azonban számos okból sohasem történik meg. Valószínűleg nem is várható el.
Nézzük meg, hogyan segíthet az alkalmazásfejlesztésben, ha „adatvezérelt” módon kezdjük el a projektet.
Az adatvezérelt alkalmazásfejlesztés lényege, hogy nem a vágyakból, lehetőségekből indul ki, hanem az aktuális folyamatokból és adatokból.
Tehát a kitűzött célt nem elképzelt vagy vizuálisan megjelenített demók segítségével határozzuk meg, hanem a jelenlegi működésünk pontos ismerete alapján.
Egy bonyolultabb feladat esetén sokat segít egy terv elkészítése, egy kész rendszer megismerése, megfelelő külső kompetenciák megvásárlása. Ugyanakkor a szervezetünk, szoftvereink, folyamataink működésének pontos ismerete nélkül sohasem tudjuk meg, hogy pontosan mire is van szükség.
A jelenlegi működésünkről pedig semmi sem ad pontosabb képet, mint az adataink.
Ugyanez fordítva is igaz, a jövőbeni működésünket semmi sem fogja jobban meghatározni, mint az új rendszerünkben az adatok struktúrája.
Mindez furcsán hangozhat egy döntéshozó számára és az átlagos dolgozó is csak annyit érzékel a munkája során, hogy megnyom egy gombot, megszervez egy meetinget, elküld egy emailt, felvisz egy tranzakciót a központi rendszerbe vagy beszúr egy sort egy excel táblába.
Minden folyamat, minden történés valahol adatot generál. Az adatok pedig a folyamat valamely szereplőjéhez kötődnek. A gond az, hogy a folyamatok egységesítését – amely szükségszerűen az adatok közös adatbázisba terelését is jelenti – egy kész megoldástól várjuk, ami mindent tud, nagyon szépek a riportjai és lehetőleg beépített mesterséges intelligenciával rendelkezik.
Ha adatvezérelt módon készítjük el a fejlesztés, a projekt tervét, akkor nem fordulhat elő, hogy valamelyik adatnak nem marad hely. Ha minden adatnak van helye, akkor az sem történhet meg, hogy valamely folyamat kimarad a tervezés során. Ha pedig minden folyamatra tekintettel voltunk, akkor nem lesz olyan szereplő, aki nem élvezné a projekt eredményeit.
Tegyük fel, hogy a kintlévőségeinket egy excel táblában tartjuk nyilván. A státuszokat különböző színekkel, az összegeket számokkal és a hozzájuk fűzött megjegyzésekkel jelöljük. Hogyan néz ki egy ilyen nem túl bonyolult üzleti folyamat átültetése egy szoftverbe?
Kézenfekvő megoldásnak tűnik egy kész „kintlévőség kezelő” szoftvernek a megvásárlása. A projektnek van eleje és vége, a költség jól kalkulálható és mivel készen van, szinte azonnal el tudjuk kezdeni használni.
Ugyanakkor lehet, hogy túl sok funkcióval rendelkezik, vagy éppen túl kevéssel. Minden felhasználót regisztrálni kell, külön jelszót kell megjegyeznie a kollégáknak a sokadik rendszerhez miközben a szállítóinkat, a kiállított számlákat is újra fel kell rögzíteni.
Másik alternatíva az egyedi fejlesztés.
Általában a probléma akkor kezdődik, amikor nekifogunk képernyőterveket rajzolni. Hova kerüljenek a gombok, a vezérlőelemek, milyen menürendszert, ikonokat használjunk? Persze az adatokat is tenni kell majd valahová, de a programozó készít majd egy-két táblát.
Például ha adatmodell szintjén egyedivé tesszük a kiállított számlák számát, sohasem lehet a rendszerben ugyanahhoz a számlához több behajtási folyamatot indítani. Még akkor sem, ha a program felülete – a programozó hibájából – ezt megengedi.
Ha az adatmodellben a számlák és a behajtási események külön táblába kerülnek és egy-sok kapcsolat van közöttük, akkor biztosan nem egy megjegyzés mezőbe kerülnek az ügyféllel történt interakciók, hanem historikusan lista szerűen lesz felépítve a rögzítő felület és a teljes folyamat is jól visszakövethetővé válik.
A példákat hosszasan lehetne sorolni, mi mindent határoz meg az adatvezérelt alkalmazás fejlesztés illetve mennyire drasztikus módon csökkenti a szoftver és a valós folyamat közötti eltérés kockázatát. Ugyanakkor egy jól felépített adatmodellből nagyon egyszerű akár összetett riportokat is készíteni.
Megosztás:
Foglaljon időpontot egy 30 perces ingyenes tanácsadásra, ahol mélyebb betekintést nyújtunk abba, hogyan is készítünk el Önnek egy testre szabott integrált rendszert kevesebb mint 10 hét alatt!
© 2023 Enrol Consulting Kft. All rights reserved.
HU 
EN