Într-o lume în care o funcție poate fi proiectată, programată și lansată mai repede ca oricând, cea mai mare problemă nu mai este viteza dezvoltării. Problema devine decizia: ce merită, de fapt, construit.
Există un moment în viața aproape fiecărui sistem dezvoltat când lista de funcții începe să trăiască propria viață.
"Clientul a cerut asta."
"Concurența are."
"Probabil nu ar trebui să fie greu."
"Dacă avem deja modulul acesta, hai să mai adăugăm..."
"AI va face asta repede."
Și dintr-o dată o altă funcție ajunge în backlog. Apoi încă una. Și încă una. Peste câțiva ani firma are o aplicație care poate aproape orice. Doar că utilizatorul tot mai greu găsește ce are cu adevărat nevoie.
Aceasta nu este exclusiv o problemă de UX. Este o problemă de business.
Când mai multe funcții nu mai înseamnă un produs mai bun
Ani de zile dezvoltarea software-ului a avut o logică destul de simplă: dacă utilizatorii au nevoie de capabilități noi, adăugăm funcții noi. Pare rezonabil.
Problema începe atunci când dezvoltarea produsului este redusă la numărul de funcții livrate. Atunci echipa începe să optimizeze nu pentru valoarea pentru utilizator, ci pentru numărul de lucruri pe care „le-a reușit să le livreze".
Apare așa-numita Feature Factory – o organizație care produce funcționalități succesive, dar nu măsoară neapărat dacă ele rezolvă cu adevărat problemele clienților.
Acest fenomen nu este nou. Nou este ritmul în care se poate dezvolta astăzi.
AI scurtează foarte mult drumul de la idee la prototip funcțional. Atlassian descrie schimbarea clar: cu agenți de dezvoltare, drumul de la „știm ce vrem să construim" la un prototip funcțional se poate scurta de la săptămâni la ore.
Este o oportunitate uriașă. Dar și o capcană.
Pentru că dacă construirea devine mai ieftină și mai rapidă, devine mai ușor să începi să construiești lucruri pe care anterior nimeni nu ar fi îndrăznit să le comande.
"Dacă putem, hai să facem"
Este una dintre cele mai costisitoare fraze în proiectele IT. Nu pentru că fiecare funcție adițională ar costa o avere. Problema este că o funcție nu își încheie viața în momentul lansării.
Fiecare modul nou trebuie apoi întreținut. Trebuie testat. Trebuie luat în considerare la schimbările viitoare. Trebuie documentat. Trebuie gestionate bug-urile. Trebuie să instruim utilizatorii. Trebuie integrat în UX. Trebuie păstrată securitatea. Trebuie verificat dacă schimbările ulterioare nu strică ceva.
De aceea costul unei funcții nu este doar costul construirii ei. Este și costul existenței ei viitoare.
Și tocmai acest cost deseori nu se vede în momentul în care cineva spune:
"Poate mai adăugăm..."
Cea mai scumpă funcție poate fi cea pe care nimeni nu o folosește
Să ne imaginăm o firmă care dezvoltă un panou B2B.
Clienții pot plasa comenzi, verifica istoricul cumpărăturilor, descărca documente și contacta un manager de cont.
Apare ideea unui sistem complex de raportare. Echipa îl proiectează. Dezvoltatorii îl construiesc. Apar grafice, filtre, exporturi, rapoarte și zeci de parametri adiționali. Funcția ajunge în producție.
Și atunci se dovedește că majoritatea clienților vor pur și simplu să știe: cât am cumpărat, ce e în tranzit și care e prețul.
Tot restul a fost presupunere. Nu au nevoie. Asta e o diferență foarte importantă.
Clientul poate cere o funcție. Asta nu înseamnă automat că acea funcție rezolvă problema lui.
"Concurența are"
Un alt clasic.
Firma analizează concurența. Vede un modul nou.
Și începe: "Trebuie și noi să avem asta."
Doar că concurența poate avea un model de business complet diferit, un alt segment de clienți, alte procese de vânzare și altă strategie de produs.
O funcție care are sens într-un sistem poate fi complet inutilă într-altul.
Aceasta este important mai ales în proiectele custom. Nu există un set universal de funcții care să facă orice aplicație bună pentru toată lumea.
Un sistem pentru un producător industrial nu ar trebui proiectat la fel ca o platformă pentru o firmă de training.
Un CRM pentru reprezentanți de vânzări nu ar trebui să funcționeze la fel ca un panou B2B pentru clienți fideli.
Un magazin online care vinde produse premium poate avea nevoie de o experiență de cumpărare complet diferită față de un magazin ale cărui principale avantaje sunt prețul.
Software-ul ar trebui să decurgă din modelul de business, nu din catalogul de funcții al concurenței.
AI schimbă mult aici
Și tocmai de aceea subiectul e azi deosebit de interesant.
Acum câțiva ani, o idee pentru o funcție trebuia să treacă prin multe etape înainte ca utilizatorul s-o poată vedea.
Analiză.
Design.
UX.
Dezvoltare.
Teste.
Lansare.
Astăzi o parte din aceste etape poate fi semnificativ accelerată de AI. Putem crea mai repede un prototip. Mai repede pregăti interfața. Mai repede scrie cod. Mai repede genera teste. Mai repede analiza date.
Și tocmai de aceea viteza dezvoltării nu mai este singurul avantaj.
Dacă oricine poate construi ceva mai repede, avantajul îl are cel care alege mai bine ce să construiască.
Atlassian, în studiul său despre viitorul product management-ului, atrage atenția asupra acestui paradox: AI crește viteza muncii, dar creșterea vitezei nu garantează produse mai bune. Totodată, 89% din managerii chestionați au raportat creșterea vitezei datorită AI, în timp ce doar 6% s-au simțit siguri în a determina ROI-ul AI la nivel organizațional.
Asta ilustrează diferența dintre a face mai repede și a obține un rezultat mai bun.
Mai întâi problema. Abia apoi funcția
Un proces bun de produs ar trebui să înceapă cu întrebarea: Ce problemă încercăm să rezolvăm?
Nu: "Ce funcție ar trebui să adăugăm?"
Pare o diferență mică. În practică schimbă totul.
Dacă clientul spune: "Avem nevoie de o aplicație mobilă",
merită să întrebi: De ce?
Poate are, într-adevăr, nevoie de o aplicație. Dar poate problema e lipsa accesului comod la panou pe telefon. Poate e suficient un UI responsive bine proiectat. Poate un PWA. Poate un modul mobil pentru un singur proces. Sau poate aplicația este necesară, dar din motive complet diferite față de cele comunicate inițial de client.
La fel funcționează și cu funcțiile.
"Avem nevoie de rapoarte automate." - De ce?
"Pentru că oamenii de vânzări pierd timp." - Pe ce anume?
"Pe copierea datelor din sistem."
Și dintr-odată se dovedește că problema nu este lipsa raportului. Problema e lipsa unei integrări.
O analiză bună poate economisi luni de dezvoltare.
Uneori cea mai bună funcție e absența unei funcții
Sună paradoxal, dar acesta ar trebui să fie rolul unui partener tehnologic experimentat.
Să nu execute doar. Să și pună sub semnul întrebării ipotezele când există motive să o facă.
Dacă un client vine cu o listă de douăzeci de funcții, un software house nu ar trebui să o trateze automat ca pe o specificație tehnică bătută în piatră.
Ar trebui să întrebe: Care dintre aceste funcții rezolvă o problemă reală? Care sunt critice? Care cresc vânzările? Care reduc munca? Care îmbunătățesc serviciul pentru client? Care sunt cerințe legale sau operaționale? Care sunt doar „un plus drăguț"?
Și mai ales: după ce criterii vom ști că o funcție a avut succes?
Fără această întrebare finală e ușor să creezi un produs care crește mereu, dar niciodată nu se știe dacă devine mai bun.
Produsul trebuie să știe să spună „nu"
Într-un bun proces de product development la fel de importantă precum lista de lucruri de construit este lista de lucruri pe care nu le construim. Asta cere curaj.
E ușor să spui: "Da, vom face."
E mai greu să spui: "Pe baza a ceea ce știm acum, nu vedem încă motivul pentru a plăti pentru asta."
Și e și mai greu să spui asta clientului care tocmai a venit cu o idee gata formulată.
Dar tocmai atunci începe colaborarea de parteneriat.
Un software house nu ar trebui să fie doar o echipă care transformă comenzi în cod. Ar trebui să ajute clientul să ia decizii tehnologice.
Uneori asta înseamnă proiectarea funcției.
Uneori simplificarea ei.
Uneori înlocuirea ei cu o altă soluție.
Iar uneori renunțarea completă la idee.
Cum recunoști o funcție pe care probabil nu o nevoiești?
Nu există un test magic, dar câteva întrebări pot domoli rapid entuziasmul.
Cine anume va folosi concret asta?
Dacă răspunsul e „toată lumea", merită să-l detaliați.
Ce problemă rezolvăm?
Dacă răspunsul e „va fi mai convenabil", probabil problema necesită o analiză mai aprofundată.
Cât de des va folosi utilizatorul asta?
O dată pe an? O dată pe lună? Zilnic?
Există o soluție mai simplă pentru aceeași problemă?
Această întrebare este deosebit de importantă.
Cum vom măsura efectul?
Mai multe vânzări? Mai puțină muncă? Proces mai scurt? Mai puține erori? Retenție mai mare?
Ce se întâmplă dacă nu construim această funcție?
Dacă răspunsul e „practic nimic", poate tocmai am găsit o funcție care nu trebuie construită.
Nu orice cerere a utilizatorului trebuie să ajungă în backlog
Aceasta este și o schimbare mentală importantă.
Feedbackul utilizatorilor este neprețuit. Dar feedbackul nu este o specificație automată de produs.
Utilizatorul vorbește despre problema lui din perspectiva experienței proprii.
Poate zice: "Am nevoie de butonul X."
Rolul echipei de produs nu este să construiască fără reflecție butonul X.
Rolul echipei este să înțeleagă: de ce utilizatorul are nevoie de el.
Abia atunci se poate decide dacă cea mai bună soluție este într-adevăr butonul X.
Poate fi automatizare.
Poate fi integrare.
Poate fi schimbarea procesului.
Poate fi un UI mai bun.
Poate fi educația utilizatorului.
Iar uneori, cu adevărat, o funcție nouă.
Asta e diferența dintre feature delivery și product development.
Datele pot spune și ele: "ștergeți asta"
Dezvoltarea produsului nu ar trebui să se oprească la adăugare.
Trebuie să te uiți și la ce există deja.
Care funcții sunt folosite?
Care sunt ignorate?
Unde abandonează utilizatorii?
Care procese ocupă cel mai mult timp?
Care elemente generează cele mai multe solicitări către suport?
Care funcții cresc conversia?
I care doar complică interfața?
Uneori cel mai bun proiect de dezvoltare nu este adăugarea unui modul nou. Este ștergerea a trei inutile. Asta poate îmbunătăți UX mai mult decât încă o lună de dezvoltare.
AI poate ajuta și aici
Interesant, AI nu trebuie folosit doar pentru a crea funcții.
Poate ajuta și la analiza dacă funcțiile au sens.
Poate analiza feedbackul utilizatorilor.
Să grupeze raportările.
Să detecteze probleme repetitive.
Să analizeze datele din suport.
Să rezume convorbirile cu clienții.
Să ajute echipa să compare ipoteze.
Să pregătească variante de soluții.
Să susțină analiza comportamentului utilizatorilor.
Deci, paradoxal, cea mai bună utilizare a AI în product development poate fi uneori nu că ne ajută să construim mai repede o funcție,
ci că mai repede descoperim că nu ar trebui s-o construim.
Web24: întâi întrebăm „de ce?"
Fiecare proiect software pornește de la o nevoie.
Uneori clientul știe exact ce vrea.
Uneori are deja o specificație gata.
Uneori vine doar cu o problemă: "Acest proces ne ia trei ore pe zi."
Și acesta este un punct de plecare foarte bun.
Pentru că atunci putem reflecta nu la cum să codăm o soluție sugerată, ci cum rezolvăm cel mai bine problema.
Asta diferențiază dezvoltarea de software dedicat de asamblarea unui produs din funcții gata făcute.
La Web24 nu este vorba ca fiecare aplicație să aibă cât mai multe capabilități.
Este vorba ca ea să aibă doar acele capabilități care sunt cu adevărat necesare afacerii respective.
De aceea două sisteme asemănătoare pot arăta și funcționa complet diferit.
Pentru că procesele sunt diferite.
Utilizatorii sunt diferiți.
Obiectivele sunt diferite.
Metodele de vânzare sunt diferite.
Modul de suport pentru clienți e diferit.
Și problema pe care software-ul trebuie să o rezolve este diferită.
Cel mai scump backlog este cel pe care nimeni nu-l pune la îndoială
În lumea AI putem intra într-o etapă foarte interesantă a dezvoltării software-ului.
Tehnologia va răspunde din ce în ce mai bine la întrebarea: "Cum să construim asta?"
Iar oamenii vor trebui să răspundă din ce în ce mai bine la întrebarea: "Ar trebui, oare, să construim asta?"
Aceasta poate fi una dintre cele mai importante schimbări în crearea de software.
Pentru că dacă costul și timpul de realizare a unei funcții scad, ispita de a le adăuga crește.
Iar odată cu ea crește importanța Product Discovery, UX, analizei datelor, discuțiilor cu utilizatorii și a unei abordări strategice a dezvoltării produsului. Gartner avertizează că dezvoltarea rapidă a produselor alimentată de AI poate conduce, printre altele, la probleme de aliniere strategic și creștere a technical debt dacă ritmul tehnologic nu este susținut de managementul produsului.
De aceea viitorul nu va aparține exclusiv firmelor care știu să construiască mai repede. Va aparține și celor care știu mai bine să aleagă ce să construiască.
Pentru că uneori cea mai bună decizie tehnologică nu sună: "Hai să mai facem o funcție."
Ci: "Să verificăm mai întâi dacă chiar avem nevoie de ea."
