Analysis paralysis

20 apr.

Să zicem că lucrezi la un proiect nou, un proiect abia început, iar acesta stă destul de mult timp în perioada de proiectare, adunare de requirement, design și/sau data modeling fără ca asta să îi aducă vreun plus de orice fel. Este foarte probabil un proiect care se încadrează în cele care suferă de analysis paralysis.

Hai să îți dau un exemplu mai aproape de viața de zi cu zi. Ai nevoie de un laptop. Începi să cercetezi piața și observi că sunt 1000 de modele și începi prin a le analiza pe toate. Le iei pe rând, le iei prin comparație, ceri părerea prietenilor (părerile, normal, sunt împărțite), cauți review-uri pe n-jde mii de forumuri, etc. După o lună îți dai seama că încă nu ai o părere bine definită și ești în aproape același punct ca în urmă cu 30 de zile.

Buun, revenind la ingineria software, analysis paralysis, în mod uzual se datorează lipsei de experiență a BA-ilor, arhitecților software, managerilor de orice fel și a developerilor. De obicei asta se întâmplă atunci când persoanele din funcțiile cheie nu sunt echipate pentru a face lucrurile să se miște. Trecând un pic la nivel organizațional, asta denotă o companie care acționează puțin ca o găină fără cap sau are o serie de reguli ce stabilesc o organizare rigidă. Presupun că nu trebuie să dau mai multe detalii pe tema asta.

Acum că am zis ce înseamnă hai să zic și cum s-ar putea rezolva această problemă din punctul meu și al altora de vedere .

Setează termene limită.

Orice decizie trebuie luată într-un anumit interval de timp. Dacă în timpul acordat nu au fost definitivate toate detaliile, alege-o pe cea care pare mai plauzibilă. Fii conștient de faptul că tot timpul vor exista necunoscute iar asta nu ar trebui să te împiedice să acționezi sau cel puțin să treci la o fază următoare.

Fii curajos în a lua decizii

Asta e strâns legată de punctul anterior dar ceea ce vreau să punctez e că uneori ar trebui să îți asculți instinctul. Bineînțeles, poți greși dar asta se poate întâmpla și în cazul unei decizii analizate și răs-analizate.

Nu încerca toate opțiunile

Pe piața actuală pentru orice lucru de care ai nevoie există o sumedenie de opțiuni pe care le poți accesa. Nu e nevoie de a le considera pe toate. Încearcă să construiești ceva destul de flexibil astfel încât la orice moment, orice componentă să poate fi înlocuită cu alternativa. Pentru moment alege lucrul care îți satisface nevoia într-un procent cât mai mare.

Treci la pasul următor

Chiar dacă nu toate detaliile sunt definitivate în pasul N-1 dar finalizarea lor ar lua prea mult timp, treci la pasul N. Câteodată ajungând cu un pas mai departe îți vei da seama că nu toate detaliile erau relevante. Ține minte YAGNI (You ain’t gonna need it).

Încă o chestie pe care trebuie să o precizez și cu asta închei este Architectural Paranoia. Există o tendință în oricare dintre noi ca atunci când pornim un proiect software să facem over-engineering în caz că mai încolo proiectul va crește ca Făt-Frumos. Nu neg importanța unui framework flexibil pentru orice proiect software, dar dacă arhitectura te împiedică să progresezi atunci adu-ți aminte de YAGNI.

Și-am încălecat pe-o șa și ți-am spus despre analysis paralysis. Ai alte păreri, debate me?

analysis paralysis

Nu fi egoist, dă mai departe să ajungă la tot poporul

Lasă un răspuns

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.