Ce întrebări să pui unei firme de software înainte să semnezi contractul

Ghid pentru clienți: cod sursă, proprietate intelectuală, garanție, suport post-lansare și SLA — ce să clarifici înainte să semnezi contractul cu o firmă de software.

Alegerea unei firme de software nu ar trebui să se bazeze doar pe preț, portofoliu sau promisiunea că „se poate face”. Un proiect software este o investiție serioasă, iar contractul pe care îl semnezi la început poate influența decisiv ce se întâmplă pe parcurs și după lansare.

Mulți clienți discută despre funcționalități, termen de livrare și cost, dar uită să întrebe lucruri esențiale: cine deține codul sursă, ce drepturi are asupra aplicației, ce se întâmplă dacă apar buguri după lansare, cum se oferă suportul, ce include mentenanța, ce garanție există, cum sunt protejate datele și ce se întâmplă dacă firma de software nu mai poate continua proiectul.

Aceste întrebări pot părea incomode la început. În realitate, ele sunt semnul unui client matur și al unei colaborări sănătoase. O firmă serioasă de software nu se va speria de ele. Dimpotrivă, va aprecia că vrei claritate înainte să înceapă proiectul.

Un contract bun nu este făcut pentru situațiile în care totul merge perfect. Este făcut pentru situațiile în care apar schimbări, întârzieri, erori, neînțelegeri sau nevoi noi. Cu cât clarifici mai multe lucruri la început, cu atât scazi riscul de conflicte mai târziu.

1. Cine deține codul sursă?

Aceasta este una dintre cele mai importante întrebări. Codul sursă este baza tehnică a aplicației. Fără acces la el, depinzi complet de firma care a dezvoltat software-ul. Dacă vrei modificări, extinderi, mentenanță sau migrare către alt furnizor, codul sursă devine esențial.

Întrebarea nu trebuie pusă vag. Nu este suficient să întrebi: „Aplicația va fi a mea?” Trebuie să clarifici concret:

• Voi primi codul sursă?
• Când îl primesc?
• În ce formă îl primesc?
• Va fi într-un repository Git?
• Am acces pe parcurs sau doar la final?
• Pot lucra cu altă echipă pe cod după finalizarea proiectului?
• Există componente care rămân proprietatea furnizorului?

O firmă de software poate folosi biblioteci open-source, framework-uri, componente proprii sau servicii externe. Nu toate aceste elemente pot fi „transferate” în același mod. De aceea, contractul trebuie să explice clar ce primești efectiv.

Pentru aplicații custom, este normal ca beneficiarul să ceară acces la codul sursă și dreptul de a continua dezvoltarea, cel puțin după achitarea integrală a proiectului.

2. Cine deține proprietatea intelectuală asupra aplicației?

Codul sursă și proprietatea intelectuală sunt legate, dar nu sunt același lucru. Poți avea acces la cod, dar să ai doar drept de utilizare. Sau poți avea drepturi extinse asupra aplicației, inclusiv dreptul de modificare, distribuire, revânzare sau dezvoltare ulterioară. Aceste detalii trebuie stabilite clar în contract.

Întrebări utile:

• Drepturile patrimoniale asupra software-ului se transferă către client?
• Transferul se face integral sau parțial?
• Transferul are loc la semnarea contractului sau după plata integrală?
• Pot modifica aplicația cu alt furnizor?
• Pot folosi aplicația pentru mai multe firme, puncte de lucru sau clienți?
• Pot revinde aplicația sau doar o pot folosi intern?
• Există module reutilizabile care rămân proprietatea firmei de software?

Pentru o aplicație internă, poate fi suficient un drept de utilizare larg și dreptul de modificare. Pentru un produs SaaS sau o platformă pe care vrei să o vinzi mai departe, drepturile trebuie tratate mult mai atent.

Nu presupune că „dacă plătesc aplicația, automat dețin tot”. În software, aceste lucruri trebuie scrise explicit.

3. Ce se întâmplă cu componentele open-source sau terțe?

