Ce determină costul unui software la comandă și cum îl ții sub control

Două companii cer „un portal simplu pentru clienții noștri” și primesc oferte foarte diferite. De obicei, ambii furnizori sunt corecți. Ei estimează lucruri diferite, pentru că cererea lasă deschise majoritatea deciziilor reale: cine folosește portalul, cu ce sisteme comunică, ce se întâmplă când ceva nu merge.

În software-ul la comandă, costul depinde mai puțin de numărul de ecrane și mai mult de numărul de reguli, roluri și conexiuni din spatele lor. Un studiu realizat de McKinsey și Universitatea Oxford pe peste 5.400 de proiecte IT a arătat că proiectele mari au depășit bugetul în medie cu 45% și au adus cu 56% mai puțină valoare decât se estimase. O mare parte din această diferență vine din lucruri pe care nimeni nu le-a clarificat de la început.

Mai jos găsești factorii de cost pe care îi întâlnim cel mai des și obiceiurile de lucru care îi țin sub control.

Principalii factori de cost

Aria de acoperire și numărul de roluri

Fiecare tip de utilizator adaugă mai mult decât un cont de autentificare. Un sistem folosit de un singur grup (de exemplu, personalul de birou) este mult mai simplu decât unul folosit de angajați, manageri, clienți, furnizori și auditori, fiecare dintre ei văzând alte date și având dreptul la alte acțiuni. Fiecare rol multiplică regulile de acces, ecranele, notificările și cazurile de test. Când îți enumeri utilizatorii, notează și ce nu are voie să vadă fiecare dintre ei.

Integrări

Conectarea la un sistem de contabilitate, un ERP, o bancă, o firmă de curierat, o autoritate fiscală sau un procesator de plăți este adesea cel mai mare element individual dintr-un proiect. Efortul depinde de cealaltă parte: există un API documentat, un mediu de test, un format de date stabil, cineva care răspunde la întrebări? O conexiune la un serviciu bine documentat poate dura câteva zile. O conexiune la un sistem vechi care exportă fișiere doar o dată pe noapte poate dura săptămâni și va cere atenție de fiecare dată când acel sistem se schimbă.

Migrarea datelor

Mutarea datelor din foi de calcul sau dintr-un sistem vechi pare un simplu copy-paste. În practică înseamnă eliminarea duplicatelor, completarea câmpurilor lipsă, corelarea codurilor vechi cu cele noi și decizii despre înregistrările care nu se încadrează nicăieri. Tot la migrare trebuie să aloce cel mai mult timp oamenii din business, pentru că doar ei știu dacă „ABC SRL” și „A.B.C. S.R.L.” sunt același client.

Cerințe de calitate și securitate

Un instrument folosit de cinci colegi și un sistem care gestionează plăți sau date personale sunt produse diferite, chiar dacă ecranele arată la fel. Cerințele privind disponibilitatea, timpul de răspuns, jurnalele de audit, copiile de rezervă, controlul accesului și protecția datelor adaugă muncă de proiectare, testare și documentare. Standardele publicate ajută la concretizarea acestor cerințe. ISO/IEC 25010 descrie caracteristicile de calitate ale unui produs, precum fiabilitatea, securitatea și mentenabilitatea, iar OWASP Application Security Verification Standard oferă o listă de cerințe de securitate pe mai multe niveluri de rigoare. Dacă alegi nivelul potrivit riscului tău real, eviți să plătești prea puțin sau prea mult.

Platforme

O aplicație web care funcționează bine în browserele de pe desktop și de pe mobil este un singur produs. Aplicațiile native pentru iOS și Android, un mod offline pentru personalul din depozit sau suportul pentru browsere vechi din rețeaua unui client adaugă, fiecare, muncă de dezvoltare, testare și publicare. Înainte să te angajezi să publici în magazinele de aplicații, verifică dacă o aplicație web responsivă acoperă nevoia reală.

Modelul de echipă

Echipă internă, freelancer, echipă externalizată sau o combinație: fiecare variantă are un alt profil de cost. Un cost zilnic mai mic nu înseamnă întotdeauna un cost total mai mic, dacă coordonarea, refacerea lucrului și predările durează mai mult. Contează cine ia deciziile, cât de repede primești răspuns la întrebări și cum rămân cunoștințele în compania ta dacă oamenii se schimbă.

