Etapa Discovery sau etapa de descoperire a produselor și soluțiilor software este esențială pentru o companie de servicii IT care dorește să aibă succes, să livreze valoare și să dezvolte o relație de parteneriat cu clienții săi pentru a rămâne competitivă pe piață.De-a lungul experienței noastre de Product Consultant și UX/UI Designer în nearshoring am avut ocazia să fim promotori dar și să contribuim la schimbarea abordării în companie, de la mentalitatea centrată pe proiect spre cea orientată spre produs, prin introducerea fazei de Discovery.
În peste zece ani am avut ocazia să observăm numeroase exemple din ambele abordări. Printre ele, exemple perfecte pentru a ilustra diferența dintre construirea produsului corect (building the right product), spre deosebire de a construi doar corect produsul (building the product right).
Am întâlnit clienți cu o abordare tradițională (waterfall), care au petrecut trei ani pentru a aduna cerințe și care încă mai au dificultăți în crearea unei soluții funcționale și dezirabile, cu extra costuri și ducând o luptă constantă de gestionare a schimbărilor (change management).
În același timp, am avut ocazia să lucrăm cu clienți care au abordat dezvoltarea de produse digitale într-un mod iterativ, axându-se nu doar pe a construi produsul corect din punct de vedere tehnic, dar și pe a înțelege piața, utilizatorii și nevoile acestora pentru a se asigura că au în vizor nevoi reale.
În toate cazurile în care noi, furnizorul de servicii IT, am fost ghidați de o mentalitate centrată pe produs și am aplicat procesul de Discovery am văzut beneficii semnificative pentru ambele părți.
Mentalitatea centrată pe Produs este o abordare standard pentru companiile de produs, însă nu putem susține același lucru despre companiile care oferă servicii de IT.
Unii iau cerințele clientului dintr-o listă și le execută foarte bine, bazând totul pe asumpții, asigurându-se că livrează totul în scopul, timpul și bugetul agreat. În acest caz vorbim de mentalitatea orientată pe proiect (project mindset).
Alții aleg varianta în care urmăresc întâi să înțeleagă obiectivele, contextul și piața clientului, nevoile pe care le țintesc și pentru cine creează produsul, cu scopul de a se asigura că soluția dezvoltată aduce valoare și ajută clientul să-și atingă obiectivele. Toate acestea sunt abordate într-un mod iterativ, agil, care permite experimentarea, validarea și învățarea, descriind perfect o abordare orientată spre produs.
În aceste situații, ei devin consultanți și parteneri pentru clienții lor, dezvoltând o relație bazată pe încredere și lucrând împreună (co-creation) pentru a atinge obiectivele produsului și implicit cele de business. În acest caz, obiectivul nu se referă doar la livrarea în scopul, timpul și bugetul stabilit, ci ține cont dacă produsul dezvoltat este conectat la nevoile reale ale utilizatorului și îndeplinește obiectivele de business asociate.
Atât pe piața de outsourcing și nearshoring din Europa, cât și în contextul IT global, trendul este în favoarea schimbării către mentalitatea centrată pe produs ca un posibil model de diferențiere, de creator de plus valoare și de suport în inovație.
În Europa de Est există între 4.500 și 6.500 de furnizori specializați în externalizarea de software, iar munca remote a eliminat bariere geografice, aducând noi oportunități, dar și concurență globală pentru aceeași forță de muncă, făcând mai dificilă păstrarea angajaților de către companii.
Prin urmare, crearea de oportunități de creștere profesională sau dezvoltarea competențelor de consultanță în locul formării de simpli executanți contribuie la menținerea avantajului competitiv al brandului de angajator, mai ales într-o piață unde nu mai e suficient să concurezi doar pentru cel mai mic preț sau pentru cel mai mare salariu. De asemenea, e o abordare care va îmbunătăți reținerea angajaților calificați, luând în considerare cele trei elemente ale motivației, autonomie, măiestrie și scop, definite de Daniel Pink în cartea sa Drive.
Pentru orice soluție software există acum o alternativă pe piață, astfel că simpla existență a unui produs nu mai garantează succesul, cum o făcea acum 10-15 ani.
Tehnologii care păreau avansate doar cu câțiva ani în urmă, devin tot mai accesibile, chiar și în industrii mai tradiționale, precum cele bancare sau de prelucrare a materialelor. Experiența utilizatorilor sau modul în care tehnologia poate să rezolve probleme devin factori determinanți în succesul unei soluții software. Smartphone-urile și tehnologia sunt parte integrantă din viețile noastre, iar granițele dintre produse și servicii se contopesc în experiențe integrate. Se spune că ne aflăm în cea de-a patra revoluție industrială unde accentul cade pe colaborarea om-mașină, algoritmi, IoT și pe sporirea capacităților umane cu ajutorul tehnologiei. Produsele digitale sunt aici pentru a face viețile oamenilor mai ușoare sau pentru a îmbogăți capacitățile umane.
Astfel că, pentru a ține pasul, nu mai e de ajuns pentru companii ca acestea să se uite la software-ul vechi și să-l copieze cu o tehnologie modernă, ci ele au nevoie să își redirecționeze atenția spre exterior, spre piață și clienți pentru a le înțelege nevoile și pentru a identifica oportunități și nișe care pot fi exploatate.
Companiile care utilizează metodologii de design centrate pe om, cum ar fi design thinking, au venituri cu 32% mai mari și randamente ale acționarilor cu 56% mai mari, conform unui studiu McKinsey. Cu alte cuvinte, companiile care înțeleg bine nevoile din piață, care își ascultă clienții, validează și testează împreună cu ei într-un mod iterativ vor avea rezultate mai bune, inclusiv din punct de vedere financiar.
Faza de Discovery este o etapă concentrată în dezvoltarea unui produs sau a unei soluții digitale, utilizată pentru a defini produse și soluții fezabile din punct de vedere tehnic și care răspund la probleme sau oportunități ale clienților bazate pe obiectivele de afaceri.
Asta înseamnă că, înainte de a începe să scriem primele linii de cod, e nevoie să parcurgem câțiva pași esențiali. Aceasta se bazează pe o abordare bazată pe design thinking, punând accentul pe înțelegerea problemei înainte de a trece la soluții. Abia după ce plasăm problemele în context, definim viziunea produsului, obiectivele de afaceri, înțelegem nevoile utilizatorilor și pașii pe care aceștia trebuie să îi parcurgă pentru a-și atinge obiectivele, putem identifica zonele de oportunitate și defini soluțiile la nevoile din piață.
Se pune astfel, accentul pe parteneriatul dintre client și furnizorul de servicii prin folosirea metodelor de co-creație, în care aceștia colaborează în mod activ, pentru a crea și livra produse centrate pe utilizator.
Dar de ce e valoroasă această abordare?
Managementul produselor, după cum spune Marty Cagan, constă în abordarea a patru tipuri de risc atunci când dezvoltăm produse digitale:
Riscul valorii (value risk) - dacă clienții vor cumpăra produsul sau dacă utilizatorii vor alege să îl folosească;
Riscul de utilitate (usability risk) - dacă utilizatorii își pot da seama cum să folosească produsul;
Riscul de fezabilitate (feasibility risk) - dacă inginerii noștri pot construi ceea ce ne trebuie cu timpul, competențele și tehnologia de care dispunem;
Dar care sunt beneficiile, atât pentru client, cât și pentru furnizorul de servicii, de a începe o potențială colaborare cu o fază de descoperire?
Abordarea celor patru riscuri de produs menționate permite schimbarea cursului înainte de a investi resurse în dezvoltare. Despre asta este vorba, de fapt, în Lean Startup și agile: "fail fast, fail often".
Este un mod rapid de a-și forma o idee despre modul de lucru al furnizorului de servicii, despre echipa acestuia și despre capacitățile sale.
Este startul perfect pentru a pune bazele unei relații bazate pe încredere.
Va primi rezultate palpabile, care pot fi ulterior folosite indiferent de relația contractuală: viziunea produsului, informații esențiale despre utilizatorii și nevoile abordate, roadmap, definirea soluției (prin user story maps, user flows sau mockups), propunere de abordare tehnică și abordare de livrare;
Este primul pas în construirea încrederii atât de necesară cu clientul.
Ajută la identificarea clară a stakeholderilor, a poziționării acestora și la crearea cadrului pentru managementul așteptărilor.
Contribuie la identificarea necunoscutelor încă din fază incipientă, care sunt adesea omise în abordarea clasică de management de proiect.
Reduce riscul de derapaj al proiectului, abordând în avans aspectele relevante.
Clarifică aspectele legate de domeniul de business, de produs și skillurile de care are nevoie furnizorul de servicii pentru a adăuga valoare colaborării.
Asigură o poziționare în rolul de consultant și contributor, nu în rolul de executant.
Obține angajamentul ambelor părți privind pașii următori.
Identifică limitările colaborării în materie de timp, buget și scop.
Cu toate că nu este singurul model, pentru prezentul articol vom vorbi despre workshopuri, care au loc la începutul colaborării sau de fiecare dată când începe o fază nouă într-un proiect. Vom răspunde mai jos unei serii de întrebări referitoare la aceste workshopuri pentru a oferi o imagine cât mai clară.
Primul moment în care recomandăm organizarea de Discovery workshopuri este chiar în faza de pre sales, adică înainte de a crea oferta pentru client. Deși ați putea alege să îl oferiți gratuit, precizăm că experiența noastră ne-a arătat că, dacă clientul îl plătește, acesta va fi mai implicat și îl va percepe ca fiind mai valoros. De asemenea, poziționează furnizorul de servicii ca expert, fiind vorba de investiție din ambele părți.
Workshopurile de Discovery nu sunt însă un lucru care se întâmplă o singură dată. Veți dori să le organizați de fiecare dată când începe o nouă fază a proiectului.
Din partea clientului:
Sponsorul proiectului;
Factorul de decizie (Project Manager, Program Manager, Product Owner) - care are un cuvânt de spus în ceea ce privește produsul și direcția acestuia;
Un reprezentant al utilizatorilor (atenție! utilizatori, nu cumpărători). Deoarece știm că acest lucru nu este întotdeauna ușor de realizat, asigurați-vă că aveți un reprezentant al utilizatorilor în sală - acesta este, de obicei, cineva din vânzări sau chiar un Product Manager / Product Owner care este în strânsă legătură cu utilizatorii.
Software architect / responsabil tehnic;
Doriți să aveți prezente din partea furnizorului de servicii toate rolurile care vă vor ajuta să acoperiți toate cele patru tipuri de riscuri menționate mai sus, chiar dacă nu veți avea toate rolurile în echipa de livrare sau clientul nu le-a cerut în mod expres. Este, de asemenea, un moment excelent pentru a vă prezenta capacitățile și de a vă întări poziția de expert.
Product Owner / Proxy Product Owner / Business Analyst;
UX/UI Designer;
Delivery Manager / Project Manager;
Limitați numărul de participanți la un workshop. Țineți cont de regula celor două pizze. Un workshop cu mai mult de 8-9 participanți poate deraia rapid. E nevoie doar de oamenii esențiali pentru a aduce cele patru perspective în jurul mesei și pentru a lua decizii. Legea lui Brooke spune: cu cât participă mai multe persoane la conversație, crește exponențial numărul liniilor de comunicare și totul devine mai greoi.
Puteți avea, de asemenea, invitați care să vină doar în anumite momente cheie - cum ar fi un delivery manager în prima parte pentru bun venit sau specialiști tehnici pentru discuțiile foarte tehnice.
Discovery workshopuri pot avea loc atât online, cât și în persoană.
În cazul în care alegeți să organizați workshopul în persoană - vă recomandăm să acordați 2 - 3 zile întregi. Nu planificați mai mult de șase ore de lucru efectiv pentru o zi și începeți cu o pauză de cafea mai lungă dimineața, deoarece oamenii sunt dornici să socializeze. De asemenea, trebuie să vă asigurați că includeți activități energizante dimineața și după prânz, împreună cu pauze de cafea mai lungi - 10 minute nu sunt de obicei suficiente - mai bine 15-20 de minute.
Recomandarea noastră este să invitați clienții la voi - în felul acesta pot cunoaște echipa și modul de lucru, dar mai aduce un beneficiu - faptul că nu sunt la ei la birou va ajuta ca ei să fie mai focalizați pe workshop și nu pe problemele care îi așteaptă în pauză în birou.
Pentru workshopurile online, recomandăm mai multe sesiuni a câte 3 ore (minim 3), repartizate pe mai multe zile.
Faceți-vă temele - cercetați compania, utilizatorii, industria și produsul. Dacă este posibil, cercetați, de asemenea, concurența sau ce fac produsele similare, anumite aspecte sau abordări tehice.
Întotdeauna folosiți call-urile de calibrare cu clienții înaintea workshopului pentru a vă asigura că așteptările sunt clare și gestionate, actualizați agenda și asigurați-vă că o împărtășim cu toți cei implicați - atât din partea clientului, cât și din partea dumneavoastră - și asigurați-vă că blocați calendarele.
Ceea ce ar trebui să ghideze agenda workshopului sunt cele patru riscuri principale legate de produs. Găsim mai jos o serie de întrebări la care ar fi ideal să răspundeți în timpul workshopului și care vă pot ajuta să structurați agenda.
Pentru a vă ajuta să începeți, iată un exemplu de agendă pentru un atelier de lucru de două zile în persoană pentru o soluție greenfield dezvoltată de la 0. E important să începem de la un cadru mai larg și să facem zoom in pe măsură ce înaintăm în workshop.
Fie că este online sau offline, o tablă digitală în Miro (sau orice alt instrument digital de whiteboarding cum ar fi Miro, Figjam) este întotdeauna foarte utilă. Chiar și în cazul workshopurilor în persoană, ni s-a întâmplat ca cineva să fie nevoit să se alăture online în ultimul moment din diverse motive. Desigur, acest lucru nu este ideal, dar faptul că sesiunile de colaborare se desfășoară direct pe o tablă Miro reduce decalajul dintre persoanele care participă în persoană și cele care sunt online.
Am mai auzit acest lucru, chiar și cu colegii noștri după ce am vorbit despre Discovery - "sună foarte bine, dar nu va funcționa niciodată aici". Ei bine, ghiciți ce? Când am început, nici la noi nu a funcționat, dar avem câteva sfaturi pentru început.
Începeți la scară mică - cu un mini discovery workshop cu echipa sau pe un proiect intern. Apoi, rezultatele se pot transforma într-un studiu de caz.
Găsiți aliați - găsiți colegi care vor să încerce acest lucru sau care au făcut acest lucru la un loc de muncă anterior, apoi aduceți colegi manageri ca ambasadori. Acest lucru vă va crește credibilitatea.
Nu vă concentrați doar pe cerințe - dacă vă concentrați doar pe enumerarea cerințelor, ați ratat întregul scop al fazei de Discovery. Nu uitați, vrem să ajutăm clientul să abordeze toate cele patru riscuri ale produsului și nu puteți face acest lucru doar trecând printr-o listă de cerințe, fără să înțelegem nevoile și obiectivele din spate. Împreună cu echipa, aveți nevoie de mai mult context pentru a putea propune și cele mai bune soluții și idei. Am primit de mai multe ori feedback din partea clienților cum că au apreciat faptul că am vrut să înțelegem nevoia din spate și să dezvoltăm o soluție care să ia în seamă nevoile.
Just do it - În unele situații este mai bine să nu așteptați prea mult timp pentru a face ceva. Doar încercați, vedeți unde vă duce. Un lucru pe care l-am făcut odată a fost să desfășurăm un Design Sprint cu un grup de oameni fără să îl denumim "Design Sprint" - am definit doar așteptările și agenda.
Aplicând faza de Discovery și o mentalitate centrată pe produs, am adus beneficii și plus valoare atât companiei noastre cât și clienților. Am dezvoltat un set de bune practici care au fost adoptate pe toate proiectele, dar asta nu s-a întâmplat peste noapte. E nevoie de răbdare și perseverență pentru a standardiza abordarea și a-i demonstra valoarea.
În cele din urmă, ne dorim ca experiența noastră să vă inspire în a dezvolta propria fază de Discovery cu obiectivul de a construi relații bazate pe încredere cu clienții voștri, cu obiectivul comun de a dezvolta produse conectate la nevoi reale ale utilizatorilor, să susțină obiectivele de business și să fie fezabile din punct de vedere tehnic.