Majoritatea aplicațiilor moderne folosesc componente open-source, framework-uri, biblioteci, API-uri externe sau servicii cloud. Acest lucru este normal și eficient. Nu are sens să construiești totul de la zero. Totuși, trebuie să știi ce dependențe există.

Întrebări importante:

• Ce tehnologii și framework-uri vor fi folosite?
• Există licențe open-source cu obligații speciale?
• Există servicii externe cu costuri lunare?
• Există API-uri plătite?
• Ce se întâmplă dacă un serviciu extern își schimbă prețul sau termenii?
• Aplicația poate funcționa fără acele servicii?
• Cine gestionează conturile pentru serviciile externe?

De exemplu, aplicația poate folosi servicii pentru email, SMS, plăți online, hărți, stocare fișiere, autentificare, analiză de date sau inteligență artificială. Costurile și responsabilitățile pentru aceste servicii trebuie clarificate.

O ofertă bună ar trebui să diferențieze costul de dezvoltare de costurile recurente externe.

4. Ce include exact prețul?

Un preț fără structură poate crea neînțelegeri. Două oferte pot părea similare ca valoare, dar să includă lucruri complet diferite.

Întreabă ce este inclus în preț:

• analiză;
• UX/UI design;
• dezvoltare frontend;
• dezvoltare backend;
• bază de date;
• panou administrativ;
• testare;
• deployment;
• configurare server;
• documentație;
• training;
• suport după lansare;
• mentenanță;
• licențe;
• integrări;
• migrare de date.

De asemenea, întreabă ce nu este inclus. Uneori, clientul presupune că designul este inclus, dar oferta acoperă doar dezvoltarea. Sau presupune că hostingul este inclus, dar acesta se facturează separat. Sau crede că modificările nelimitate sunt incluse, deși oferta acoperă doar funcționalitățile definite inițial.

Claritatea financiară este esențială. O firmă serioasă ar trebui să poată explica de unde vine costul și ce primești pentru el.

5. Cum sunt gestionate schimbările de cerințe?

În aproape orice proiect software apar schimbări. Este normal. Pe măsură ce vezi aplicația, testezi fluxuri și implici utilizatori reali, apar idei noi sau ajustări. Problema nu este schimbarea. Problema este lipsa unui proces pentru schimbare.

Întrebări utile:

• Cum se tratează cerințele noi?
• Cum se estimează impactul asupra costului?
• Cum se estimează impactul asupra termenului?
• Cine aprobă schimbările?
• Există un document de change request?
• Schimbările mici sunt incluse sau se facturează separat?
• Cum se prioritizează funcționalitățile noi?

Fără un proces clar, proiectul poate scăpa de sub control. Un proces sănătos de change management protejează și clientul, și furnizorul.

6. Cine este ownerul de proiect din partea clientului?

Această întrebare pare internă, dar este foarte importantă. Un proiect software are nevoie de o persoană responsabilă din partea clientului. Aceasta centralizează feedbackul, ia decizii, validează livrările și comunică prioritățile.

Întreabă firma de software cum preferă să colaboreze:

• Cine trebuie să ofere feedback?
• Cât de des sunt întâlnirile?
• Cum se validează funcționalitățile?
• Ce se întâmplă dacă feedbackul întârzie?
• Cum sunt documentate deciziile?

La rândul tău, trebuie să desemnezi un owner intern. Dacă feedbackul vine de la cinci persoane diferite, cu opinii contradictorii, proiectul se blochează. O colaborare bună are responsabilități clare de ambele părți.

7. Ce metodologie de lucru folosiți?

Nu trebuie să fii expert în Agile sau Waterfall, dar trebuie să înțelegi cum va fi gestionat proiectul.

Întrebări utile:

• Lucrați cu livrări incrementale?
• Vom vedea demo-uri pe parcurs?
• Cât de des primim progres?
• Există sprinturi sau etape definite?
• Putem testa module înainte de final?
• Cum se gestionează feedbackul?
• Există un roadmap?

Scopul este să eviți situația în care vezi aplicația abia la final și descoperi că nu corespunde așteptărilor. Pentru aplicații custom, livrările incrementale sunt foarte utile.

8. Ce garanție oferă după lansare?

