Când începe să se scufunde un proiect?
Fiecare proiect IT pornește cam la fel. Sunt planuri ambițioase, un calendar, prezentarea primelor machete și convingerea că în câteva luni compania va folosi un sistem modern. La început totul pare promițător, dar în timp apar primele întârzieri. Termenul este amânat cu o săptămână, apoi cu o lună. Numărul erorilor crește, comunicarea cu furnizorul devine din ce în ce mai dificilă, iar răspunsurile următoare sună: "Mai avem puțin", "E doar o corecție minoră" sau "Suntem aproape de final."
Într-un moment se dovedește că în loc de un produs gata compania are un proiect neterminat pe care nimeni nu vrea să-l preia.
Acesta este un scenariu mult mai frecvent decât s-ar părea.
Cea mai mare problemă nu este codul
Majoritatea antreprenorilor presupun că dacă proiectul nu funcționează, vina o poartă codul scris prost. Da — uneori chiar așa este. În practică însă, mult mai des problema este mai profundă.
Lipsește documentația. Arhitectura a fost construită "pe parcurs". Nu există teste automate. Integrările au fost realizate provizoriu. Funcționalități noi au fost adăugate fără a analiza impactul asupra întregului sistem. Ca rezultat, chiar și o modificare mică cauzează alte erori.
E puțin ca o renovare a unei case fără proiect. Fiecare cameră poate fi terminată, dar în timp se descoperă că pereții nu sunt unde ar trebui, instalațiile sunt trase la întâmplare, iar reconstrucția devine tot mai costisitoare.
Când merită să spui "stop"?
Unul dintre cele mai grele momente pentru proprietarul unei companii este decizia de a întrerupe colaborarea cu furnizorul actual. Mulți antreprenori amână această decizie prea mult timp.
De ce?
Pentru că proiectul a consumat deja mulți bani.
Pentru că e păcat de timp.
Pentru că poate "mai reușește".
Psihologia numește asta efectul costurilor irosite. Cu cât am investit mai mult, cu atât ne este mai greu să recunoaștem că direcția actuală nu duce nicăieri.
Între timp, uneori cea mai bună decizie nu este să mai arunci bani în aceeași problemă, ci să oprești proiectul și să analizezi situația cu calm.
Poate fi salvat orice proiect?
Nu. — Și merită spus asta sincer.
Există proiecte a căror reparare ar costa mai mult decât reconstruirea lor de la zero. Se mai întâmplă, de asemenea, ca tehnologia folosită să fie deja depășită sau arhitectura gândită astfel încât să împiedice dezvoltarea ulterioară.
De aceea primul pas nu ar trebui niciodată să fie făgăduieli.
Primul pas ar trebui să fie un audit.
Abia după o analiză atentă a codului, documentației, infrastructurii și proceselor se poate răspunde la întrebarea dacă merită mai mult să repari soluția existentă sau să pornești un proiect nou.
Un partener tehnologic bun nu va spune ce vrea clientul să audă.
Va spune ce este mai bine pentru afacerea sa, din punct de vedere business.
Cum arată, în practică, salvarea unui proiect?
Contrar aparențelor, nu începe cu programarea.
Mai întâi trebuie să înțelegem cu ce avem de-a face.
Analizăm arhitectura sistemului, calitatea codului, modul de comunicare între module, securitatea datelor, performanța și posibilitățile de dezvoltare ulterioară. Verificăm documentația, istoricul modificărilor și tehnologiile folosite. Adesea deja după câteva zile se vede unde este problema reală.
Abia atunci se conturează un plan de acțiune.
Uneori este suficient să ordonăm codul și să corectăm câteva elemente cheie. Alteori este necesară reconstrucția unor module selectate. Se întâmplă și ca soluția cea mai rezonabilă să fie crearea unui nou sistem, folosind ceea ce s-a reușit deja să se pună la punct.
Nu există două proiecte identice.
La fel cum nu există o singură rețetă pentru salvarea lor.
De ce preluarea unui proiect este mai dificilă decât crearea unuia nou?
Aceasta este o întrebare pe care o auzim des de la clienți.
Răspunsul este simplu.
Creând un sistem de la zero, cunoaștem fiecare decizie de proiect. Știm de ce a fost aleasă o anumită soluție și care au fost ipotezele inițiale.
Preluând proiectul altcuiva, mai întâi trebuie să reconstruim acea cunoaștere.
E puțin ca și cum ai prelua construcția unei case după o echipă care a lăsat șantierul fără planuri, fără documentație și fără informații despre ce s-a realizat.
De aceea salvarea proiectelor necesită nu doar abilități de programare, ci și experiență arhitecturală, analitică și de proiectare.
Partenerul tehnologic ar trebui să fie alături de tine și când apar probleme
Un software house bun nu se recunoaște după modul în care începe un proiect.
Se recunoaște după modul în care reacționează când apar dificultăți.
Nu totul poate fi prevăzut. Cerințele de business, tehnologiile și nevoile utilizatorilor se schimbă. Cheia este dacă echipa poate găsi soluții, comunica clar riscurile și lua împreună cu clientul cele mai bune decizii.
Atunci se construiește încrederea.
Cum lucrăm la Web24?
Abordăm cu multă prudență proiectele care necesită preluare.
Nu facem promisiuni după prima discuție.
Mai întâi analizăm situația. Verificăm ce a fost realizat, ce se poate reutiliza și ce va necesita reconstrucție. Abia apoi pregătim recomandarea și planul de acțiuni.
Scopul nostru nu este să scriem încă mii de linii de cod.
Scopul nostru este să aducem proiectul în punctul în care începe să susțină cu adevărat dezvoltarea afacerii.
Rezumat
Dacă proiectul tău a rămas blocat, furnizorul a încetat să răspundă, calendarul există doar teoretic, iar corecțiile succesive generează alte erori, asta nu înseamnă încă că totul e pierdut.
În multe cazuri problema poate fi rezolvată.
Trebuie însă să începi cu un singur pas - o analiză serioasă a situației.
Pentru că înainte de a începe să salvezi proiectul, merită mai întâi să afli de ce a început să se scufunde.
