Sa kushton në të vërtetë një projekt softueri? Si planifikojnë IT-ja dhe departamenti funksional përpjekjet, rreziqet dhe rezervat në mënyrë realiste

Pyetja „Sa kushton realisht një projekt softueri?“ duket në parim e thjeshtë: merrni tarifa ditore, i shumëzoni me disa muaj dhe shtoni kostot e licencave. Në praktikë, devijimet e mëdha rrallë lindin nga vetë implementimi i funksioneve të veçanta. Ato lindin atje ku realiteti i kompanisë takon teknologjinë: procese të paqarta, probleme të fshehura me të dhënat, ndërfaqe me efekte anësore, kërkesa për siguri dhe përputhshmëri, përpjekjet për testim dhe pranimin, Rollout në disa lokacione, si dhe operimi i vazhdueshëm pas Go-live.

Kjo shkrim kategorizon faktorët tipikë të kostos në projektet e softuerit në mënyrë që drejtuesit e IT-së, administratorët, përgjegjësit e projekteve dhe departamenti i fushës së biznesit të mund të planifikojnë së bashku buxhete realistike dhe rezerva. Përqendrimi nuk është tek programimi si qëllim në vetvete, por tek ato elemente që e bëjnë planifikimin të besueshëm në praktikë: supozime të qarta, logjikë të qëndrueshme vlerësimi, katalogë rreziqesh, pika vendimmarrjeje dhe një pamje kostoje për të gjithë ciklin e jetës.

Pse „Implementierung“ është vetëm një pjesë e së vërtetës

Shumë diskutime për buxhetin fillojnë me një shtrirje të ngushtë: „Sa kushton zbatimi?“ Me të vërtetë zakonisht kuptohet koha e zhvillimit. Kjo pamje është e pamjaftueshme, sepse një zgjidhje dixhitale e afërt me proceset e biznesit pothuajse gjithmonë integrohet në një peizazh sistemi ekzistues. Përfshihen modele përdoruesish dhe role, ruajtja e të dhënave, ndërfaqet, monitorimi, backup, rifillimi, proceset e suportit dhe dokumentimi. Secila prej këtyre shtresave prodhon punë që, varësisht nga shkalla e pjekurisë së organizatës suaj të IT-së, mund të jetë e konsiderueshme.

Shenjat tipike që perspektiva e kostove është tepër e ngushtë:

• Kërkesat përshkruajnë funksione, por jo rrjedhat e të dhënave, pranimet apo kërkesat e operimit.
• Nuk ekziston një pamje e qartë se cilat sisteme duhet të lidhen dhe kujt i „përkasin“ këto sisteme (pronari, operimi, ofruesi).
• Testi dhe pranimi konsiderohen si „më vonë“, edhe pse ato janë faktorë përcaktues për afatet dhe buxhetin.
• Puna për migrim, autorizime dhe trajnime nënvlerësohet.

Një pamje më realistike e kostove lind kur e konsideroni projektin si futje ose modernizim të një sistemi produktiv – përfshirë dorëzimin në operim dhe kostot pasuese (Total Cost of Ownership, shkurt TCO: kostoja e përgjithshme për operim, mirëmbajtje dhe zhvillim të mëtejshëm).

Llojet e kostove: CAPEX, OPEX dhe kostot e brendshme „të padukshme“

Në kompani, projektet e softuerit shpesh trajtohen si një investim njëherësh (CAPEX). Operimi dhe zhvillimi i mëtejshëm janë OPEX (kosto të vazhdueshme). Për planifikimin është vendimtare të mendohet të dyja së bashku: një Go-live i lirë mund të bëhet i shtrenjtë nëse mungon mirëmbajtshmëria, observueshmëria dhe aftësia për suport.

Në praktikë duhet të dalloni të paktën katër lloje të kostove:

• Kosto të jashtme të projektit: zbatim, konsulencë, rishikime të arkitekturës, mbështetje për testim, drejtim projekti nga ofruesit e shërbimeve.
• Kosto personale të brendshme: kohë e departamentit të fushës për qartësimin e proceseve, test, pranimin (UAT: Testi i pranimit nga përdoruesi), përdorues kyç, përgjegjësit e të dhënave, operimi i IT-së për mjediset.
• Kosto teknike të operimit: infrastrukturë (On-Prem oder Cloud), operimi i bazës së të dhënave, monitorim, backup, procese për incidente dhe patch, gatishmëri.
• Kosto të implementimit: trajnime, Rollout, komunikim, operim paralel, regjistrim i përkohshëm i dyfishtë, Cutover (koha e planifikuar e ndërrimit).

