Najpomalším prvkom tvojej aplikácie môže byť... človek.
Keď firma povie, že jej aplikácia je pomalá, prvá reakcia je zvyčajne veľmi technická. Treba skontrolovať server. Databázu. API. SQL dotazy. Cache. Infraštruktúru. Veľkosť súborov. JavaScript. Čas odozvy jednotlivých služieb.
A je to úplne správne. Technical performance má obrovský význam.
Lenže niekedy všetky grafy vyzerajú dobre, server odpovedá rýchlo, aplikácia sa načíta v rozumnom čase a používatelia aj tak hovoria: "Trvá to príliš dlho."
A vtedy sa objaví zaujímavejšia otázka. Možno aplikácia vôbec nie je pomalá. Možno len núti človeka čakať.
2 sekundy odozvy, 20 minút práce
Predstavme si pracovníka, ktorý musí pripraviť ponuku pre klienta.
Systém funguje spoľahlivo. Každá obrazovka sa otvára rýchlo. Nie sú žiadne chyby. Server odpovedá takmer okamžite.
Lenže aby pripravil ponuku, pracovník musí: otvoriť klienta, prejsť do objednávky, skopírovať číslo produktu, otvoriť druhý modul, vyhľadať produkt, prepísať údaje, vrátiť sa na prvú obrazovku, vybrať kategóriu, prejsť na ďalšiu kartu, načítať ceny, ručne skontrolovať zľavu, skopírovať výsledok do Excelu a potom ho znova prepísať do systému.
Každá jednotlivá operácia môže trvať niekoľko sekúnd.
Technicky všetko funguje skvele. Lenže celý proces zaberie 20 minút.
A práve tu klasické chápanie výkonnosti prestáva stačiť.
Pretože používateľa nezaujíma predovšetkým čas odozvy API. Zaujíma ho čas potrebný na dokončenie úlohy.
Technical performance je len začiatok
Výkonnosť systému možno merať mnohými spôsobmi.
Môžeme analyzovať čas odozvy servera, čas načítania pohľadu, dotazy do databázy, využitie pamäte, zaťaženie procesora či oneskorenia medzi službami.
To sú veľmi dôležité metriky. Ale existuje ešte jedna vrstva.
Perceived performance, teda výkonnosť vnímaná používateľom.
A ešte širšie sa dá pozrieť na operational performance - teda na to, ako rýchlo a efektívne je človek schopný vykonať reálnu úlohu s použitím systému.
A práve na tejto poslednej vrstve firmy veľmi často strácajú najviac času. Pretože možno postaviť mimoriadne rýchlu aplikáciu, ktorá bude stále pomalým pracovným nástrojom.
Najpomalší systém sú niekedy sedem obrazoviek
Predpokladajme, že pracovník vybavuje reklamáciu.
Systém vyžaduje sedem krokov.
Najprv otvorenie klienta.
Potom objednávky.
Následne produktu.
Potom reklamačného formulára.
Potom kategórie problému.
Následne rozhodnutia.
Na konci potvrdenia.
Každá obrazovka sa načíta za 0,5 sekundy.
Z pohľadu developera môže všetko vyzerať veľmi dobre. Ale používateľ vykonal sedem prechodov, sedemkrát zmenil kontext a sedemkrát musel premýšľať, čo urobiť ďalej.
Ak takýchto operácií robí denne niekoľko desiatok, problém už nie je len otázkou pohodlia. Stáva sa nákladom. A nejde len o čas strávený pred obrazovkou. Pridáva sa únava, počet chýb, potreba opráv dát, prerušené úlohy a rastúca záťaž pracovníka.
Formulár so 40 poľami nie je rýchly len preto, že sa rýchlo otvára
To je jeden z klasických príkladov.
Formulár sa otvorí bleskovo. - Skvelé.
Lenže používateľ musí vyplniť 40 polí.
Časť informácií firma už má.
Časť sa dá načítať z CRM.
Časť sa dá vypočítať.
Časť závisí od predchádzajúcich odpovedí.
A napriek tomu sa systém človeka pýta na všetko znova.
Vtedy problémom nie je performance aplikácie.
Problémom je návrh procesu a rozhrania.
Dobrý systém by mal využívať údaje, ktoré už má.
Ak klient uviedol adresu doručenia pri predchádzajúcej objednávke, prečo ju má pracovník zadávať znova? Ak systém pozná firmu klienta, prečo má používateľ znova vyberať jej údaje? Ak odpoveď na prvú otázku vylučuje polovicu ďalších polí, prečo sú všetky viditeľné od začiatku?
Niekedy najlepší spôsob, ako zrýchliť aplikáciu, nie je optimalizácia kódu. Je odstránenie práce, ktorú používateľ nemá vykonávať.
Najdrahší je čas človeka vynásobený mierkou
Jedna dodatočná minúta sa môže zdať ako nič.
Pracovník vykoná operáciu 5-krát denne. - 5 minút.
Za mesiac sa z toho stane viac ako 1,5 hodiny.
Ale čo ak to robí 20 ľudí? Čo ak sa operácia vyskytuje 30-krát denne? Čo ak sa týka celého oddelenia? Čo ak sa systém bude používať ďalších päť rokov?
Potom sa jedna minúta prestáva javiť ako minúta. Stáva sa prevádzkovým nákladom.
Preto pri navrhovaní systému pre firmu sa oplatí pýtať sa nielen: "Ako dlho trvá odpoveď servera?"
ale aj: "Koľko času potrebuje človek, aby dokončil úlohu?"
Sú to dve úplne odlišné otázky.
Systém môže byť rýchly, ale proces pomalý
To je ešte širší problém.
Predstavme si nákupný proces vo firme.
- Pracovník podá žiadosť.
- Systém ju uloží okamžite.
- Ale potom musí čakať na schválenie nadriadeného.
- Nadriadenému príde správa.
- Otvorí systém.
- Skontroluje dokument.
- Postúpi ho financiám.
- Financie skontrolujú rozpočet.
- Potom niekto musí schváliť objednávku.
Technicky môže aplikácia fungovať dokonale. A proces trvá tri dni.
Môžeme povedať, že aplikácia je rýchla?
Technicky - možno.
Z pohľadu biznisu - pracovník čaká tri dni.
A práve preto si navrhovanie biznisových systémov vyžaduje pohľad za samotné rozhranie. Treba vidieť celý pracovný tok.
"Prosím čakajte" je tiež súčasť UX
Je tu ešte jeden zaujímavý prípad.
Niekedy systém skutočne vykonáva dlhú operáciu.
Generuje report.
Spracúva veľký súbor.
Synchronizuje dáta.
Posiela veľa záznamov do externého API.
Spúšťa zložitý proces.
Nie vždy sa dá dosiahnuť, aby to trvalo sekundu. Ale dá sa dosiahnuť, aby používateľ vedel, čo sa deje.
To je obrovský rozdiel.
Hlásenie: "Načítava sa..."
je niečo úplne iné než: "Pripravujeme report. Spracovalo sa 72% údajov. Môžete zatvoriť okno - report bude pripravený na pozadí."
V druhom prípade používateľ dostáva informáciu, kontrolu a predvídateľnosť.
To je práve jeden z prvkov perceived performance.
Systém môže stále vykonávať tú istú operáciu 20 sekúnd. Ale používateľská skúsenosť je úplne iná.
Najhoršie je čakanie bez informácií
Človek oveľa horšie vníma čakanie, keď nevie, či systém vôbec niečo robí.
Klikneme. - Nič.
Klikneme druhýkrát. - Stále nič.
Funguje systém?
Zasekol sa?
Treba obnoviť stránku?
Bol formulár odoslaný?
Môžeme zavrieť okno?
To je moment, keď používateľ začína bojovať s aplikáciou.
A keď používateľ začne bojovať so systémom, objavujú sa ďalšie problémy.
Obnovovanie stránky.
Opätovné odosielanie formulára.
Duplikáty.
Telefonáty na podporu.
Chyby.
Zbytočné hlásenia.
A čas práce ďalších ľudí...
Preto informovanie používateľa o stave operácie nie je kozmetický doplnok. Je súčasťou návrhu efektívneho systému.
A niekedy aplikácia čaká za človeka
To je asi najzaujímavejší prípad.
Systém vyžaduje, aby človek vykonal činnosť, ktorú by technológia vedela vykonať automaticky.
Pracovník získava údaje z jedného systému.
Prenáša ich do druhého.
Kontroluje podmienku.
Kopíruje výsledok.
Posiela správu.
Mení stav.
Čaká.
Potvrdzuje.
Prenáša údaje ďalej.
A robí to niekoľkokrát denne.
Nie je tam porucha.
Nie je tam chyba.
Systém funguje podľa predpokladov.
Lenže predpoklady boli zlé.
Automatizácia nemusí znamenať umelú inteligenciu.
Niekedy najväčšou automatizáciou je jednoducho zabezpečiť, aby systémy prestali vyžadovať od človeka ručné prenášanie informácií medzi sebou.
Architektúra má priamy vplyv na to, ako dlho používateľ čaká
V tejto fáze sa dostávame k technickým otázkam.
Ak sa aplikácia skladá z mnohých služieb, každé volanie môže priniesť oneskorenie. Ak systém zakaždým získava tie isté údaje z externého API, možno zvážiť cache. Ak report zakaždým prepočítava milióny záznamov od začiatku, možno je potrebná iná stratégia generovania údajov. Ak používateľ musí čakať na operáciu, ktorú netreba vykonať okamžite, možno zvážiť asynchrónne spracovanie. Ak niekoľko procesov vykonáva tú istú prácu, možno problém spočíva v architektúre.
Práve tu sa začína prepájať UX, performance a software architecture.
Dizajnér vidí problém používateľa.
Analytik vidí proces.
Programátor vidí kód.
Architekt vidí závislosti.
Dobrý systém by mal spojiť všetky štyri perspektívy.
Nie každú operáciu treba zrýchľovať
Aj to je dôležité.
Niekedy firma investuje veľké peniaze do optimalizácie operácie, ktorá sa vyskytuje raz denne.
Medzitým iná činnosť, vykonávaná 50 ľuďmi niekoľkokrát denne, zostáva prakticky nedotknutá.
Preto pred optimalizáciou je dobré vedieť: čo vlastne optimalizujeme a pre koho?
Nejde o to, aby sa každá obrazovka otvárala za 100 milisekúnd.
Ide o to, aby bol systém rýchly tam, kde rýchlosť má biznisový význam.
Ak sa finančný report môže generovať 15 sekúnd raz denne, možno to nie je problém. Ak vyhľadávanie zákazníkov odpovedá 4 sekundy pri každej operácii obchodníka, situácia vyzerá úplne inak.
Performance by sa malo hodnotiť v kontexte frekvencie, kritickosti a nákladov danej činnosti.
Ako nájsť skutočné úzke hrdlo?
Namiesto otázky len programátorom: "Prečo je aplikácia pomalá?"
sa oplatí začať pri používateľoch: "Ukáž mi, ako vykonávaš svoju prácu."
Nie: "Čo je pre teba nepohodlné?"
Iba:
"Ukáž mi, ako pripravuješ ponuku."
"Ukáž mi, ako vybavuješ reklamáciu."
"Ukáž mi, ako zadávaš nového zákazníka."
"Ukáž mi, ako uzatváraš objednávku."
A potom sa často ukážu veci, ktoré nie sú viditeľné v kóde.
Excel.
Poznámkový blok.
Druhý monitor.
Kopírovanie údajov.
Ručné kontrolovanie.
Telefonáty.
Otváranie piatich kariet.
Obnovovanie stránky.
Čakanie na e-mail.
Otázka kolegu.
Práve tam sa často nachádza skutočné úzke hrdlo.
Dobrá aplikácia nielen odpovedá rýchlo
Dobrá aplikácia umožňuje rýchlo vykonať prácu.
Je to jemný, ale zásadný rozdiel.
Môžete mať technicky veľmi výkonnú aplikáciu, ktorá od používateľa vyžaduje tucet kliknutí. Môžete mať krásne rozhranie, ktoré skrýva zložitý proces. Môžete mať skvelú architektúru, ktorá nerieši skutočný biznisový problém. A môžete mať systém, ktorý technicky nie je rekordér vo výkonnosti, ale umožní zamestnancovi urobiť za päť minút niečo, čo predtým trvalo pol hodiny.
Aj preto by sa software house nemal pozerať na aplikáciu výlučne cez prizmu kódu.
Kód je prostriedok. Cieľom je efektívne fungujúci biznis.
Skôr než optimalizuješ server, zmeraj človeka
Túto vetu sa oplatí zapamätať si.
Ak si používatelia sťažujú, že aplikácia je pomalá, nezačni automaticky zvyšovaním výkonu servera.
Najprv skontroluj celý proces.
Koľko času zaberie úloha?
Koľko obrazoviek treba prejsť?
Koľko údajov používateľ vypisuje ručne?
Koľkokrát prepisuje tie isté informácie?
Na koľko systémov sa musí prepínať?
Koľkokrát čaká?
Na čo čaká?
Vie, že systém stále pracuje?
Dá sa časť práce vykonať automaticky?
Sú údaje, ktoré už máme, opäť získavané od človeka?
Až potom sa oplatí ísť o úroveň nižšie a skontrolovať API, databázu, infraštruktúru, cache, fronty či architektúru aplikácie.
Lebo niekedy sa problém naozaj nachádza v kóde.
Ale niekedy sa nachádza medzi obrazovkou a stoličkou.
A potom najlepšou optimalizáciou nie je rýchlejší server.
Je ňou lepšie navrhnutý systém.
Najpomalším prvkom tvojej aplikácie môže byť človek.
A úlohou dobrého software house'u nie je zabezpečiť, aby človek klikal rýchlejšie.
Úlohou dobrého software house'u je zabezpečiť, aby musel klikať menej.