Garanția este un subiect care trebuie clarificat înainte de semnare. În software, garanția se referă de obicei la corectarea erorilor pentru funcționalitățile livrate conform specificațiilor. Nu înseamnă dezvoltarea gratuită de funcționalități noi.

Întrebări importante:

• Există perioadă de garanție?
• Cât durează?
• Ce tipuri de probleme sunt acoperite?
• Ce înseamnă bug?
• Ce nu este considerat bug?
• Cum se raportează erorile?
• Care este timpul de răspuns?
• Garanția acoperă și probleme cauzate de servicii externe?

De exemplu, dacă aplicația nu salvează corect o comandă conform specificațiilor, aceasta este o eroare. Dacă după lansare clientul dorește un nou tip de raport, aceasta este o funcționalitate nouă. Diferența trebuie clarificată, altfel apar discuții dificile.

9. Ce suport post-lansare există?

Lansarea nu este finalul proiectului. După lansare apar întrebări, ajustări, buguri, utilizatori noi, modificări de business și nevoi de optimizare.

Întreabă:

• Oferiți suport post-lansare?
• Este inclus în preț?
• Pentru cât timp?
• Ce canale de suport există? Email, telefon, ticketing, chat?
• Care este timpul de răspuns?
• Suportul include doar buguri sau și întrebări de utilizare?
• Există pachete lunare de suport?

Pentru aplicații business, suportul este esențial. O aplicație fără suport poate deveni rapid o problemă, mai ales dacă gestionează procese importante: comenzi, clienți, documente, facturi, programări sau rapoarte.

10. Există SLA?

SLA vine de la Service Level Agreement. Este un acord care definește nivelul de serviciu: timpi de răspuns, timpi de intervenție, disponibilitate, priorități și responsabilități.

Nu orice proiect mic are nevoie de SLA complex. Dar dacă aplicația este critică pentru business, SLA-ul devine important.

Întrebări utile:

• Există SLA?
• Care este timpul de răspuns pentru incidente critice?
• Care este timpul de răspuns pentru probleme normale?
• Există suport în weekend?
• Există suport în afara programului?
• Cum se clasifică incidentele?
• Ce se întâmplă dacă aplicația este indisponibilă?
• Cine monitorizează aplicația?

Pentru un site de prezentare, un SLA strict poate fi inutil. Pentru un portal de comenzi, o platformă de transport, un sistem medical sau o aplicație financiară, SLA-ul poate fi esențial.

11. Cine se ocupă de hosting, servere și infrastructură?

Aplicația trebuie să ruleze undeva. Hostingul și infrastructura trebuie clarificate dinainte.

Întrebări importante:

• Unde va fi găzduită aplicația?
• Pe serverul clientului sau în cloud?
• Cine administrează serverul?
• Cine plătește hostingul?
• Cine configurează backupul?
• Cine monitorizează serverul?
• Ce se întâmplă dacă serverul cade?
• Există acces pentru client?
• Datele sunt stocate în UE?

Pentru aplicații care procesează date personale sau date sensibile, locația și securitatea infrastructurii sunt importante. De asemenea, trebuie clarificat dacă firma de software are acces la producție și în ce condiții.

12. Cum se face backupul?

Backupul este una dintre cele mai importante măsuri de siguranță, dar este adesea ignorat până apare o problemă.

Întrebări esențiale:

• Există backup automat?
• Cât de des se face?
• Unde se stochează backupurile?
• Cât timp se păstrează?
• Se testează restaurarea backupului?
• Cine este responsabil de backup?
• Ce se întâmplă în caz de pierdere de date?

Un backup netestat nu oferă suficientă siguranță. Trebuie să existe un plan clar de restaurare. Pentru aplicații critice, backupul trebuie tratat ca parte a infrastructurii de business, nu ca o opțiune tehnică.

13. Cum sunt protejate datele personale?

Dacă aplicația gestionează utilizatori, clienți, angajați, pacienți, parteneri sau orice alte persoane fizice, apar obligații privind protecția datelor.

Întrebări utile:

