.jpg)
Academia Română a fost creată în 1866 pentru a cristaliza cele mai înalte valori intelectuale din provinciile românești într-o societate erudită menită să consolideze identitatea națională pe baza a patru componente esențiale: limbă și literatură, istorie, etnografie și cultură. La...
De ce esueaza implementarile software
4. Lipsa unei structuri/ierarhii clare de proiect. O structura clara de proiect permite ca proiectul sa fie perceput (atat din interior, de catre membri) cat si din exterior, ca un demers unitar (asa numitul „One Team”), ce manifesta coeziune si un sens clar de actiune. De asemenea, o structura clara pune în evidenta mecanismele de „escaladare” (ridicarea problemelor aparute în ierarhia proiectului si a organizatiei) în lipsa carora proiectul poate fi oprit de aparitia unor disensiuni pe chestiuni punctuale.
O structura de proiect pune de asemenea în evidenta rolul extrem de important al sponsorului proiectelor (care nu este numai personajul care semneaza si da banii, ci si cel care trebuie sa aiba rezolutia finala în toate problemele critice pentru evolutia proiectului).
5. Probleme legate de aplicatie. Nu, nu este vorba în mod necesar de erorile software (celebrele bug-uri), desi existenta acestora este un fapt cotidian în lumea software, un fapt care face zile amare multor programatori si consultanti. Paradoxal poate, dar cred ca bug-urile sunt o problema minora comparativ cu o alta clasa de probleme legate de aplicatiile software – si anume gradul de adecvare al aplicatiilor la verticala/specificul afacerilor clientului.
Am scris mai pe larg într-un articol anterior pe aceasta tema (a „aplicatiilor verticale”) – pe scurt însa este vorba de faptul ca foarte adesea aplicatii software „orizontale” (adica dezvoltate fara a tine cont de specificul vreunei afaceri anume) sunt vandute la companii care au cerinte critice extrem de speciale. Spun vandute si nu implementate, pentru ca (de exemplu) o aplicatie de productie care în mod normal modeleaza operatii de asamblare nu va putea fi niciodata implementata într-o companie din industria carnii, unde modelul de procesare este unul de „dezasamblare”. Rezultatul este asa numitul „shelfware”, CD-uri si manuale de software ce stau frumos aliniate pe un raft din biroul managerului IT, ca marturie a esecului proiectului în cauza.
In încheiere, trebuie spus ca nu mi-am propus ca lista de mai sus sa fie exhaustiva (exista studii ce inventariaza zeci de cauze de esec) si nici macar nu are pretentia de a fi o ierarhie a cauzelor – ea fiind pur si simplu rezultatul experientei personale de consultant, manager de proiect si vanzator de aplicatii (un fel de Top 5 personal). Mi-ar face placere sa stiu mai multe (pe adresa de e-mail de mai jos) despre experientele personale ale celor ce au citit acest articol...
Robert Komartin
Parerea ta conteaza: 
Informatizare in Tomania
