Cum alege un software house un CEO fără cunoștințe tehnice

Un CEO nu trebuie să evalueze linii de cod. Trebuie să evalueze dacă furnizorul înțelege problema de afaceri, poate transforma ambiguitatea într-un scope clar și dispune de un sistem de livrare care reduce riscul.

Cea mai frecventă greșeală este alegerea pe baza unei prezentări impresionante sau a celui mai mic preț. Calitatea reală se vede în modul în care software house-ul pune întrebări, definește livrabilele, gestionează schimbările și demonstrează că sistemul funcționează.

Începeți de la rezultatul de afaceri

Înainte de a solicita o ofertă, descrieți ce trebuie să se schimbe în funcționare. De exemplu, să se reducă timpul de emitere a unei oferte, să nu se mai piardă cereri, să fie conectat portofoliul de clienți cu ERP-ul sau să fie creat un nou canal digital de venituri.

Evitați să începeți cu o listă mare de funcționalități. Funcționalitățile sunt soluții posibile. Rezultatul este motivul pentru care investiți. Un partener bun vă va ajuta să conectați fiecare funcționalitate critică cu un utilizator, o problemă și un obiectiv măsurabil. Dacă întrebarea vizează specific CRM, vedeți mai întâi dacă vi se potrivește CRM gata făcut sau personalizat.

Verificați cum se face discovery-ul

Întrebați ce se întâmplă înainte de începerea dezvoltării. Cine participă? Cum sunt înregistrate fluxurile? Cum sunt confirmate cerințele? Care este livrabilul discovery-ului?

Dacă firma poate oferi un preț final și o dată pentru un proiect complex după o discuție generală scurtă, probabil fie subestimează scope-ul, fie include o marjă mare de incertitudine. Precizia ofertei depinde de precizia înțelegerii.

Cereți să cunoașteți echipa reală

Prezentarea comercială poate fi făcută de directori seniori, dar proiectul poate fi atribuit altcuiva. Cereți să cunoașteți project owner-ul și responsabilul tehnic. Întrebați cine va participa, cât de disponibili sunt și cine decide atunci când apare un obstacol tehnic.

Nu trebuie să evaluați CV-ul fiecărui dezvoltator. Trebuie să vă asigurați că există un responsabil cu vizibilitate asupra întregului proiect și că cunoștințele nu se află într-o singură persoană.

Evaluați proiecte similare în mod corect

Un portofoliu mare nu dovedește prin el însuși potrivirea. Cereți două sau trei proiecte cu complexitate, integrare sau mediu de reglementare similare. Întrebați care a fost problema, ce a fost livrat, ce s-a schimbat în timpul implementării și ce rezultat a fost măsurat.

Imaginile unei aplicații demonstrează design. Nu demonstrează stabilitate, adopție, performanță sau rezultat de afaceri.

Cereți un scope clar și criterii de acceptare

Fiecare funcționalitate de bază trebuie să aibă un criteriu de acceptare. Dacă sistemul „se conectează cu ERP-ul”, trebuie definit ce date sunt transferate, în ce direcție, cât de des, ce se întâmplă în caz de eroare și cine este responsabil pentru API.

Oferta trebuie să separe ce este inclus, ce nu este inclus, ce ipoteze au fost făcute și ce parte depinde de terți.

Înțelegeți modelul de cost

În fixed price, furnizorul își asumă un risc mai mare privind scope-ul și de obicei adaugă o marjă de siguranță. În time and materials, clientul plătește timpul real, dar își asumă o incertitudine mai mare privind costul total. În modelul pe faze, fiecare etapă este aprobată înainte de începerea următoarei.

Nu există un model care este întotdeauna mai bun. Alegerea corectă depinde de cât de mature sunt cerințele și câtă schimbare este anticipată.

Verificați securitatea și continuitatea

Întrebați unde este găzduit sistemul, cum se face backup-ul, cum sunt gestionate accesurile, cum sunt înregistrate incidentele și ce subîmputerniciți sunt folosiți. Cereți să aflați cine deține conturile critice și cum va continua proiectul dacă se schimbă colaborarea.

Răspunsul „suntem conformi cu GDPR” nu este suficient. Sunt necesare măsuri concrete, roluri și documente contractuale.

Evaluați modul de comunicare

Colaborarea într-un proiect software implică incertitudine. Ceea ce contează este cât de repede echipa semnalează o problemă și ce informații oferă pentru a se putea lua o decizie. Căutați un ritm stabil, decizii scrise, demo-uri ale materialului funcțional și un backlog vizibil.

Certitudinea excesivă este un semnal de alarmă. Un partener matur separă ceea ce știe, ceea ce presupune și ceea ce trebuie testat.

Zece întrebări înainte de atribuire

1. Ce problemă considerați că rezolvăm și cum vom măsura succesul?
2. Care este primul livrabil și când îl vom vedea funcționând?
3. Cine este responsabil pentru scope, deciziile tehnice și comunicare?
4. Ce ipoteze include oferta?
5. Cum sunt aprobate schimbările și cum afectează costul și timpul?
6. Ce date și integrări depind de noi sau de terți?
7. Care sunt criteriile de acceptare?
8. Cum se realizează securitatea, copiile de siguranță, monitorizarea și răspunsul la incidente?
9. Ce se livrează dacă se încheie colaborarea?
10. Care este costul total de funcționare după lansare?

Argonstack începe proiectele personalizate cu o analiză de afaceri și o planificare tehnică. Obiectivul este ca propunerea să descrie un sistem care poate fi livrat, verificat și pus în funcțiune, nu doar o listă atractivă de funcționalități.

Pasul următor

Evaluați proiectul, riscul și rezultatul așteptat înainte de a aloca bugetul.

Întrebări frecvente

Trebuie să aleg cea mai mică ofertă?

Nu înainte de a confirma că ofertele acoperă același scope. Prețul cel mai mic poate rezulta din mai puține livrabile, ipoteze diferite sau absența unor activități critice.

Am nevoie de propriul meu CTO?

Nu întotdeauna. Pentru un proiect important, aveți însă nevoie de o supraveghere tehnică independentă sau cel puțin de un consultant experimentat care să verifice arhitectura, securitatea și livrabilele.

Care este cel mai important semnal de alarmă?

Incapacitatea furnizorului de a descrie clar ce nu știe încă și cum va confirma acest lucru.