Bogdan Ionita, despre software, afaceri, Romania
Nov/09

5

Culmea managementului de proiect

/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 :)

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace

RSS Feed

4 Comments for Culmea managementului de proiect

elena | November 5, 2009 at 10:47 am

din experienta proprie, unica explicatie pentru o asemenea decizie as putea sa o asociez cu incheierea unor intelegeri de business la baza carora a stat in mod semnificativ si respectivul manual de utilizare. Altfel chiar e o “culme” demna de povestit :) )

Bogdan Ionita | November 5, 2009 at 11:37 am

da, dar in cazul acela firma probabil ar trebui sa ofere produsul gratis si ca ceara bani pentru manualul de utilizare :) )

Stefan Morcov | March 9, 2010 at 4:28 pm

Sună un pic la limita absurdului să faci un manual fără să vezi produsul. Nu au cum să nu existe diferenţe.

Dar sună a fast-tracking. Se practică. Uneori chiar trebuie făcut. Implică asumarea de costuri suplimentare şi rework pentru câştigarea de timp. Există şi metode de reducere a riskului (dar nu de evitare).

În primul rând, specificarea corectă; în al 2lea rând comunicarea intensivă între echipele diferite care lucrează în paralel la WP-uri care în mod normal se fac secvenţial.

Dacă a existat o specificaţie iniţială bine făcută, diferenţele ar trebui să fie minore între manual şi aplicaţie. Rezultă efort suplimentar de sincronizare – dar acceptabil, comparabil poate cu efortul de actualizare a unui manual de la o versiune de sistem la alta.

Concluzia mea este că specificaţia iniţială era vagă şi sistemul definit insuficient (notă: deşi mai sus scrie că specs erau clare…) (notă 2: se întâmplă şi aşa – dar în acest caz într-adevăr nu te apuci să faci fast-tracking).

Concluzia mea 2 este că autorul manualului nu a vorbit niciodată cu echipa de dezvoltare. Ca o mini-extrapolare, mă întreb dacă vreunul din cei doi au vorbit vreodată şi cu analistul de business :)

PS: doar de plăcerea root-cause analysis şi ca să fiu eu avocatul diavolului în sensul bun :) – poate manualul era corect şi aplicaţia era greşită. E un murphism incredibil de adevărat că orice program face ceva bun, dar nu întotdeauna (aş zice că de fapt foarte rar) ceea ce trebuia să facă. See validare vs. verificare.
Mă rog, nu am date suficiente, acesta este doar un joc ideatic.

Bogdan Ionita | March 9, 2010 at 6:28 pm

Corecte observatiile. Tot ce pot sa spun este ca acel produs inca nu este lansat nici acum, din aceleasi motive (uite produsul, nu e manualul si invers). Partea proasta e ca nimanui nu i se mai pare ciudat si s-a ajuns exact la concluzia din articolul meu initial: echipa de programare asteapta intai sa vada manualul si ignora specificatiile :D

Leave a comment!

« Jenson Button sau Ros Brawn?

Despre antreprenori si surse de inspiratie »

Theme Design by devolux.org

Norisor de etichete (sic!)

Comentarii recente:

To top