Shpeshherë kostot e brendshme nuk shprehen saktë në raundet e buxhetit. Kjo çon më vonë në konflikte: IT-ja „dorëzon“, por departamenti funksional nuk ka kapacitet të mjaftueshëm për pranimin dhe pastrimin e të dhënave – projekti vonohet dhe kostot e jashtme rriten.

Çfarë duhet të ofrojnë në thelb vlerësimet e përpjekjeve (dhe çfarë jo)

Një vlerësim i përpjekjeve nuk është një orakull, por një mjet për vendimmarrje nën pasiguri. Ai duhet të sigurojë tre gjëra: një korridor të besueshëm, një listë të supozimeve qendrore dhe një pasqyrë transparente të rreziqeve. Vlerësimet rrallë dështojnë nga matematika, por nga mungesa e përcaktueshmërisë në scope dhe kushtet kornizë.

E rëndësishme është dallimi:

• Scope (Fusha e shërbimit): Cilat procese, role, objekte të të dhënave, ndërfaqe, raporte dhe kërkesa jo-funksionale (p.sh. performanca, disponueshmëria, auditueshmëria) përfshihen?
• Komplexität: Sa shumë përjashtime, variante, autorizime, mandate, gjuhë, lokacione, integrime ka?
• Unbekannte: Ku mungojnë informacionet, akseset, cilësia e të dhënave ose vendimet funksionale?

Një vlerësim i besueshëm shënon qartë se çfarë nuk përfshihet. Kjo nuk është një „nënvlerësim“, por mbron buxhetin dhe afatin. Në praktikë, një katalog i pasaktësisht i përjashtimeve shpesh vlen më shumë se një numër me dy shifra pas presjes dhjetore.

„Sa kushton vërtet një projekt software“: Shtytësit më të zakonshëm të kostove

Shtytësit e mëposhtëm shfaqen përsëri dhe përsëri në projekte – pavarësisht nëse po zhvilloni një softuer biznesi nga e para, po modernizoni një zgjidhje ekzistuese apo po shtoni një portal.

1) Kërkesa me hap interpretimi

„Përdoruesi mund të autorizojë procese“ tingëllon e padëmshme, por mund të nënkuptojë, varësisht nga organizata: parimin e kontrollit me dy persona, rregullimet e përfaqësimit, kufijtë e shumave, protokollimin, eskalimet, njoftimet me e-mail, historikun, raportimin. Pa kriteret e pranimit (kushtet e qarta se kur diçka konsiderohet „e përfunduar dhe e saktë“) një funksion kthehet në një pikë diskutimi të përhershme – dhe buxheti bëhet një objektiv i lëvizshëm.

Për planifikimin është e dobishme: Përcaktoni për çdo proces themelor të paktën (a) Happy Path, (b) devijimet e shpeshta, (c) rastet e gabimit dhe (d) dëshmitë e pranimit (cilat prova pritet të kërkojë auditi ose pronari i procesit?).

2) Ndërfaqet dhe efektet e tyre anësore

Ndërfaqet rrallë janë „vetëm një REST-Endpunkt“. REST (Representational State Transfer) përshkruan një parim të zakonshëm të API për ndërfaqet web. Në mjediset e ndërmarrjeve vijnë shtesat: modelet e të dhënave nuk përputhen, fushat janë formuar historikisht, kohët nuk përputhen, dhe gabimet duhet të jenë të gjurmueshme. Çdo integrim kërkon gjithashtu rregulla për versionimin, monitorimin dhe mbështetjen.

Shtytësit e kostos shpesh janë:

• mosqartësi në sovranitetin e të dhënave (cilit sistem i takon roli kryesor?),
• mungesë e mjediseve të testimit ose e të dhënave të testimit,
• ndryshueshmëri e kufizuar e sistemeve të palëve të treta,
• Përpunim batch vs. kohë reale (p.sh. operacione natën, përpunim i bazuar në radhë).

Nëse vlerësoni integrimet, planifikoni jo vetëm „Implementierung“, por edhe koordinimin me palët e treta, testet kontraktore/ndërfaqeve, skenarët e gabimeve dhe dokumentacionin e operimit.

3) Migrimi i të dhënave dhe cilësia e të dhënave

Migrimi i të dhënave është shpesh një nën-projekt i pavarur. Nuk bëhet vetëm për kopjimin e tabelave, por për mapim (përshtatjen e fushave të vjetra me ato të reja), pastrim, dublikatat, historizim dhe raporte përputhjeje. Bëhet veçanërisht i kushtueshëm kur të dhënat shqyrtohen vonë dhe mungojnë rregullat e biznesit („Wie gehen wir mit ungültigen Lieferadressen um?“, „Welche Altvorgänge müssen migriert werden?“).

