Managementul proiectelor

Dezvoltarea rapid a aplicaiilor software

1. INTRODUCERE
2. STRATEGIA DEZVOLTRII RAPIDE
2.1. Strategia general
2.2. Cele patru dimensiuni ale dezvoltrii rapide
2.2.1.1. Oamenii
2.2.1.2. Procesul
2.2.1.3. Produsul
2.2.1.4. Tehnologia
3. GREELI CLASICE
3.1. Efectul greelilor asupra programrii dezvoltrii
3.2. Enumerarea greelolor clasice

1
4
4
5
5
6
8
8
9
9
10

1. INTRODUCERE
Problema timpului de dezvoltare este insidioas i omniprezent. Diferite studii au artat c
aproape dou treimi dintre proiecte depesc substanial estimrile (Lederer & Prasad 1992,
Gibbs 1994, Standish Group 1994). Data planificat a livrrii este depit cu 25 - 50 % i
mrimea alunecrii programului planificat crete cu mrimea proiectului (Jones 1994). An
dup an, sursele vitezei de dezvoltare au aprut n fruntea listei celor mai critice probleme
puse n faa comunitii dezvoltatorilor de software (Symons 1991).
Dei problema dezvoltrii lente a proiectelor este presant, unele organizaii se dezvolt rapid.
Cercettorii au descoperit diferene de 10 la 1 n productivitate ntre companii din cadrul
acelorai industrii, iar unii cercettori au gsit variaii chiar mai mari (Jones 1994).
Unul dintre scopurile cursului este de a furniza grupurilor care sunt n mod curent mai
aproape de "1" (n cadrul acestui raport de 1 la 10) informaiile necesare pentru a se apropia
de "10". Cursul i propune s v ajute n aducerea sub control a proiectelor voastre, care s
furnizeze o funcionalitate sporit ntr-un timp de dezvoltatre mai sczut.
Care sunt segmente int ale cursului ?

Responsabilii n partea tehnic

Unele exemple practice care v vor fi prezentate sunt tehnice. Ca responsabili n acest sector,
nu vei avea probleme n implementarea lor. Alte exemple sunt orientate mai mult spre
management, care este de fapt i titlul cursului. Presupunem c suntei (sau vei deveni n
scurt timp) manageri pe partea tehnic, deci oameni capabili s mnuiasc att problemele
1

tehnice, ct i pe cele manageriale. Naiva dihotomia tehnic-managerial nu este tocmai

potrivit, responsabilii din sectorul tehnic fiind adesea chemai s fac recomandri uppermanagement-ului n legtur cu problemele de management orientate tehnic.

Programatorii individuali
Multe proiecte software sunt derulate de ctre programatori individuali sau de ctre "selfmanaged teams", punnd participanii din zona tehnic individual n roluri de responsabili
tehnici.

