Egy új projekt ajánlatkérésekor a legtöbb megrendelő azt hiszi, hogy a saját ötlete egyedi. Valójában a rendszer alja szinte mindig ugyanaz, a bejelentkezéstől a jogosultságkezelésen és a naplózáson át a deploy folyamatig és a tesztkörnyezetig. Ez a projekt gerince, nem a lényege. Az ügyfél nem ezért fizet, mégis minden projektben újra meg kell építeni, ha nincs rá kész alap.
Mi az, ami minden projektben ugyanaz
Ha végigmegyünk az elmúlt évek egyedi rendszerein, a lista kiábrándítóan ismétlődő:
- felhasználók, meghívás, jelszó-visszaállítás, munkamenet-kezelés,
- szerepkörök és jogosultságok, gyakran nem képernyő-, hanem mezőszinten,
- cégadatok, szervezeti felépítés, több telephely, több cég egy rendszerben,
- naplózás arról, hogy ki mit módosított, mikor, és mi volt az előző érték,
- értesítések e-mailben és az alkalmazáson belül,
- keresés, szűrés, export, alap kimutatások,
- és az egész köré egy deploy folyamat meg egy tesztkörnyezet.
Ebből a megrendelő pontosan semmit nem lát a demón. Mégis ez az a rész, ami a legtöbb projektben a fejlesztési idő nagyobbik felét viszi el, mielőtt bármi elkezdene arról szólni, amiért a rendszert megrendelték.
Az alap egyszer épül meg
Nálunk ez az alap egyszer épült meg, és azóta minden új projekt erre a keretre települ. A gyakorlatban ez azt jelenti, hogy a projekt nem üres repóból indul, mert az első naptól ott van a jogosultsági modell, a felhasználókezelés, a naplózás és az értesítés, megírva és letesztelve. Az első dolog, amit a megrendelő lát, a saját folyamata, nem egy bejelentkező képernyő.
Az is megváltozik, hogy a keret mire megy el. Nem kell kétszer fizetni, egyszer az alapokért, egyszer az üzleti logikáért. Mivel pedig ugyanaz az alap több projektet szolgál ki, egy javítás vagy egy biztonsági frissítés minden rendszerbe megérkezik, ahelyett hogy mindenhol külön, emlékezetből íródna meg újra.
Miért nem termék a keretrendszer
A keretrendszer szándékosan nem termék, és nem is válik azzá. Ha egy belső eszközből terméket csinálunk, elkezd mindenkinek megfelelni akarni. Konfigurációs kapcsolók nőnek rá, a dokumentációját karban kell tartani, a kompatibilitást a saját korábbi verzióival is meg kell őrizni. Pont az a rugalmasság vész el belőle, ami miatt megérte megépíteni.
A mi keretünk azt tudja, amit a saját projektjeink tényleg igényelnek (nem többet és nem kevesebbet), és minden projekt után azzal frissül, amit a következő ügyfélnél újra hasznosítani tudunk. Ez a különbség egy dobozos termék és egy műhely szerszáma között.
Amikor nem éri meg
Van, amikor ez nem éri meg. Egy olyan projektnél, ahol a rendszer szinte teljes egésze az ügyfél saját, senki más által nem használt logikájából áll (egy különleges gyártási folyamat vezérlése, egy egyedi mérési eljárás, egy hardverhez kötött adatgyűjtés), ott a közös alap alig ad hozzá bármit, és a keretrendszerhez való igazodás inkább lassítana, mint gyorsítana.
Ugyanez a helyzet, ha a rendszernek nincs bejelentkezése, nincs jogosultsága és nincs adminja, hiszen egy publikus számológép vagy egy egyoldalas eszköz alá nem kell vállalati alapréteg. Ott a tiszta, keretrendszer nélküli fejlesztés a jobb választás, és ezt jobb az ajánlat előtt kimondani, mint a projekt közepén.
A kérdés minden ajánlat előtt
Mennyi a projektben az, amit már megoldottunk, és mennyi az, ami tényleg új? Ha az első nagy, a keretrendszer sokat hoz. Ha a második, akkor az a becsületes válasz, hogy ez a projekt nulláról épül. Így is adunk rá árat.
