marți, martie 19, 2024

De ce nu merge cardul de sănatate?

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.

Dar, cum spuneam, inginerii sunt optimişti prin definiţie şi încep mereu alte proiecte. Îmi vine să cred că şi Sisif tot pe la Politehnică a trecut….

Distribuie acest articol

26 COMENTARII

  1. Problemele apărute în România la sistemul informatic al cardul naţional de sănătate se repetă în Polonia, iar cauzele menţionate de domnul Badici în articolul său sunt identice la Varşovia.

  2. Si pe aici proiectele mari sunt o catastrofa, cu citiva ani in urma a fost catastrofa „vignettei” pt. camioane, s-au depasit termenele cu anii si budgetul. Mai nou Philarmonia din Hamburg, a costat de zece ori mai mult si a intirziat de asemenea. Dar cea mai penibila istorie e BER, aeroportul din Berlin, a inceput in 2006, trebuia sa coste 1 miliard, pina acum s-au cheltuit 6 Miliarde si nu se stie cind va fi gata. Sau Airbus A 400, sau americanul F 35.

    Un exemplu pozitiv e insa tunelul Gotthard, care s-a terminat mai repede si a iesit mai ieftin decit prevazut.

    Pe de alta parte e un mit ca numai proiectele de stat merg uneori prost. Exista si nenumarate proiecte de firme sau concerne private care sunt macelarite, dar despre astea se vorbeste mai putin.

    Se spune ca pur si simplu mintea omeneasca nu ar fi in stare sa coordoneze chestii atit de complexe. Si cind te gindesti ca Dumnezeu a reusit sa faca o lume intreaga in numai 6 zile!

    • Cred că tot la dumneavoastră în Germania e o catedrală care s-a terminat după vreo sută de ani, meşterul Manole a fost mult mai eficient la Curtea de Argeş :)
      Sigur că eşuează şi proiectele private, doar că alea ne privesc mai puţin dacă nu suntem implicaţi în ele. Am avut de-a face cu o cunoscută firmă de pantofi de sport care a migrat de la Scala la Navision si acum vor înapoi :) dar na, sunt banii lor, distracţia lor … insă în general firmele private îşi drămuiesc mai bine banii şi îsi iau măsuri si pentru „după”. In zona de stat, mai ales la noi, există si pericolul ca după ce vin „ceilalţi” să nu îti mai iei banii sau să se schimbe toţi funcţionarii din posturile cheie şi să nu mai ştie nimeni de unde a început proiectul…, dar cel mai rău e că nu e pe banii lor….
      Dumnezeu se pare că a reuşit pentru că a făcut totul singur, n-a avut nevoie de subcontractori sau furnizori :) Din păcate la noi e mai greu, că oricât am zice „să se facă lumină”… tot ai nevoie de un electrician pentru asta. Si oricum proiectul lui e si el departe de a fi perfect….

      • Sagrada Famila a inceput in 1882 si cica va fi gata in 2026… oare cum va fi Catedrala Neamului?

        Cind faceam proiectare ne-am hotarit sa modularizam, dar in asa fel incit un modul sa nu depaseasca 400 de repere, cam atit e capabil sa tina-n mina un proiectant. Si a functionat f. bine … pina cind s-au combinat modulele, intotdeauna intre ele erau probleme, la asa numitele Schnittstelle…

        Cica-n ziua de azi e f. greu de coordonat proiecte mari si pt. ca legile au devenit extrem de stufoase, imi imaginez ca la problema cardului de sanatate trebuiesc niste legi de protectia pacientului… asa cum aeroportul din Berlin a uitat sa se uite la legile contra incendiu!

        • Eu mă gândeam la domul din Koln, dar e bună si Barcelona :) La noi au fost „templele foamei” terminate în anii din urmă sub formă de Mall-uri, şi încă mai sunt din astea, ziduri părăsite şi neisprăvite… problema e că lucrurile nu depind numai de proiectare, mai depind si de finanţare, de politică, de ce se mai întâmplă prin lume ( mi-am adus aminte cum cumpăraseră rommânii o fabrică de lămpi când tocmai apăruseră tranzistorii…. )

        • Tare sunt curios cum naiba fac baietii aia care proiecteaza microprocesoarele din ziua de azi, cand creatiile lor au depasit miliardul de tranzistori! Pe schema dvs de modularizare la 400 de repere, mie imi ies trei niveluri de proiectanti, fiecare din ei cu cate 400 de subordonati…

          • La microprocesoare mai merge si cu copy/paste, tranzistorii aia fac parte din blocuri identice, de exemplu regiştri de memorie, ca e unul, ca sunt 100 tot aia e, presupun că planul de asezare pe siliciu nu il fac cu tuş la planşetă. De aia presupun că e vorba de 400 de repere diferite, că doar n-or consta proiectele doar în 400 de cuie identice :)

  3. Înainte de a se apuca de scris, programatorii pot fi detaşaţi câte o lună în diferite puncte de lucru, ca să înţeleagă cerinţele sistemului; vor şti cu mult mai mare acurateţe la ce trebuie să răspundă aplicaţia. Apoi, dezvoltarea modulară poate rezolva multe probleme ulterioare. În al treilea rând, dezvoltatorul aplicaţiei trebuie să ceară şi să fie receptiv la feedback din partea utilizatorilor.

    • „programatorii pot fi detaşaţi câte o lună în diferite puncte”
      Ei bine, sinteti indulgent :P o luna doar.
      Legenda de acum citeva zeci de ani spunea ca absolventii de drept din Japonia aveau primul an de serviciu asigurat: un an la puscarie ca „sa vada ce si cum”.
      „Ce si cum” vor da pedepsele in urmatorii ani.

  4. Din experenta mea personala (ceva tot in domneiul informaticii medicale)….
    aia care dintai se discuta habar nu au despre ce este vorba.
    Ala „manager” se sanatate habar nu are ce „se face” „mai jos” . Ei „stie” ce a vazut la televizor (Odisea spatiala , Terminator samd)
    Ala de la firma de informatica a cam legat la gard de ani de zile scrisu de cod. Ste ce vorbeste da nu prea stie unde se afla firma lui dpv al capcitatii (adica stii in gnl geografia cat sa ajungi la Braila .. da te afli la Urziceni si te crezi la Slobozia!!)

    In fine cand acordul partilor sa- realizat cineva dinsectiru medical este :condamnat: sa expllice analistului Partea proastra este ca nu stie ce „vrea” . Adica nu stie care este obiectul programului. Ca si le a vazut acelasi filme cu intigente artificiale … insa sa va spui un „mare secret” – nuel intocmeste raportarile! Si nicodata da niciodata nu esti pus sa discuti cu aia de la raportari. Ce naiba cum sa decida statiscinana in locul sefului de sectie? (Care este si aglomerat … si in gnl nu este dispus sa asculte parerile analistului)

    Sa nu uitam :pot aparea „frecusuri” intre manager (care a legat la gard de ani de zile .. asta daca a facut cumva un peorect de la cap la coada) atata de obisnuit ca managerului de proiect „să se descurce” si ii impune managerului de proiect o sarcina sa zicem „dubioasa” [adica poti face asa ceva insa rezulatele vor fi aleatorii ca forma de prezentare .. experenta proprie o saptamana poerduta]. Mai rau un ins cu exprienta in reralizarea proeictelor pot sa isidea seama rapid ca intra „in fundatura” si o zic. „Manager”ul face criza de personalitate …. gaseste alt manager de proiect care accepta (are mai putuina experenta) .. iese prost , se prelungesc termenele si ghici cine este de vina? Ala „batran” cu experenta !!!

    Cat despre cod sursa ….. un proect mare are multe linii . Si oricat de bume ar fi scisa documentatia … codul sursa depoinde intrisec de personalitatea celui care il scrie … Daca tu esti obisnuit sa mergi pe ramura de Then vei avea mici neplaceri depand codul unuia care mergea pe Else.. dar sunt si cestii si mai „grave” …. astfke incat ubnii ca considwere „imposibil” codul scris (f corect!) de altul . De exmplu unii considera „nebunie” sa „imbrici” vreo 7 If uri…. altii zic ca este „elegant”

  5. Exista solutii pentru arhitectura cardului nu trebuie noi sa reinventam roata: ce fel de model clinic informatic, cum sa il faci „future-proof” ca sa nu mai conteze daca e pentru Windows 7 sau 10, si mai ales standardele, vocabularele, terminologiile: ICD-10 sau SNOMED. FHIR sau HLA7.

    • Eu nu la „plastic” mă refer, plasticul merge. Problema e ca avem un intreg sistem, cu servere, cu baze de date, cu operatii decontate de casă şi operaţii nedecontate de casă ( urmăriti la medicul dvs de familie) cu calculatoare in fiecare cabinet…. Aici sunt problemele majore, nu la standardele de stocare sau la cititoarele de carduri.

      • Ma-ntreb daca nu e mai simplu pur si simplu sa se cumpere un sistem existent. Asemenea sisteme exista in muilte tari din lume, nu vad de ce trebuie reinventata roata, o simpla traducere ar fi absolut suficienta.

        • Nu m-am interesat in cazul asta specific, dar presupun că nu există prea multe implementări (sunt sub 200 de ţări parcă la ONU, si nu toate au sistem de sănătate centralizat) si probabil toate sunt „artizanale” .

          • Un exemplu de sistem centralizat de sanatate (health card) ar putea fi cel din Canada la nivel de provincie (de peste 10 milioane de locuitori) dar si la inter-provincial care functioneaza bine merci.

  6. Am avut ocazia sa vorbesc cu niste oameni care au lucrat in proiect si am avut si experienta impelementarii de asemenea proiecte. Da, probleme mentionate sunt reale … la un nivel superficial. Cauzele sunt mult mai simple: lipsa de expertiza la beneficiar si la castigatorul contractului.

    Beneficiarul nu are experienta de nici un fel ca sa scrie cerinte functionale. Ei au idee ce vor, dar nu stiu sa o formalizeze sau sa o valideze (cu utilizatorii, in primul rand). Pentru ca, fara nici o intentie de a jigni, in contractele in care beneficiarul e statul decidentul e un politruc incompetent si „informaticienii” sunt ratatii care nu si-au gasit ceva mai bun de facut pe o piata care plateste orice om decent de cateva ori mai bine decat statul. O un domeniu care necesita inalta calificare, in care un analist sau un arhitect software bun castiga mai mult decat un ministru. Pentru ca ei au competente formate in zeci de ani, nu la sedintele de partid.

    De partea furnizorului nu exista experienta. Da, exista experti, dar nu ii baga nimeni in proiecte cu statul, ca nu e nevoie: daca oricum specificatiile sunt dupa ureche si estimarile de cost umflate cu un ordin de marime, ca sa acopere orice nevoie care apare, e mai simplu sa iei echipe de incepatori platiti prost care sa scrie cod de proasta calitate decat sa iei experti care sa faca ceva eficient. De obicei asta pana se apropie termenul de predare si nu exista mai nimic, atunci cheama expertii care in 2 luni pun pe picioare ceva la care se lucra de 2-3 ani, dar in alea 2 luni fac si ei minimul posibil pentru ca proiectul pe bune ar fi necesitat 1 an cu experti.Tot ce conteaza e sa aibe suficiente functionalitati incat sa il accepte beneficiarul, cu promisiunea ca se rezolva pe parcurs problemele observate din start: de-aia e nevoie de contracte de mentenanta scumpe.

    In Romania si in multe tari exista experti in IT. Mai buni decat e nevoie pentru un asemenea sistem, dar sunt destul de rari si costa mult, pentru ca o asemenea expertiza se aduna in 10-15 ani de munca grea si invatat continuu, ceea ce omul de rand nu face. Si din mitul IT-ului romanesc o mare parte e efectul de halo al expertilor si a muncii lor, nu a marii mase de amatori cu ifose. In asemenea proiecte e nevoie de experti in procese, in interfete utilizator si uzabilitate, in arhitecturi de date, in baze de date (DB Administrators), in quality assurance, testing (test driven development suna cunoscut?), de front end developers, de specialisti in retele; ce companie in genul celor care castiga contracte cu statul au asemenea experti? Nici una, apeleaza la contractori cand le ajunge cutitul la os, dar pana se intampla asta pierd vremea cheltuind aiurea banii din contracte cu programatori „full stack” de 3000 de lei bucata.

  7. “programatorii pot fi detaşaţi câte o lună în diferite puncte”
    1. Depinde si metodilogia de implementare. In ultimele 2 proiecte am lucrat in echipe mixte. In acest fel implementatorul benefeciaza de cunostintele din interior iar, dupa finalizarea proiectului, beneficiarul are suportul tehnic necesar.
    2. Proiectul trebuie sa fie dorit cu ardoare de catre beneficiar, aduca sa nu fie doar un proiect pentru a arde niste bani europeni.

  8. Aceste disfunctionalitati, cam dese (unele inerente), nu cumva sint „gindite” si folositoare cuiva, undeva?
    Intreb, nu acuz.
    Intreb gindind la afirmatia lui @ Stefan S : „2. Proiectul trebuie sa fie dorit cu ardoare de catre beneficiar” nu doar pentru „a arde niste bani europeni”.

    • Eu personal nu am informatii din cercurile respective; ca principiu am „bifat” şi faptul că orice proiect are si adversari. As putea bănui că, de exemplu în cazul nostru o parte din funcţionari au anumite interese într-o zonă politică, alţii în alta dar din moment ce s-a pus in functiune înseamnă că „s-a dorit”, există şi proiecte care nu s-au pus in funcţiune, sau s-au pus doar pe hârtie… „Cu ardoare” n-aş putea spune, cum ziceam, nu sunt banii lor, e mai bine să meargă decât să nu meargă, că nu mai punem atâtea întrebări, dar dacă nu merge n-o să devină depresiv nici un funcţionar, asta vă garantez :)

  9. Poate un alt mecanism de plata ar motiva implementarea unor proiecte mai bune: abonamentul.

    Firma care implementeaza proiectul nu ia grosul banilor din implementarea in sine ci tocmai din intretinerea periodica si care presupune si modificari / actualizari. Asta inseamna ca in cazul in care le face corect va avea un cashflow predictibil pe urmatorii 10-20 ani fara prea multa munca.

    • Da, dar de asta ziceam că in general proiectele noastre fiind pe fonduri europene trebuie să se cam incadreze intr-un exerciţiu bugetar. Iar noi oricum suntem mereu cu cel putin doi ani in urmă cu aceste exerciţii…

  10. O sa mai dureze vreo 10-15 ani cred, pana o sa inceapa sa functioneze cat de cat bine aceste sisteme. Oricum nu vor fi finalizate niciodata, ele se vor perfectiona, evolua, modifica si renaste continuu. E utopie sa crezi ca un ciocan nu poate fi reinventat, sau ai cumparat un automobil si il vei lasa mostenire stranepotilor. Ei ar trebui sa contracteze sistemul ca serviciu nu ca produs.

  11. bineee … da’ avem si noi o „stakeholders’ analysis”, cu strategii de „atac” pe fiecare categorie?

    metodologia PMI recomanda, in faza de initiere, sa se faca „analiza beneficiarilor”, clasarea in diverse categorii (pro, neutri, anti – proiect) si sa se schiteze niste „strategii” (stiu, e mult spus, da’ ofera imaginea completa) pentru mentinerea si/sau atragerea de „partea buna a fortei” …

  12. În cazul proiectelor/sistemelor cu care am avut ocazia să mă intersectez am constatat următoarele:

    – în „echipa proiectului„ au fost cerute cele mai firești dar și cele mai exotice certificări. Doar pentru a „securiza„ proiectul
    – caietele de sarcini/cerințele sînt scrise de parcă cineva de la beneficiar a mai lucrat la cel puțin încă „n„ proiecte de același tip.
    – specificațiile tehnice emanate de către benficiar sînt fix pe tehnologia X.
    – în cadrul proiectului, achiziția echipamentelor se face înainte de finalizarea etapei de analiză.
    – în nici un contract nu a existat o clauză de „software escrow„

    Exemplu: într-un proiect care însumează 520 de zile, etapa de analiză a fost de …49 de zile :).

    Puține dintre proiectele IT publice au fost gîndite cu scopul de a rezolvă o problemă/problemele organizației.

  13. Am vazut un proiect de sanatate implementat. O companie de sanatate cu 4 milioane de clienti a inceput acest proiect acum 20 de ani. Responsabil pe proiect (beneficiar) a fost pe tot parcursul proiectului un singur om. In fiecare etapa proiectul trebuia sa fie functional altfel nu primeau o treime din bani. Bag-urile erau reparate pe banii proiectantului. Cerintele proiectului erau definite clar de la inceput si supuse licitatiei. Dupa primii cinci ani au simtit nevoia modernizarii si actualizarii programului. Acum programul este la un nivel foarte inalt (de vis) atit pentru medici, farmacisti si pacienti. Programul coordoneaza datele la un nivel de prelucrare automata pentru elaborarea de retete (in baza protocolului de tratament), mentinerea unui stoc de medicamente si consumabile in limite stabilite, pentru prescrierea si prelucrarea analizelor. Privind in urma, programul a pornit de la premize gresite care au marit costurile: au folosit sistemul de operare Windows care a evoluat, si a impus actualizari in masa pentru timpi scurti. In cazul caderi retelei sistemul de sanatate este blocat. Este drept ca au fost rare cazurile, dar trebuiesc luate in calcul .

  14. Din reacțiile la acest articol înțeleg doua aspecte;

    – softul nu este o autostrada așa ca la un control se spune așa – este pe aici pe undeva dar nu merge ca nu s-a plătit licența. Fiind bani grămadă interesul este sa nu meargă ca sa se semneze adiționale;
    – deși la toate marile aplicații IT din lume lucrează dezvoltatori romani, la noi aceiași romani au manageri corupți care nu-i lasă sa facă cum trebuie; Dovada este ca au fost puși sa posteze!

    Uite așa am ajuns de rasul lumii! Afara facem aplicații care merg iar in tara se scurg miliarde de euro pe aplicații care nu merg. Este de fapt realitatea cruda la cat de pricepuți sunt miniștrii politici. La tehnocrați se poate pe gratis iar la politicieni nu se poate cu căruțe de bani (la educație, sănătate, la BNR, la agricultura, la finanțe, etc). Dragnea poate fi mândru de miniștrii săi!

