Fejlessz okosan: LEAN, MVP és valódi megtérülés KKV-knak

Képzelj el két céget ugyanazzal a tervvel. Mindkettő ki akarja váltani a kézi státuszkövetést. Az első leül, specifikációt ír, félévre leköti a keretet, és az első működő verziót fél év múlva látja. A második három hét alatt megcsinálja a legszűkebb változatot, amit az értékesítés már használni tud, és az első héten kiderül, hogy a státuszokból kettő fölösleges, egy pedig hiányzik.

Mindkét cég tévedett. A különbség az, hogy az egyik három hét után tudta meg, a másik hat hónap után. A pénz nem a tévedésbe ment el, hanem abba az időbe, ameddig senki nem tudta, hogy tévedés.

Egy fejlesztési projekt mindig befektetés, és a kérdés nem az, hogy mennyibe kerül, hanem az, hogy megtérül-e. A LEAN szemlélet, az MVP gondolkodás és az agilis módszertan ezt a kérdést tartja nyitva. Attól lesz egy fejlesztés kontrollált és mérhető, hogy közben végig van hol megállni és megnézni, jó felé mentek-e.

Mibe kerül a késői felismerés?

A hat hónap alatt nem csak idő telik el. Változik körülötte minden.

A specifikáció akkor íródott, amikor az értékesítés még két emberből állt. Mire kész a rendszer, négyen vannak, és közben bevezettek egy új árazási logikát, amiről a fejlesztés nem tud. A kollégák fél éven át a régi módon dolgoztak, a szokásaik megszilárdultak, és az új felület ehhez képest lesz idegen. Aki a tervet írta, időközben elment vagy másra figyel, tehát a döntések mögötti indok senkinél nincs meg.

A legdrágább tétel viszont nem ezek közül kerül ki, hanem abból, hogy a hat hónap után nehéz visszakozni. Aki hat hónapot beletett, az nem fogja azt mondani, hogy nem kellett volna. Inkább kijavítja, bővíti, megtoldja. A rossz irány így nem lezárul, hanem karbantartási tétellé válik.

Mi a LEAN szemlélet?

A LEAN alapelve egyetlen mondatba fér. Minimalizáld a felesleges funkciókat, és maximalizáld az üzleti értéket.

A gyakorlatban ez néhány kellemetlen döntést jelent. A „majd egyszer jó lesz” funkciók kimaradnak, még akkor is, ha valakinek fontosak, mert a fejlesztés a most is fájó problémára megy. A munka rövid ciklusokban halad, tehát mindig van egy közeli pont, ahol meg lehet állni és megnézni, jó irányba mentek-e. A cél nem a komplexitás növelése, hanem a felesleges munka kiiktatása, és felesleges az a munka, amiről a végén kiderül, hogy senki nem használja.

Mi az MVP?

Az MVP (Minimum Viable Product) a lehető legegyszerűbb működő verzió.

Nem kompromisszum és nem félkész termék, hanem egy tesztelhető, üzletileg validálható megoldás, amit gyorsan be lehet vezetni, ami gyorsan visszajelzést ad, és amivel keveset lehet veszíteni, mert kevés van benne. Megmutatja, hogy egy fejlesztés valóban értéket teremt-e, mielőtt túl sok pénzt költenénk rá.

A szűkítés nem a minőségről szól. A kevesebb funkció mögött az áll, hogy hamarabb legyen olyan ember, aki élesben használja, és meg tudja mondani, mi hiányzik.

Mikor nem az MVP a helyes válasz?

Ha a fejlesztés egy jogszabályi határidőre megy, akkor nincs mit validálni, mert a követelmény adott, a részletekben nincs mérlegelés, és a félkész változat nem elég. Ugyanez igaz akkor, ha a folyamat egyetlen lépését nem lehet kihagyni anélkül, hogy az egész értelmetlen lenne. Egy raktári bevételezés, ami nem tud tételt rögzíteni, nem szűkített verzió, hanem használhatatlan.

A harmadik eset a legkellemetlenebb. Ha a felhasználók egy külső ügyfélkör, nem a saját csapatod, akkor a félkész verzió nem visszajelzést hoz, hanem elveszett ügyfelet. Belső felhasználóval kísérletezni olcsó, mert ő megmondja, mi nem jó. Az ügyfél nem mondja meg, csak elmegy.

Az MVP tehát nem szabály, hanem eszköz a tanulás felgyorsítására. Ahol nincs mit tanulni, ott nincs mit felgyorsítani.

Miért fontos az agilis módszertan?

Az agilis fejlesztés lényege az, hogy a terv nem szerződés, hanem a jelenlegi legjobb tudásunk. Rövid szakaszokban halad a munka, a végükön újra lehet rangsorolni, és ami visszajelzésként jön, az nem a következő projektbe kerül be, hanem a következő két hétbe.

