ai atins un punct sensibil, pentru ca partea tehnica are contra-argumente si mai dureroase. da, proiectele ies de cacat atunci cand cel care le cere / coordoneaza este un idiot sau nu stie sa ce sa ceara si asta este cruda realitate de care ei se lovesc mai des.
considerand tonul in care au fost scrise as zice ca te-ai lovit de curand de proiecte ce tine de web / online… soft-ul corporate e uneori intr-o situati mai buna, alteori intr-o situatie chiar mult mai proasta :).

2 chestii pe care tot managerii ar trebui sa le stie:
– trebuie investit intr-un arhitect de solutii competent cu experienta in spate in domeniul respectiv. tehnicul va face o aplicatie pe care sa o inteleaga doar ei, nu oamenii obisnuiti, iar testarea primeste ceva care nu mai poate fi schimbat decat cu eforturi masive si este pusa intr-o situatie de a se multumi cu ce exista ca altfel “nu mai vine banul”
– in romania nu se investeste si in calitate, se pune accent pe dezvoltare – solutie care se doveste “distractiva” mai putin pentru investitor si client. aplicatia nu e testata din primele etape si ok-ul se da cu jumatate de gura, ii cunosc doar pe programatori, merg la bere impreuna…

7. Corectitudinea estimarilor depinde de claritatea si completitudinea specificatiilor si de cat de mult sunt schimbate pe parcurs. Nu sunt posibile specificatii perfecte si uneori se impun schimbari pe parcurs; dar atunci acceptati faptul ca automat proiectarea initiala trebuie ajustata si ca va exista un impact.

6. Este un caz particular al problemei 7. Un backend de calitate este mult mai flexibil si permite mai multe features pe frontend. Dar trebuie sa se aloce initial timp suficient pentru a fi proiectat si creat, iar specificatiile trebuie sa fie robuste. Daca se lucreaza exagerat de mult la backend inseamna ca (a) specificatiile de baza variaza anormal de des; si/sau (b) nu s-a investit suficient timp in faza de proiectare a backend-ului, s-a facut o carpeala care trebuie peticita si ajustata permanent.

5. Cateodata trebuie sa cumperi anumite solutii. Nu toti oamenii din IT produc snake-oil. Unii produc lucruri valoroase, stiu ca sunt valoroase si le vand la un pret corespunzator. Exemplu: cand graficianul cere Photoshop, i-l cumperi.

4. Mirajul refacerii de la zero este un viciu al oamenilor tehnici. Este atractiv pentru ca le permite sa proiecteze o solutie completa, un exercitiu care angreneaza toate cunostintele si creaza experienta valoroasa. Cei care doresc sa se maturizeze trebuie sa si-l recunoasca si controleze. Maturizare insemnand sa livreze.

3+2. Uneori este o problema de usability; interactiunea cu end-user este neadecvata. Din pacate se acorda foarte rar suficienta atentie interfetei utilizator. Este creata fie de oameni tehnici, care nu sunt utilizatori tipici, fie de management, client, graficieni etc. care nu au neaparat competentele necesare.

Apoi, orice proiect IT are anumite faze peste care nu se poate trece. Din pacate deseori se taie din testing si bug-fixing pentru a oferi mai multe features pe hartie. Asumati-va consecintele.

1. Nu sunt de acord cu explicatia data. Inginerii sunt artizani care creaza lucruri estetice si functionale. Uneori opere de arta. Isi iubesc meseria pentru ca lasa ceva in urma lor si le pasa de fiecare surub montat. Au implicit o reactie viscerala impotriva celor a caror meserie jongleaza cu lucruri intangibile si/sau care le trivializeaza munca.

Daca doriti ca oamenii din IT sa fie realmente interesati: tratati-i cu respect; platiti-i corect; incercati sa le intelegeti munca. Acest ultim aspect este mai important decat se crede. Nu poti face management IT aplicand precepte generice de management sau teorii din carti. Trebuie sa stii ce presupune procesul specific si sa cunosti caracteristici, idiosincrazii, cutume etc. ale oamenilor din bransa.

