Kas me peaksime selle ehitama? Küsimus, mida esitame enne koodi kirjutamist

Kui organisatsioon pöördub tarkvaraarendusettevõtte poole, eeldatakse tavaliselt, et vestlus lõpeb ettepanekuga midagi ehitada: uus rakendus, vananeva süsteemi asendus, platvorm lahus olevate protsesside ühendamiseks. See on arusaadav eeldus, kuid see jätab vahele küsimuse, millele tuleks vastata enne, kui keegi räägib tehnoloogiast, eelarvetest või tarneaegadest.

Kas me peaksime selle tõesti ehitama?

Libertas Software Researchis (LSR) usume, et teadmine, kas tarkvara arendada, on sama oluline kui teadmine, kuidas. Mõnikord on tellitud rakendus just see, mida vaja. Mõnikord katab väljakujunenud SaaS-platvorm vajaduse suurepäraselt või annab olemasolevate süsteemide ühendamine tulemuse ilma asendamise kulude ja häireteta. Eesmärk on parandada organisatsiooni toimimist, mitte lisada veel üks rakendus niigi keerulisse keskkonda.

Alustage probleemist, mitte lahendusest

Organisatsioonid kipuvad kirjeldama lahendust, mida nad arvavad vajavat, mitte probleemi, mis neil on. „Aruandluse töölaud“ või „rakendus, mis asendab meie tabelid“ kõlab täpselt, kuid ütleb vähe selle kohta, mis päringu tekitas.

Võtame igakuise juhtkonna aruande, mis koostatakse käsitsi mitmest tabelist ja süsteemist. See võtab päevi ja kui see valmis saab, on andmed juba aegunud. Ilmselge järeldus on, et vaja on aruandlustarkvara. Lähemal vaatlusel on tegelik probleem sageli lahus olevad andmed ja ebaühtlased protsessid: tagasihoidlik integratsiooniprojekt, mitte uus rakendus. Ja kui uuring näitab, et vaja on spetsiifilisi töövooge või kontrolle, mida ükski toode ei toeta, siis just siis teenib tellitud arendus oma koha.

Millal on ostmine mõistlikum

Kommertsturg on küps. CRM-il, raamatupidamisel, ajastamisel, dokumendihalduse ja ärianalüütikal on tooted, mille taga on aastatepikkune lihvimine. Kui üks neist vastab teie vajadustele ilma põhjendamatute piiranguteta, lisab tellitud asendus vähe väärtust.

Kuid võrrelge kogu omamiskulu, mitte tellimushindu. 500 £ kuus maksev toode on viie aasta jooksul 30 000 £, enne kui lisate seadistuse, integratsioonid, lisalitsentsid või muudatused oma protsessides. Kontrollige, kuidas hind skaleerub, kas saate andmed eksportida ja mis juhtub, kui pakkuja muudab oma mudelit. Ja olge ettevaatlik, kui äri sunnitakse loobuma tegevustest, mis seda tõeliselt eristavad, ainult seetõttu, et toode eeldab muud.

Mõnikord on vastus ühendada see, mis teil juba on

Enamik organisatsioone kogub aja jooksul süsteeme: rahandus ühes, tegevus teises, klienditeenindus kolmandas. Iga töötab hästi; nad lihtsalt ei räägi omavahel, mistõttu tekivad viivitused, topelttöö ja vasturääkiv info.

Kõige ühe rakendusega asendamine on ahvatlev, kuid riskantne. Olemasolevad platvormid hoiavad aastatepikkust tegevusteadmist ja varjatud integratsioone. Hoolikalt kavandatud integratsioonikiht (API-de ühendamine, ülekannete automatiseerimine, aruandluse koondamine usaldusväärsetest allikatest) võib nende investeeringute eluiga pikendada. See nõuab põhjalikku mõtlemist autentimise, andmete omandi, veakäsitluse ja auditeeritavuse üle, kuid integratsiooni soovitamine asendamise asemel ei ole halvem inseneritöö. Sageli on see läbimõeldum arhitektuuriotsus.

Millal on tellitud lahendus õige investeering

Mõned nõuded ei sobi tõesti peavoolu toodetega: spetsiifilised tegevused, ebatavalised turvalisuse või andmete vajadused või tarkvara, mis on ise konkurentsieelis. Siin laseb tellitud tarkvara arhitektuuril järgida seda, kuidas äri tegelikult töötab.

See paindlikkus toob kaasa pikaajalise vastutuse hoolduse, turvalisuse, testimise ja toe eest. Süsteem võib täita algset spetsifikatsiooni ja olla siiski halb investeering, kui seda on raske hooldada või see ei kohandu. Tellitud arendus on õigustatud, kui spetsiaalselt valmistatud lahenduse eelised kaaluvad üles nii esialgse kulu kui ka pideva omamiskohustuse.