Manageri
Managerii consider adeseori c dezvoltarea rapid a unui software este n primul rnd o
problem tehnic. Cu toate acestea, un manager poate face n mod normal la fel de mult ca i
dezvoltatorii pentru a mbunti viteza dezvoltrii proiectului. Acest curs va descrie i
exemple de dezvoltare rapid la nivelul managementului.
Cursul pune accentul pe problemele legate de dezvoltarea de software, innd cont de faptul
c acest domeniu este ntr-o explozie fantastic pe scar global, dar i naional i local,
reprezentnd unul dintre puinele sectoare viabile i de mare perspectiv ale rii noastre.
Muli dintre voi sunt antrenai n mod direct sau indirect n activiti de dezvoltare de
software, iar ceilali suntei cu siguran n zone adiacente, n care problemele legate de
aplicarea i mentenaa software-ului sunt stringente.
n acest context, putem considera c proiectele software pot fi optimizate pentru oricare dintre
urmtoarele scopuri: rata de defectare cea mai sczut, viteza de execuie cea mai mare,
gradul de acceptan de ctre utilizator cel mai ridicat, mentenabilitatea cea mai bun, costul
cel mai sczut sau timpul de dezvoltare cel mai scurt. O abordare inginereasc ne conduce
ctre buna cntrire a problemelor: poi optimiza timpul de dezvoltare tind de la calitate?
Tind de la capacitatea de folosin? Cernd dezvoltatorilor s lucreze peste program? Cnd
"momentul adevrului" se apropie, cte reduceri n planificare poi opera? Sunt cteva dintre
ntrebri la care vom rspunde mpreun de-a lungul acestui curs.
Putem s vorbim despre o criz a softitilor relativ la problema dezvoltrii lente a softurilor?
n occident da. Iar la noi ncepe s apar. Clienii i managerii rspund acestei probleme n
primul rnd prin creterea presiunii planificrii i prin suprancrcarea dezvoltatorilor.
Presiunea excesiv a planificrii se produce n aproximativ 75 % dintre proiectele mari i n
aproximativ 100 % dintre proiectele foarte mari (Jones 1994). Aproape 60 % dintre
dezvoltatori spun c nivelul de stres resimit este n cretere (Glass 1994). Media
dezvoltatorilor n SUA lucreaz ntre 48 i 50 de ore pe sptmn (Krantz 1995). Muli
muncesc considerabil mai mult. Nu este deci surprinztor c satisfacia general a muncii din
acest domeniu a sczut semnificativ n ultimii ani (Zawacki 1993). O reconsiderare a
managementului proiectelor software poate aduce mbuntiri substaniale i din acest punct
de vedere.

Dezvoltarea rapid - ce este i ce vrea ea?

Managerul de producie mi-a spus c dorete s construiasc un produs potrivit pentru o
schimbare. El dorete s fim ateni la calitate, s prevenim neconformitatea, s inem sub
control planificarea i s putem furniza o dat predictibil a lansrii.
Cnd a sosit timpul de a face efectiv proiectul, a devenit clar c lansarea cu rapiditate a
produsului a fost singura prioritate real. Utilizabilitatea? Nu avem timp. Performana? Nu
putem atepta. Mentenabilitatea? La urmtorul proiect. Testarea? Utilizatorii notri doresc
produsul acum. S li-l oferim acum.
Acest manager de producie nu conduce numai proiectul unui produs. i el se poate identifica
cu aproape orice manager de producie. Timpul de dezvoltare a devenit o prioritate att de
important, nct i-a "furat" pe oameni de la alte consideraii semnificative, chiar de la acelea
care influeneaz n ultim instan i timpul de dezvoltare.
Ce este dezvoltarea rapid ?
Depinde de cine se gndete la asta. Pentru unii oameni, aplicarea unei singure unelte sau a
unei singure metode. Pentru un hacker - 36 de ore pentru un scop. Pentru inginerul din IT RAD (Rapid Development), o combinaie ntre uneltele CASE, implicarea intensiv a
utilizatorului i "timeboxes" foarte strnse. Pentru programatorul tip "vertical-market" elaborarea cu rapiditate a unui prototip utiliznd ultima versiune de Visual Basic sau Delphi.
Pentru managerul disperat care dorete s scurteze termenele - orice chestiune practic
desprins din cele mai recente numere ale revistelor de afaceri.
Oricare dintre aceste unelte i metode este bun atta timp ct "merge" i fiecare poate
contribui la creterea vitezei de dezvoltare. Dar pentru a furniza un beneficiu maxim, trebuie
ca fiecare s fie orchestrat ca parte a unei strategii cuprinztoare. Niciuna dintre ele nu se
poate aplica n toate cazurile. i niciuna dintre ele nu se poate msura cu anumite alte
practici care nu sunt gndite n mod obinuit ca practici pentru dezvoltare rapid, dar care au
oricum profunde implicaii asupra dezvoltrii rapide.
n cadrul acestui curs, termenul de "dezvoltare rapid" este mai degrab o sintagm
descriptiv, care contrasteaz cu "dezvoltare lent i tipic". Un termen generic care nseamn
acelai lucru ca i "scurtarea termenelor".
Atunci, un "proiect dezvoltat rapid" este orice proiect care trebuie s sublinieze viteza de
dezvoltare. In climatul zilelor noastre, aceast descriere se potrivete unei sumedenii de
proiecte.

