Vo svete, kde sa funkciu dá navrhnúť, naprogramovať a nasadiť rýchlejšie než kedykoľvek predtým, najväčším problémom prestáva byť rýchlosť vývoja. Problémom sa stáva rozhodnutie, čo vlastne stojí za to vytvoriť.
Existuje moment v živote takmer každého rozvíjaného systému, keď zoznam funkcií začne žiť vlastným životom.
„Klient o to požiadal.“
„Konkurencia to má.“
„To asi nebude ťažké.“
„Keď už máme ten modul, pridajme ešte...“
„AI to spraví rýchlo.“
A zrazu ďalšia funkcia putuje do backlogu. Potom ďalšia. A ďalšia. Po niekoľkých rokoch má firma aplikáciu, ktorá vie takmer všetko. Lenže používateľ čoraz ťažšie nájde to, čo skutočne potrebuje.
Toto nie je výlučne problém UX. Je to obchodný problém.
Kedy viac funkcií prestáva znamenať lepší produkt
Roky vývoja softvéru mali relatívne jednoduchú logiku: ak používatelia potrebujú nové možnosti, pridáme nové funkcie. Znie to rozumne.
Problém nastáva, keď sa vývoj produktu zredukuje na počet doručených funkcií. Vtedy tím začne optimalizovať nie podľa hodnoty pre používateľa, ale podľa počtu vecí, ktoré sa podarilo „doviesť“.
Vzniká takzvaná Feature Factory – organizácia, ktorá produkuje ďalšie funkcionality, no nemusí merať, či skutočne riešia problémy klientov.
Tento jav nie je nový. Nové je tempo, v akom sa dnes môže rozvíjať.
AI výrazne skracuje cestu od nápadu k fungujúcemu prototypu. Atlassian opisuje zmenu priamo: s vývojovými agentmi sa cesta od „vieme, čo chceme postaviť“ k fungujúcemu prototypu môže skrátiť z týždňov na hodiny.
To je obrovská príležitosť. Ale aj pasca.
Pretože ak sa budovanie stáva lacnejšie a rýchlejšie, ľahšie je začať stavať veci, ktoré si predtým nikto neodvážil objednať.
„Ak môžeme, tak urobme“
To je jedna z najdrahších viet v IT projektoch. Nie preto, že každá ďalšia funkcia stojí majland. Problém je v tom, že funkcia nikdy nekončí svojim životom v momente nasadenia.
Každý nový modul treba neskôr udržiavať. Treba ho testovať. Treba ho zohľadňovať pri ďalších zmenách. Treba dokumentovať jeho fungovanie. Treba riešiť jeho chyby. Treba školenie používateľov. Treba zohľadniť ho v UX. Treba strážiť jeho bezpečnosť. Treba kontrolovať, či ďalšie zmeny v systéme niečo nepokazia.
Preto náklady na funkciu nie sú len náklady na jej vytvorenie. Je to aj náklad na jej budúcu existenciu.
A práve tieto náklady často nie sú viditeľné v momente, keď niekto povie:
„Tak možno pridajme ešte...“
Najdrahšia funkcia môže byť tá, ktorú nikto nepoužíva
Predstavme si firmu, ktorá vyvíja B2B panel.
Klienti môžu zadávať objednávky, kontrolovať históriu nákupov, sťahovať dokumenty a kontaktovať svojho opatrovateľa.
Objaví sa nápad na rozsiahly reportingový systém. Tím ho navrhne. Vývojári ho postavia. Vzniknú grafy, filtre, exporty, zostavy a desiatky dodatočných parametrov. Funkcia sa nasadí do produkcie.
A potom sa ukáže, že väčšina klientov chce jednoducho vedieť: koľko som nakupoval, čo je na ceste a aká je cena.
Všetko ostatné bolo predpokladom. Nepotrebujú to. To je veľmi dôležitý rozdiel.
Klient môže požiadať o funkciu. To ešte neznamená, že riešením jeho problému je táto funkcia.
„Konkurencia to má“
To je druhý klasik.
Firma analyzuje konkurenciu. Vidí nový modul.
A začína: „Musíme to mať tiež.“
Lenže konkurencia môže mať úplne iný obchodný model, inú cieľovú skupinu, iné predajné procesy a inú produktovú stratégiu.
Funkcia, ktorá dáva zmysel v jednom systéme, môže byť v inom úplne zbytočná.
To je obzvlášť dôležité v zákazkových projektoch. Neexistuje univerzálny súbor funkcií, ktorý spraví každú aplikáciu dobrú.
Systém pre priemyselného výrobcu by sa nemal navrhovať rovnako ako platforma pre vzdelávaciu spoločnosť.
CRM pre obchodníkov by nemalo fungovať rovnako ako B2B panel pre stálych klientov.
E-shop predávajúci prémiové produkty môže potrebovať úplne iný nákupný zážitok než obchod, ktorého hlavný argument je cena.
Softvér by mal vychádzať z obchodného modelu, nie z katalógu funkcií konkurencie.
AI tu mení naozaj veľa
A práve preto je táto téma dnes zvlášť zaujímavá.
Ešte pred niekoľkými rokmi musel nápad na novú funkciu prejsť mnohými etapami, kým ho používateľ mohol vidieť.
Analýza.
Návrh.
UX.
Vývoj.
Testy.
Nasadenie.
Dnes sa časť týchto etáp môže výrazne zrýchliť vďaka AI. Môžeme rýchlejšie vytvoriť prototyp. Rýchlejšie pripraviť rozhranie. Rýchlejšie napísať kód. Rýchlejšie vygenerovať testy. Rýchlejšie analyzovať dáta.
A práve preto rýchlosť vývoja prestáva byť sama o sebe dostačujúcou výhodou.
Ak každý môže rýchlejšie niečo postaviť, výhodu začne mať ten, kto lepšie vyberá, čo postaviť.
Atlassian vo svojej štúdii o budúcnosti product managementu upozorňuje na tento paradox: AI zvyšuje tempo práce, no samotné zvýšenie tempa ešte nezaručuje lepšie produkty. Zároveň 89 % respondentov z manažmentu uviedlo zvýšenie rýchlosti práce vďaka AI, zatiaľ čo len 6 % sa cítilo istých pri určovaní konkrétneho ROI AI v celej organizácii.
To veľmi dobre ukazuje rozdiel medzi robiť rýchlejšie a dosahovať lepší výsledok.
Najprv problém. Až potom funkcia
Dobrý produktový proces by mal začínať otázkou: Aký problém sa snažíme vyriešiť?
Nie: „Ktorú funkciu máme pridať?“
Zdá sa to ako malý rozdiel. V praxi to mení všetko.
Ak klient povie: „Potrebujeme mobilnú aplikáciu“,
stojí za to spýtať sa: Prečo?
Možno naozaj potrebuje aplikáciu. Ale možno je problém v tom, že chýba pohodlný prístup k panelu na telefóne. Možno stačí dobre navrhnuté responzívne rozhranie. Možno PWA. Možno mobilný modul jedného procesu. Alebo aplikácia je potrebná, len z úplne iných dôvodov, než klient pôvodne uviedol.
Rovnako to funguje s funkciami.
„Potrebujeme automatické reporty.“ – Prečo?
„Lebo obchodníci strácajú čas.“ – Na čom?
„Na prepisovaní dát zo systému.“
A zrazu sa ukáže, že problémom nie je nedostatok reportov. Problémom je chýbajúca integrácia.
Dobrá analýza dokáže ušetriť mesiace vývoja.
Niekedy je najlepšou funkciou jej absencia
Znie to paradoxne, no práve taká by mala byť úloha skúseného technologického partnera.
Nielen realizovať. Tiež spochybňovať zadania, keď na to existuje dôvod.
Ak klient príde so zoznamom dvadsiatich funkcií, software house by ho nemal automaticky brať ako technickú špecifikáciu vyrytú do kameňa.
Mal by sa opýtať: Ktoré z týchto funkcií riešia reálny problém? Ktoré sú kritické? Ktoré zvyšujú predaj? Ktoré skracujú prácu? Ktoré zlepšujú zákaznícku podporu? Ktoré sú požadované právne alebo operačne? Ktoré sú len „fajn doplnok“?
A predovšetkým: Ako zistíme, že daná funkcia bola úspešná?
Bez tejto poslednej otázky je ľahké vytvoriť produkt, ktorý neustále rastie, no nikdy nie je jasné, či sa skutočne zlepšil.
Produkt by mal vedieť povedať „nie“
V dobrom product developmente je rovnako dôležitý zoznam vecí, ktoré postavíme, ako zoznam vecí, ktoré nestavia. To vyžaduje odvahu.
Lebo ľahko povedať: „Áno, urobíme to.“
Ťažšie je povedať: „Na základe toho, čo vieme, ešte nevidíme dôvod, aby sme za to platili.“
Ešte ťažšie je povedať to klientovi, ktorý práve prišiel s hotovým nápadom.
Ale práve vtedy začína partnerská spolupráca.
Software house by nemal byť len tímom, ktorý premieňa príkazy na kód. Mal by pomáhať klientovi robiť technologické rozhodnutia.
Niekedy to znamená navrhnúť funkciu.
Niekedy ju zjednodušiť.
Niekedy ju nahradiť iným riešením.
A niekedy úplne zrieknuť nápadu.
Ako rozpoznať funkciu, ktorú pravdepodobne nepotrebujete?
Neexistuje jeden magický test, ale niekoľko otázok dokáže rýchlo schladiť entuziazmus.
Kto konkrétne z toho bude využívať?
Ak odpoveď znie „všetci“, stojí za to upresniť.
Aký problém riešime?
Ak odpoveď znie „bude to pohodlnejšie“, problém pravdepodobne potrebuje ďalšiu analýzu.
Ako často bude používateľ túto funkciu využívať?
Raz za rok? Raz za mesiac? Denne?
Existuje jednoduchší spôsob riešenia toho istého problému?
Táto otázka je obzvlášť dôležitá.
Ako zmeráme efekt?
Viac predaja? Menej práce? Kratší proces? Menej chýb? Vyššia retencia?
Čo sa stane, ak túto funkciu nepostavíme?
Ak odpoveď znie „vlastne nič“, možno sme práve našli funkciu, ktorú netreba budovať.
Nebude každá požiadavka používateľa putovať do backlogu
To je tiež dôležitá mentálna zmena.
Feedback od používateľov je bezcenný. Ale feedback nie je automatická produktová špecifikácia.
Používateľ hovorí o svojom probléme cez prizmu vlastnej skúsenosti.
Môže povedať: „Potrebujem tlačidlo X.“
Úlohou produktového tímu nie je bezreflexné vytvorenie tlačidla X.
Úlohou tímu je pochopiť: prečo používateľ to tlačidlo potrebuje.
Až potom možno rozhodnúť, či je najlepším riešením naozaj tlačidlo X.
Môže to byť automatizácia.
Môže to byť integrácia.
Môže to byť zmena procesu.
Môže to byť lepšie rozhranie.
Môže to byť vzdelávanie používateľa.
A niekedy naozaj nová funkcia.
To je rozdiel medzi feature delivery a product development.
Dáta tiež môžu povedať: „odstráňme to“
Vývoj produktu by nemal končiť pridávaním.
Treba sa tiež pozerať na to, čo už existuje.
Ktoré funkcie sa používajú?
Ktoré sú ignorované?
Kde používatelia vypadávajú?
Ktoré procesy zaberajú najviac času?
Ktoré prvky generujú najviac ticketov do supportu?
Ktoré funkcie zvyšujú konverziu?
A ktoré len komplikujú rozhranie?
Niekedy najlepší rozvojový projekt nie je pridanie ďalšieho modulu. Je ním odstránenie troch zbytočných. To môže zlepšiť UX viac než ďalší mesiac vývoja.
AI tu môže tiež pomôcť
Zaujímavé je, že AI nemusí slúžiť iba na tvorbu funkcií.
Môže tiež pomáhať v analýze, či funkcie dávajú zmysel.
Môže analyzovať feedback používateľov.
Zoskupovať hlásenia.
Detegovať opakujúce sa problémy.
Analyzovať dáta zo supportu.
Zhrnúť rozhovory s klientmi.
Pomáhať tímu porovnávať hypotézy.
Pripravovať varianty riešení.
Podporovať analýzu správania používateľov.
Teda paradoxne najlepšie využitie AI v product developmente môže niekedy spočívať nie v tom, že vďaka nej rýchlejšie postavíme ďalšiu funkciu,
ale v tom, že rýchlejšie zistíme, že ju stavať nemáme.
Web24: najprv sa pýtame „na čo?“
Každý softvérový projekt začína potrebou.
Niekedy klient presne vie, čo potrebuje.
Niekedy má už hotovú špecifikáciu.
Niekedy príde len s problémom: „Tento proces nám zaberá tri hodiny denne.“
A to je veľmi dobrý východzí bod.
Pretože potom môžeme premýšľať nielen o tom, ako naprogramovať navrhované riešenie, ale ako najlepšie vyriešiť ten problém.
To vlastne odlišuje tvorbu dedikovaného softvéru od skladania produktu z hotových funkcií.
Vo Web24 nejde o to, aby každá aplikácia mala čo najviac možností.
Ide o to, aby mala tie možnosti, ktoré sú naozaj potrebné danému biznisu.
Preto dva podobné systémy môžu vyzerať a fungovať úplne odlišne.
Lebo sa líšia procesy.
Lebo sa líšia používatelia.
Lebo sa líšia ciele.
Lebo sa líši spôsob predaja.
Lebo sa líši spôsob podpory klienta.
A líši sa aj problém, ktorý má softvér vyriešiť.
Najdrahší backlog je ten, ktorý nikto nevyzýva
V svete AI môžeme vstúpiť do veľmi zaujímavého štádia vývoja softvéru.
Technológia bude čoraz lepšie odpovedať na otázku: „Ako to postaviť?“
A človek bude musieť čoraz lepšie odpovedať na otázku: „Či to vôbec máme stavať?“
To môže byť jedna z najdôležitejších zmien vo vývoji softvéru.
Pretože ak klesnú náklady a čas na realizáciu ďalšej funkcie, pokušenie ich pridávať rastie.
A spolu s tým rastie význam Product Discovery, UX, analýzy dát, rozhovorov s používateľmi a strategického prístupu k vývoju produktu. Gartner upozorňuje, že rýchly vývoj produktov poháňaný AI môže viesť napríklad k problémom so strategickým zladením a rastom technického dlhu, ak technologické tempo nejde ruka v ruke s riadením produktu.
Preto budúcnosť nebude patriť výlučne firmám, ktoré dokážu stavať rýchlejšie. Bude patriť aj tým, ktoré dokážu lepšie vyberať, čo stavať.
Lebo niekedy najlepšie technologické rozhodnutie neznie: „Urobme ešte jednu funkciu.“
Ale: „Najprv overme, či ju skutočne potrebujeme.“
