Spašavanje Softverskih Projekata i Tehnički Oporavak

Spašavanje softverskog projekta je specijalizirani inženjerski proces u kojem se preuzima blokiran, tehnički neispravan ili budžetski prekoračen softver, s ciljem stabilizacije, refaktoriranja i dovođenja do uspješnog lansiranja. Prema izvješću Standish Group CHAOS 2020, 19% softverskih projekata potpuno propadne, a dodatnih 50% kasni, prekorači budžet ili ne isporuči dogovoreni opseg.

Specijalizirani smo za preuzimanje projekata u kriznim situacijama. Problem obično nije u pojedinačnim bugovima, nego u arhitekturi, akumuliranom tehničkom dugu ili raspadu komunikacije između tima i stakeholdera. Nećemo samo dijagnosticirati uzroke; stabilizirat ćemo produkciju, osigurati podatke i isporučiti pisanu mapu puta do lansiranja s fiksnim rokovima.

Većina projekata koji propadaju pokazuje iste znakove mnogo prije nego što itko to nazove neuspjehom:

• rokovi se stalno pomiču i svaki novi datum dolazi s novim objašnjenjem
• svaki popravak pokvari nešto drugo
• kod razumije samo jedna osoba, a ta osoba odlazi ili je nedostupna
• dokumentacije i testova gotovo da nema
• troškovi rastu bez vidljivog napretka
• prethodni tim više ne odgovara
• greške u produkciji postaju uobičajena pojava

Jedan znak je upozorenje. Tri ili više obično znače da je problem strukturne naravi, a ne nekoliko grešaka.

Dubinska tehnička revizija je sustavna procjena zdravlja softverskog sustava koja pokriva kod, infrastrukturu, sigurnost i dokumentaciju. Bez nje je svaki popravak pogađanje, a pogađanje je u kriznom projektu skupo.

Naša revizija pokriva četiri kritične dimenzije:

• Kvaliteta koda: Statička analiza TypeScript i JavaScript baze koda, identifikacija uskih grla, ciklomatska složenost iznad praga i mapiranje tehničkog duga s procjenom troška otplate.
• Infrastruktura: Procjena AWS ili Vercel konfiguracije, zdravlje PostgreSQL ili MongoDB baze podataka, analiza uptime logova i procjena skalabilnosti pod opterećenjem.
• Dokumentacija: Reverzno inženjerstvo poslovne logike iz koda kada dokumentacija ne postoji, jer je u većini spašavanja dokumentacija nepotpuna ili zastarjela.
• Sigurnost: Hitno krpanje kritičnih propusta (SQL injection, XSS, nezaštićeni API endpointi) koje su ostavili prethodni timovi ili nastali zbog brzog isporučivanja bez code review-a.

Nije svaki projekt vrijedan spašavanja. U prvoj procjeni gledamo je li jezgra, odnosno model podataka i arhitektura, dovoljno zdrava da se na njoj može graditi. Ako jest, stabilizacija i dovršetak često su brži put nego početak ispočetka. Ako nije, to kažemo, i to prije nego što platite popravak. Odluka je vaša i temelji se na pisanoj procjeni, a ne na prodajnom pritisku.

Proces oporavka softvera je strukturirani pristup u tri faze koji transformira nestabilan sustav u deployabilan, održiv proizvod. Faze su sekvencijalne jer svaka ovisi o rezultatu prethodne. Preskakanje stabilizacije i izravan skok na refaktoring najčešća je pogreška koja značajno produžuje spašavanje.

• Faza 1. Stabilizacija (tjedan 1–3): Ispravljanje kritičnih bugova koji uzrokuju gubitak podataka, pad produkcije ili sigurnosne propuste. Cilj je stabilan, deployabilan build bez novih regresija.
• Faza 2. Refaktoring (tjedan 3–6): Čišćenje najproblematičnijih modula, razdvajanje čvrsto vezanih komponenti, zamjena pokvarenih integracija, optimizacija baze podataka. Svaka promjena prolazi kroz automatske testove.
• Faza 3. Evolucija (tjedan 6–10): Dodavanje preostalih funkcionalnosti potrebnih za izlazak na tržište. Predaja dokumentacije i 30-dnevna podrška nakon lansiranja.