2. STRATEGIA DEZVOLTRII RAPIDE

2.1 Strategia general
Putei realiza o dezvoltare rapid urmrind o strategie cu patru linii directoare:

Evitai greelile clasice.

Aplicai bazele dezvoltrii.

Conducei riscurile pentru a evita ntoarcerile catastrofale.

Aplicaii practicile orientate spre planificare (vitez, risc planificat, vizibilitate):

o Care mbuntesc viteza dezvoltrii, permindu-v s livrai produsul mai
repede.
o Care reduc riscul planificat, permindu-v s evitai depiri uriae ale
planificrii.
o Care fac vizibil progresul, permindu-v s nlturai aparent unei dezvoltri
ncete.

Cea mai buna planificare

posibil

Figura 2.1 Cei patru piloni ai dezvoltrii rapide

Pilonii din figur ilustreaz cteva aspecte importante:
Sprijinul optim pentru cea mai bun planificare posibil este cnd avem toi pilonii i cnd i
facem pe toi ct mai puternici posibil. Fr sprijinul primilor trei, abilitatea voastr n
planificare va fi n primejdie putei s folosii cele mai solide practici orientate pe planificare,
dar dac facei greeala clasic de a scurta timpul destinat calitii produsului n faza timpurie
a proiectului, vei pierde timp corectnd defecte atunci cnd este cel mai scump. Proiectul va
ntrzia.
Dac srii peste principiul de dezvoltare de a crea un proiect bun nainte de a lucra efectiv,
produsul va avea de suferit cnd concepia lui se va schimba n unele pri prin dezvoltare i
proiectul va ntrzia. i dac nu conducei riscurile, putei afla chiar nainte de data lansrii c
un subcontractor-cheie este n urm cu trei luni fa de planificare. i vei ntrzia iari.
Figura sugereaz de asemenea c primii trei piloni furnizeaz cel mai mare sprijin necesar
pentru cea mai bun planificare. Poate c nu un sprijin ideal, dar cea mai mare parte din
4

necesar. Este posibil s fii capabili s realizai o planificare optim fr practici orientate pe
planificare.
Putei realiza ns cea mai bun planificare prin concentrarea numai pe practici orientate pe
planificare? Este un act foarte dificil de echilibrat i v vei priva de sprijinul n general
necesar.
2.2. Cele patru dimensiuni ale dezvoltrii rapide
n timp ce ncercai s evitai greeli i s navigai la vitez maxim cu cele mai eficiente
practici orientate pe planificare, proiectul vostru opereaz de-a lungul a patru dimensiuni
importante:

Oamenii

Procesul

Produsul