Planifikimi realist kërkon këtu:

• një inventar migrimi (cilat objekte, cilat sasi, cilat burime),
• një kontroll të cilësisë së të dhënave (fushat e detyrueshme, intervalet e vlerave, referencat),
• të paktën një provë me përputhje (kontrolle të mostrave, shumave, plausibilitete funksionale),
• një strategji për kalimin (bllokim i të dhënave, operim paralel, plan rikthimi).

4) Testimi, pranimi dhe regresioni

Efforti i testimit shpesh nënvlerësohet, sepse nuk duket si „Fortschritt“. Në sisteme pranë prodhimit, ai është mekanizmi që përkthen rreziqet në punë të planifikueshme. Testet e regresionit (testime përsëritëse pas ndryshimeve) bëhen veçanërisht të rëndësishme kur sistemi shpërndahet përmes disa Releases ose kur përfshihen shumë role.

Për buxhetin dhe afatet vendimtare:

• Kush teston çfarë (IT, departamenti funksional, përdorues kyç)?
• Cilat mjedise testimi ekzistojnë, sa afër janë me prodhimin (Staging)?
• Si do të sigurohen, anonimzohen dhe rivendosen të dhënat e testimit?
• Si funksionon menaxhimi i mangësive (prioritetet, afatet, miratimet)?

UAT nuk duhet planifikuar si „Endphase“, por si një takt i përsëritur: dorëzime të vogla, të pranueshme zvogëlojnë rrezikun e surprizave të mëdha pak para Go-live.

5) Siguria, të drejtat dhe auditueshmëria

Kërkesat për siguri shpesh konkretizohen vonë. Atëherë nuk bëhet vetëm për „Login“, por për modelet e roleve, protokollimin (Audit-Trail: protokolle të ndryshimeve dhe të aksesit të gjurmueshme), trashëgiminë e të drejtave, rizertifikimin dhe, nëse nevojitet, Single Sign-on (SSO, p.sh. via SAML 2.0 si standard për federimin e identitetit).

Kosto shtesë lind për shkak të:

• koordinim me Identity-Management dhe shërbimet e direktorive,
• koncept për rolet teknike dhe funksionale,
• protokollim me ruajtje dhe me mundësi analizimi (jo vetëm „Logfiles“),
• proceset e miratimit (kontrollë me dy persona, ndarja e detyrave).

Nëse keni nevojë për auditueshmëri, kjo është një karakteristikë e arkitekturës dhe e operimit, jo një shenjë që shtohet më vonë.

6) Gati për operim: Monitoring, Runbooks, Support

Një sistem është i “përfunduar” vetëm kur ai është i menaxhueshëm në operim. Kjo përfshin monitoring (mbikëqyrje e disponueshmërisë dhe e gabimeve), alerting (alarmim i synuar), Backups, proceset e patchimit, si dhe Runbooks (manuale operimi për raste standarde dhe ndërprerje). Ky punim shpesh shtyhet në projekte si “më vonë”, por përfundohet menjëherë pas Go-live si punë e ngutshme për ekipin.

Planifikoni punën operative që herët, veçanërisht kur:

• nevojiten mjedise të shumta (Dev/Test/Prod) dhe ato duhet të mbahen konsistente,
• zgjidhja ofron ndërfaqe me procese kritike,
• diskutohen objektiva të disponueshmërisë ose SLAs (Service Level Agreements).

Modelet e buxhetit që funksionojnë në praktikë

Modeli i përshtatshëm i buxhetit varet shumë nga sa të qëndrueshme janë kërkesat dhe kushtet kornizë. Në shumë kompani situata është e përzier: proceset kryesore janë të qarta, detajet lindin gjatë projektit. Atëherë ndihmojnë modele që lejojnë koridore dhe faza mësimi.

Çmimi i fiksuar, Time & Material dhe çmimi i synuar: ku janë kurthet

Çmimi i fiksuar funksionon vetëm me një specifikim të qartë dhe kushte pranimi të qëndrueshme. Përndryshe, ju zhvendosni rrezikun te Change Requests (kërkesat për ndryshim) dhe përfundoni me konflikte rreth „kështu ishte menduar“. Time & Material (faturimi sipas përpjekjes) është fleksibël, por kërkon drejtim të fortë: prioritarizim, transparencë mbi Burn-Rate (përdorimi i buxhetit për periudhë) dhe vendime të qarta Stop/Go. Çmimi i synuar është një model ndërmjetës: një buxhet synimi me koridor dhe ndarje të përcaktuar të rrezikut, i kombinuar me matje transparente të përparimit.