Abia cand aceste conditii nu sunt indeplinite oamenii din tehnic devin cinici si dezinteresati. Este o greseala enorma sa porniti de la ideea ca sunt fie geeks complet rupti de realitate fie mercenari. Acestea sunt cazuri extreme. Omul tehnic tipic isi doreste (a) sa produca lucruri utile (b) sa-si sporeasca cunostintele facand asta si (c) sa fie apreciat pentru munca facuta.

Are si parti bune. E bine sa impui revizii periodice a ceea ce s-a facut, ce trebuie facut, sa impui un stil de lucru care produce imbunatatiri mici si constante. Programatorii sunt ca studentii, daca-i lasi de capul lor vor toci in noaptea de dinaintea examenului.

Altfel Scrum e o mare prostie. Cel mai grav: nu se aloca timp elaborarii de specificatii si estimarilor tehnice. Task-urile sunt alese exclusiv pe baza meritelor business si executantii sunt fortati sa scoata estimari din burta ad-hoc. Rezulta eforturi de dezvoltare care nu au decit intimplator legatura cu realitatea. Se rateaza in mod constant obiectivele sau sunt atinse prin eforturi anormale care taxeaza programatorii.

Alta prostie: culpabilizarea si stresarea executantilor. Termenele nerealiste incep sa se resimta iar pentru cei care protesteaza Scrum recomanda luarea in vizor si eliminarea pentru ca “nu se pot adapta”. Incepe sa semene a cult religios? Stati s-o vedeti pe urmatoarea:

Se transforma comunicarea in interiorul echipei in scop in sine si se iroseste timp cu ritualuri imbecile. Exemplu: daily meetings. Teorie: promoveaza comunicarea in echipa si transmiterea informatiei privind mersul proiectului. Practic: comunicarea oricum are loc, vorbim de membrii aceleiasi echipe care lucreaza permanent impreuna. Acele 15 minute se transforma in minim 30 de productivitate zero datorita plimbarii pina la locul obligatoriu de intalnire, toata treaba devine o mini-vacanta. Daca mai ai si un manager de geniu care decide sa se faca daily meeting dimineata poti sa arunci la cos o ora intreaga. Toate astea ar putea fi inlocuite cu un simplu email de la fiecare membru catre team leader la sfarsitul zilei.

Metodele Agile sunt in general extremisme. Contin elemente bune dar din pacate e nevoie de manageri priceputi pentru a le extrage. Ceilalti le aplica orbeste si obtin doar moduri noi si interesante de fail.

Acum vreo 20 de ani, cind am primit primul PC si ceva carti/reviste, auzeam acelasi lucru.

Cred ca e timpul sa ne consideram o industrie matura, si sa ne comportam ca o industrie matura.

Încă un lucru: nu compara Google cu boutique-urile din .ro! Pentru a lansa acel feature de care vorbeai în numai câteva ore au fost nevoie de săptămâni (dacă nu luni) de cercetare şi testare. De exemplu, caută şi vezi cam de cât timp este în teste unul din ultimele feature-uri Google: fade-in şi fade-out pentru toate elementele din homepage-ul Google, cu excepţia logo-ului şi a formularului de căutare.
-

Nu neg faptul că şi la noi se pot face lucruri de calitate şi într-un interval relativ mic de timp, ci vreau doar să subliniez că vina (acolo unde e cazul) este împărţită între cele 2 grupuri de oameni. IT-iştii sunt uneori incompetenţi, dar asta nu înseamnă că oamenii de vânzări/marketing/creativii/etc. au întotdeauna dreptate. Cercetarea şi documentarea sunt la fel de importante ca dezvoltarea.