Tehnologia
n general, organizaiile tind s vad dimensiunile pe care nu sunt axate ca fiind fixe.
Organizaiile cele mai eficiente n realizarea dezvoltrii rapide optimizeaz toate cele patru
dimensiuni simultan.
Odat ce realizai c fiecare dintre cele patru dimensiuni poate furniza prghii consistente n
planificare, aceasta din urm poate deveni mai complet, mai creativ, mai eficace i mai
capabil de a satisface toate prile implicate.
2.2.1 Oamenii
Cercetrile n aceast problem s-au coagulat cu precdere n ultimii 15-20 de ani. Este acum
posibil s pim printre concluziile multor studii individuale i s sintetizm cteva concluzii
generale vis--vis de tendinele cercetrilor.
Prima concluzie este c acest aspect are cel mai mare impact asupra productivitii i calitii
software-ului. Din ultima parte a anilor '60, studiile au relevat c productivitatea
programatorilor individuali cu niveluri similare de experien variaz dup un factor de cel
puin 10 la 1 (Sackman 1968, Curtis 1981, Mills 1983, DeMarco 1985, Card 1987, Valett
1989).
De asemeni, studiile au gsit variaii n performana intregii echipe de 3, 4 sau 5 la 1.
(Weinberg 1974, Boehm 1981, Mills 1983, Boehm 1984). Dup 20 de ani de experimente,
cercettorii de la NASA's Software Egineering Laboratory au concluzionat c nu tehnologia
este rspunsul; cele mai eficiente practici sunt acelea care influeneaz potenialul uman al
dezvoltatorilor lor (Basili 1995).
Este ct se poate de clar c orice organizaie care este serioas n ceea ce privete
mbuntirea productivitii trebuie s priveasc mai nti spre problematica uman a
motivaiei, lucrului n echip, seleciei personalului i pregtirii. Luate mpreun, acestea
conteaz mai mult dect procesul, productivitatea i tehnologia. Lor trebuie s v adresai
dac dorii s reuii.

Cursul se va ocupa de cteva ci prin care putei maximiza potenialul uman n scopul
reducerii factorului timp.
Selecia personalului pentru echipele proiectelor
n cartea sa de referin, Software Engineering Economics, Barry Boehm prezint cinci
principii ale seleciei personalului (Boehm 1981):

Talent de vrf Utilizai mai degrab oameni mai buni i mai puini.

Corespondea cu job-ul Completai sarcinile n corelaie cu aptitudinile i motivaia

personalului disponibil.

Progresia carierei Ajutai oamenii mai degrab s se perfecioneze dect s-i forai s
lucreze acolo unde au mai mult experien sau unde sunt mai necesari.

Echilibrul echipei Selectai oamenii care se completeaz i armonizeaz reciproc.

Eliminarea oamenilor nepotrivii Eliminai i nlocuii membrii-problem ai echipei ct

mai repede posibil.

Organizarea echipei
Felul n care sunt organizai oamenii are un efect semnificativ asupra eficienei muncii lor.
Shop-urile de software pot beneficia de croirea echipelor lor dup mrimea proiectului,
caracteristicile produsului i scopurile programate. Un proiect software specific poate
beneficia de asemenea de specializarea corespunztoare.
Motivaia
Este puin probabil ca o persoan creia i lipsete motivaia s lucreze din greu; este mai
probabil ca aceasta s lucreze la limit. Motivaia este aliatul potenial cel mai puternic pe
care l avei pentru dezvoltarea rapid a proiectelor.
2.2.2 Procesul
Procesul include att metodologiile de managementul, ct i cele tehnice. Efectul pe care l
are asupra planificrii dezvoltrii proiectului este mai uor de evaluat dect cel al oamenilor i
a fost reflectat printr-o munc intens de ctre diverse organizaii. Hughes Aircraft, Lockheed,
Motorola, NASA, Raytheon i XEROX, care s-au axat explicit pe mbuntirea proceselor de
dezvoltare proprii, au redus la jumtate, de-a lungul ctorva ani, timpii de acces la pia a
produsului, iar costul i defectele le-au redus de 3 pn la 10 ori (Pietrasanta 1991, Myers
1992, Putnam 1992, Bibbs 1994, Basili 1995, Saiedian 1995).
Unii oameni consider c atenia spre proces este sufocant i c nu exist nici un dubiu
asupra faptului c unele procese sunt peste msur de rigide sau birocratice. Unele persoane
au creat standarde pentru procese n primul rnd cu scopul de a se simi ei nii puternici. Dar
aceasta reprezint un abuz de putere i faptul c se poate abuza de direcionarea unui proces
nu ar trebui s permit defimarea beneficiilor pe care le poate oferi focusarea pe process.
Forma cea mai comun a abuzrii de process este neglijena i efectul ecesteia este c
dezvoltatorii inteligeni i contiincioi se gsesc pe ei nii lucrnd inefficient i la
intersecia scopurilor cnd nu este nevoie ca ei s lucreze n acest fel. O atenie axat pe
process poate fi de ajutor.
6

