Cum alegeți un furnizor de dezvoltare software

O greșeală în alegerea furnizorului costă mai mult decât orice rând din deviz. Un termen ratat înseamnă un sezon pierdut, iar un cod care nu poate fi predat altei echipe înseamnă rescriere de la zero. În același timp, portofoliul și prețul, la care se uită de obicei primele, spun cel mai puțin despre viitorul proiect.

Vom vedea cum să alegeți sistematic un furnizor de dezvoltare: ce să pregătiți înainte de căutare, când se potrivește un freelancer și când aveți nevoie de un studio, ce 12 puncte să verificați, ce să fixați în contract și ce semnale ar trebui să vă pună în gardă încă de la prima întâlnire.

De unde începeți: sarcina înaintea furnizorului

Nu are rost să comparați executanți fără o descriere a sarcinii: fiecare va evalua propria versiune a produsului, iar prețurile vor diferi de câteva ori. Înainte de a trimite cereri, pregătiți măcar un caiet de sarcini scurt, de 2–4 pagini:

• scopul produsului și metrica de succes;
• rolurile utilizatorilor și scenariile-cheie;
• funcțiile obligatorii ale primei versiuni;
• integrările (CRM, 1C, plăți, depozit);
• cerințele privind datele și găzduirea;
• intervalul de buget și termenul până la care aveți nevoie de produs.

Același caiet de sarcini, trimis la 4–6 candidați, transformă alegerea din ghicit în comparație. Structura pas cu pas și un exemplu găsiți în articolul cum se întocmește un caiet de sarcini pentru dezvoltare.

Freelancer sau studio de dezvoltare

Întrebarea „freelancer sau studio de dezvoltare” nu ține de calitate — printre specialiștii independenți sunt mulți ingineri puternici. Ține de riscuri și de amploarea sarcinii.

O variantă practică pentru multe companii: studioul realizează MVP-ul și construiește arhitectura, apoi produsul este predat echipei interne împreună cu codul și documentația. Funcționează doar dacă predarea a fost prevăzută de la bun început — despre asta mai jos.

Checklist: 12 puncte pentru alegerea executantului

Această listă este la fel de utilă fie că decideți cum să alegeți un studio de dezvoltare pentru o platformă, fie un dezvoltator independent pentru un bot. Notați fiecare punct pe scala „da / parțial / nu”.

1. Studii de caz relevante. Nu „imagini frumoase”, ci proiecte de complexitate similară: roluri, integrări, încărcare. Cereți să vi se arate un produs funcțional, nu doar capturi de ecran.
2. Oamenii care vor face proiectul. Cine anume se ocupă de arhitectură, cine scrie codul, veți avea contact direct cu dezvoltatorii sau doar cu managerul.
3. Procesul. Cât de des au loc demo-urile, există un mediu de testare, unde se vede tabla de sarcini. Un răspuns normal — demo în fiecare săptămână și mediu de testare din primele săptămâni.
4. Întrebările adresate dvs. Un furnizor puternic pune multe întrebări incomode despre afacere și metrici. Dacă estimarea a venit într-o oră fără nicio întrebare, este estimarea altui lucru.
5. Structura estimării. Devizul este împărțit pe etape și funcții, se văd ipotezele și riscurile, nu o singură cifră „la cheie”.
6. Drepturile asupra codului. În contract se precizează explicit că drepturile exclusive asupra rezultatului trec la dvs., iar repozitoriul se află în contul dvs.
7. Găzduirea. Produsul se instalează pe serverele dvs. sau în cloudul dvs., domeniile și accesele sunt înregistrate pe numele dvs.
8. Securitatea. Cum sunt păstrate secretele și accesele, cine are acces la producție, cum sunt prelucrate datele personale conform 152-FZ (legea rusă privind datele personale).
9. Calitatea codului. Există code review, teste automate, CI/CD, monitorizarea erorilor. Cereți să vi se arate un fragment de cod sau organizați un apel tehnic cu expertul dvs.
10. Documentația și predarea. Ce primiți la final: descrierea arhitecturii, instrucțiuni de instalare, accese, instruirea echipei.
11. Suportul după lansare. Există SLA: timpul de reacție la o eroare critică, orele de lucru, costul unei ore de îmbunătățiri.
12. Recomandările. Posibilitatea de a vorbi cu unul-doi clienți anteriori este cea mai bună metodă de a verifica tot ce s-a enumerat mai sus.

Dacă un candidat primește „nu” la punctele 6, 7 și 10, restul aproape că nu mai contează: chiar și un produs bun va deveni ostaticul relației cu o singură echipă.

Drepturile asupra codului și unde e găzduit produsul