• Ce date personale procesează aplicația?
• Cine este operatorul de date?
• Firma de software este persoană împuternicită?
• Există acord de prelucrare a datelor?
• Ce măsuri de securitate sunt implementate?
• Există loguri de acces?
• Datele pot fi exportate sau șterse la cerere?
• Ce se întâmplă cu datele după încetarea contractului?
• Există subcontractori care au acces la date?

GDPR nu este doar o bifă formală. Dacă aplicația gestionează date importante, protecția lor trebuie gândită din etapa de proiectare.

14. Cine are acces la datele din producție?

În timpul dezvoltării și suportului, firma de software poate avea nevoie de acces la server, bază de date sau conturi administrative. Acest lucru trebuie controlat.

Întrebări importante:

• Cine are acces la mediul de producție?
• Accesul este limitat?
• Există loguri?
• Se folosesc conturi individuale sau conturi comune?
• Accesul poate fi revocat?
• Dezvoltatorii folosesc date reale în testare?
• Datele de producție sunt anonimizate în mediile de test?

Aceste întrebări sunt foarte importante pentru securitate. Datele reale nu ar trebui copiate liber în medii de test fără reguli clare.

15. Există documentație?

Documentația nu trebuie să fie exagerată, dar trebuie să existe.

Întrebări utile:

• Primesc documentație tehnică?
• Primesc documentație de utilizare?
• Există instrucțiuni pentru administratori?
• Există documentație pentru API?
• Există descrierea arhitecturii?
• Există ghid pentru instalare sau deployment?

Fără documentație, devii dependent de oamenii care au construit inițial aplicația. Dacă echipa se schimbă, mentenanța devine mai dificilă. Pentru aplicații custom, documentația este parte din valoarea proiectului.

16. Cum se face predarea proiectului?

Predarea nu înseamnă doar „aplicația este live”. O predare completă poate include:

• cod sursă;
• acces la repository;
• acces la server;
• documentație;
• date de administrare;
• instrucțiuni de deployment;
• listă de servicii externe;
• conturi și credențiale;
• backupuri;
• ghid de utilizare;
• training;
• situația funcționalităților livrate.

Întreabă de la început ce primești la final. Altfel, poți descoperi că aplicația funcționează, dar nu ai control real asupra ei.

17. Cum se tratează mentenanța?

Mentenanța este diferită de garanție. Garanția acoperă, de regulă, erorile funcționalităților livrate. Mentenanța acoperă menținerea aplicației funcționale și actualizate în timp.

Întrebări utile:

• Există contract de mentenanță?
• Ce include? Actualizări de securitate, monitorizare, backup, optimizări?
• Actualizări de framework?
• Verificări periodice?
• Suport utilizatori?
• Funcționalități noi?
• Cât costă lunar?

Pentru aplicații business, mentenanța nu trebuie ignorată. Tehnologiile se schimbă, serviciile externe se actualizează, apar vulnerabilități, iar businessul evoluează. O aplicație fără mentenanță se învechește.

18. Ce se întâmplă dacă vrem să schimbăm furnizorul?

Este o întrebare sensibilă, dar foarte importantă. Un client serios trebuie să știe dacă poate continua proiectul cu altă echipă în viitor.

Întrebări utile:

• Pot muta proiectul la alt furnizor?
• Primesc codul sursă?
• Primesc documentația?
• Primesc baza de date?
• Primesc acces la infrastructură?
• Există clauze care limitează colaborarea cu altă echipă?
• Există perioadă de tranziție?

O firmă serioasă nu ar trebui să construiască dependență artificială. Este normal să existe reguli comerciale și contractuale, dar clientul trebuie să aibă claritate asupra opțiunilor sale.

19. Cum se măsoară finalizarea proiectului?

Un proiect software trebuie să aibă criterii de acceptanță. Altfel, finalizarea devine subiectivă. Clientul spune că aplicația nu este gata, furnizorul spune că a livrat conform contractului.

Întrebări utile:

• Cum se stabilește că o funcționalitate este finalizată?
• Există criterii de acceptanță?
• Există proces de testare?
• Cât timp are clientul pentru validare?
• Ce se întâmplă dacă nu oferă feedback la timp?
• Cum se documentează bugurile?
• Cum se acceptă livrările parțiale?