KKV-nál ez azért kritikus, mert a működés gyorsan változik. Egy új nagy ügyfél, egy kilépő kolléga vagy egy szállítóváltás hetek alatt átrendezi, mi a fontos. Aki fél éve elfogadott tervet valósít meg, nem fegyelmezett, csak régi információ alapján dolgozik.

Hogyan mérjük a megtérülést?

Minden fejlesztés előtt el kell dönteni, mit mérünk rajta. Mennyi időt takarít meg, csökkenti-e az adminisztrációt, kevesebb lesz-e tőle a hiba, javítja-e az átláthatóságot, és növeli-e az árbevételt vagy a konverziót.

A ROI nem csak pénzügyi mutató. Az időmegtakarítás, a szorosabb kontroll és a kevesebb hiba ugyanúgy mérhető üzleti érték.

Egy dolgot a fejlesztés előtt kell megcsinálni, mert utólag már nem lehet. Írjátok le, hol tartotok most. Hány perc egy ajánlat összeállítása, hányszor kell visszakérdezni egy megrendelésnél, hetente hány órát tölt valaki azzal, hogy összeszedi az adatokat egy riporthoz. Ha ez nincs meg, akkor a bevezetés után nem lesz mihez mérni, és a megtérülésről mindenki azt fogja mondani, amit érez.

A tévhit, hogy minden nulláról indul

Sok cég azért fél a fejlesztéstől, mert azt gondolja, hogy mindent egyedileg kell felépíteni, a jogosultságoktól és a szerepköröktől a naplózáson, a fájlkezelésen, az adatbiztonságon és az értesítéseken át az ügyfél-, a projekt- és a feladatkezelésig. Azt is, hogy utólag végig lehessen követni, mi mikor történt.

Ezek viszont nem attól lesznek jók, hogy egyediek. Alapinfrastruktúra-elemek, és minden cégnél nagyjából ugyanazt kell tudniuk.

Ha ezeket minden alkalommal nulláról kell fejleszteni, az jelentősen növeli a költséget és a kockázatot. Ráadásul pont ezek viszik el az elején az időt, és így a valódi kérdés megválaszolása, hogy jó irányba mentek-e, hónapokkal későbbre csúszik.

Hogy mikor éri meg saját rendszert építeni, és mikor jobb kész eszközzel indulni, arról külön cikkben írtunk.

Hogyan működik ez az IntrApp esetében?

Az IntrApp a fenti tételek nagy részét már tartalmazza. Megvan benne a szerepkör- és jogosultságkezelés, a részletes naplózás, a fájl- és dokumentumtárolás, az ügyfél- és adatkezelés, a projekt- és feladatkezelés és a belső kommunikáció. A fejlesztés tehát nem az alapoknál kezdődik, hanem ott, ahol a cég tényleg különbözik a többitől.

Nem CRM és nem ERP, és nem is egy újabb program a sor végére. Ez az alap, amin a cég fut, és a felsorolt tételek nem külön eszközök benne, hanem ugyanannak a működésnek a nézetei. Ettől lesz belőle indulópont, nem pedig egy újabb dolog, amit integrálni kell.

Mit jelent ez egy konkrét kérésnél

Tegyük fel, hogy egy cég egyedi státuszkövetést szeretne, automatikus értesítéssel. A jogosultságok, a naplózás és a fájlkezelés már megvannak, ezekkel nem kell kezdeni. Ami marad, az az egyedi üzleti logika, és abból is elég az első körben az alap státuszlogika.

Onnantól a sorrend ugyanaz, mint bármelyik MVP-nél. A saját csapat használja élesben, mérhetővé válik, mennyi idő szabadul fel és mennyivel kevesebb a hiba, a következő változat pedig már ebből indul. A nyereség nem a fejlesztés árában van, hanem abban, hogy hamarabb kiderül, jó irányba mentetek-e.

Miért fontos a moduláris rendszer?

A moduláris felépítés miatt nem kell egyszerre mindent bevezetni. Elég egy területtel kezdeni, azt élesben használni pár hétig, és utána eldönteni, mi jöjjön. Így a bevezetés maga is kis lépésekből áll, nem egyetlen nagy váltásból, ami után a fél cég egyszerre tanul újra mindent. Az első hetek ezért inkább elvételről szólnak, mint hozzáadásról, és erről külön cikkben írtunk.

Mit fejlessz, és mit ne

A cél nem az, hogy több funkció legyen, hanem az, hogy több üzleti érték keletkezzen.

Az IntrApp nem nulláról induló fejlesztés, hanem egy stabil alap, amire gyorsan, kontrolláltan és mérhetően lehet építkezni. Ami mégis hiányzik, nem zsákutca. Kérhetsz funkciót, és ha az ügyfélkör nagyjából háromnegyede is használná, ingyen elkészítjük. Hogy egy kérés ebbe a körbe esik-e, azt mi ítéljük meg, mert mi látjuk az egész ügyfélkört.

Ne költs feleslegesen. Csak azt fejleszd, ami valóban előreviszi a csapatodat és a cégedet, és úgy, hogy a legrövidebb idő alatt derüljön ki, ha mégsem.