Vendimtare nuk është etiketa, por qeverisja: Kush vendos për ndryshimet e scope-it, si vlerësohen pasojat, dhe cilat rezerva janë parashikuar për këtë?

Planifikimi me faza në vend të „gjithçka njëherësh“

Një planifikim realist shpesh ndan tre nivele:

• Discovery/Scoping: Qartëson proceset, të dhënat, integrimet, rreziqet dhe vizionin e synuar. Rezultati: backlog i besueshëm, kornizë arkitektonike e përafërt, koridor vlerësimi.
• Delivery in Inkrementen: Dorëzoni funksione në pako të pranueshme, teste integrimi të hershme, pranime funksionale të hershme.
• Go-live und Hypercare: kalim i kontrolluar, stabilizim, dorëzim në operim, dokumentim, vendosje e mbështetjes.

Kjo ndarje ul rrezikun që paqartësi të mëdha të mbeten të fshehura deri pak para Go-live. Gjithashtu e bën buxhetin më të negociueshëm, sepse pas fazës së Discovery mund të vendosni me bazë më të qëndrueshme.

Planifikoni rezerva: Bufi nuk është neglizhencë, por menaxhim i rrezikut

„Bufër“ shpesh ka një reputacion të keq në gjuhën e projektit. Më e mirë është të shihet si rezerva për rreziqe të përcaktuara qartë. Rezervat janë efektive kur ato (a) janë të arsyetuara, (b) janë të destinuara për një qëllim të caktuar dhe (c) kanë kushte aktivizimi: Kur të përdoret rezerva, kush vendos, si bëhet rregullimi?

Burime rezervash të provuara janë:

• Rezervë për ndryshimet e përmbajtjes për kërkesa të reja/ndryshuese me një kontroll të qartë të ndryshimeve.
• Rezervë për integrim për probleme me ndërfaqet, koordinime me furnizues të tretë, format të papritura të të dhënave.
• Rezervë për cilësi për ripunime testimi, çështje performance, stabilizim.
• Rezervë për futje për trajnim, rollout, kapacitete shtesë supporti në javët e para.

E rëndësishme: rezervat nuk janë një çek bosh. Ato nuk zëvendësojnë prioritarizimin. Një projekt i mirë mund të lërë rezervat të papërdorura – ose t’i përdorë në mënyrë të synuar për të amortizuar rreziqet pa rrezikuar afatet.

Si nga një ide e përgjithshme del një numër i besueshëm: një rrjedhë pune praktike

Shumë kompani kanë nevojë herët për një vlerë orientuese për buxhetin dhe kapacitetin. Njëkohësisht, në fillim mungojnë detajet. Kjo zgjidhet nëse përllogaritjen e trajtoni si proces.

Hapi 1: Përcaktoni me shkrim kufijtë e projektit dhe jo-objektivat

Shkruani në një faqe: objektivat, jo-objektivat, vendet/ndarjet organizative të prekura, proceset kritike, sistemet dhe ndërfaqet. „Jo-objektivat“ janë veçanërisht efektive kundër zgjerimit të pakontrolluar të përmasës së projektit.

Hapi 2: Hartë e integrimeve dhe e të dhënave

Nuk keni nevojë për një diagram arkitekture të përsosur. Por një përmbledhje se cilat sisteme ofrojnë të dhëna, cilat sisteme i konsumojnë dhe ku janë vendosur identitetet/autoritetet. Vetëm ky përshkrim përmirëson në mënyrë të konsiderueshme vlerësimin dhe dialogun mbi rreziqet, sepse varësitë bëhen të dukshme.

Hapi 3: Dokumentoni supozimet dhe nxirrni një korridor vlerësimi

Për çdo epikë më të madhe (paketë pune më e madhe) përcaktoni supozimet: mjedisi i testimit i disponueshëm po/jo, cilësia e të dhënave e mirë/mesatare/e dobët, ndërfaqja stabile/duke kërkuar ndryshim, rrugët e vendimmarrjes të shpejta/të ngadalta. Nga kjo lind një korridor (optimist/realist/pesimist) në vend të një numri të vetëm.

Hapi 4: Trajtoni kërkesat e cilësisë dhe të operimit si „fushë të detyrueshme“

Monitorimi, regjistrimi (logging), backup, modeli i roleve, dokumentimi dhe dorëzimi nuk janë shtesa opsionale. Nëse i përfshini këto tema në planifikimin bazë, ofertat dhe pritshmëritë e brendshme bëhen më të krahasueshme – dhe vënia në prodhim bëhet më e planifikueshme.