Tehnološka širina u spašavanju projekata znači sposobnost dijagnosticiranja i popravljanja sustava neovisno o stacku koji je izabrao prethodni tim. Projekt koji treba spašavanje najčešće koristi tehnologiju koju prethodni tim nije u potpunosti razumio.

Uspješno smo stabilizirali projekte u sljedećim stackovima:

• Frontend oporavak: Refaktoring Next.js 14/15/16, React i TypeScript aplikacija, rješavanje hydration mismatcheva, PPR slot grešaka i loših Core Web Vitals rezultata.
• API i backend popravci: Node.js (Express, NestJS) i kompleksne PostgreSQL migracije podataka s nula downtime-a.
• AI realignment: Popravak loših LLM implementacija, halucinacija, ranjivosti na prompt injection i neoptimalnih RAG pipelineova s Pinecone ili Chroma vektorskim bazama.
• Cloud rescue: Migracija pogrešno konfiguriranih AWS okruženja, smanjenje previsokih Lambda troškova, zaštita izloženih S3 bucketa i postavljanje CloudWatch alarma koji nedostaju.

Spašavanje kreće brže kada imate spremno:

• pristup repozitoriju i hosting ili cloud računima
• sva postojeća dokumentacija, zadaci ili specifikacije
• osoba koja zna što proizvod mora postići
• kontakt s prethodnim programerima, ako je moguće

Ako nešto od toga nedostaje, krećemo od onoga što postoji. Sam nedostatak pristupa dio je dijagnoze.

U situaciji spašavanja projekta svaki dan kašnjenja povećava ukupni trošak oporavka. Naš proces hitnog preuzimanja dizajniran je za maksimalnu brzinu bez žrtvovanja dijagnostičke točnosti.

Tri koraka do plana oporavka:

1. Hitni upit: Opišite nam trenutni status, što ne radi, koliko je korisnika pogođeno, koji su rokovi. NDA potpisujemo odmah, prije pristupa kodu.
2. Brza procjena: Provodimo reviziju baze koda, infrastrukture i deploy pipeline-a. Dobivate pisani izvještaj s rangiranim prioritetima.
3. Plan preuzimanja: Isporučujemo fiksnu cijenu i rokove za svaku fazu: stabilizaciju, refaktoring i evoluciju. Bez skrivenih troškova, bez otvorenih procjena.

Vremenski okvir spašavanja softvera je strukturirani plan koji definira što se događa svaki tjedan, kada su potrebne vaše odluke i kada možete očekivati stabilnu produkciju. Bez jasnog rasporeda, spašavanje se pretvara u otvoreni konzalting, a projekti bez definiranog vremenskog okvira redovito prekoračuju budžet.

Tjedan 1, hitna dijagnoza: Dobivamo pristup kodu, infrastrukturi i dostupnoj dokumentaciji. Razgovaramo s ključnim dionicima: product ownerom, preostalim developerima i krajnjim korisnicima ako su dostupni. Do kraja tjedna dobivate pisani izvještaj: identificirani uzroci, rizici rangirani po ozbiljnosti i preporučeni slijed akcija.

Tjedni 2–3, stabilizacija: Krpamo najkritičnije probleme: gubitak podataka, sigurnosne propuste i potpuni pad funkcionalnosti. Cilj je stabilan, deployabilan build. Dokumentiramo svaku promjenu u Git historyju i tehničkim bilješkama.

Tjedni 4–6, strukturni popravak: Rješavamo arhitekturalne probleme: razdvajanje čvrsto vezanih modula, zamjena pokvarenih integracija trećih strana, migracija na održiviji podatkovni model. Radimo inkrementalno s CI/CD pipeline-om i automatskim testovima na svakom PR-u.

Tjedni 7–10, predaja ili nastavak: Ako vaš interni tim preuzima, pripremamo potpunu tehničku dokumentaciju, provodimo sesije prijenosa znanja i ostajemo dostupni za pitanja 30 dana. Ako nastavljamo kao razvojni partner, prelazimo u standardni sprint-bazirani angažman.

Svako spašavanje je drugačije. Dijagnoza u prvom tjednu daje vam poštenu prognozu prije nego što se obvežete na puni angažman.