În 2008, am lucrat pentru câteva luni într-o echipă de cinci persoane la dezvoltarea unei aplicații de Business Intelligence. Din punctul de vedere contractual proiectul era limitat la un buget și o dată de livrare fixe. Purtam atât cascheta de șef de proiect, cât și de arhitect și de dezvoltator, deși nu mai eram obsedat de controlul excesiv și credeam în capacitatea echipei de a produce autonomă software de calitate. Proiectul a fost excelent. Pornind de la ideea de business, care m-a fascinat la acel moment, până la implementarea tehnică, optimizări de calcul pe un volum mare de date, transformarea datelor, lucrul cu noul format de office, ș.a.m.d.

Mi se părea totuși ciudat să intru pe un proiect unde perimetrul inițial era vag și să fiu constrâns la numărul de zile de lucru vândute. Însă n-a fost nevoie să adopt o atitudine prea defensivă, deoarece lucram după modelul în V, conform căruia trebuia să trecem printr-o fază de specificații înainte de a începe dezvoltarea. Dacă perimetrul funcțional devenea prea mare aș fi știut în urma acestei etape. La specificații am lucrat cam 10 zile în strânsă colaborare cu clientul, întorcându-mă din Franța încrezător că proiectul va ieși conform pretențiilor inițiale.

Proiectul a decurs normal și fără întârzieri. Clientul a organizat chiar și un audit la final, nu mă întrebați de ce la final, concluzia fiind că nu mai văzuseră un produs de o asemenea calitate. Totul pare ca în povești, cu toate acestea am avut parte și de niște întâmplări mai puțin plăcute pentru client. Conform primelor negocieri, împreună cu aplicația trebuia să livrăm și:

• planul de calitate,
• un caiet de specificații detaliat,
• o documentație tehnică detaliată,
• cazurile de test,
• ghidul utilizatorului și
• ghidul de instalare.

Când clientul mi-a cerut să-i mut un buton de pe un formular din colțul dreapta-jos în colțul stânga-jos, am avut nevoie de două ore să fac o așa zisă analiză de impact a modificărilor. Ecranul fiind unul central se repeta de foarte multe ori în patru documente. I-am estimat schimbarea la două zile. Mi s-a părut jenant. L-am asigurat că poate să negocieze oricând cu noi și să renunțe la condițiile contractuale. N-a vrut. După calculele mele, pe întreaga perioadă a proiectului cineva a lucrat permanent la scrierea acestor documente detaliate, pe care nu le-a folosit sau citit nimeni vreodată. Nici măcar ghidul utilizatorului n-a fost folosit, aplicația fiind destul de intuitivă. Analiza și discuțiile erau necesare, dar fără toate documentele. Din cele 10 zile de specificații, 4 zile am lucrat cu clientul. Restul efortului fiind reprezentat de mutarea informațiilor din stenograme și transformarea schițelor de pe hârtie în diagrame. Nu numai că n-am avut întârzieri sau costuri suplimentare, dar puteam face același proiect cu cel puțin 20% mai ieftin dacă nu cumva și mai repede.

Ce aș face diferit?

Deși toată lumea a fost încântată de rezultatele acestui proiect aș face multe lucruri diferit. Mă voi rezuma însă strict la ceea ce ține de utilitatea ghidului de utilizator. Atunci când clientul își exprimă nevoile, verific cu el dacă într-adevăr există o utilitate suficient de mare în așteptările lui și i-aș vorbi de principiile dezvoltării în flux continuu:

• Cine va folosi acel ghid?
• Când?
• Cât de des?
• Documentul este cea mai bună formă?
• Ce s-ar întâmpla dacă livrăm produsul dar nu reușim să facem acel ghid?

Legat de documentația tehnică trebuie să conștientizăm că această necesitate a apărut în primul rând cu scopul de a face procesele și munca auditabile, nu dintr-o nevoie a clientului sau a echipei de dezvoltare. Dacă echipa vrea să documenteze ceva, cumva, va acționa în consecință.

Utilitatea documentației

Acest articol a fost citit de 2082 ori