Criteriile de acceptanță protejează ambele părți. Clientul știe ce trebuie să primească, iar furnizorul știe ce trebuie să livreze.

20. Care sunt riscurile proiectului?

O întrebare foarte bună este: „Care sunt principalele riscuri pe care le vedeți în acest proiect?” Răspunsul spune multe despre maturitatea firmei de software.

O firmă serioasă nu promite că totul va fi simplu dacă proiectul este complex. Va identifica riscuri precum:

• cerințe neclare;
• integrări dificile;
• migrare de date;
• dependențe de furnizori externi;
• termene foarte strânse;
• buget limitat;
• lipsa unui owner de proiect;
• date incomplete;
• utilizatori greu de implicat;
• securitate;
• performanță;
• schimbări de scope.

O firmă care discută deschis riscurile nu încearcă să te sperie. Încearcă să construiască un proiect realist.

21. Ce experiență aveți cu proiecte similare?

Portofoliul contează, dar nu trebuie să cauți neapărat o firmă care a făcut exact același proiect. Mai important este să vezi dacă înțelege tipul de complexitate.

Întrebări utile:

• Ați mai lucrat cu aplicații similare?
• Ați mai făcut integrări cu sisteme externe?
• Ați mai construit portaluri, dashboarduri, CRM-uri, aplicații interne?
• Cum abordați proiectele cu roluri și permisiuni?
• Cum gestionați migrarea datelor?
• Cum testați aplicațiile business?

Poți cere exemple anonimizate, studii de caz sau explicații despre proiecte relevante.

22. Ce se întâmplă dacă apar întârzieri?

Întârzierile pot apărea în orice proiect. Important este cum sunt gestionate.

Întrebări utile:

• Cum comunicați întârzierile?
• Cum se actualizează timeline-ul?
• Ce se întâmplă dacă întârzierea este din partea furnizorului?
• Ce se întâmplă dacă întârzierea este cauzată de feedbackul clientului?
• Există milestone-uri?
• Plata este legată de livrări?

Un contract bun trebuie să trateze realist întârzierile, nu să pretindă că nu pot exista.

23. Cum arată comunicarea pe parcurs?

Comunicarea slabă este una dintre principalele cauze ale problemelor în proiectele software.

Întreabă:

• Cine este persoana de contact?
• Cât de des avem întâlniri?
• Primim demo-uri?
• Primim rapoarte de progres?
• Unde raportăm feedbackul?
• Folosim email, ticketing, project management?
• Cum sunt documentate deciziile?

Un proiect bun are ritm de comunicare. Nu trebuie să existe întâlniri inutile, dar trebuie să existe transparență.

24. Ce trebuie să pregătim noi ca beneficiar?

Un proiect software nu este doar responsabilitatea furnizorului. Clientul trebuie să ofere informații, feedback, acces, decizii și validări.

Întreabă firma de software:

• Ce aveți nevoie de la noi?
• Cine trebuie să participe la discovery?
• Ce documente trebuie pregătite?
• Avem nevoie de exemple de rapoarte?
• Trebuie să oferim acces la sisteme existente?
• Cine testează aplicația?
• Cine validează livrările?

Această întrebare ajută mult. Arată că tratezi proiectul ca pe o colaborare, nu ca pe o comandă aruncată peste gard.

25. Ce ar trebui să fie scris neapărat în contract?

Un contract software bun ar trebui să clarifice cel puțin următoarele:

• obiectul proiectului;
• funcționalitățile incluse;
• livrabilele;
• prețul și modalitatea de plată;
• calendarul estimativ;
• responsabilitățile părților;
• procesul de schimbare a cerințelor;
• drepturile asupra codului sursă;
• drepturile de proprietate intelectuală;
• garanția;
• suportul post-lansare;
• mentenanța;
• SLA-ul, dacă este cazul;
• confidențialitatea;
• protecția datelor;
• hostingul;
• backupul;
• predarea proiectului;
• condițiile de încetare;
• limitările de răspundere;
• procedura de acceptanță.

Nu toate contractele trebuie să fie complicate, dar toate trebuie să fie clare.