Cele mai mari succese în business coincid cu statutul de a fi în vârful ierarhiei pieței, după ce ai făcut față unora dintre cele mai mari provocări precum abilitatea de a dejuca planurile adversarilor direcți și adaptabilitatea cât mai rapidă la condiții noi. Domeniul cel mai tehnologic oferă atât povești de succes cât și eșecuri. Prima mare rețea de socializare, Friendster, a fost “păcălită” de către cei de la Myspace, care la rândul lor au fost “păcăliți” de cei de la Facebook. Netscape au fost “păcăliți” de cei de la Yahoo!, care la rândul lor au fost “păcăliți” de cei de la Google. Cu toții știm că aceste situații nu se termină aici, și, undeva, într-un subsol sau garaj, cineva lucrează la următorul “big thing” care ar putea deveni cel mai mare actor pe piață.
Toate companiile mici și mijlocii doresc să crească într-un timp foarte scurt, să devină tot mai complexe în organizare și să poată să manevreze cât mai ușor situațiile neașteptate, pentru a putea să reacționeze cât mai ușor la cererile clienților din piață. Este foarte important să se poată adapta cât mai repede și cât mai ușor la schimbările propuse și impuse de către clienții din piață. De fapt, singura variabilă constantă rămâne schimbarea. Cu cât reușim mai repede să ne adaptăm, cu atât vom avea mai mult timp să progresăm, reușind să furnizăm servicii premium la timp.
Cu permisiunea dumneavoastră, pentru a simplifica și mai mult traducerea și interpretarea pe mai departe, aș dori să considerăm următoarea convenție, în cazul celor doi termeni din limba engleză - outcome și output – utilizați în rândurile următoare:
Output – un produs/rezultat finit așteptat și agreat de beneficiar;
Outcome – un produs/rezultat finit care adaugă valoare mare la beneficiar mergând spre zona de satisfacție mare .
Ce-ar putea schimba și ne-ar putea diferenția de alții? Este suficient doar să livrăm ceva anume? Care este diferența între un output și un outcome? Există o distincție clară între cele două?
Mulți dintre noi ar crede sau ar considera, la prima vedere, că întrebările sunt mai mult retorice sau că nu ar exista nici o diferență relevantă între cei doi termeni.
Am putea da ca exemplu, diferența dintre mediocritate și a unui lucru care ar putea dura și ar aduce valoare în timp. Multe dintre companii sunt marcate de faptul că deciziile sunt luate pe baza lucrurilor care nu aduc neapărat valoare (output), în timp ce organizațiile mari încearcă să facă acest lucru luând în considerare, pe cât posibil, rezultatele care aduc și valoare mare în timp pentru clienți (outcome).
Dacă considerăm un simplu rezultat ca fiind extrinsec, și acele rezultate care aduc valoare adăugată clienților ca fiind intrinseci, cred că ar merita un efort în plus pentru a încerca să înțelegem mai bine semnificația fiecăruia dintre acestea.
În general, companiile măsoară succesul în termeni ca venituri și economii, ceea ce nu este cu nimic greșit, fiind chiar o practică comuna sau recomandată. Dar privind doar din această perspectivă, se omite interesul legat de motivul pentru care se face ceea ce se face. Se evită de fapt interesul pentru a înțelege ce dorește cu adevărat clientul și ce anume poate să-i aducă lui cu adevărat valoare. Dar pentru a găsi răspunsuri la aceste gen de întrebări și frământări, este nevoie de foarte multă colaborare, context favorabil, înțelegere între părți și respectarea principiilor agile de bază.
Din păcate, multe dintre companiile de outsourcing actuale, pun mai multă valoare pe “output” decât pe “outcome”. Practic, se pune accentul mai mult pe volum decât pe calitate. Tendința actuală este de a măsura cât de repede putem să satisfacem cerințele clientului. Sugestiv în acest sens este cazul echipelor agile unde se pune un accent deosebit pe indicatori de performanță ca număr total de “stories” finalizat sau număr total de “story points” finalizat pe durata unui interval de timp (vezi “sprint/iteration”). Un alt exemplu, în cazul echipelor “Lean”, se folosesc indicatori de performanță ca “cycle time” și/sau “lead time”. Practic, ideea de “output” conține numărul de linii de cod scris, numărul total de funcționalități finalizate.
Mulți reprezentanți marcanți în lumea Agile cred cu ardoare că merită investit timp în a găsi variante care să dea o nouă dimensiune proceselor agile. Se poate începe prin a reevalua forma curentă a “Agile Manifesto”, care există deja de cel puțin un deceniu. Cunoaștem deja ceea ce recomandă acest agile manifesto. Aceleași persoane direct implicate în acest fenomen, au început să observe că în zilele noastre, dacă nu aducem un plus la ceea ce am putea numi “software la cheie”, multe colaborări se vor deteriora sau se vor răci, ajungându-se la pierderea clienților existenți, aceștia îndreptându-se spre alte alternative. Cred că este important să oferim clienților acel WOW.
Din nou, cu permisiunea voatră, aș dori să deviez, mai mult sau mai puțin de la subiect, și să încerc să aduc câteva exemple care pot fi considerate modalități de a aborda puțin diferit forma curentă de exprimare Agile. Aceste exemple sunt inspirate din colaborarea personală, directă sau indirectă cu câteva persoane marcante în curentul Agile la nivel global (Ken Rubin, Mitch Lacey, Steve Denning, etc).
Aș începe cu favorita mea:
Scopul implicit în Agile manifesto ar fi “working software” care s-ar traduce în realizarea/producerea unui “output”. Chiar și finalizarea și release-ul unui “story” este considerat parte din output. În contrast, prin impresionarea unui client prin efectul de WOW, ne referim de fapt la “outcome” care poate fi considerat mai mult ca o experiență umană. Așadar, schimbarea mentalității de la “output” la “outcome” este fundamentală.
Cu toții cunoaștem faptul că în Scrum există o lungă discuție pe tema definirii termenului de “DONE” în cazul funcționalităților care trebuiesc livrate la final de sprint. Multe companii refuză însă să accepte faptul că funcționalitatea nu este completă până când clientul nu trăiește efectul de WOW.
Ideal, se consideră că metodologiile agile surprind plăcut clienții oferind efectul de WOW. Bineînțeles, toate acestea au un cost, iar acest cost este strâns legat de fiecare persoană implicată. Când persoanele direct implicate decid să părăsească organizația, se ajunge în punctul din care s-a plecat, făcându-se doar “software la cheie”. Este vital să se consolideze scopul definit și să se cunoască faptul ca acest scop este unul explicit.
Importanța măsurării gradului de satisfacție al clientului prin “Net Promoter Score” nu poate fi niciodată exagerată. Fără aceste măsurători, satisfacția clientului poate deveni o simplă afirmație. Ca urmare, organizațiile revin din nou la vechile priorități legate DOAR de partea financiară. Doar prin aceste măsurători, organizațiile își pot concentra atenția și pot atinge obiectivul de a satisface clienții prin efectul de WOW.
Mai sunt și multe alte abordări îmbunătățite a versiunii inițiale de “agile manifesto” care pot aduce rezultate uimitoare clienților, însă scopul articolului curent, nu face referire doar la acest aspect.
Revenind la subiectul principal, livrare cu efect de WOW, livrarea strategică ar fi considerată de mulți ca un efort colectiv în schimbarea percepției din a avea un număr mare de output-uri la o calitate mai bună a rezultatului (outcome). În loc să se concentreze pe producerea mai multor output-uri, tot mai multe persoane influente consideră ca țelul organizațiilor orientate pe servicii ar trebui să fie producerea de outcome-uri mai bune. Cheia ar putea fi înțelegerea și conștientizarea obiectivelor și outcom-urilor corecte, și apoi, găsirea celei mai coerente, simple și ieftine căi de a le realiza.
Am menționat la începutul articolului importanța manevrabilității simple și corecte. A fi obiectivi și concentrați pe outcome-uri, ajută oamenii în particular și companiile în general, să se adapteze rapid la schimbare și să iasă în față competitorilor.
Totul sună perfect până acum, dar marea încercare începe în momentul în care ne concentrăm să facem această schimbare de mentalitate și ajungem să ne întrebăm cum o facem de fapt.
Personal, cred că este alegerea fiecărei companii, folosind diferite unelte și concepte, dar trebuie să luăm în considerare o abordare care ar permite inovare rapidă, în ritm cu oportunitățile care apar mereu.
Există în mediul business o zicală: clientul are întotdeauna dreptate. Aceasta ar putea fi un principiu bun în unele situații, dar nu mai este suficient pentru situațiile și organizațiile de azi orientate pe servicii.
Cred că putem găsi o formulare mai bună și mai actuală: dacă nu ne ascultăm clienții, vom eșua, iar dacă ascultăm numai de clienții noștri, vom eșua.
Cu toții știm că doleanțele clienților sunt transformate într-o listă de cerințe numită backlog în lumea agile, care este prioritizată. Apoi, noi încercăm să realizăm acele părți despre care credem că vor îndeplini acele cerințe. Toate echipele fac acest lucru din nou și din nou, cu o concentrare colectivă pe prioritizarea și realizarea și mai multor cerințe într-un mod din ce în ce mai eficient. Dar este un lucru chiar responsabil, având în vedere că în final dezvoltăm ceea ce ne cer clienții. Așadar ce ar fi greșit? Toți directorii de pe partea de business vor fi satisfăcuți.
Mulți dintre noi pun semnul egal între dezvoltarea cerințelor și succesul în piață, așadar echipele se concentrează rapid pe designul, dezvoltarea și testarea soluțiilor care îndeplinesc cerințele, în loc să încerce să înțeleagă pe deplin problemele și cauzele lor sau dorințele ascunse în backlog. Până când oamenii nu înțeleg pe deplin ce încearcă să rezolve, nu vor putea să găsească cel mai bun mod de a rezolva acea problemă. Până când o organizație nu înțelege pe deplin care sunt obiectivele pe care dorește să le atingă și ce fel de outcom-uri dorește să prezinte, nu poate să înțeleagă ce oportunități să urmărească. Ca să dezlegăm acest mister, trebuie să știm ce se întâmplă, de ce se întâmplă și cine se confruntă cu ce probleme.
Outcom-ul muncii noastre este cel care contează cu adevărat. Cu toții intuim că obiectivul nostru nu este să dezvoltăm 10 funcționalități, ci să îmbunătățim viețile clienților noștri cât de bine putem. Pentru a realiza acest lucru, trebuie să ne concentrăm asupra outcom-ului și a impactului pe care îl va avea munca noastră asupra utilizatorilor produselor noastre.
Totuși, nu putem să ne limităm gândirea numai asupra outcom-ului. Ca să avem cel mai mare impact posibil asupra vieților clienților noștri, trebuie să lucrăm activ pentru a minimiza output-urile în timp ca să maximizăm outcom-urile sau valoarea serviciilor noastre. Ca ingineri, ne concentrăm mereu pentru a crește output-ul echipelor noastre.
Cu fiecare “story”, țintim să înțelegem valoarea pe care încercăm să o dăm clienților noștri, ceea ce în general se traduce prin crearea unui produs minim viabil (conceptul cunoscut de toată lumea, MPV).
Este foarte important să facem alegerea corectă și să începem dezvoltarea “story”-ului potrivit. Chiar dacă, această alegere și această decizie sunt în principal responsabilitatea unui “product owner”, eu sunt adeptul ideei conform căreia și noi ca ingineri putem să aducem o contribuție foarte importantă prin simplul fapt de a ne întreba “alegem sau nu să dezvoltăm acele story-uri, punând în balanță efortul necesar și valoarea rezultată, astfel încât să avem cel mai mare impact asupra vieților clienților noștri ?”
Care va fi cea mai bună alegere pentru noi: să dezvoltăm 10 lucruri mediocru sau doar 5 dar sclipitoare ?
Bucla Mobius, descoperită de matematicienii germani August Ferdinand Mobius și Johann Benedict (conform Wikipedia, o fâșie Mobius este o “suprafață cu o singur plan și o singură componentă ca și limita”), arată ca o buclă continuă cu o răsucire în mijloc. Această buclă poate reprezenta fluxul constant de informație care ar trebui să existe într-o organizație pentru a explica cu claritate obiectivele companiei la toate nivele ei.
În bucla Mobius, putem începe oriunde considerăm că situația o cere, dar e foarte important să se înceapă cu o înțelegere clară a problemei sau a situației, și după aceea, putem să aprofundăm înțelegerea. Pot fi situații în care putem avea de la început un set definit de opțiuni și trebuie să ne uităm înapoi pentru a fi siguri că avem o foarte bună înțelegere a problemei sau a situației.
Cu bucla Mobius în minte, ca o alternativă la modul tradițional al businessului, putem oferi transparență asupra luării deciziilor și a investițiilor. Acest lucru aduce un adaos important pentru a putea urmări investițiile și a verifica dacă acestea aduc valoarea dorită sau dacă ar trebui ca aceste investiții să fie făcute în alte arii (această schimbare ar fi vizibilă prin reprioritizarea listei de story-ri în backlog).
Nu este ușor să ne motivăm oamenii să facă această schimbare de mentalitate către crearea de outcom-uri. Mulți tind să rămână în zona lor de confort. Poate e mai potrivit ca această schimbare să se facă în paralel, încercând să se pună accentul treptat pe outcom-uri.
Cu ajutorul lui Gabrielle și al lui Ryan, am descris mai jos câteva din beneficiile, principiile și pașii pe care această mentalitate bazată pe outcom-uri le include și cere.
Idei multiple pot fi testate într-un timp scurt, influențând astfel deciziile luate având în vedere aceste rezultate palpabile și nu doar previziuni.
Realizând doar minimul necesar pentru a avea un produs viabil, scurtăm timpul până la ieșirea pe piață.
Investițiile sunt făcute în tranșe, reducând astfel riscurile și posibilitatea apariției unor costuri suplimentare neprevăzute.
Realizarea unui produs minim viabil înseamnă mai puțin cod sursă de dezvoltat și menținut, reducând costurile generice ale SDLC.
Mobius are la bază patru principii esențiale
Atenția sporită pe outcom-uri care aduc valoare, decât pe output-uri care aduc efort mărit.
Concentrarea echipelor de dezvoltare în rezolvarea problemelor și a urmăririi oportunităților de care beneficiază atât compania cât și clienții acesteia.
Măsurarea valorii în mod continuu pentru a asigura că se merge în direcția corectă.
Împuternicirea echipelor de dezvoltare pentru a atinge outcom-urile propuse în cadrul constrângerilor existente.
Mobius are 7 pași care lucrează împreună (ce întrebări trebuie să punem și să răspundem)
Problema sau oportunitatea - ce problemă încercăm să rezolvăm și ce oportunitate dorim să urmărim?
Outcome-uri - care sunt cele mai importante outcome-uri pe care urmează să le îmbunătățim ?
Profunzime - descoperirea amănuntelor problemei sau alte oportunități.
Opțiuni - care sunt opțiunile curente pe care le avem pentru a putea îmbunătăți cele mai importante outcome-uri?
Livrarea - livrăm cea mai optimă opțiune incremental și învățăm din ea.
Măsurare - cât de mult am mișcat acul balanței ?
Adaptabilitate - ar trebui să continuăm pe direcția de acum, sau ar trebui să ne schimbăm opțiunile?
În final, aș dori să recomand tuturor, să continuăm să îmbunătățim ajustările proceselor agile, prin a analiza și revizui versiunea actuală a Agile Manifesto, pentru a reuși să identificăm neajunsurile și a reuși sistematic să le îndepărtăm.
Dacă nu ne ascultam clienții vom eșua, iar dacă ne ascultăm numai clienții, vom eșua!
Mike Cohn - “Coaching Agile Teams” Mike Cohn - “User Stories Applied” Mitch Lacey - “The Scrum Field Guide” Steve Denning - “The Leader’s Guide to Radical Management” Gabrielle Benefield & Ryan Shriver - “Mobius - Create, deliver and measure value” http://www.mobiusloop.com
de Ovidiu Mățan
