Costul mentenanței software este cifra care transformă un proiect reușit într-o discuție dificilă optsprezece luni mai târziu. Construcția a fost bugetată, aprobată și livrată. Ce se întâmplă după lansare a fost descris drept „suport" și a primit o sumă pe care cineva a ghicit-o, iar suma aceea a fost aproape întotdeauna prea mică.

Motivul ține de structură, nu de neglijență. O construcție are un domeniu pe care îl poți cota. Mentenanța nu are domeniu, pentru că este definită de lucruri care nu s-au întâmplat încă: o bibliotecă în care apare o vulnerabilitate, un furnizor care schimbă o API, un utilizator care nimerește un caz la care nu s-a gândit nimeni.

Regula empirică pe care o citează toată lumea este de 15 până la 20 la sută din costul construcției pe an, iar apropierea ei de adevăr o face periculoasă. Nimerește destul de des cât să pară sigură și greșește într-o direcție previzibilă: subestimează primul an, când ies la iveală defectele, și se prăbușește complet pentru sistemele cu obligații de reglementare sau cu multe integrări externe, unde munca este declanșată de evenimente din afară, nu de propriul cod.


Ce acoperă de fapt costul mentenanței software

Cinci categorii distincte, iar amestecarea lor este exact ceea ce produce cifra greșită.

Munca de corectare. Repararea defectelor. Se concentrează la început, pentru că majoritatea erorilor ies la suprafață în primele luni de utilizare reală, iar aceasta este categoria pe care regula procentuală o descrie cel mai bine.

Munca de adaptare. Ținerea pasului cu ce nu depinde de tine. O dependență publică un patch de securitate. Un procesator de plăți retrage o versiune de API. Un browser își schimbă comportamentul. Nimic din toate acestea nu adaugă o funcționalitate și toate sunt obligatorii.

Munca de prevenție. Actualizarea înainte de a fi obligat. Sărirea peste ea nu elimină costul, îl amână și îl umflă, și așa ajunge o actualizare de rutină a framework-ului un proiect de trei luni.

Operarea curentă. Găzduire, monitorizare, copii de siguranță, certificate și timpul oamenilor care le urmăresc. Adesea contabilizată separat, ceea ce este în regulă atât timp cât cineva o contabilizează.

Modificările mici. Șirul constant de ajustări pe care le generează un sistem în producție de îndată ce are utilizatori reali. Individual banale, laolaltă cea mai mare categorie în majoritatea anilor.

Numai prima este ceea ce oamenii înțeleg de obicei prin mentenanță. Celelalte patru sunt motivul pentru care se termină bugetul.

De ce induce în eroare regula procentuală

Se ancorează de mărimea greșită. Efortul de mentenanță urmează numărul de piese în mișcare și ritmul în care lumea din afară le schimbă, nu cât a costat întâmplător construcția.

Două sisteme construite cu aceiași bani pot să difere de trei ori. O aplicație de sine stătătoare, cu două dependențe și fără expunere la reglementări, este ieftin de ținut în funcțiune. Un sistem care integrează șase servicii externe, prelucrează date cu caracter personal și intră sub reguli de sector nu este, pentru că fiecare dintre acele integrări este o sursă de muncă pe care nu o programezi tu.

Procentul presupune în plus o stare stabilă care nu există în primul an. Utilizarea reală găsește defectele, iar primele șase luni de după lansare stau de obicei mult peste media anuală, până când lucrurile se așază.

O estimare mai bună pornește de la piesele în mișcare. Numără integrările, obligațiile de conformitate și numărul de utilizatori care generează solicitări de suport, apoi cotează timpul pe care acestea îl consumă realist. Ghidul nostru despre costul dezvoltării de software la comandă tratează latura de construcție a aceleiași aritmetici.

Capitolele pe care echipele le uită

Actualizarea dependențelor. Nu este opțională, pentru că bibliotecile nepetecite sunt calea prin care sistemele ajung compromise, iar efortul este cu adevărat imprevizibil, fiindcă depinde de ce fac cei care le întrețin.

Schimbările de API externe. Un furnizor retrage o versiune și îți dă un termen. Nu ai ales tu momentul și nu îl poți refuza.

Reînnoirea certificatelor și a domeniilor. Banală, până când unul expiră într-un weekend și site-ul cade.

Monitorizarea și răspunsul la ea. Alertele nu folosesc la nimic fără cineva care să reacționeze, iar disponibilitatea aceea este un cost real, indiferent dacă se strică ceva sau nu.

Transferul de cunoștințe. Oamenii pleacă. Cât costă ca următoarea persoană să învețe sistemul este un cost de mentenanță, proporțional cu cât de puțin a fost scris pe hârtie.

