Întrebări și răspunsuri
Ce garanții primești la un proiect software
Garanția reală stă în trei clauze concrete — restul promisiunilor sunt marketing care nu supraviețuiește primului conflict.
La un proiect software primești în mod normal trei garanții, toate cu acoperire contractuală: garanția pentru buguri (remedierea gratuită a defectelor descoperite într-o perioadă de 3–12 luni de la lansare — standardul pieței românești), garanția predării (cod sursă, documentație și toate accesele ajung la tine, verificabil, la recepție) și, dacă semnezi și mentenanță, un SLA cu timpi de răspuns măsurabili pe niveluri de gravitate. Cuvântul-cheie la prima dintre ele e „defect”: garanția acoperă situațiile în care aplicația nu face ce s-a specificat — formularul care pierde date, calculul care dă rezultat greșit — nu situațiile în care tu îți dorești altceva decât s-a specificat. Distincția bug versus change request e cea mai frecventă sursă de conflict post-lansare, și tocmai de aceea merită definită în contract cu exemple, cât încă vă simpatizați. La fel de importantă e lista inversă: ce nu poate garanta niciun furnizor onest — poziții în Google, un anumit număr de clienți sau „zero buguri pentru totdeauna”. Cine îți promite din această listă nu îți oferă mai multă siguranță, ci îți arată că semnează orice pentru a închide vânzarea.
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247
Pe scurt
Garanția pentru buguri: 3–12 luni
Defectele față de specificație se repară gratuit în perioada convenită, cu termen de intervenție diferențiat: criticele în ore-zile, minorele grupate în actualizări periodice.
Garanția predării
Cod sursă în repository-ul tău, documentație de instalare, accese la servere și servicii — verificate la recepție printr-un test simplu: poate alt programator să ruleze proiectul doar din ce ai primit?
SLA la mentenanță
Timp de răspuns și de rezolvare pe niveluri de gravitate, în scris: de exemplu răspuns în 4 ore lucrătoare la incident critic. Fără SLA, „ne ocupăm cât de repede putem” înseamnă orice.
Diferența bug vs. change request
Bug: aplicația nu respectă specificația semnată. Change request: specificația se schimbă. Primul se repară din garanție; al doilea se estimează și se plătește — clar în contract, cu exemple.
Cum arată clauzele corecte în contract
Clauza de garanție sănătoasă are patru elemente: durata (de la data recepției, nu de la data semnării contractului — la un proiect de 6 luni diferența e enormă), definiția defectului prin raportare la specificația anexată, termenele de remediere pe gravitate și canalul de raportare (un sistem de tichete, nu telefoane pierdute). Un exemplu de formulare utilă: „defect critic — aplicația e inutilizabilă sau produce pierderi de date; intervenție în maximum 8 ore lucrătoare, remediere în maximum 3 zile lucrătoare”.
La predare, clauza corectă enumeră livrabilele explicit: codul sursă complet cu istoricul modificărilor, scripturile de instalare, documentația tehnică, credențialele tuturor serviciilor pe numele firmei tale și cesiunea drepturilor patrimoniale asupra codului scris pentru tine. Adaugă și un test de recepție obiectiv: lista scenariilor care trebuie să funcționeze pentru ca proiectul să fie considerat acceptat, cu o perioadă de acceptanță (uzual 10–15 zile lucrătoare) în care verifici pe îndelete. Fără criterii scrise de recepție, „am terminat” și „nu e gata” sunt doar opinii care se ceartă.
Întrebări frecvente
Firma îmi oferă doar 30 de zile de garanție. E puțin?
Da, sub uzanțele pieței — 3 luni e pragul de jos rezonabil, 6–12 luni e zona bună, mai ales la proiecte complexe unde unele defecte ies la iveală abia în scenarii rare (închidere de lună, vârf de trafic sezonier). 30 de zile acoperă doar defectele evidente și e negociabil aproape întotdeauna: cere extinderea, eventual contra unui procent mic din valoare, și vezi din reacție cât de mult are încrederea furnizorului în propriul cod.
Garanția acoperă și problemele apărute după o actualizare de sistem?
De regulă nu automat: dacă o versiune nouă de browser, de sistem de operare sau de serviciu terț strică o funcționalitate, cauza nu e un defect al codului livrat, ci o schimbare de mediu — iar adaptarea intră la mentenanță, nu la garanție. Exact de aceea garanția și contractul de mentenanță sunt complementare: prima acoperă ce era stricat de la început, al doilea ține aplicația vie într-un mediu care se schimbă.
Ce fac dacă firma refuză să repare un defect evident în garanție?
Documentezi: descrii pașii de reproducere, atașezi capturi și trimiți notificarea pe canalul din contract, invocând clauza de garanție și specificația încălcată. Dacă refuzul persistă, o notificare formală (eventual prin avocat) cu termen de conformare precedă orice altceva; retenția finală de 10–20% din preț, dacă ai negociat-o, e exact pârghia pentru astfel de momente. Cheia e ca „defect” să fie definit în contract — altfel disputa devine subiectivă.
Există garanție și la proiectele făcute cu freelanceri?
Doar dacă o scrii în contract — și aici e diferența practică față de firme: garanția unui freelancer valorează cât disponibilitatea lui viitoare, care nu e instituțională. Dacă lucrezi cu un freelancer, compensează contractual: perioadă de garanție explicită, cod predat în repository-ul tău de la primul sprint și documentație suficientă cât alt programator să poată prelua. Astfel garanția devine recuperabilă chiar dacă persoana devine indisponibilă.
Pagini similare
Resurse conexe
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247