Cum ții costul sub control

Începe cu un produs minim viabil

Definește cea mai mică versiune care aduce valoare reală unor utilizatori reali și construiește mai întâi această versiune. Pentru un portal de clienți, asta ar putea însemna autentificare, statusul comenzilor și descărcarea documentelor, fără chat, analize sau aplicație mobilă. Un MVP nu este o demonstrație: oamenii trebuie să îl poată folosi în munca de zi cu zi. Rolul lui este să confirme ce contează înainte să cheltui bani pe ce ar putea conta.

Livrează în etape

Împarte munca în etape scurte, fiecare încheiată cu software funcțional pe care îl poți încerca. Principiul din Manifestul Agile rămâne valabil: livrează frecvent software funcțional, la un interval de la câteva săptămâni la câteva luni. Fiecare etapă este un moment natural pentru a revizui cheltuielile, a schimba prioritățile sau a te opri. Un proiect lung, cu o singură livrare la final, nu îți oferă niciuna dintre aceste opțiuni.

Scrie criterii de acceptanță clare

Pentru fiecare funcționalitate, convine în scris cum vei ști că este gata. „Facturile pot fi exportate” este o formulare vagă. „Un contabil poate exporta toate facturile dintr-o lună selectată într-un fișier pe care sistemul de contabilitate îl importă fără modificări manuale” poate fi testat. Criteriile clare reduc disputele, refacerile și costul care se acumulează încet din funcționalitățile care rămân „aproape gata” luni la rând.

Gestionează schimbările în mod deliberat

Cerințele se vor schimba și chiar trebuie să se schimbe atunci când afli ceva nou. Problema este schimbarea necontrolată. Păstrează o regulă simplă: fiecare cerere nouă primește o scurtă descriere scrisă, o estimare și o decizie despre ce se amână pentru a-i face loc. Așa bugetul rămâne vizibil, iar prima versiune nu se umflă pe nesimțite.

Uită-te la costul total de deținere

Prima lansare este doar o parte din cost. Pe durata de viață a unui sistem mai plătești și pentru:

găzduire, domenii, certificate și copii de rezervă
licențe terțe și taxe pentru API-uri
actualizări de securitate și upgrade-uri ale bibliotecilor de care depinde software-ul
monitorizare și suport atunci când ceva se strică
modificări mici, pe măsură ce procesele tale și legislația se schimbă
timpul pe care propriii angajați îl petrec administrând sistemul

Scurtăturile luate pentru a prinde un termen timpuriu au și ele un preț. Martin Fowler numește asta datorie tehnică: codul intern dezordonat face fiecare modificare viitoare mai lentă, ca dobânda la un împrumut. O anumită datorie este o alegere rezonabilă pentru un MVP, atât timp cât este o decizie conștientă și o plătești în etapele următoare.

O listă de verificare înainte să ceri o ofertă

Enumeră rolurile utilizatorilor și ce poate vedea și face fiecare.
Enumeră fiecare sistem la care trebuie să se conecteze software-ul, cu o persoană de contact pentru fiecare.
Descrie datele pe care le ai astăzi și unde se află.
Notează cerințele legale și de securitate: date personale, facturare electronică, audit, perioade de păstrare.
Decide de ce platforme ai nevoie acum și care pot aștepta.
Definește ce trebuie să includă prima versiune utilizabilă și ce nu trebuie să includă.

Un furnizor care primește această listă poate face estimarea pe baza faptelor, nu a presupunerilor, iar tu poți compara ofertele pe aceeași bază.

Cum te poate ajuta NOWANI TECH

Ajutăm companiile să transforme o idee vagă într-o arie de acoperire clară, o primă versiune utilizabilă și un plan etapizat cu criterii de acceptanță, înainte să înceapă cheltuielile mari. Construim în etape scurte și planificăm găzduirea, mentenanța și suportul din prima zi, astfel încât costul complet să fie vizibil din timp. Dacă pregătești un proiect și vrei o a doua opinie despre aria de acoperire sau despre buget, contactează-ne.