/rant

Din 1998 de cand am pornit prima afacere in software, cred ca am fost implicat in cateva sute bune de proiecte de toate felurile. Uneori ajung pe cate un site si imi ia ceva timp sa-mi dau seama ca respectivul produs a fost facut de noi. Credeam ca am vazut cam tot ce se putea in materie de management al proiectelor software: lipsa de specificatii, modificarea modificarii, feature-uri absurde, deadline-uri de toate marimile si bugetele, sedinte inutile, proiecte copiate, produse finalizate dar necomercializate vreodata, update-uri ce “trebuiau” sa fie neaparat facute in noaptea de revelion, produse cu asteptari aiuristice, programatori ‘problema’ si tot asa.

De o vreme sunt implicat intr-un proiect foarte interesant legat de Digital Rights Management. Ideea respectiva e excelenta, dar ca in multe cazuri practica te omoara. Recent am dat peste ceea ce consider a fi absurditatea maxima in materie de project management. Pe scurt, avem asa:
- specificatiile proiectului: nimic extrem de detaliat, dar indeajuns de clare si de discutate (nu exagerez, 2 ani sunt putini) incat sa stii unde trebuie sa ajungi. In paranteza fie spus, nici nu sunt adeptul specificatiilor facute la sange, mai ales daca nu vorbim de software la comanda (le consider a fi echivalentul unui business plan pe care decizi sa il urmezi litera cu litera, desi e clar ca afacerea a luat-o intr-o directie gresita);
- dezvoltarea proiectului: “se face sefu, pai se poate altfel?”
- in paralel cu dezvoltarea proiectului, fara sa anunte, CEO-ul (atentie, numit de VC) decide sa nu se iroseasca timp asa ca se incepe lucrul si la continutul siteului, al materialelor promo si al continutului manualului de utilizare;
- se ajunge cu proiectul intr-o faza alpha, tocmai bun de testat piata cu el.

Toate bune si frumoase pana aici, doar ca in mod evident produsul nu corespunde cu manualul. Nici nu ar fi avut cum, din moment ce manualul a fost facut nu dupa produs, ci dupa interpretarea specificatiilor din partea unuia sau altuia. E firesc sa fie asa: daca eu ma apuc si povestesc la 2 persoane cum arata casa mea, fara ca ele sa fi vazut casa, iar apoi le pun sa o deseneze, garantat o sa fie diferente semnificative in interpretarea fiecarei persoane.

Stupoare: CEO-ul decide ca produsul sa fie modificat astfel incat sa se pupe cu manualul ))) Nu, produsul nu era prost gandit/dezvoltat sau neconform cu specificatiile, ci doar neconform cu manualul de utilizare. Tot ce pot sa spun e ca ma bucur ca n-am acceptat sa particip ca investitor.

Asa ca atentie dezvoltatorilor de software: inainte de a va apuca de programare, cititi manualul de utilizare al produsului pe care urmeaza sa-l dezvoltati