Creșterea volumului de date. Costul de stocare urcă, interogările care erau rapide încetinesc, iar munca de rezolvare vine după un calendar stabilit de propriul tău succes. Ghidul nostru despre performanța bazelor de date arată cum se vede asta în practică.

Cât costă în Regatul Unit

Intervale anuale aproximative pentru mentenanța unui sistem la comandă, presupunând un furnizor extern și nu personal intern.

Tipul sistemuluiCost anual tipic
Unealtă internă mică, puține integrări£6.000 până la £15.000
Aplicație pentru clienți, mai multe integrări£20.000 până la £60.000
Platformă reglementată sau cu trafic marede la £60.000 în sus

Acestea nu includ găzduirea și licențele, care se facturează separat și variază enorm. Presupun de asemenea că sistemul se află într-o stare rezonabilă. Mentenanța a ceva ce nimeni nu a documentat, fără teste și cu o singură persoană care îl înțelege, costă mai mult și poartă un risc pe care niciun abonament nu îl elimină.

Cum să structurezi înțelegerea

Un abonament cu ore definite funcționează când volumul este în mare previzibil. Cumpără disponibilitate, adică tocmai lucrul pentru care plătești în cea mai mare parte, iar orele neconsumate nu sunt risipă, fiindcă alternativa este să nu ai pe nimeni.

Plata la timp și materiale se potrivește sistemelor care se schimbă puțin, dar timpul de răspuns devine cel pe care îl permit celelalte angajamente ale furnizorului, iar acesta este compromisul.

Un contract de suport la preț fix mută riscul la furnizor, care îl include în tarif. Rezonabil pentru sisteme critice, acolo unde predictibilitatea valorează mai mult decât marja.

Oricare variantă ai alege, stabilește ce înseamnă mentenanță și ce înseamnă funcționalitate nouă înainte de a avea nevoie. Granița aceea este sursa aproape fiecărei dispute din relațiile de suport, iar definirea ei la început nu costă nimic.

Mecanik întreține sisteme pe care nu le-a construit, la fel ca pe cele proprii, ca parte din activitatea noastră de dezvoltare software . Prima lună a oricărei preluări înseamnă de obicei documentare, pentru că tocmai asta determină costul fiecărei luni de după.


Lecturi conexe: Contract la preț fix sau la timp și materiale? , Cum scrii o cerere de ofertă software care aduce cotații utile , Escrow software: cine are cu adevărat nevoie și Dezvoltarea unui MVP: domeniu, cost și termene .


Întrebări frecvente

Cât costă mentenanța software pe an? Regula empirică obișnuită spune 15 până la 20 la sută din costul construcției pe an, dar subestimează primul an, când ies la iveală defectele, și nu mai funcționează deloc pentru sistemele cu multe integrări sau cu obligații de reglementare. Intervalele aproximative din Regatul Unit merg de la £6.000 până la £15.000 pentru o unealtă internă mică și până la £60.000 sau mai mult pentru o platformă reglementată ori cu trafic mare, fără găzduire.

Ce include de fapt mentenanța software? Cinci categorii: munca de corectare a defectelor, munca de adaptare care ține pasul cu dependențele și cu schimbările de API externe, munca de prevenție care actualizează înainte de a fi obligat, operarea curentă cu găzduire și monitorizare, plus șirul constant de modificări mici pe care le generează un sistem în producție. Numai prima este ceea ce înțeleg cei mai mulți prin mentenanță.

De ce nu este de încredere regula procentului din costul construcției? Se ancorează de mărimea greșită. Efortul de mentenanță urmează numărul de piese în mișcare și viteza cu care lumea din afară le schimbă, nu cât a costat construcția. Două sisteme făcute cu aceiași bani pot să difere de trei ori, în funcție de numărul de integrări, de expunerea la reglementări și de volumul de suport.

Ce costuri de mentenanță uită echipele să bugeteze? Actualizările de dependențe, retragerile de API externe cu termene pe care nu le-ai ales, reînnoirea certificatelor și a domeniilor, disponibilitatea umană din spatele alertelor de monitorizare, transferul de cunoștințe când pleacă oamenii și efectul creșterii volumului de date asupra costului de stocare și a vitezei interogărilor.

Să aleg un abonament sau să plătesc la nevoie? Un abonament cu ore definite se potrivește unui volum previzibil și cumpără disponibilitate, adică tocmai lucrul pentru care plătești în cea mai mare parte. Plata la timp și materiale se potrivește sistemelor care se schimbă puțin, dar timpul de răspuns depinde de celelalte angajamente ale furnizorului. Oricare variantă alegi, definește ce este mentenanță și ce este funcționalitate nouă înainte de a avea nevoie.