Evitarea dublrii muncii

Dac cerinele se schimb n etapele finale ale proiectului, trebuie s-l reproiectai, rescriei i
retestai. Dac rezult, de exemplu, probleme n faza de testare, putei fi pui n situaia de a
renuna la elemente pe care le-ai elaborat n detaliu i de a o lua de la nceput. Una dintre cele
mai importante ci de a salva timpul ntr-un proiect este de a orienta procesul astfel nct s
evitai s facei acelai lucru de dou ori.
Raytheon a ctigat IEEE Computer Societys Software Process Achievement Award n anul
1995 pentru reducerea costurilor pentru rework de la 41% la mai puin de 10%, triplndu-i
simultan productivitatea (Raytheon 1995). Relaia dintre cele dou elemente este una de
substan, nu o coinciden.
Asigurarea calitii
Asigurarea calitii are dou scopuri principale. Primul este acela de a se asigura faptul c
produsul lansat are un nivel acceptabil al calitii (Dei important, nu este printre scopurile
acestui curs). Al doilea este de a detecta erori n etape n care coreciile sunt mai puin
consumatoare de timp (i la costuri mai mici), la momente ct mai apropiate de acela n care
au fost introduse n sistem. Asigurarea calitii este astfel o parte indispensabil a oricrui
program de dezvoltare rapid.
Bazele dezvoltrii
Dei practicile standard de analiz, proiectare, construcie, integrare i testare nu produc
planificri strlucitoare prin ele nsele, pot preveni rsucirea proiectelor spre zone
necontrolabile. Jumtate dintre provocrile dezvoltrii rapide sunt de a evita dezastrele, i
aceasta este o zon n care principiile ingineriei software standard exceleaz.
Managementul riscului
Una dintre practicile specifice care este focusat pe evitarea dezastrelor este managementul
riscului. Dezvoltarea rapid nu este sufficient de bun dac rmnei blocai cu dou
sptmni nainte de termenul de lansare a produsului.
intirea resurselor
Resursele pot fi avute n vedere n mod eficient (caz n care contribuie la productivittea
general), sau pot fi direcionate greit i utilizate ineficient. ntr-un proiect de dezvolatre
rapid, este mai important dect n mod obinuit ca s obinei maximum de impact pentru
banii planificai. Practicile cele mai bune, cum sunt birouri de productivitate, planificare
corespunztoare i timp de lucru suplimentar voluntary, ajut pentru a fi siguri c obinei
maximum de munc efectuat zilnic.
Planificarea ciclului de via
Una dintre cheile intirii eficiente a resurselor este de a le aplica n cadrul unui ciclu de via
care s aib sens pentru proiectul vostru concret. Fr un model al ntregului ciclu de via,
putei lua decizii care sunt axate individual pe int, dar direcionate colectiv n mod greit.Un
model al ciclului de via este util pentru c descrie un plan de management de baz. De
exemplu, dac avei un proiect riscant, un model de ciclu de via oriectat pe risc va fi
7

