Építsük meg? A kérdés, amelyet a kódírás előtt felteszünk

Amikor egy szervezet szoftverfejlesztő céghez fordul, általában azt várják, hogy a beszélgetés valami megépítésére tett ajánlattal végződik: új alkalmazás, egy elavuló rendszer leváltása, a különálló folyamatokat összekötő platform. Érthető feltételezés, de átugorja azt a kérdést, amelyre válaszolni kellene, mielőtt bárki a technológiáról, költségvetésről vagy szállítási határidőkről beszélne.

Tényleg meg kell építenünk?

A Libertas Software Researchnél (LSR) úgy gondoljuk, hogy annak tudása, hogy érdemes-e szoftvert fejleszteni, ugyanolyan fontos, mint annak tudása, hogyan. Néha az egyedi alkalmazás pontosan megfelelő. Néha egy bevált SaaS-platform tökéletesen kielégíti az igényt, vagy a már meglévő rendszerek összekötése a leváltás költsége és zavara nélkül hozza meg az eredményt. A cél az, hogy egy szervezet működése javuljon, nem az, hogy még egy alkalmazás kerüljön egy már így is bonyolult környezetbe.

A problémából induljon ki, ne a megoldásból

A szervezetek hajlamosak azt a megoldást leírni, amelyről azt hiszik, hogy szükségük van rá, ahelyett, hogy a problémájukat írnák le. A „jelentéskészítő irányítópult” vagy az „alkalmazás, amely kiváltja a táblázatainkat” jól meghatározottnak hangzik, de keveset mond arról, mi váltotta ki a kérést.

Vegyünk egy havi vezetői jelentést, amelyet kézzel állítanak össze több táblázatból és rendszerből. Napokig tart, és mire elkészül, az adatok már elavultak. Kézenfekvő következtetés, hogy jelentéskészítő szoftver kell. Közelebbről nézve a valódi probléma gyakran a különálló adatok és az egységtelen folyamatok: szerény integrációs projekt, nem új alkalmazás. És ha a vizsgálat azt mutatja, hogy olyan speciális munkafolyamatokra vagy kontrollokra van szükség, amelyeket egyetlen termék sem támogat, akkor érdemli ki a helyét az egyedi fejlesztés.

Mikor érdemesebb vásárolni

A kereskedelmi piac érett. A CRM-nek, a könyvelésnek, az ütemezésnek, a dokumentumkezelésnek és az üzleti intelligenciának olyan termékei vannak, amelyek mögött évek finomítása áll. Ha az egyik észszerűtlen korlátozások nélkül kielégíti az igényeit, az egyedi csere kevés értéket ad hozzá.

De a teljes birtoklási költséget hasonlítsa össze, ne az előfizetési árakat. Egy havi 500 £-os termék öt év alatt 30 000 £, mielőtt hozzáadná a konfigurálást, az integrációkat, a további licenceket vagy a saját folyamatai módosítását. Ellenőrizze, hogyan skálázódik az árazás, exportálhatja-e az adatait, és mi történik, ha a szállító megváltoztatja a modelljét. És legyen óvatos, ha az üzletet arra kényszerítik, hogy feladja azokat a tevékenységeket, amelyek valóban megkülönböztetik, csak azért, mert egy termék mást feltételez.

Néha a válasz az, hogy összekötjük, ami már megvan

A legtöbb szervezet idővel rendszereket halmoz fel: a pénzügy az egyiken, a működés a másikon, az ügyfélszolgálat a harmadikon. Mindegyik jól működik; csak nem beszélnek egymással, így késések, duplikált munka és következetlen információk jönnek létre.

Mindent egyetlen alkalmazással kiváltani csábító, de kockázatos. A meglévő platformok évek működési tudását és rejtett integrációit őrzik. Egy gondosan megtervezett integrációs réteg (API-k összekötése, átvitelek automatizálása, jelentések összesítése megbízható forrásokból) meghosszabbíthatja ezeknek a befektetéseknek az élettartamát. Alapos gondolkodást igényel a hitelesítés, az adattulajdon, a hibakezelés és az auditálhatóság terén, de az integráció javasolása a csere helyett nem alacsonyabb rendű mérnöki munka. Gyakran ez az átgondoltabb architekturális döntés.

Mikor megfelelő befektetés az egyedi fejlesztés

Egyes követelmények valóban nem illenek a főáramú termékekbe: speciális működés, szokatlan biztonsági vagy adatigények, vagy olyan szoftver, amely önmagában versenyelőny. Itt az egyedi szoftver lehetővé teszi, hogy az architektúra azt kövesse, ahogyan az üzlet valójában működik.

Ez a rugalmasság hosszú távú felelősséggel jár a karbantartásért, a biztonságért, a tesztelésért és a támogatásért. Egy rendszer megfelelhet az eredeti specifikációnak, és mégis rossz befektetés lehet, ha nehéz karbantartani vagy nem tud alkalmazkodni. Az egyedi fejlesztés akkor indokolt, ha a célra épített megoldás előnyei meghaladják mind a kezdeti költséget, mind a birtoklás folyamatos kötelezettségét.

