Proces
Cum lucrăm, etapă cu etapă
Un proiect de software se strică cel mai des din lucruri care nu țin de cod: nu se știe ce se construiește, nu se vede nimic luni în șir și nimeni nu spune la timp că termenul a alunecat. Mai jos e felul în care încercăm să nu ajungem acolo.
Patru reguli care se aplică în toate etapele
Procesul de mai jos e împărțit în șase etape, dar regulile astea patru nu depind de etapă. Sunt lucruri pe care le poți verifica singur, în orice zi a proiectului, fără să ne întrebi pe noi — și de aceea le scriem aici, nu în prezentarea comercială.
Vezi lucrarea, nu rapoarte despre ea
Ai acces permanent la o versiune de test și la codul din repository. Nu trebuie să ne crezi pe cuvânt că s-a lucrat săptămâna asta — intri și te uiți.
Codul e al tău de la primul commit
Repository-ul, serverul și conturile la servicii externe stau pe numele firmei tale. Poți duce proiectul la altă echipă oricând, fără să ceri voie și fără să aștepți o predare.
Etape scurte, decizii dese
Împărțim lucrarea în bucăți de una-două săptămâni. Cu cât bucata e mai scurtă, cu atât te costă mai puțin o schimbare de direcție — și cu atât mai devreme afli dacă ceva nu merge.
Fără dependență de noi
Documentăm ce am construit și instruim omul care rămâne cu aplicația. Mentenanța se contractează pentru că e convenabilă, nu pentru că nimeni altcineva nu se descurcă în codul nostru.
Etapele
De la prima discuție până după lansare
Etapele nu sunt obligatoriu toate. Dacă ai deja o analiză scrisă, sărim peste a doua; dacă vrei doar un audit, ne oprim după ea. Ce nu sărim niciodată e ordinea.
-
01
Discuția de început
1–3 zile lucrătoare
O discuție în care aflăm ce trebuie rezolvat. Nu prezentăm tehnologii și nu trimitem ofertă pe nevăzute.
Ce facem
- Ne spui cum lucrezi acum: ce programe folosești, unde se pierde timp și cine face manual munca pe care vrei să o automatizezi.
- Punem întrebările incomode — cine folosește aplicația zilnic, ce se întâmplă concret dacă nu o construiești și ce ai mai încercat până acum.
- Îți spunem direct dacă problema ta se rezolvă mai simplu cu un produs existent de pe piață. Se întâmplă, și e mai bine să o auzi la început.
Ce rămâne la tine
- Un rezumat scris al discuției, ca să verifici dacă am înțeles corect.
- Un răspuns clar: e ceva ce știm să facem bine sau nu.
De ce avem nevoie de la tine
O oră din timpul cuiva care chiar face munca de zi cu zi, nu doar al persoanei care aprobă bugetul.
-
02
Analiza și estimarea
3–7 zile lucrătoare
Transformăm discuția într-un document: ce se construiește, în ce ordine, în cât timp și ce rămâne pentru mai târziu.
Ce facem
- Împărțim aplicația în funcționalități și le ordonăm după cât de mult contează pentru tine, nu după cât de interesante sunt pentru noi.
- Separăm prima versiune de restul. Prima versiune trebuie să fie folosibilă, nu completă — altfel plătești luni de dezvoltare înainte să vezi dacă direcția e bună.
- Estimăm fiecare bucată separat și cu interval, nu cu o cifră unică. O estimare exactă la zi, dată înainte de a scrie o linie de cod, e o promisiune care se încalcă singură.
- Verificăm din timp integrările: ce sisteme trebuie să vorbească între ele, ce documentație există și ce limite impun. Aici apar cele mai multe surprize.
Ce rămâne la tine
- Un document cu perimetrul lucrării, etapele și termenele.
- O ofertă împărțită pe etape, în care vezi ce plătești pentru fiecare.
- Lista riscurilor pe care le-am identificat, cu ce facem dacă apar.
De ce avem nevoie de la tine
Acces la documentația sistemelor cu care aplicația trebuie să vorbească și o persoană care poate răspunde la întrebări despre regulile voastre de business.
-
03
Fluxuri și ecrane
1–2 săptămâni
Desenăm aplicația înainte să scriem cod. E ultimul moment în care o schimbare costă cât o discuție.
Ce facem
- Stabilim ecranele principale și drumul utilizatorului prin ele, de la deschiderea aplicației până la lucrul terminat.
- Definim rolurile și ce vede fiecare. Un operator, un șef de echipă și un contabil nu au nevoie de aceleași butoane, iar un ecran care le arată pe toate nu e util nimănui.
- Marcăm punctele în care omul poate rămâne blocat: un câmp obligatoriu pe care nu are de unde să îl completeze, o aprobare care depinde de un coleg în concediu, un import care pică la jumătate.
- Stabilim structura datelor. Ce se leagă de ce, ce se poate șterge și ce trebuie păstrat pentru audit sau pentru lege.
Ce rămâne la tine
- Schițele ecranelor principale, pe care le poți arăta echipei tale înainte să existe aplicația.
- Lista rolurilor și a permisiunilor, negru pe alb.
De ce avem nevoie de la tine
Câteva ore de discuție pe schițe. Modificările făcute acum nu costă nimic; aceleași modificări după două luni de dezvoltare costă exact cât rescrierea.
-
04
Dezvoltarea, pe iterații
majoritatea proiectului
Construim în bucăți de una-două săptămâni. La finalul fiecăreia intri în aplicație și o folosești, nu citești despre ea.
Ce facem
- Lucrăm pe o versiune de test la care ai acces permanent, cu date de probă. Nu aștepți până la final ca să vezi cum arată.
- La finalul fiecărei iterații primești o listă scurtă cu ce s-a terminat, ce s-a amânat și ce urmează.
- Codul intră în repository de la prima zi, cu istoric complet. Poți vedea oricând cine ce a modificat și când.
- Scriem teste automate pentru părțile în care o greșeală doare: calcule, drepturi de acces, integrări cu sisteme externe. Nu pentru tot — testele care nu prind nimic sunt cost, nu siguranță.
- Dacă apare o cerință nouă la mijloc, o estimăm separat și decizi tu dacă intră acum sau după lansare.
Ce rămâne la tine
- O adresă de test unde aplicația rulează, actualizată la fiecare iterație.
- Cod în repository-ul tău, cu istoric și cu teste.
- Un raport scurt la fiecare livrare, fără jargon.
De ce avem nevoie de la tine
Feedback în câteva zile de la fiecare livrare. Un răspuns care întârzie două săptămâni întârzie proiectul cu două săptămâni — e singura parte pe care nu o putem compensa noi.
-
05
Verificare și lansare
3–7 zile lucrătoare
Punem aplicația pe serverul real și verificăm ce se întâmplă când o folosesc oameni adevărați, cu datele lor.
Ce facem
- Testăm fluxurile de la cap la coadă, pe date reale, inclusiv cazurile urâte: o comandă anulată la jumătate, un utilizator fără drepturi, un fișier greșit la import.
- Configurăm serverul, certificatul, backup-urile automate și verificăm că o restaurare chiar funcționează. Un backup netestat nu e backup.
- Migrăm datele existente și verificăm, număr cu număr, că nu s-a pierdut nimic pe drum.
- Pregătim măsurarea: ce se urmărește, ce înseamnă o conversie și de unde vin vizitatorii — ca deciziile de după lansare să aibă pe ce se sprijini.
- Instruim echipa care va folosi aplicația și rămânem disponibili în primele zile, când apar întrebările reale.
Ce rămâne la tine
- Aplicația în producție, pe domeniul tău.
- Documentație de administrare, scrisă pentru omul care rămâne cu ea.
- Acces la toate conturile — server, domeniu, servicii externe — pe numele firmei tale.
De ce avem nevoie de la tine
Câteva ore din timpul oamenilor care vor folosi zilnic aplicația, ca să o testeze înainte de lansare. Sunt singurii care găsesc problemele reale.
-
06
După lansare
continuu, cât are sens
Lansarea nu e finalul proiectului, e prima zi în care afli cum se comportă aplicația în realitate.
Ce facem
- Perioadă de garanție după lansare: reparăm fără cost ce nu funcționează conform înțelegerii.
- Urmărim erorile din producție și le vedem, de obicei, înainte să ne scrie cineva despre ele.
- Actualizăm dependențele și versiunile de securitate, dacă rămâi pe mentenanță. O aplicație lăsată nefolosită doi ani devine scumpă de repornit.
- Discutăm ce urmează pornind de la ce s-a văzut în utilizare reală, nu de la lista de dorințe de acum șase luni. De obicei jumătate din ea nu mai are sens.
Ce rămâne la tine
- Garanție pe ce am livrat.
- Un contract de mentenanță, dacă îl vrei — opțional, nu obligatoriu.
- Tot ce ține de proiect predat, în așa fel încât să poți continua și fără noi.
De ce avem nevoie de la tine
Să ne spui ce nu merge. Un utilizator care se obișnuiește cu o problemă și își face o metodă ocolitoare costă mai mult decât o problemă raportată în ziua în care a apărut.
Angajamente
Ce îți garantăm și ce nu îți promitem
Prima listă o poate scrie orice firmă de software. A doua se poate scrie doar dacă nu ai de gând să câștigi lucrarea cu orice preț.
Ce îți garantăm
- Un termen pe fiecare etapă, nu unul singur la final. Dacă alunecă, afli când alunecă, nu în ziua predării.
- Codul sursă integral, în repository-ul tău, de la primul commit.
- Toate conturile — server, domeniu, servicii externe — deschise pe numele firmei tale.
- O persoană din echipa noastră care îți răspunde direct, fără drumuri prin formulare de suport.
- Perioadă de garanție după lansare, în care reparăm fără cost ce nu funcționează conform înțelegerii.
Ce nu îți promitem
- Un preț fix pentru o cerință care încă nu e scrisă. Estimăm după ce știm ce construim, nu înainte.
- Un termen ales ca să câștigăm lucrarea. Preferăm să pierdem un proiect decât să îl întârziem cu trei luni.
- Că prima versiune conține tot ce ți-ai dorit. Conține ce e util din prima zi; restul intră după ce vezi aplicația la lucru.
- Că lucrăm cu orice tehnologie. Dacă nu e ceva ce știm bine, îți spunem și îți recomandăm pe cineva mai potrivit.
- Că nu apar probleme. Apar la orice proiect — diferența e cât de repede le afli și cine le repară.
Procesul, aplicat
Cum au arătat etapele astea pe proiecte reale
Un proces descris pe o pagină e o promisiune. Studiile de caz sunt aceleași etape, cu deciziile care au ieșit din ele — inclusiv cele pe care le-am schimbat pe drum.
Un CRM în care oamenii de vânzări chiar intră
Firma avea deja un CRM de abonament. Problema nu era că lipsea o unealtă, ci că nimeni nu o completa — pentru că nu îi dădea nimic celui care introducea datele.
Citește studiul → Financiar-bancarDosarul de credit, cu fiecare pas reconstituibil
Într-un dosar de creditare, întrebarea nu e doar „ce s-a decis", ci „cine a văzut ce și pe ce bază". Un flux ținut pe mail nu poate răspunde la a doua.
Citește studiul → TransportO flotă care nu mai depinde de un fișier și de un om
Flota se conducea dintr-un fișier cu date de expirare pe care cineva își propunea să îl verifice săptămânal. A funcționat până în săptămâna în care omul acela a fost în concediu.
Citește studiul →Întrebări frecvente
Ce se întreabă despre felul în care lucrăm
Sunt întrebările care apar în prima discuție, aproape de fiecare dată. Dacă a ta nu e aici, scrie-ne — răspundem la fel de direct.
Pune-ne o întrebareCât durează, de la prima discuție până la lansare?
Depinde de câte fluxuri are aplicația și de câte sisteme externe trebuie să atingă. Pentru o aplicație de gestiune internă de dimensiune obișnuită, între două și patru luni. Pentru o soluție deja gândită pentru domeniul tău, mai puțin. Ce putem promite este că primești o estimare pe etape după analiză, nu un termen aruncat la prima discuție.
Pot să mă opresc între etape?
Da, și e gândit așa intenționat. Fiecare etapă se încheie cu ceva ce rămâne la tine: documentul de analiză, schițele, codul livrat până atunci. Nu există un punct în care ai plătit și nu ai nimic în mână.
Cine deține codul la final?
Tu, de la primul commit, nu de la ultimul. Repository-ul e al firmei tale și noi lucrăm în el. Nu păstrăm componente proprietare pe care să trebuiască să le licențiezi ca aplicația să funcționeze.
Ce se întâmplă dacă vreau o schimbare la jumătatea proiectului?
O estimăm separat și decizi dacă intră acum sau după lansare. Nu o refuzăm și nu o strecurăm nici în tăcere peste termenul convenit. Motivul pentru care lucrăm pe iterații scurte e exact acesta: o schimbare cerută la două săptămâni de la o livrare e ieftină, aceeași schimbare cerută la finalul unui proiect de șase luni nu mai e.
Lucrați și cu firme care au deja echipă tehnică?
Da. Uneori intrăm ca echipă externă pe o parte a produsului, alteori facem un audit de cod și predăm un document pe care echipa internă îl duce mai departe singură. În cazul ăsta stabilim de la început unde se termină responsabilitatea noastră și unde începe a lor, ca să nu rămână zone de care nu răspunde nimeni.
Cum se plătește?
Pe etape, la livrarea fiecăreia, nu tot la început și nu tot la final. Analiza se plătește separat de dezvoltare, pentru că e utilă și dacă te oprești acolo — documentul rezultat poate fi dus la orice altă echipă.
De ce nu primesc o ofertă direct, fără analiză?
Putem da un interval orientativ după prima discuție, și o facem. Ce nu putem da este un preț ferm pentru o listă de cerințe care nu e încă scrisă — acela ar fi ori mult prea mare, ca să acopere necunoscutele, ori mult prea mic, cu discuția neplăcută mutată la jumătatea proiectului.
Ce se întâmplă dacă dispăreți la jumătatea proiectului?
Codul e deja la tine, în repository-ul tău, cu istoric complet și cu documentul de analiză alături. Asta nu ne face de neînlocuit, și tocmai ăsta e scopul: să poți continua cu altcineva fără să reconstruiești de la zero.
Prima etapă e o discuție, nu un contract
Spune-ne ce ai de construit sau unde se blochează ce ai deja. Dacă e ceva ce știm să facem bine, îți spunem cum am porni. Dacă nu, îți spunem și asta.