LĂSAȚI UN MESAJ

Vă rugăm să introduceți comentariul dvs.!
Introduceți aici numele dvs.

Autor

Mihai Badici
Mihai Badici
Absolvent al Facultății de Electronică si Telecomunicații București ( 1991) Administrator de sistem cu peste zece ani de experiență cu specializari in sisteme de stocare si securitatea datelor. De asemenea a absolvit in 1996 Facultatea de Litere la Universitatea Bucuresti. In prezent, consultant IT independent, colaboreaza pe mai multe proiecte legate de infrastructura de date.

Sprijiniți proiectul Contributors.ro

Pagini

Carti noi

 

Cu acest volum, Mirel Bănică revine la mai vechile sale preocupări și teme de cercetare legate de relația dintre religie și modernitate, de înțelegerea și descrierea modului în care societatea românească se raportează la religie, în special la ortodoxie. Ideea sa călăuzitoare este că prin monahismul românesc de după 1990 putem înțelege mai bine fenomenul religios contemporan, în măsura în care monahismul constituie o ilustrare exemplară a tensiunii dintre creștinism și lumea actuală, precum și a permanentei reconfigurări a raportului de putere dintre ele.
Poarta de acces aleasă pentru a pătrunde în lumea mănăstirilor o reprezintă ceea ce denumim generic „economia monastică”. Autorul vizitează astfel cu precădere mănăstirile românești care s-au remarcat prin produsele lor medicinale, alimentare, cosmetice, textile... Cumpara cartea de aici

