Costul mentenanței software: ce ar trebui să acopere bugetul

Costul mentenanței software depinde de sistemul pe care îl aveți și de responsabilitatea pe care vreți s-o preia cineva. Un buget util separă munca necesară pentru preluarea aplicației, munca recurentă prin care aceasta rămâne fiabilă și modificările pe care vreți să le lansați.

Dacă comparați furnizori, cereți-le tuturor să ofere un preț pentru același set de activități. O sumă lunară care exclude publicarea versiunilor, actualizarea dependențelor și investigarea incidentelor nu poate fi comparată cu una care le include.

Porniți de la aplicație, nu de la un procent

Prețul construirii inițiale nu îi spune unui furnizor nou dacă copiile de siguranță pot fi restaurate, dacă dependențele mai sunt susținute sau dacă integrarea de plăți eșuează pe tăcute. Înainte să tratați o estimare ca pe un angajament, aflați ce rulează în producție și ce părți au nevoie de atenție.

Notați:

Ce face aplicația și care sunt fluxurile cele mai importante.
Dacă este o aplicație web, un produs SaaS, un API sau un sistem intern.
Mediul de execuție, framework-ul, baza de date și găzduirea, dacă le cunoașteți.
Cine are acces la depozitul de cod, la publicarea versiunilor și la conturile furnizorilor.
Defecțiunile recente, actualizările amânate și următoarele modificări planificate.
Orele în care firma are nevoie de suport și cine se ocupă de incidentele urgente.

Dacă dezvoltatorul inițial a plecat, folosiți lista de verificare pentru preluarea codului ca să identificați accesele și cunoștințele care lipsesc. Puteți aduna aceste informații fără să alegeți mai întâi un furnizor nou.

Separați patru părți ale bugetului

1. Preluarea inițială și stabilizarea

O echipă nouă trebuie să înțeleagă producția, să verifice accesele, să pună la punct un proces de publicare repetabil și să verifice că sistemul poate fi refăcut după o defecțiune. Documentația lipsă sau un framework fără suport pot adăuga muncă înainte ca mentenanța obișnuită să înceapă.

Întrebați ce livrează etapa inițială și ce ar determina o estimare revizuită. Păstrați-o separat de angajamentul lunar continuu, ca ambele părți să vadă cât costă moștenirea sistemului.

2. Întreținerea recurentă

Enumerați lucrările planificate: actualizări de dependențe și de securitate, verificări înaintea lansărilor, teste de restaurare a copiilor de siguranță, monitorizare și documentație operațională. Stabiliți cât de des se face fiecare și ce dovezi primiți.

Facturile de găzduire, de bază de date, de e-mail și ale altor furnizori fac parte tot din bugetul de operare. Precizați dacă le plătiți direct sau prin furnizorul de mentenanță. Timpul de inginerie și facturile de infrastructură sunt costuri diferite.

3. Suportul și incidentele

Precizați intervalul de acoperire, fusul orar, canalul de contact și ce se consideră urgent. Timpul de răspuns înseamnă că cineva începe să evalueze problema; nu înseamnă că problema este rezolvată în acel interval.

Pentru o firmă din SUA sau Canada care lucrează cu o echipă la distanță, discutați explicit suprapunerea programului. Nu presupuneți că un contract lunar de mentenanță include răspuns în timpul nopții sau în weekend.

4. Îmbunătățirile planificate

Separați corectarea erorilor de modificările privind modul în care funcționează produsul. O integrare nouă sau o schimbare mare a unui flux are nevoie de funcționalități definite, chiar dacă aceeași echipă face și mentenanța, și dezvoltarea.

Convenți cum se stabilesc prioritățile, cum se aprobă estimările și ce se întâmplă când într-o lună apare mai multă muncă decât capacitatea disponibilă. Discuția aceasta contează mai mult decât denumirea pachetului.

O fișă de buget pe care o puteți trimite furnizorilor

Completați aceste rânduri înainte de a compara ofertele:

Munca inițială: accese lipsă, configurarea publicării, verificări de refacere și reparații urgente.
Lucrări tehnice recurente: activități, frecvență și capacitatea inclusă.
Facturi ale furnizorilor: găzduire, bază de date, e-mail, monitorizare și alte servicii.
Suport: intervalul de acoperire, așteptări privind răspunsul și ce intră în incidente.
Modificări de produs: priorități și o cale de aprobare separată.
Incertitudine: zonele pe care furnizorul trebuie să le inspecteze înainte să se angajeze.

Pentru fiecare ofertă, cereți furnizorului să marcheze ce este inclus, ce este exclus și ce nu se știe încă. Întrebați cum sunt tratate capacitatea neutilizată și munca peste cea agreată. Nu presupuneți că oricare dintre ele se reportează sau se facturează automat.

Când o ofertă mică lasă munca neacoperită

Un furnizor poate oferi legitim un serviciu restrâns. Riscul este un gol de care nu răspunde nimeni: suport pentru aplicație fără actualizarea dependențelor, monitorizare fără o persoană care primește alertele sau copii de siguranță fără verificarea restaurării.

Întrebați cine răspunde de fiecare gol. Puteți păstra o activitate în interiorul firmei, puteți angaja un specialist sau puteți include activitatea în mentenanța agreată. Rezultatul util este o responsabilitate asumată explicit.

Reparare, modernizare sau mentenanță continuă?

Dacă aplicația este susținută și se publică ușor, întreținerea recurentă poate fi suficientă. Dacă este nevoie mai întâi de o actualizare a framework-ului, de repararea publicării sau de o migrare de date, definiți separat acea muncă.

Ghidul nostru despre reparare sau rescriere vă ajută să deosebiți intervențiile țintite de înlocuirea completă. Bugetul de mentenanță trebuie să reflecte decizia aceasta, nu să ascundă un proiect de modernizare în întreținerea de rutină.

Discutați mentenanța aplicației dumneavoastră

AL+ oferă servicii de mentenanță software pentru aplicații web și produse SaaS existente, inclusiv pentru sisteme construite de alt dezvoltator sau de o altă agenție.

Scrieți-i lui Paul despre mentenanța software. Descrieți aplicația, tehnologiile folosite dacă le cunoașteți, țara dumneavoastră, problema actuală și orele de suport de care aveți nevoie. Trimiteți mai întâi o descriere; nu includeți în e-mail parole, chei API sau date ale clienților.