Aplicații construite în jurul procesului tău real, când nicio soluție de pe piață nu îl acoperă. Prima întrebare pe care o punem nu este cum se construiește, ci dacă trebuie.
Un sistem construit la comandă nu se termină la lansare. Din acel moment cineva trebuie să îl întrețină la nesfârșit: dependențele primesc vulnerabilități, sistemele cu care se leagă își schimbă interfețele, cerințele legale se modifică, iar oamenii care l-au construit pleacă.
Costul acesta este invizibil în momentul deciziei, când toată lumea compară prețul dezvoltării cu prețul unei licențe. Comparația corectă se face pe trei ani și include, de partea construitului, întreținerea, iar de partea cumpăratului, munca de a-ți adapta procesul.
Facem calculul acesta înainte de contract și îți arătăm cifrele. De multe ori concluzia este să nu construiești, iar noi ți-o spunem chiar dacă înseamnă un proiect mult mai mic pentru noi.
| Situație | Recomandarea noastră |
|---|---|
| Procesul tău este chiar avantajul competitiv | Construiește. O platformă generică te obligă să lucrezi ca toată lumea, adică să renunți la ce te diferențiază |
| Costul licențelor pe utilizator a depășit costul dezvoltării | Construiește. Se întâmplă des la echipe care cresc. Calculul se face pe trei ani, cu creșterea prevăzută |
| Nicio soluție nu acoperă o cerință de care depinde afacerea | Construiește doar acea parte, și o legăm de restul. Nu are rost să înlocuiești tot pentru o funcție |
| Datele trebuie să rămână la tine, din motive legale sau contractuale | Construiește sau găzduiește la tine. Uneori este singura variantă acceptabilă |
| Procesul tău seamănă cu al tuturor din industrie | Cumpără. Vei plăti mai puțin și vei primi un produs testat de mii de utilizatori |
| Cerința vine de la o singură persoană | Verifică întâi. Dacă nimeni altcineva nu simte problema, probabil nu este una de sistem |
| Procesul se schimbă din trimestru în trimestru | Stabilizează întâi procesul. Orice construim va fi depășit înainte de lansare |
Cea mai frecventă greșeală într-un proiect de companie nu este subdimensionarea, ci supradimensionarea: o arhitectură făcută pentru un milion de utilizatori, la un sistem folosit de patruzeci de oameni. Rezultatul este cost triplu și un sistem pe care nimeni nu îl mai poate depana.
Alegem cea mai simplă structură care rezolvă cerințele reale, cu drum clar de creștere dacă volumul apare. Complexitatea se adaugă când o cere realitatea, nu preventiv.
Structura datelor este cea mai scumpă decizie de schimbat mai târziu. Un ecran se rescrie într-o zi. O structură de date greșită, cu doi ani de informație reală în ea, se corectează în săptămâni și cu risc.
Modelăm întâi ce entități există, cum se leagă, ce se păstrează și cât. Inclusiv întrebările incomode: ce înseamnă ștergerea unui client când există facturi legate de el.
Roluri și permisiuni definite de la început, autentificare în doi pași pentru conturile cu drepturi mari, jurnal care înregistrează cine ce a modificat și când, pe datele care contează.
Adăugate ulterior, toate acestea înseamnă atingerea fiecărei componente. Proiectate de la început, sunt aproape gratuite și îți rezolvă în avans jumătate din cerințele oricărui audit.
Structurat previzibil, comentat unde raționamentul nu este evident, cu teste automate pe fluxurile critice. Testele nu sunt pentru noi, sunt pentru cel care va schimba codul peste doi ani fără să știe ce mai atinge.
Fără componente proprietare care te-ar lega de noi. Testul pe care ni-l aplicăm: cât i-ar lua unui dezvoltator din afară să preia proiectul.
Stăm cu oamenii care fac munca, nu doar cu cine o descrie. Ce se întâmplă real diferă aproape întotdeauna de procedura scrisă.
Comparație pe trei ani, cu cifre. Dacă o soluție existentă câștigă, ți-o spunem și ne oprim aici.
Un document pe care îl poate citi și evalua un alt furnizor. Fără el, orice estimare este o presupunere.
Cazul principal, funcțional, în mâinile oamenilor în două până la patru luni. De aici încolo deciziile se iau pe feedback real.
Ceva verificabil la fiecare două săptămâni. Poți schimba direcția fără să pierzi luni de muncă.
Documentație tehnică, documentație pentru utilizatori, sesiuni cu echipa ta și o perioadă în care rămânem aproape.
Cel mai mare risc într-un proiect de software nu este tehnic. Este să construiești luni întregi ceva ce nu se potrivește cu realitatea. Un sistem livrat integral după un an ajunge la utilizatori când cerințele s-au schimbat deja, iar corecțiile costă cât o bună parte din proiect. Livrările la două săptămâni nu sunt un moft de metodologie, sunt singura formă de asigurare împotriva acestui risc.
Comparăm costul total pe trei ani, nu prețul de pornire. La cumpărat intră licențele pe utilizator, care cresc odată cu echipa, plus munca de a-ți îndoi procesul după cum cere platforma. La construit intră dezvoltarea, plus întreținerea permanentă. Dacă procesul tău seamănă cu al tuturor din industrie, cumpăratul câștigă aproape întotdeauna, iar noi îți spunem asta.
Este de așteptat și lucrăm ca să fie posibil. Livrăm la interval scurt tocmai pentru ca schimbarea de direcție să coste săptămâni, nu luni. Ce nu se poate ieftin este schimbarea premisei de bază, adică a problemei pe care o rezolvă sistemul. De aceea insistăm atât pe etapa de dinaintea codului.
Tu, de la prima linie scrisă. Îl primești pe parcurs, nu la final, într-un depozit pe care îl controlezi. Nu folosim componente proprietare care te-ar lega de noi. Testul pe care ni-l aplicăm este simplu: cât i-ar lua unui dezvoltator din afară să preia proiectul.
Da, și este de multe ori varianta cea mai bună. Putem construi și preda cu instruire, putem completa echipa pe o perioadă, sau putem prelua doar o componentă. Cerem un singur lucru: un om la voi care poate lua decizii. Proiectele nu se blochează pe probleme tehnice, se blochează așteptând aprobări.
Orientativ, între zece și douăzeci la sută pe an din costul dezvoltării, în funcție de complexitate și de câte sisteme externe sunt implicate. Acolo intră actualizări de dependențe, corecții de securitate, adaptări la schimbările altor sisteme și monitorizare. Îți dăm cifra în scris înainte să semnezi, nu în anul doi.
Spune-ne ce nu funcționează în procesul tău. Dacă răspunsul corect este să nu construiești, îți spunem în prima discuție.