potrivit; i dac avei cerine vagi, un model de ciclu de via incremental va putea funciona
cel mai bine.
Orientarea spre client
Unul dintre salturile cele mai semnificative ntre dezvoltarea tradiional de software tip
mainframe i stilurile de dezvoltare mai moderne a fost acela spre un puternic accent pe
nevoile i dorinele clientului. Dezvoltatorii au nvat c producerea de software conform cu
specificaiile este numai jumtate din munc. Cealalt jumtate este ajutarea clientului pentru
a-i da seama de cea ce produsul trebuie s fie i de cele mai multe ori aceata solicit o
abordare diferit de cea tradional bazat pe specificaii scrise pe hrtie. S v punei de
aceeai parte cu clientul este cea mai bun cale de a evita dublrile masive ale muncii cauzate
de decizia clientului potrivit creia produsul pentru acre tocmai ai consumat 12 luni nu este
cel corect de fapt. Practicile cele mai bune de lansare n etape, livrare i prototipuri bazate pe
evoluie i negociere principial v pot conferi un control rezonabil.
2.2.3 Produsul
Produsul este cea mai tangibil dintre cele patru dimensiuni n discuie. Dac poi reduce setul
de caracteristici ale produsului, poi reduce timpii n cadrul planificrii produsului.
Mrimea produsului
Este cel mai important element singular care contribuie la planificarea dezvoltrii.
Caracteristici suplimentare cer specificaii, proiectare, construcie, testare i integrare
suplimentare. Reducerea la jumtate a mrimii unui program de dimensiuni medii va reduce
efortul cerut cu aproape dou treimi.
2.2.4 Tehnologia
Schimbrile din unelte mai pin eficiente n unelte mai eficiente pot fi de asemenea o cale
rapid de a mbunti viteza de dezvoltare. Schimbarea din limbaje de nivel jos (limbaje de
asamblare) n limbaje de nivel nalt (C, Pascal) a fost una dintre cele mai importante din
istoria dezvoltrii software-ului.

1. GREELI CLASICE
Dezvoltarea de software este o activitate complex. Un proiect software tipic poate prezenta
multe oportuniti de a nva din greeli.
1.1. Efectul greelilor asupra programrii dezvoltrii
Michael Jackson spunea ntr-unul din cntecele sale c "One bad apple don't spoil the whole
bunch, baby". Aceasta poate fi adevrat pentru mere, dar pentru software n nici un caz. Un
mr ru poate strica ntregul proiect.
Un grup de cercettori de la ITT a trecut n revist 44 de proiecte n 9 tri pentru a examina
impactul a 13 factori de productivitate asupra acesteia (Vosburgh 1984). Aceti factori
includeau utilizarea practicilor de programare moderne, dificultatea codului, cerinele de
performan, nivelul de participare a clientului n specificaiile cerute, experiena personalului
i alte cteva. Ei au mprit fiecare dintre aceti factori n categorii care te-ai atepta s fie
asociate cu o performa sczut, medie sau ridicat. De exemplu, ei au mprit factorul
"practici moderne de programare" n utilizare sczut, medie i ridicat (figura 2.1.).
Rezultatele desprinse sunt interesante. Modelul general artat este reprezentativ pentru fiecare
dintre factorii de productivitate studiai. Cercettorii de la ITT au gsit c proiecte din
categorii de la care se ateptau s aib o productivitate sczut au avut ntr-adevr
productivitate sczut, cum este cazul irului ngust de la categoria "Sczut". Dar
productivitatea din categoriile performanei nalte a variat foarte mult, cum este artat n irul
larg de la categoria "Ridicat". Productivitatea proiectele din aceast categorie a variat de la
sczut la excelent.
Procentul
productivitii
nominale

Sczut

Mediu

(0-25%)

(26-75%)

Ridicat
(76-100%)

Legend

+ 200

Maximum
75 %
Media
25%

+ 100

Fig. 2.1. Utilizarea practicilor programrii moderne

(procente din sistemul
9 total)

Mimimum

