Unul dintre primele lucruri pe care le afli atunci când citeşti un articol sau o carte despre gestiunea proiectelor din IT este acela că proiectele informatice se deosebesc foarte mult de toate celelalte proiecte. Chiar și atunci când subiectul principal este legat de gestiunea proiectelor în general, se fac referiri directe cu privire la ineficienţa anumitor metode atunci când avem de-a face cu proiecte software. Din păcate nu este întotdeauna explicat în ce costau acele deosebiri şi se insistă mai degrabă pe a descrie soluţii, mai mult sau mai puţin eficiente. Articolul de faţă îsi propune să evidenţieze şi analizeze principalele aspecte caracteristice proiectelor informatice.
Unul dintre cele mai intens citate rapoarte statistice cu privire la succesul proiectelor informatice este Standish Group Chaos Report, care an de an publică rezultate procentuale ce evidenţiază ponderea proiectelor finalizate cu succes, a celor eşuate precum şi a celor care au întâmpinat dificultăţi majore până la finalizare. Criteriile care stau la baza acestui raport sunt foarte simple şi se referă ca scop, timp şi bani, sau mai precis la:
Proiectele de succes erau considerate acelea care respectau cu brio toate aceste criterii, cele eşuate erau cele care se stopau fără a mai fi finalizate din cauza nerespectării unuia sau mai multor criterii, iar cele finalizate reprezentau proiectele care au fost până la urmă terminate, rezultatul proiectelor fiind implementat cu condiția reevaluări și ajustării în mode semnificativ a unora dintre criterii.
Tabelul următor prezintă câteva dintre rezultatele raportului de-a lungul timpului, începând cu rezultatul "şocant" din 1994, ce relevă o rată de succes extrem de scăzută, şi până aproape de zilele noastre. Şi această statistică vine să confirme existenţa unei diferenţe evidente între proiectele informatice şi celelalte proiecte, un procent de eşec de 20-30% fiind de neconceput în vreunul dintre celelalte domenii, de la cel al construcţiilor de clădiri sau maşini până la servicii medicale.
| An | Succes | Finalizat | Eşec |
| 1994 | 16% | 53% | 31% |
| 1996 | 27% | 33% | 40% |
| 1998 | 26% | 46% | 28% |
| 2000 | 28% | 49% | 23% |
| 2002 | 34% | 51% | 15% |
| 2004 | 29% | 53% | 18% |
| 2007 | 35% | 46% | 19% |
| 2009 | 32% | 44% | 24% |
Desigur că se poate discuta mult pe marginea acestor statistici şi a relevanţei lor. Pentru că "proiect informatic" este un termen care acoperă un spectru destul de larg şi eterogen de proiecte, e neclar ce fel de proiecte au fost luate în considerare. Între anii 1994 şi 2000 de exemplu, s-au studiat în jur de 30000 de proiecte informatice doar din Statele Unite ale Americii. Pentru 2004 raportul precizează că au fost luate în considerare peste 50000 de proiecte din întreaga lume (58% SUA, 27% Europa, 15% rest), cei de la Standish Group International asigurându-ne că s-a respectat un echilibru între numărul proiectelor mici, medii şi mari.
În altă ordine de idei, este destul de restrictiv să măsurăm succesul unui proiect luând în considerare doar criteriile scop, timp şi ban. Calitatea produsului sau a serviciului rezultat reprezintă la rândul său un criteriu important. De asemenea, există proiecte care nu au respectat cele trei criterii, dar care au fost considerate de către organizaţiile în care s-au desfăşurat ca fiind de mare success pentru că au atras ulterior noi proiecte importante, după cum există şi proiecte ce au excelat în toate cele trei direcţii însă presiunea exercitată a făcut ca echipa de proiect să se destrame rapid după terminarea proiectului pierzându-se experienţa şi expertiza câştigată în domeniul proiectului respectiv.
După cum se poate observa şi din graficul următor, în 2012 raportul vine cu informaţii agregate pe diferite tipuri de metodologii utilizate în gestionarea proiectelor. Aşa cum era de aşteptat, metodologiile Agile ameliorează simţitor numărul de proiecte eşuate, însă ele nu pot fi aplicate cu success pentru toate tipurile de proiecte informatice.
Dar ne-am îndepărtat destul de mult de scopul declarat al articolului. Ce am dorit să subliniem până la acest punct este doar că există diferenţe notabile între proiectele informatice şi celelalte tipuri de proiecte şi că aceste diferenţe par a influenţa negativ succesul acestora. În cele ce urmează le vom descrie pe cele mai importante.
Din fericire sau din păcate (în funcţie de perspectiva din care privim lucrurile), activitatea de dezvoltare a softului este una creativă. Nu există, aşa cum se întâmplă în cazul altor activităţi, un nomenclator care să precizeze care este timpul uzual necesar pentru implementarea unei ferestre ce conţine, să zicem, două liste derulante, un grid şi două butoane. În ciuda dezvoltării de instrumente sofisticate de generare automată a codului sau de implementarea diverselor biblioteci de clase sau framework-uri, fiecare proiect nou vine cu provocările proprii în ceea ce priveşte creativitatea.
Un exemplu edificator în acest sens este dat în cartea "The Healthy Software Project: a guide to successful development", (1993, autori M. Norris, P. Rigby, M. Payne) care face un experiment chestionând un număr de 44 de experţi în legătură cu numărul de instrucţiuni care apar în codul de mai jos:
#define LOWER 0
#define UPPER 300
#define STEP 20
main()
{
int fahr;
for (fahr=LOWER; fahr<=UPPER; fahr=fahr+STEP)
printf("%4d %6.1 f\n", fahr, (5.0/9.0*(fahr-32)))
}Răspunsurile acestora cuprind toate numerele între 1 şi 9 inclusiv (11 experţi au răspuns 6, alţii 11 au răspuns 9, restul alegând ca răspuns un alt număr din interval)! Concluzia este imediată: dacă nişte experţi în domeniul software nu reuşesc să cadă de acord asupra unei întrebări simple pe baza unui program de 9(!) linii, înseamnă că este de aşteptat ca estimările într-un proiect software să difere foarte mult de la o persoană la alta, aceste estimări având o relativ restrânsă legătură cu experienţa acumulată.
O practică uzuală este aceea ca estimările date (atunci când este vorba de estimări de timp şi nu în puncte de complexitate) să fie mărite cu 20% de către project manager înainte ca ele să fie transmise către client, pentru a se asigura o oarecare "linişte" (deşi sunt situaţii în care acest 20% este departe de a fi suficient).
O altă consecinţă directă a acestui aspect o reprezintă dificultatea gestionării schimbărilor într-o echipă de proiect, persoanele care vor înlocui anumiţi membri ai echipei rareori respectând estimările date de aceştia.
Şi pentru ca lucrurile să fie "complete", pentru multe dintre activităţile estimate este foarte dificil de controlat progresul. Cele mai reprezentative exemple aici sunt activităţile de analiză şi proiectare unde putem ştii când s-au terminat aceste activităţi, dar nu vom putea specifica dacă la un moment dat ne aflăm la 50% la 75% din activitatea respectivă.
Rezultatul muncii unei echipe ce dezvoltă un produs informatic este compus dintr-o colecţie de "texte" de diferite tipuri: documente de analiză şi proiectare, cod sursă, manuale de utilizare şi operare etc. Doar o parte dintre acestea interesează sau au vreo semnificaţie pentru cei care vor utiliza produsul.
Clientul final tinde să evalueze un produs informatic după ceea ce vede, şi ceea ce vede este în general o interfaţă grafică cu utilizatorul.
Deoarece nu există nimic concret de arătat clientului în faza de analiză a cerinţelor, acesta îşi formează o imagine proprie asupra rezultatului final care de cele mai multe ori nu se potriveşte cu produsul dezvoltat. În plus, există tendiţa de a include în cadrul specificaţiilor elemente care reprezintă mai degrabă dorinţe decât nevoi reale de business. Se ajunge astfel într-un punct caracterizat de un grad ridicat de frustrare, în care echipa de proiect ştie că a dezvoltat conform specificaţiilor funcţionale dar clientul nu poate utiliza aplicaţia finală pentru că nu este ceea ce şi-a imaginat că va fi. Acest rezultat poate fi ameliorat prin prezentarea unuia sau mai multor prototipuri în fazele timpurii ale dezvoltării produsului, însă clientul nu va face întotdeauna diferenţa între acestea şi produsul final crezând că nu s-a depus un efort semnificativ între timp, interfaţa cu utilizatorul rămânând aproape neschimbată.
Tot din cauza invizibilităţii softului şi implicit a complexităţii acestuia, cerinţele iniţiale par foarte uşor de modificat şi implementat în cadrul unei aplicaţii.
Fără doar şi poate produsele software au o structură extrem de complexă. Într-o aplicaţie de dimensiuni medii există extrem de multe conexiuni între diverse elemente software care fac aproape imposibilă testarea şi validarea completă a acestora. Un exemplu simplu în care folosim nouă condiţii succesive intercalate poate rezulta într-un număr impresionant de căi posibile care trebuie testate fiecare în parte pentru o validare completă. Acest lucru însă ar putea să nu fie realizabil nici într-o săptămână, chiar dacă testul fiecărei căi ar dura o secundă. Mai mult, aceste teste ar trebui reluate de fiecare dată când se face o modificare. Prin urmare multe dintre bug-uri persistă o vreme îndelungată (chiar ani de zile) într-o aplicaţie până să fie descoperite sau, mai rău, până să îşi arate efectele.
După cum se spunea în aceeaşi carte menţionată anterior, "The Healthy Software Project: a guide to successful development": "...în cazul proiectelor software aşa numitele proceduri de control al calităţii au uneori de-a face mai degrabă cu limitarea defecţiunilor decât cu garantarea calităţii produsului final." Şi acest lucru a rămas valabil şi în 2012, în ciuda tuturor metodologiilor moderne de dezvoltare a softului apărute în ultimii ani.
Complexitatea softului este dată şi de numărul de tranziţii şi "traduceri" ce trebuie realizate între fazele ciclului de viaţă al unui produs. Specificaţiile funcţionale (redactate în limbaj natural) sunt translatate într-un model de analiză (diagrame vizuale care modelează toate soluţiile posibile ale problemei enunţate în specificaţii), care ulterior este translatat într-un model de proiectare (unde se particularizează modelul de analiză pentru o soluţie specifică), care mai apoi este translatat în cod sursă, acesta din urmă fiind translatat într-un model executabil (prin compilare sau interpretare). Tot acest lanţ de translatări, în ciuda faptului că anumite tranziţii sunt automatizate, face procesul de dezvoltare a softului mult mai vulnerabil la erori umane. Acest lucru este cauzat de greşeli de "traducere" sau prin persistarea erorilor nedescoperită la timp în fazele de specificare sau analiză până în modelul executabil.
Dinamismul cu care se confruntă proiectele software se manifestă în trei direcţii relevante. Pe de o parte există atracţia noutăţii tehnologice. Ştim că tehnologia avansează foarte rapid şi an de an apar biblioteci şi framework-uri noi, şi versiuni îmbunătăţite ale limbajelor şi mediilor de dezvoltare. Din punct de vedere al unui project manager, păstrarea framewok-urilor iniţiale în care a fost dezvoltat un anumit soft este o condiţie elementară de păstrare a stabilităţii acestui soft. Pe de altă parte nu trebuie ignorată apetenţa echipei pentru a lucra cu ultimele tehnologii (inerent mai instabile şi cu neajunsuri încă nerezolvate sau nediscutate pe forumurile de specialitate). Există un efort constant şi care nu trebuie neglijat, de păstrare a unui echilibru între stabilitate şi eliminarea unui sentiment de plafonare a echipei de dezvoltare.
A doua direcţie ce conferă dinamism proiectelor software este fluctuaţia personalului, care în domeniul IT este foarte ridicată. O fluctuaţie "sănătoasă" pentru o organizaţie se situează undeva în jurul a 10 procente. Un studiu realizat de Ziarul Financiar arată ca în domeniul IT în România fluctuaţia de personal este la nivelul de 20%, şi ea nu se datorează în principal nivelului de salarizare (cum este în cazul altor domenii) ci diferenţelor de cultură şi a sentimentului de nerealizare profesională. Efectele acestei fluctuaţii, după cum subliniam şi în secţiunea 1, constau în reconsiderarea planificărilor anterioare şi de adaptare a noilor veniţi la proiect. Nu trebuie însă neglijată tendinţa noilor veniţi de a respinge codul scris de predecesorii lor, încercând uneori chiar să îşi asume responsabilitatea înlocuirii complete a acestui cod, acţiune ce conduce la anularea validărilor anterioare.
În fine, o dinamică aparte faţă de alte proiecte o au cererile de modificare frecvente venite din partea clientului în diverse faze ale ciclului de viaţă a dezvoltării unui proiect software. Această caracteristică a proiectelor software a condus la dezvoltarea medologiilor Agile care includ acest aspect ca pe o componentă activă a procesului de dezvoltare.
Am încercat să evidenţiem unele dintre aspectele care considerăm că diferenţiază în mod clar proiectele software de alte proiecte existente şi care au o contribuţie decisivă în situarea acestor proiecte pe un loc fruntaş în topul eşecurilor pe tipuri de proiecte.
Desigur că alături de dificultăţile de măsurare, invizibilitatea, intangibilitatea, complexitatea, şi dinamismul proiectelor software, există şi alte aspecte specifice. De exemplu, sporirea resurselor într-un proiect software întârziat nu elimină decalajul ci sporeşte întârzierea, deoarece capacitatea de efort a membrilor echipei scade cu o cantitate egală cu efortul de comunicare cu noul membru. Aceste lucruri nu se întâmplă în marea majoritate a proiectelor în care se desfăşoară cu preponderenţă activităţi de rutină.
Scopul articolului nu a fost acela de a emite soluţii de gestionare a particularităţilor, acestea putând contitui subiectul unui viitor articol. Cu siguranţă însă, categoria metodologiilor Agile de dezvoltare a softului are în vedere o bună parte a acestor particularităţi.
Nu dorim să încheiem articolul fără a pune o întrebare firească ce rezultă în urma acestei analize: "Cum se face că, în pofida tuturor acestor neajunsuri, industria software rezistă şi chiar înfloreşte?" Răspunsul este unul optimist, ce se referă la beneficiile aduse de rezultatele proiectelor software şi a necesităţii acestora. Fără doar şi poate, aplicaţiile software au menirea de a ne face viaţa mai simplă într-o multitudine de aspecte ale vieţii cotidiene. Chiar dacă uneori ele se blochează sau funcţionează eronat, le acceptăm, trecem cu uşurinţă peste multe dintre aceste erori sau găsim căi de ocolire a lor deoarece avantajele obţinute pun în umbră aceste neajunsuri.