Este cea mai subestimată secțiune. O poveste tipică: produsul funcționează, dar e găzduit pe serverul furnizorului, domeniul e înregistrat pe numele unui angajat al acestuia, iar repozitoriul nu îl aveți. În această situație, schimbarea echipei se transformă în negocieri.

Ce trebuie fixat

• Cesiunea dreptului exclusiv asupra codului sursă și a designului în favoarea dvs. — prin procese-verbale, pe etape sau la finalul proiectului.
• Lista componentelor terțe utilizate și a licențelor lor: bibliotecile open source cu licențe „contagioase” pot limita utilizarea comercială.
• Repozitoriul (GitHub, GitLab sau propriul dvs.) este creat în contul companiei dvs., iar furnizorul lucrează în el ca participant invitat.
• Cloudul, serverele, domeniile, conturile de dezvoltator în App Store și Google Play, cabinetele de plăți — înregistrate pe persoana juridică a dvs.
• Predarea include documentația, variabilele de mediu, schema infrastructurii și instrucțiunile de instalare.

Contract, plată și SLA

Modelul de plată influențează comportamentul ambelor părți. Două scheme principale:

În ambele cazuri, legați plata de rezultate verificabile: etapa este recepționată, scenariile trec pe mediul de testare, codul se află în repozitoriul dvs. O plată în avans de sută la sută pentru întregul proiect este o idee proastă în orice model.

Recepția și garanția

Stabiliți cum se recepționează fiecare etapă: după checklistul de scenarii din caietul de sarcini, pe mediul de testare, cu un termen fix pentru observații (de exemplu, 5 zile lucrătoare). Conveniți separat perioada de garanție după lansare — de obicei de la una la trei luni —, în care furnizorul corectează gratuit erorile din funcționalitatea realizată. Este important să distingeți o eroare („butonul de plată nu funcționează în Safari”) de o cerință nouă („hai să adăugăm plata în rate”): a doua se plătește ca modificare de volum.

Suport conform SLA

SLA-ul de suport descrie de obicei: clasele de incidente (critic, grav, minor), timpul de reacție și de restabilire pentru fiecare, orele de lucru (program de lucru sau 24/7), modul de escaladare și costul îmbunătățirilor din afara suportului.

Semnale de alarmă la prima întâlnire

• Estimare fără întrebări și fără analiză — „facem în 2 săptămâni”, fără să fi înțeles sarcina.
• Un preț de 2–3 ori mai mic decât al celorlalți candidați pentru același caiet de sarcini, fără explicații pe seama a ce.
• Refuzul de a arăta produse funcționale sau de a oferi contactul măcar al unui client.
• „Codul îl predăm după plata integrală”, „găzduirea doar la noi”, „domeniul îl înregistrăm pe noi, e mai comod”.
• Niciunul dintre dezvoltatori nu participă la întâlniri — doar managerul de vânzări.
• Același stack pentru orice sarcină: și pentru un bot, și pentru un marketplace, și pentru un sistem AI se propune același lucru.
• Niciun răspuns la întrebarea „ce se întâmplă dacă peste un an vrem să schimbăm furnizorul”.

Cum alegeți un studio web: întrebări pentru întâlnire

Dacă vă gândiți cum să alegeți un studio web pentru un site sau o aplicație web, adăugați la checklistul general câteva întrebări specifice:

1. Ce indicatori de viteză au ultimele dvs. site-uri? Se poate verifica în PageSpeed Insights chiar în timpul întâlnirii.
2. Cum prevedeți SEO-ul tehnic: micromarcare, sitemap, adrese canonice, viteză?
3. Ce CMS folosiți și cât de comod se poate modifica conținutul fără un dezvoltator?
4. Cum este organizată analitica: obiective, evenimente, legătura cu CRM-ul?
5. Ce include suportul și cât costă o oră de îmbunătățiri după lansare?

Reperele de buget vă ajută să eliminați ofertele nerealiste încă înainte de întâlniri: prețurile orientative sunt adunate în articolul cât costă dezvoltarea unui site și pe pagina prețuri pentru dezvoltare. Ce intră de obicei în volumul de lucru pentru un site — de la prototip la găzduire și analitică — se vede pe exemplul paginii dezvoltare de site-uri și aplicații web.

Pentru transparență — propria noastră abordare, după care ne puteți verifica și pe noi cu acest checklist: codul, repozitoriile, serverele și domeniile aparțin clientului, produsul se instalează pe serverele dvs. sau în cloudul dvs. și este predat funcțional, cu documentație; aveți acces direct la dezvoltatori și demo-uri săptămânale. Mai multe despre echipă — pe pagina despre studioul B2B-Lab, exemple de lucrări — în secțiunea studii de caz.