Mitte iga probleem ei vaja rohkem tarkvara

Mõnikord on probleemiks protsess. Kinnitused, aruanded ja administratiivsed sammud kuhjuvad aastatega, kaua pärast seda, kui neid loonud asjaolud on kadunud. Nende automatiseerimine täpselt sellisena nagu need on, säilitab vaid keerukuse.

Kui dokument vajab viit kinnitust, ärge küsige, kuidas viit kinnitust automatiseerida, vaid miks igaüks neist eksisteerib ja millist riski see katab. Tarkvara on suurepärane järjepidevate reeglite rakendamisel, kuid see ei oska öelda, kas protsess on mõistlik. Töövoo lihtsustamine või vastutuse selgitamine võib tuua tõelist kasu ilma veel ühe süsteemita, mida õppida ja toetada.

Vaadake kaugemale algkuludest

Tellitud projektidel on suur algkulu, samas kui SaaS jaotab oma kulu tellimustele, mistõttu võrdlus tundub ebaühtlane. Aus võrdlus hõlmab kogu eluiga: juurutus, litsentsimine, majutus, tugi, hooldus, integreerimine, koolitus ja tulevased muudatused.

Arvestage ka mittetegevuse kulu. Ebaefektiivne protsess, mis sööb 20 töötundi nädalas, on umbes 1040 tundi aastas. Illustratiivse 35 £ tunnihinna korral on see umbes 36 400 £ aastas, eeldusel et aja saab tõepoolest tagasi võita ja ümber suunata. Lisage halb andmekvaliteet ja aeglased otsused, mida on raskem hinnastada, kuid mis on sama reaalsed. Parim valik ei ole odavaim, vaid see, milles on tugevaim segu väärtusest, vastuvõetavast riskist ja pikaajalisest jätkusuutlikkusest.

Miks soovitaks tarkvaraettevõte tarkvara mitte ehitada?

See on õiglane küsimus. Kui soovitame toodet või väikest integratsiooni, on see paberil vähem arendustööd.

Kuid arenduskoormuse pakkumise ja tarkvarauuringute ning arhitektuuri partneri rolli vahel on vahe. Meie töö algab enne spetsifikatsiooni olemasolu: probleemi mõistmine, valikute kaalumine ja abistamine otsustamisel, kuhu investeerida. Sellel on väärtus tulemusest sõltumata ning tavaliselt on analüüsi-, arhitektuuri-, planeerimis- ja integreerimistööd teha ka siis, kui tellitud arendus ei ole vastus.

Arenduse soovitamine, mida te ei vaja, on kontraproduktiivne. Õigel ajal ja spetsifikatsiooni kohaselt tarnitud projekt kukub siiski läbi, kui see ei olnud õige lahendus. Kliendi aitamine vältida tarbetuid kulutusi loob usaldust, mis kestab.

Võime ehitada ei ole põhjus ehitada

Tehisintellekt ja kaasaegsed tööriistad muudavad koodi kiiremaks ja odavamaks. See on kasulik, kuid teeb eelneva mõtlemise olulisemaks, mitte vähem oluliseks, sest pingutus, mis kunagi sundis küsima „kas me seda tõesti vajame?“, kaob. On täiesti võimalik ehitada midagi tehniliselt suurepärast, tarnida see tõhusalt ja avastada, et see oli vale vastus.

Enne arenduse algust tahame selgeid vastuseid äriprobleemi, selle lahendamata jätmise hinna, nende nõuete kohta, mida olemasolevad tooted ei suuda katta, selle kohta, kuidas edu mõõdetakse (töötlusaeg, täpsus, nähtavus, vastavus, mitte funktsioonide arv) ja kes lahendust hiljem käitab ning toetab.

On projekte, kus tellitud tarkvara on selgelt õige, teisi, kus integratsioon on parema väärtusega, ja kolmandaid, kus valmisplatvorm teeb töö ära. Oluline on, et soovitus tuleneks teie organisatsiooni mõistmisest, mitte eeldusest selle kohta, mida tarkvaraettevõte müüa tahab.

Enne kui küsime, kuidas me peaksime midagi ehitama, tasub kindlaks teha, kas me peaksime seda üldse ehitama.

Libertas Software Research teeb koostööd organisatsioonidega, et uurida, hinnata, kavandada ja arendada tarkvaralahendusi, keskendudes pikaajalisele hooldatavusele, tegevusväärtusele ja teadlikele tehnoloogiainvesteeringutele.