În 2006 am avut șansa să lucrez alături de un client care m-a învățat multe din lucrurile despre care vorbesc astăzi. Benoit Gantaume, directorul tehnic din partea clientului, era un mare entuziast XP. Tipul era interlocutorul nostru principal. Nu prea înțelegeam eu despre ce vorbea el când venea vorba de Agile, însă cel mai ciudat aspect al colaborării noastre era faptul că nu aveam voie să acceptăm defecte. La început mi s-a părut utopic. Cum adică? Fără bug-uri? Nu credeam că se poate. Produsul la care lucram era o aplicație portabilă făcută în C++. Clientul vindea câte 7.000.000 (șapte milioane :D) de licențe în fiecare trimestru și refuza cu încăpățânare să-și facă un serviciu de suport pentru utilizatorii de pe întreg mapamondul. Și mai ciudat a fost că toată organizarea aceea funcționa. Timp de doi ani de zile am avut doar două defecte întoarse din mâinile utilizatorilor. Acestea au fost izolate și foarte greu de reprodus. Cădea cerul pe pământ când se întâmpla, însă chiar și așa, vorbim doar două defecte în doi ani de zile. La început credeam că-i nebun sau zgârcit. Mai târziu mi-am dat seama că era doar un client mai deștept ca mine.
Secretul consta tocmai în filozofia clientului de a nu accepta defecte. De îndată ce descopeream o problemă în timpul dezvoltării trebuia să facem în așa fel încât acea problemă să nu mai apară niciodată. Este la fel de drept că am pornit foarte greu proiectul, mai ales până ne-am învățat cu filozofia TDD, CPPUnit și multe altele.
Când am trecut la ISO 9001, am pierdut acest aspect important din vedere. Era implicită nevoia gestiunii de defecte, iar eu eram prea necopt să conștientizez subtilele diferențe. Am avut în continuare proiecte de o calitate foarte bună, dar nu mai atinsesem performanța din 2006.
În 2009, în cartea Scaling Lean & Agile Development a lui Craig Larman, am auzit pentru prima dată de conceptul „Oprește și rezolvă” (Stop and Fix). „Managerii de la Toyota sunt antrenați de managerii-profesori să-și aloce timpul necesar opririi liniei de producție când apar defecte sau probleme. În loc să găsească o soluție rapidă la problemă (sau să treacă peste aceasta), o echipă declanșa un eveniment kaizen pentru a înțelege rădăcinile cauzei și să inițieze pașii necesari găsirii unei soluții solide – una care în mod ideal ar trebui să împiedice defectele sau slăbiciunile să mai apară, și deci să crească calitatea.”
Așa am învățat diferența dintre „Calitatea este foarte importantă” și „Calitatea este cel mai important slogan al nostru”. „Toyota este faimoasă pentru principiul opririi liniei de producție prin care oricine poate să tragă de un cordon când vede un defect și să oprească toată munca pe acea linie. Acesta este un pas către un răspuns sistematic în construirea produselor de calitate. Un alt exemplu: Toyota încurajează crearea dispozitivelor capabile să detecteze ele singure erorile, să oprească singure linia de producție și să alerteze muncitorii de problema găsită…Această practică lean se numește jidoka.”
Echipele agile își apropie mottoul „Calitatea este foarte importantă”. Se vor opri din dezvoltare de îndată ce descoperă o problemă și o rezolvă. Răspunsul la întrebarea cine este responsabil cu calitatea produsului final? trebuie să fie echipa de dezvoltare, nu un alt departament, manager sau o altă echipă. Managerii sunt adesea un magnet de muncă inutilă și atrag „gestiunea de defecte” în ansamblul de procese, amânând astfel rezolvarea problemelor și auto-satisfăcându-se doar prin identificărea și cuantificarea acestora.
Calitatea este cel mai important slogan al nostru!
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 4108 ori