Dacă tocmai aţi câştigat un contract pentru mentenanţa sistemului cardului de sănătate, nu aveţi noroc, habar n-am de ce nu merge acest sistem, va trebui să vă descurcați singuri. Ceea ce vreau să discut este în general situaţia proiectelor mari de acest tip, nu acest caz particular.
Desigur, ne-am obişnuit ca sistemele implementate de stat, fie că e guvern sau instituţii subordonate, să meargă în general prost sau foarte prost. Este, evident, în mare parte rezultatul corupţiei; banii sunt cheltuiţi fără prea mare responsabilitate şi în final nimănui nu îi pasă. Dar acesta este doar răspunsul simplu; din păcate proiectele mari au tendinţa să eşueze şi în alte părţi, unde nu zic că nu există corupţie ( ba cum nu!) , dar măcar corupţii sunt un pic mai responsabili.
În general, eventualitatea ca un proiect să reuşească este benefică pentru cei care l-au promovat. Chiar dacă o parte din bani s-au dus pe panseluţe sau pe maşini de lux absolut necesare proiectului, dacă finalul este fericit există o probabilitate mare ca nimeni să nu mai întrebe cum şi de ce; nu că nu ar fi motive, ci pur şi simplu pentru că atenţia publică va fi deturnată de cele care nu reuşesc; cum astea sunt majoritare, e prea mult de lucru ca să le urmăreşti pe toate. Deci am zice că, în afară de varianta „tunurilor”, în care cei implicaţi fug în insulele Belize ( sau pe unde s-o mai fugi în ziua de azi) a doua zi după încasarea facturii, toată lumea îşi doreşte ca proiectul să reuşească. Totuşi, de cele mai multe ori proiectele se transformă într-un fel de mort viu care este ţinut „pe perfuzii” până la următorul proiect, la fel de prost, care îl va înlocui.
Prima problemă, despre care am mai scris de-a lungul timpului, este analiza insuficientă. Dacă, să zicem, când implementezi un ERP într-o companie cam ştii la ce să te aştepţi, cu mici variaţii , şi la final oricum vei avea o grămadă de retuşuri de făcut şi un număr de utilizatori mai mult sau mai puţin nemulţumiţi, un proiect inedit cum este cel al cardului de sănătate, pe care o să îl folosesc drept exemplu în continuare, este extrem de greu de analizat corespunzător. Beneficiarul de fapt nu ştie exact ce vrea ( ceea ce e oarecum normal) iar furnizorul încearcă să transpună într-un limbaj funcţional bruma de informaţii. E o dilemă din care nu cred că se poate ieşi decât prin sistemul „trial and error”. Adică o implementezi cum ţi se pare ok, vezi ce iese şi modifici până obţii un rezultat corespunzător.
Numai că acest sistem nu prea corespunde cu ciclul de implementare al proiectelor de la noi, majoritatea implementate pe fonduri europene. Asta cam presupune ca la un moment dat să „închizi” proiectul, semnezi recepţia, plăteşti factura şi o dai mai departe spre decontare. E puțin loc pentru partea de customizare ulterioară, mai ales că furnizorul, dacă ştie cam câtă muncă înseamnă nu prea e interesat de această fază şi va încerca să o „sară”. Dacă beneficiarul nu îşi dă seama, sau e „ajutat” să nu îşi dea, norocul furnizorului, sau, ca să citez din cineva: „ghinion”.
O altă problemă ar fi capacitatea tehnică. Chiar dacă firmele mai mari de IT de la noi şi de aiurea au destui programatori dintre care suficienţi sunt experimentaţi, o arhitectură de dimensiuni mai mari necesită o experienţă pe care foarte puţini o au. Din păcate, industria IT s-a diversificat puternic, domeniile s-au specializat foarte mult şi este greu să pui toate elementele laolaltă: soluţiile hardware, zona de reţea, disponibilitatea și diversele componente software.Să ne gândim doar că de la începerea până la finalizarea unui asemenea proiect, care se poate întinde pe câţiva ani, s-ar putea ca o tehnologie să fie complet înlocuită. Plastic vorbind, începi pe Windows 7 şi termini pe Windows10.
Problema capacităţii tehnice este cu atât mai dificilă cu cât s-ar putea ca nici măcar furnizorul să nu fie conştient de ea. Orice manager s-a obişnuit să îi dea o sarcină managerului de proiect iar acesta să se descurce. E mai degrabă o relaţie bazată pe încredere decât una bazată pe cunoaşterea competenţelor. S-ar putea ca managerul de proiect să fie grozav în alt domeniu decât cel de care ai nevoie; când construieşti proiecte unicat nu prea ai de unde să ştii.
Problema tehnologiei. Furnizorul va folosi, evident, tehnologia pe care o are în prăvălie. Dacă are programatori de Java, va lucra în Java, dacă e distribuitor Oracle, va construi proiectul pe baza de date a acestora. Acesta este în general un lucru bun, nu are rost să pui ursul să sară într-un picior dacă el aleargă bine în patru; pe de altă parte tehnologia respectivă s-ar putea să nu fie cea mai potrivită scopului, din diverse motive, din care unele ar putea fi mai întâi financiare însă vor deveni în curând tehnologice, pentru că vor limita resursele disponibile. Câteva observaţii pentru exemplul nostru: în general giganţii bazelor de date preferă soluţiile centralizate, ceea ce conduce la achiziţionarea unor echipamente cu performanţe monstruoase; evident pentru soluţii de acest tip o arhitectură distribuită, chiar dacă e mai complexă din punct de vedere software, duce la fiabilitate mai bună şi la preturi acceptabile pentru hardware. Vorba unui profesor de-al meu, „după cum vedeţi, centralismul nu e bun NICI în tehnică”.
Problema monopolului. Un proiect original va construi un monopol artificial pentru întreţinerea ulterioară. Dacă beneficiarul a reuşit să facă în aşa fel încât să nu ceară codul sursă, practic nimeni altul decât furnizorul nu se va putea încumeta la un contract de întreţinere ulterioară. Dar chiar şi dacă acel cod este disponibil, lucrurile sunt dificile pentru un eventual concurent, mai ales că documentaţia bine scrisă în IT e mai greu de găsit decât un politician bine intenţionat în Parlament.
Problema optimismului. Inginerii sunt optimişti prin definiţie. Dacă nu mă credeţi, mergeţi la Răzoare şi căutaţi plăcuţa cu „în trei ani aici va fi staţia ta de metrou”. Este pusă în 2009 cred. Dacă nu ar fi optimişti, nu s-ar mai apuca niciodată de vreun proiect. Din acest motiv, orice proiect durează mai mult decât este estimat; nu contează din vina cui. Într-o vreme, obişnuiam să înmulţesc cu doi orice estimare, dar asta nu m-a scutit totdeauna de surprize. Ca o consecinţă logică a acestui fapt, bugetul va fi aproape totdeauna depăşit, mai ales ca timp; software-ul va fi pus în funcţiune într-o fază incipientă şi bineînţeles va avea tot felul de probleme.
Problema adversarilor. Este utopic să crezi că un asemenea proiect va face pe toată lumea fericită. Evident unele persoane vor fi afectate de punerea în funcţiune a software-ului; cunosc cazuri în care angajaţi au refuzat ani de zile să introducă datele în aplicaţie; atunci când n-au mai avut încotro am aflat şi de ce. Alţii îşi vor pierde slujba, aşa cum a fost cazul cu centralistele din satul meu natal atunci când s-a înlocuit centrala manuală. Când s-a pornit softul din exemplul nostru, îmi amintesc de un farmacist care a sărit pe fereastră; poate a fost o coincidenţă, nu ştiu. În tot cazul, e bine să ştii că orice proiect are adversarii lui.
Citeste intreg articolul si comenteaza pe Contributors.ro