Un exemplu recent este proiectul de la Launch48, http://sevinde.ro . Nişte oameni au venit cu ideea, a părut ok şi s-au grăbit s-o implementeze doar pentru a arăta că, vezi doamne, se poate!
Aiurea! Dacă ar fi cercetat cineva un pic, ar fi aflat că în multe dintre oraşele mari din ţară (Timişoara, Constanţa, etc.), consiliile locale au interzis afişele gen “Mă vinde” din geamurile autoturismelor, aplicând amenzi celor care nu respectă hotărârea. Astfel, ideea care făcea proiectul să fie diferit de alte site-uri de anunţuri, s-a cam dus naibii… Asta nu i-a oprit s-o implementeze. Asta până când vor descoperi lipsurile şi îşi vor da seama că-s doar un alt site de anunţuri, dar căruia îi lipsesc o parte din beneficiile oferite de restul site-urilor de acelaşi gen. Deci, deşi s-a lucrat mai puţin, rezultatul este unul slab, fapt ce ar fi putut fi evitat dacă se investea mai mult timp în studierea problemei, găsirea soluţiei şi implementarea ei. Să nu mai vorbim de faptul că ideea se presupunea a fi implementată în 48 de ore… Care ore au cam trecut!

Ideea e că, dacă vrei ceva de calitate, trebuie să investeşti timp şi resurse, nu se poate face orice doar bătând din palme!

Sunt perfect de acord cu tine si un mare fan al metodelor de dezvoltare agile. Teoria se aplica si proiectelor IT non-software, insa si acolo exista solutii. Existenta acestor metode, din nefericire, nu inseamna automat ca sunt folosite la nivelul la sunt necesare.

In lumea IT de cativa ani exista solutii (si abordari) verificate pentru probleme si proiecte de acest gen.

Vezi concepte de dezvoltare (si livrare de functionalitate) iterativa gen Agile, Scrum, Extreme Programming si modurile de lucru gen Feature Driven Development, Test Driven Development – solutiile intuite de tine se apropie pe undeva de aceste concepte. In principal modul de lucru Agile propune lucrul in iteratii (ex: 2 saptamani), livrare continua de functionalitate (ex: vezi Google care poate livra functionalitati noi la fiecare cateva ore fara sa strice functionalitatea existenta), flexibilitate mare ce permite adaptarea la cerintele clientului/pietei chiar daca ele vin tarziu in decursul proiectului. Vezi si: http://agilemanifesto.org/principles.html

Alocari gen “lucrul la backend 3-6 luni” sunt incompatibile cu Agile si sunt considerate o greseala din start.

Exista si in Romania o miscare firava in aceasta directie. Un exemplu: http://www.agileworks.ro/agile-scrum-more/

Hai ca ma intind la povesti si am pierdut un Pomodoro pentru acest comentariu (vezi http://www.pomodorotechnique.com/).

P.S.: Scuze, dar a expirat timpul în care-mi puteam edita comentariul anterior!

Prima, cea cu 3-6-12luni, mi se pare cea mai grea de “tratat” intrucat chiar daca la majoritatea proiectelor adaug circa 30% la timpul comunicat de echipa tehnica, mi s-a intamplat si mi-o iau peste ochi de cateva ori ca nu am livrat la timp. Inca mai am de invatat cum sa tratez mai bine deadlineurile date de tehnic.

Partea cu “lucram la backend” cred totusi ca sta in atributiile account managerului, sau echivalentului acestuia, sa-i explice clientului valoarea adaugata chiar daca ea va fi undeva in “backend” si nu va putea fi testata direct de catre client.

Cateva lucruri generale:
- toti cei implicati in proiect, indiferent de competente, trebuie sa lucreze impreuna, nu unul impotriva altuia
- in online, specificatiile unui proiect se pot schimba de la o zi la alta in functie de cum evolueaza piata (se poate scrie un articol si despre asta, e poveste lunga despre cum te poti proteja in astfel de situatii)

In incheiere trebuie sa spun: acest textarea e mult prea mic (latime) si imi este greu sa scriu mai mult :)

7. Dureaza 3-6-12 luni.
Motiv: De cele mai multe ori specificaţiile iniţiale sunt incomplete. În calitate de tehnic, de multe ori am fost nevoit să dau o estimare mai mare a timpului pentru a acoperi o parte din adăugările/modificările ce puteau apărea pe parcurs. Şi tot de multe ori, acestea au fost în număr mai mare decât am estimat.