Faptul c acele proiecte de la care s-a ateptat s aib o productivitate sczut au confirmat
aceasta nu trebuie s surprind. Dar c multe proiecte de la care se astepta o productivitate
foarte bun au avut de fapt una sczut, aceasta poate constitui o surpriz. Ceea ce relev
graficul este c utilizarea oricror practici specifice bune este necesar dar nu suficient
pentru a atinge maximum de vitez de dezvoltare. Chiar dac facei unele lucruri bine, cum ar
fi utilizarea la o capacitate ridicat a practicilor moderne de programare, putei face nc a
greeal care anuleaz ctigurile pe care le-ai realizat n productivitate.
2.1. Enumerarea greelilor clasice
Unele practici de dezvoltare ineficient sunt alese att de des, de att de mult lume, cu
rezultate proaste att de predictibile, nct merit s fie numite "greeli clasice". Multe dintre
greeli au o atracie seductoare. Vrei s salvai un proiect care este n urma planificrii?
Adugai mai muli oameni! Vrei s reducei termenele planificate? Planificai mai agresiv!
Unul dintre contributorii cheie afecteaz negativ restul echipei? Ateptai pn la sfritul
proiectului pentru a-l da afar! Avei de completat un proiect presant ca termen? Luai-v
orici dezvoltatori sunt disponibili acum i ncepei ct mai repede posibil.
Greelile enumerate n continuare au un numitor comun: nu vei accede n mod necesar la o
dezvoltare rapid dac vei evita aceste greeli, dar n mod sigur vei ntrzia dezvoltarea dac
nu le vei evita. Odat ce le vei nelege efectele asupra vitezei de dezvoltare, vei putea
utiliza lista lor n ajutorul planificrii proiectului i managementului riscului.
Pentru uurina referirii, lista greelilor a fost mprit pe cele patru dimensiuni ale vitezei de
dezvoltare: oamenii, procesul, produsul i tehnologia.
Oamenii
Iat cteve dintre greelile clasice legate de oameni:
1: Motivaie subminat. Un studiu dup altul relev faptul c motivaia are probabil efectul
cel mai mare asupra productivitii i calitii (Boehm 1981). Tragei concluziile i din Studiul
de caz 2.1., fcut la laborator.
2: Personal slab. Dup motivaie, att capacitile individuale ale membrilor echipei, ct i
relaia dintre ei care determin comportarea ca echip, au cea mai mare influen asupra
productivitii (Boehm 1981, Lakhanpal 1993). Tragei concluziile i din Studiul de caz 2.1.
3: Angajai cu probleme necontrolabile. Este o problem obinuit i bine neleas de
vreme ce Gerald Weingerg a publicat Psychology of Computer Programming n anul 1971.
Eecul n a lua atitudine fa de angajatul-problem este cea mai obinuit plngere a
memebrilor echipei vis--vis de eful lor. (Larson 1989). Tragei concluziile i din Studiul de
caz 2.1.
4: Eroism. Unii dezvoltatori software accentueaz pe eroismul proiectelor (Bach 1995). Dar
fac mai mult ru dect bine. Vedei i Studiul de caz 2.1. Un accent pus pe eroism ncurajeaz
asumarea riscurilor i descurajeaz cooperarea ntre numeroii stakeholder-i implicai n
10

procesul de dezvoltare software. Unii manageri ncurajeaz comportamentul eroic cnd se

