Codul scris în grabă devine scump pentru că fiecare scurtătură adaugă „datorie tehnică”: soluții rapide care funcționează azi, dar fac fiecare schimbare viitoare mai lentă, mai riscantă și mai costisitoare. La început economisești zile; mai târziu plătești săptămâni, prin erori repetate, funcții care se adaugă greu și programatori care pierd timp ca să înțeleagă ce a făcut altcineva.
Asta nu înseamnă că ar fi greșit să mergi repede. Într-un produs nou, viteza este uneori singura șansă de a învăța din piață. Diferența dintre o scurtătură rațională și una păguboasă stă în faptul că o faci cu bună știință și o rezolvi la timp. Lista de verificare de mai jos te ajută să deosebești cele două cazuri.
Ce înseamnă, simplu, datoria tehnică
Gândește-te la o bucătărie în care, de câte ori ești grăbit, lași vasele nespălate. O zi sau două merge. După o lună, nu mai găsești nimic, fiecare gătit ia dublu și ți-e greu să inviți pe cineva. Datoria tehnică funcționează asemănător: nu strică imediat, dar acumulează „dobândă” sub forma timpului suplimentar necesar fiecărei schimbări.
Conceptul este explicat mai pe larg în materialul despre datoria tehnică într-un startup: ce este și cum o controlezi, util mai ales dacă vorbești cu programatori și vrei să înțelegi termenii folosiți.
Lista de verificare: scurtături acceptabile și scurtături periculoase
Scurtături de obicei acceptabile, dacă sunt notate
- Procese făcute manual în loc de automatizate, cât timp volumul este mic.
- Design simplu, fără rafinări, pentru primele teste.
- Funcții absente, dar planificate, în loc de funcții făcute pe jumătate.
- Servicii externe folosite în loc de dezvoltări proprii, pentru părți care nu țin de miezul produsului.
Scurtături de obicei periculoase
- Lipsa oricărei verificări automate a funcțiilor critice, cum ar fi plățile sau înregistrarea.
- Date personale stocate fără protecție sau fără o idee clară despre cine are acces.
- Cod copiat din mai multe locuri, cu aceeași logică repetată în zece fișiere.
- Lipsa oricărei documentări, astfel încât doar o persoană înțelege cum funcționează totul.
- Copii de siguranță inexistente sau netestate.
- Schimbări făcute direct pe produsul folosit de clienți, fără mediu de test.
Semne că datoria tehnică a devenit o problemă
- O modificare simplă durează mult mai mult decât ar fi sperat cineva.
- Fiecare funcție nouă strică ceva care mergea.
- Programatorii spun frecvent „nu știu ce se întâmplă dacă ating asta”.
- Apar aceleași erori de mai multe ori, în locuri diferite.
- Cei noi în echipă au nevoie de luni ca să devină productivi.
- Planurile se mută mereu, iar explicațiile sunt tot mai tehnice.
Dacă recunoști trei sau mai multe, merită să oprești dezvoltarea unor funcții noi pentru o perioadă și să investești în curățenie.
Cum controlezi datoria fără să încetinești produsul
- Notează fiecare scurtătură în momentul în care o faci. O listă simplă, cu data și motivul, e suficientă. Ce nu e notat se uită.
- Alocă o parte din timp pentru curățenie. Mulți fondatori rezervă o parte din fiecare ciclu de lucru pentru îmbunătățiri interne, de exemplu în jur de o cincime din timp.
- Repară întâi ce te încetinește cel mai mult. Nu tot codul vechi merită rescris; concentrează-te pe zonele atinse des.
- Cere explicații în limbaj de afaceri. Un programator poate spune „modulul de plăți durează trei zile la fiecare modificare; cu două zile investite acum, va dura una”. Asta te ajută să decizi.
- Verifică funcțiile critice automat. Testele pentru plăți, înregistrare și date sensibile se plătesc de obicei repede.
- Documentează esențialul. Câteva pagini despre cum se instalează, cum se testează și cum funcționează părțile principale fac diferența când pleacă sau vine cineva nou.
Un exemplu: scurtătura care a costat trei săptămâni
O echipă mică lansează rapid un magazin online și, ca să economisească timp, scrie regulile de reduceri direct în mai multe pagini. Merge bine câteva luni. Apoi apare nevoia de a schimba modul de calcul al reducerilor pentru clienții fideli. Fiindcă regula e copiată în opt locuri, fiecare modificare riscă să strice altceva. Ce părea o zi economisită devine trei săptămâni de lucru, iar în acest timp apar și erori în comenzi.
Dacă echipa ar fi notat scurtătura și ar fi centralizat regula la prima ocazie, costul ar fi fost de câteva ore. Lecția nu este că trebuie să eviți scurtăturile, ci să le ții evidența și să le repari înainte să se înmulțească.
Cum explici costul către cei care nu sunt tehnici
Dacă vorbești cu parteneri, colegi sau investitori, folosește comparații. Poți spune: „am construit repede ca să testăm cererea; acum că ea există, investim câteva săptămâni ca să nu pierdem luni în viitor”. O explicație cinstită și legată de rezultate este de obicei bine primită.
| Alegere | Câștig pe termen scurt | Cost pe termen lung |
|---|---|---|
| Livrare rapidă fără verificări | Funcția apare mai devreme | Erori repetate, încredere scăzută |
| Totul făcut „perfect” de la început | Cod curat | Lansare întârziată, risc de a construi ceva nedorit |
| Scurtături notate și reparate periodic | Viteză și învățare | Cost mic, controlat |
Ultima variantă este, de regulă, cea mai sănătoasă într-un produs nou: mergi repede, dar știi ce ai lăsat în urmă și când revii.
Când e momentul să investești în curățenie
Un moment potrivit este după ce ai confirmat că produsul rezolvă o problemă reală și că oamenii îl folosesc. Înainte, orice investiție în perfecțiune poate fi risipită dacă produsul se schimbă. Imediat după, ignorarea datoriei începe să coste mai mult decât repararea ei. Păstrează un ritm: luni de explorare rapidă, apoi o perioadă de consolidare, apoi din nou explorare.
Restul etapelor de dezvoltare a unui produs, de la MVP la lansare și mentenanță, sunt grupate în categoria Produs. Dacă dorești o imagine de ansamblu a drumului unui fondator, merită răsfoită și pagina principală StartupInfo.