Hapi 5: Një ritëm drejtues me pika vendimmarrjeje

Planifikoni pika të përcaktuara ku vendoset: cilat funksionalitete hyjnë në inkrementin e ardhshëm, cilat rreziqe janë ndryshuar, cilat rezerva mbeten të bllokuara? Kështu shmangni skenarin klasik që buxheti diskutohet vetëm kur është tashmë shpenzuar.

Komunikimi midis IT-së dhe fushës: Ku vendosen vërtet kostot

Shumica e kostove shtesë në fund janë pasojë e vendimeve: më shumë variante, më shumë përjashtime, më shumë raste të veçanta, pranim i shtyrë, integrime shtesë. Këto vendime rrallë i marrin vetëm zhvilluesit; ato lindin në koordinim midis fushës, IT-së dhe, nëse duhet, blerjeve/përputhshmërisë.

Rregullime të dobishme që stabilizojnë kostot:

• Përkufizimi i gatishmërisë: Kur një kërkesë është kaq e qartë sa të mund të zbatohen (të dhënat, rolet, kriteret e pranimit, data e pranimit)?

Kjo është veçanërisht e rëndësishme për vendimmarrësit: shpërthimet e kostove shpesh nuk janë një „ofrues shërbimi tepër i shtrenjtë“, por një tregues i mungesës së proceseve vendim-marrëse dhe të pranimit.

Kur dështojnë vlerësimet e kostove: modelet tipike dhe masat kundër

„Fillojmë shpejt dhe sqarojmë pjesën tjetër rrugës“

Të fillosh shpejt ka kuptim kur ekziston një plan të qartë mësimi. Pa një fazë Discovery, megjithatë, grumbulloni borxhe: të dhëna të paqarta, ndërfaqe të dobëta, kërkesa të paplota për operimin. Masë kundër: timebox për përcaktimin e fushës dhe një skenar të parë funksional end-to-end (nga hyrja deri te përpunimi, përfshirë ndërfaqen dhe regjistrimin e logeve).

„IT-ja e bën si punë anësore“

„Në anash“ në realitet do të thotë: ndërprerje, ndërrime konteksti, kohëzgjatje më të gjata. Për projektet kritike për biznesin, kapaciteti është pengesa kryesore, jo vetëm paratë. Masë kundër: kohë të fiksuara fokusimi dhe WIP-Limits (Work in Progress: kufizim i punëve paralele), që të sigurohet aftësia për dërgesë.

„Ne kursen testimin dhe dokumentacionin“

Kjo kursen afatshkurtër, por rrit rrezikun e ndërprerjeve dhe ngarkesën e suportit. Bëhet veçanërisht e shtrenjtë kur pas Go-live mungon know-how dhe trajtimi i incidenteve zgjat. Masë kundër: përcaktimi i standardeve minimale (p.sh. runbook për çdo proces kryesor, monitoring për ndërfaqet, nivele të qarta logu).

Përfundim: Planifikimi realist i kostove do të thotë të bësh të dukshme pasigurinë

Përgjigjja për „Sa kushton vërtet një projekt softueri?“ rrallë është një numër i vetëm. Planifikimi realist lind kur IT-ja dhe departamenti i biznesit i trajtojnë së bashku sasinë e punës, realitetin e integrimit dhe kërkesat e operimit si elemente me vlerë të barabartë. Vlerësimet e mira japin korridore, supozime të dokumentuara dhe një logjikë të qartë rezervash në vend të saktësisë false.

Nëse jeni para një vendimi buxhetor, ia vlen të investoni herët në scoping, qartësimin e të dhënave dhe integrimeve. Kjo ul ripunimet, stabilizon afatet dhe bën që rezervat të jenë të menaxhueshme. Ai që planifikon që nga fillimi operimin, testimin, migrimin dhe ndryshimet, fiton jo vetëm një buxhet më realist, por edhe një zgjidhje që qëndron e qëndrueshme në përdorim të përditshëm.

Nëse dëshironi të vlerësoni në mënyrë të strukturuar gjendjen tuaj fillestare dhe të krijoni një pamje të qëndrueshme të kostove dhe risqeve për iniciativën tuaj të softuerit, mund ta sqaroni këtë në hapin e ardhshëm së bashku me ne: Kontaktoni.

Për këtë temë janë të rëndësishme gjithashtu kostot e projektit të softuerit dhe buxheti i projektit IT. Artikulli vlerëson këto aspekte në mënyrë të kuptueshme dhe tregon çfarë ka rëndësi në praktikë.

Diskutoni projektin ose iniciativën e modernizimit me Net-Base.