bazeaz prea mult pe atitudinea excesiv se poate, afectnd capacitatea de a se lua aciuni
corective. Atitudinea se poate produce micii pai ctre adevratele dezastre. (DeMarco 1995).
5: Adugare de personal la un proiect ntrziat. Aceasta este probabil cea mai clasic
dintre greelile clasice. Cnd un proiect este n ntrziere, suplimentarea de personal poate lua
mai mult productivitate de la membrii echipaei existente dect adaug noii membrii. Unii
autori compar aceasta cu punerea gazului pe foc (Brooks 1975).
6: Birouri nghesuite, zgomotoase. Cei mai muli dezvoltatori consider condiiile de lucru
drept nesatisfctoare. Aproximativ 60% raporteaz c nu au ori suficient linite, ori
suficient intimitate (DeMarco 1987). Mediile zgomotoase, populate, lungesc durata
dezvoltrii.
7: Friciuni ntre dezvoltatori i clieni. Se pot produce n mai multe feluri. Clienii pot s
simt c dezvoltatorii nu sunt cooperani atunci cnd refuz s semneze programarea
dezvoltrii dorit de clieni sau cnd nu pot s furnizeze ceea ce au promis. Dezvoltatorii pot
s simt ca clienii nu sunt rezonabili, insistnd pe programri nerealiste sau schmbri ale
specificaiilor dup ce acestea au fost fundamentate. Pot fi i simple conflicte personale dintre
cele dou grupuri.
Principalul efect al friciunilor este slaba comunicare, iar efectele secundare ale slabei
comunicri includ slaba nelegere a cerinelor, slaba proiectare a interfeei-utilizator i, n
cazul cel mai ru, refuzul clenilor de a accepta produsul completat. n medie, friciunile
dintre clieni i dezvoltatori devin att de severe nct ambele pri iau n considerare
abandonarea proiectului (Jones 1994). Aceste friciuni sunt consumatoare de timp i distrag
ambele pri de la munc real din cadrul proiectului.
8: Ateptri nerealiste. Reprezint una dintre cauzele cele mai obinuite ale friciunilor dinre
clieni i dezvoltatori. Vedei i Studiul de caz 2.1. De asemeni, unii manageri pot intra n
ncurctur alocnd fonduri bazndu-se pe o estimare prea optimist.
Dei asteptrile nerealiste nu lungesc prin ele nsele programarea dezvoltrii, totui ele
contribuie la percepia c aceasta este prea lung, iar asta poate fi aproape la fel de ru. Un
studiu al Standish Group a plasat ateptrile realiste n topul 5 al factorilor necesari pentru
asigurarea succesului unui proiect (Standish Group 1994).
9: Lipsa unui sprijin eficient al proiectului. Sprijinirea proiectului la nivel nalt este
necesar n multe aspacte ale dezvoltrii rapide, incluznd planificarea realist, controlul
schimbrii i introducerea noilor practici de dezvoltatre. Fr un sprijin eficiant n conducerea
executiv, alte persoane de la nivelul conducerii organizaiei voastre v poate fora s
acceptai termene nerealiste sau s facei schimbri care v submineaz proiectul. Lipsa unui
sponsor executiv eficient garanteaz virtual eecul proiectului (Thomsett 1995).
10: Lipsa convergenei stakeholder-ilor. Toi actorii majori din cadrul proiectului trebuie si uneasc eforturile. Aceasta include sponsorul executiv, conductorul echipei, membrii
echipei, echipa de marketing, utilizatorii finali, clienii i oricine altcineva care are un interes
11

n sprijinirea proiectului, factori ai cror convergen conduce la o coordonare precis a

proiectului.
11: Neimplicarea utilizatorului. Studiul efectuat de Standish Group relev faptul c motivul
numrul 1 al succesului proiectelor este implicarea utilizatorilor (Standish Group 1994).
Proiectele fr implicarea timpurie a utilizatorului final risc nelegerea greit a cerinelor
proiectului i sunt vulnerabile n ceea ce privete consumul de timp ulterior n proiect.
12: Politica plasat deasupra substanei. Iat rezultatul unui studiu efectuat pe patru echipe
cu orientri diferite (Constantine 1995). "Politicienii" - concentrai pe relaia cu managerii lor.
"Cercettorii" - concentrai pe cutarea i strngerea informaiei. "Izolaionitii" - retrai n ei
nii, crend granie ale proiectului fa de non-membrii proiectului. Generalitii" - fcnd
cte puin din toate: relaia cu managerii, cercetare, coordonare cu alte echipe pe calea
fluxurilor normale de lucru. Iniial, "politicienii" i "generalitii" au fost deopotriv bine
vzui de top-management. Dar dup un an i jumtate, echipa "politicienilor" a fost
nregistrat ultima ca rezultate. Punerea politicii deasupra rezultatelor este fatal pentru
dezvoltarea orientat pe vitez.

12