Carti noi

În ciuda repetatelor avertismente venite de la Casa Albă, invazia Ucrainei de către Rusia a șocat întreaga comunitate internațională. De ce a declanșat Putin războiul – și de ce s-a derulat acesta în modalități neimaginabile până acum? Ucrainenii au reușit să țină piept unei forte militare superioare, Occidentul s-a unit, în vreme ce Rusia a devenit tot mai izolată în lume.
Cartea de față relatează istoria exhaustivă a acestui conflict – originile, evoluția și consecințele deja evidente – sau posibile în viitor – ale acestuia. Cumpara volumul de aici

 

Carti

După ce cucerește cea de-a Doua Romă, inima Imperiului Bizantin, în 1453, Mahomed II își adaugă titlul de cezar: otomanii se consideră de-acum descendenții Romei. În imperiul lor, toleranța religioasă era o realitate cu mult înainte ca Occidentul să fi învățat această lecție. Amanunte aici

 
„Chiar dacă războiul va mai dura, soarta lui este decisă. E greu de imaginat vreun scenariu plauzibil în care Rusia iese învingătoare. Sunt tot mai multe semne că sfârşitul regimului Putin se apropie. Am putea asista însă la un proces îndelungat, cu convulsii majore, care să modifice radical evoluţiile istorice în spaţiul eurasiatic. În centrul acestor evoluţii, rămâne Rusia, o ţară uriaşă, cu un regim hibrid, între autoritarism electoral şi dictatură autentică. În ultimele luni, în Rusia a avut loc o pierdere uriaşă de capital uman. 
Cumpara cartea

 

 

Esential HotNews

contributors.ro

Contributors.ro este intr-o permanenta cautare de autori care pot da valoare adaugata dezbaterii publice. Semnaturile noi sunt binevenite cata vreme respecta regulile de baza ale site-ului. Incurajam dezbaterea relaxata, bazata pe forta argumentelor.
Contact: editor[at]contributors.ro