Nem minden probléma igényel több szoftvert

Néha maga a folyamat a probléma. A jóváhagyások, jelentések és adminisztratív lépések évek alatt halmozódnak fel, jóval azután, hogy az őket létrehozó körülmények megszűntek. Pontosan úgy automatizálni őket, ahogy vannak, csak megőrzi a bonyolultságot.

Ha egy dokumentumhoz öt jóváhagyás kell, ne azt kérdezze, hogyan automatizálja az öt jóváhagyást, hanem azt, hogy miért létezik mindegyik és milyen kockázatot fed le. A szoftver kiváló az egységes szabályok alkalmazásában, de nem tudja megmondani, hogy a folyamat észszerű-e. Egy munkafolyamat egyszerűsítése vagy a felelősségek tisztázása valódi eredményeket hozhat egy újabb, megtanulandó és támogatandó rendszer nélkül.

Nézzen túl a kezdeti költségen

Az egyedi projektek nagy kezdeti költséggel járnak, míg a SaaS az előfizetésekre osztja szét a költségét, így az összehasonlítás egyoldalúnak tűnik. A tisztességes összehasonlítás a teljes élettartamot lefedi: bevezetés, licencelés, tárhely, támogatás, karbantartás, integráció, képzés és jövőbeli változtatások.

A tétlenség költségét is vegye számításba. Egy hetente 20 munkaórát felemésztő hatékonytalan folyamat évi mintegy 1040 óra. Óránként illusztratív 35 £-mal számolva ez évi mintegy 36 400 £, feltéve, hogy az idő valóban visszanyerhető és átirányítható. Tegye hozzá a rossz adatminőséget és a lassú döntéseket, amelyeket nehezebb beárazni, de ugyanolyan valódiak. A legjobb lehetőség nem a legolcsóbb, hanem az, amelyben az érték, az elfogadható kockázat és a hosszú távú fenntarthatóság a legerősebb keveréke van meg.

Miért javasolná egy szoftvercég, hogy ne építsen szoftvert?

Jogos kérdés. Ha terméket vagy kis integrációt javaslunk, az papíron kevesebb fejlesztési munkát jelent.

De különbség van a fejlesztési kapacitás biztosítása és a szoftverkutatási és architektúra-partnerként való fellépés között. Munkánk azelőtt kezdődik, hogy a specifikáció létezne: a probléma megértése, a lehetőségek mérlegelése és segítség abban, hogy hová fektessen be. Ennek értéke van az eredménytől függetlenül, és általában akkor is marad elemzési, architektúra-, tervezési és integrációs munka, amikor az egyedi fejlesztés nem a válasz.

Olyan fejlesztést javasolni, amelyre nincs szüksége, kontraproduktív. A határidőre és a specifikációnak megfelelően leszállított projekt is kudarcot vall, ha nem ez volt a megfelelő megoldás. Ha segítünk egy ügyfélnek elkerülni a felesleges költést, az tartós bizalmat épít.

Az, hogy meg tudjuk építeni, nem ok az építésre

A mesterséges intelligencia és a modern eszközök gyorsabbá és olcsóbbá teszik a kód előállítását. Ez hasznos, de az előzetes gondolkodást fontosabbá teszi, nem kevésbé, mert az erőfeszítés, amely egykor arra kényszerítette az embereket, hogy megkérdezzék „tényleg szükségünk van erre?”, eltűnik. Teljesen lehetséges technikailag kiválót építeni, hatékonyan leszállítani, és rájönni, hogy rossz válasz volt.

A fejlesztés megkezdése előtt világos válaszokat akarunk az üzleti problémára, a megoldatlanul hagyás költségére, arra, hogy a meglévő termékek mely követelményeket nem tudják kielégíteni, arra, hogyan mérik a sikert (feldolgozási idő, pontosság, átláthatóság, megfelelőség, nem a funkciók száma), és arra, hogy ki fogja üzemeltetni és támogatni a megoldást utána.

Lesznek olyan projektek, ahol az egyedi szoftver egyértelműen helyes, mások, ahol az integráció jobb ár-érték arányt kínál, és megint mások, ahol egy készen kapható platform elvégzi a munkát. Az a lényeg, hogy az ajánlás az Ön szervezetének megértéséből következzen, nem abból a feltevésből, hogy mit akar eladni egy szoftvercég.

Mielőtt megkérdeznénk, hogyan építsünk meg valamit, érdemes megállapítani, hogy egyáltalán meg kell-e építenünk.

A Libertas Software Research szervezetekkel dolgozik együtt szoftvermegoldások kutatásán, értékelésén, tervezésén és fejlesztésén, a hosszú távú karbantarthatóságra, a működési értékre és a megalapozott technológiai beruházásokra összpontosítva.