6. Lucram la backend.
Motiv: Probabil chiar se lucrează la backend. :)

5. Trebuie sa cumparam echipamentul X, softul Y si solutia Z.
Motiv: Ai dreptate, de cele mai multe ori această afirmaţie vine de la entuziaşti sau de la necunoscători care, pentru a construi un monopost pentru carting, au nevoie de un motor V8.
Uneori însă, chiar e nevoie de o soluţie scumpă, în lipsa căreia… (vezi punctul următor :P )

4. Trebuie (re)-scris/facut de la zero.
Motiv: Probabil nu au fost alocate fondurile pentru soluţia scumpă X de mai sus. :)
Alteori, pentru că ceea ce există deja este o mizerie făcută de amatori, care ar putea afecta dezvoltarea proiectului în viitor. Şi, în cele din urmă, da, probabil e nejustificată propunerea.

3. Totul este sub control. Proiectul e 95% gata.
Motiv: Probabil că, în conformitate cu specificaţiile iniţiale, proiectul chiar este 95% gata. Totuşi, cum am mai spus, acele specificaţii iniţiale nu sunt întotdeauna complete şi mai apar modificări neprevăzute pe final. Ce-i mai dureros este că, destul de des, managerii/persoanele atehnice vin pe final cu chestii de genul: “ar mai fi o chestiuţă pe care vreau s-o faceţi, dar care n-o să vă ia mult”… De unde ştii că n-o să ia mult? Ştii ce implică asta din punct de vedere tehnic?

2. Am testat, functioneaza.
Motiv: Probabil ai lăsat un tehnician să proiecteze interfaţa cu utilizatorul. Să-ţi fie învăţătură de minte! :) Aplicaţia probabil chiar funcţionează, dar într-un mod nu foarte intuitiv, pe care o persoană normală nu-l înţelege cu uşurinţă, de aceea ajunge să fie respinsă.

1. Ne intereseaza proiectul!
Motiv: Lipsa specificaţiilor, lipsa fondurilor pentru resursele necesare, constrângerea de a lucra pe cod deja existent şi de proastă calitate, presiunile şi impunerea unui “workflow” anormal, de genul “mai lăsaţi backend-ul şi faceţi ceva şi la frontend să putem arăta ceva clientului”, chestiile “mici” care apar când ţi-era lumea mai dragă şi credeai că începi să întrezăreşti luminiţa de la capătul tunelului, reproşurile şi lipsa recunoştinţei pentru faptul că ai tras ca un bou şi ai făcut tot posibilul să mulţumeşti o echipă de marketing care mai mult te-a încurcat decât să te ajute… Ei bine, toate astea pot duce în unele cazuri la un oarecare dezinteres în ceea ce priveşte un proiect! :)

Cred ca acest post arata o oarecare ignoranta in ceea ce priveste proiectele software care in general sunt greu de estimat, greu de urmarit si se fac dupa ureche.

Generalizarile nu ajuta..

Ramane de vazut cat esti de dispus sa platesti pentru un proiect implementat de o echipa profesionista si care urmeaza o metodologie.

De asemenea mai ramane de vazut in ce masura esti capabil sa iti structurezi ideile astfel incat proiectul sa fie coerent de la inceput pana la sfarsit. In multe cazuri IT-ul primeste ca input niste vise si trebuie sa scoata ceva utilizabil.

Asadar esti dispus sa platesti? Ai merge la frizer sa iti scoata maselele?

Niste cifre: http://www.it-cortex.com/Stat_Failure_Rate.htm

Problemele de genul acesta apar de cele mai multe ori din cauza oamenilor care conduc proiectul, care nu stiu ce si cum sa ceara si care, din lipsa de experienta, prefera sa lase anumite decizii la latitudinea programatorului.

Mitul programatorului creativ, super calificat, multi lateral dezvoltat, care le face pe toate proactiv este, in cele mai multe din cazuri, doar un mit.

Daca ai un sistem de management al proiectelor eficient, proceduri clare care se respecta si reusesti sa iti castigi programatorii ca fani ai proiectului atunci succesul e asigurat.