Cel mai lent element al aplicației tale poate fi... omul.
Când o companie spune că aplicația ei este lentă, prima reacție este de obicei foarte tehnică. Trebuie verificat serverul. Baza de date. API-ul. Interogările SQL. Cache-ul. Infrastructura. Dimensiunea fișierelor. JavaScript-ul. Timpul de răspuns al fiecărui serviciu.
Și pe bună dreptate. Technical performance are o importanță enormă.
Doar că, uneori, toate graficele arată bine, serverul răspunde rapid, aplicația se încarcă într-un timp rezonabil, iar utilizatorii spun în continuare: "Durează prea mult."
Și atunci apare o întrebare mai interesantă. Poate aplicația nici măcar nu este lentă. Poate pur și simplu îl obligă pe om să aștepte.
2 secunde de răspuns, 20 de minute de muncă
Să ne imaginăm un angajat care trebuie să pregătească o ofertă pentru un client.
Sistemul funcționează bine. Fiecare ecran se deschide rapid. Nu există erori. Serverul răspunde aproape imediat.
Doar că, pentru a pregăti oferta, angajatul trebuie să: deschidă clientul, meargă la comandă, copieze numărul produsului, deschidă al doilea modul, caute produsul, transcrie datele, revină la primul ecran, aleagă categoria, treacă la fila următoare, preia prețurile, verifice manual reducerea, copieze rezultatul în Excel, apoi să îl transcrie din nou în sistem.
Fiecare operațiune individuală poate dura câteva secunde.
Tehnic, totul funcționează excelent. Doar că întregul proces durează 20 de minute.
Și exact aici înțelegerea clasică a performanței nu mai este suficientă.
Pentru că utilizatorul nu este interesat în primul rând de timpul de răspuns al API-ului. Îl interesează timpul necesar pentru a finaliza o sarcină.
Technical performance este doar începutul
Performanța sistemului poate fi măsurată în multe moduri.
Putem analiza timpul de răspuns al serverului, timpul de încărcare al interfeței, interogările către bază, utilizarea memoriei, încărcarea procesorului sau latențele dintre servicii.
Acestea sunt metrici foarte importante. Dar există și un al doilea strat.
Perceived performance, adică performanța percepută de utilizator.
Și, mai larg, putem privi operational performance - adică cât de repede și eficient este capabil omul să finalizeze o sarcină reală folosind sistemul.
Și tocmai pe acest ultim strat companiile pierd foarte des cel mai mult timp. Pentru că poți construi o aplicație extrem de rapidă, care totuși va rămâne un instrument lent de lucru.
Cel mai lent sistem este uneori format din șapte ecrane
Să presupunem că un angajat gestionează o reclamație.
Sistemul cere șapte pași.
Mai întâi deschiderea clientului.
Apoi a comenzii.
Apoi a produsului.
Apoi a formularului de reclamație.
Apoi a categoriei problemei.
Apoi a deciziei.
La final, confirmarea.
Fiecare ecran se încarcă în 0,5 secunde.
Din perspectiva dezvoltatorului, totul poate arăta foarte bine. Dar utilizatorul a făcut șapte treceri, și-a schimbat de șapte ori contextul și de șapte ori a trebuit să se gândească ce să facă mai departe.
Dacă astfel de operațiuni sunt făcute de zeci de ori pe zi, problema încetează să mai fie una de confort. Devine un cost. Și nu este vorba doar despre timpul petrecut în fața ecranului. Apar oboseala, numărul de greșeli, necesitatea corectării datelor, sarcini întrerupte și o încărcare tot mai mare pentru angajat.
Un formular cu 40 de câmpuri nu este rapid doar pentru că se deschide repede
Acesta este unul dintre exemplele clasice.
Formularul se deschide fulgerător. - Excelent.
Doar că utilizatorul trebuie să completeze 40 de câmpuri.
O parte din informații compania le are deja.
O parte poate fi preluată din CRM.
O parte poate fi calculată.
O parte depinde de răspunsurile anterioare.
Și totuși sistemul îl întreabă din nou pe om totul.
Atunci problema nu este performanța aplicației.
Problema este proiectarea procesului și a interfeței.
Un sistem bun ar trebui să folosească datele pe care deja le are.
Dacă clientul a furnizat adresa de livrare la o comandă anterioară, de ce ar trebui angajatul să o introducă din nou? Dacă sistemul cunoaște firma clientului, de ce utilizatorul ar trebui să-i aleagă din nou datele? Dacă răspunsul la prima întrebare exclude jumătate din câmpurile următoare, de ce sunt toate vizibile de la început?
Uneori, cel mai bun mod de a accelera aplicația nu este optimizarea codului. Este eliminarea muncii pe care utilizatorul nu ar trebui să o facă.
Cel mai scump este timpul omului înmulțit cu scala
Un minut în plus poate părea nimic.
Angajatul efectuează operațiunea de 5 ori pe zi. - 5 minute.
La scara unei luni, ajunge la peste 1,5 ore.
Dar dacă o fac 20 de persoane? Dar dacă operațiunea apare de 30 de ori pe zi? Dar dacă privește întregul departament? Dar dacă sistemul va fi folosit în următorii cinci ani?
Atunci un singur minut încetează să mai fie un minut. Devine un cost operațional.
De aceea, atunci când proiectăm un sistem pentru o companie, merită să întrebăm nu doar: "Cât durează răspunsul serverului?"
ci și: "Cât timp îi trebuie unui om pentru a finaliza sarcina?"
Sunt două întrebări complet diferite.
Sistemul poate fi rapid, iar procesul lent
Aceasta este o problemă și mai amplă.
Să ne imaginăm un proces de achiziție într-o companie.
- Angajatul depune o cerere.
- Sistemul o salvează imediat.
- Dar apoi trebuie să aștepte aprobarea superiorului.
- Superiorul primește un mesaj.
- Deschide sistemul.
- Verifică documentul.
- Îl transmite la departamentul financiar.
- Finanțele verifică bugetul.
- Apoi cineva trebuie să aprobe comanda.
Tehnic, aplicația poate funcționa perfect. Iar procesul durează trei zile.
Putem spune că aplicația este rapidă?
Tehnic - poate.
Din perspectiva business-ului - angajatul așteaptă trei zile.
Și tocmai de aceea proiectarea sistemelor de business necesită o privire dincolo de simpla interfață. Trebuie să vezi întregul flux de lucru.
"Vă rugăm să așteptați" este și el un element de UX
Mai există încă un caz interesant.
Uneori sistemul chiar execută o operațiune lungă.
Generează un raport.
Procesează un fișier mare.
Sincronizează datele.
Trimite multe înregistrări către un API extern.
Pornește un proces complex.
Nu întotdeauna se poate face să dureze o secundă. Dar se poate face ca utilizatorul să știe ce se întâmplă.
Asta face o diferență uriașă.
Mesajul: "Se încarcă..."
este cu totul altceva decât: "Pregătim raportul. 72% din date au fost procesate. Poți închide fereastra - raportul va fi gata în fundal."
În al doilea caz, utilizatorul primește informație, control și predictibilitate.
Acesta este exact unul dintre elementele perceived performance.
Sistemul poate continua să execute aceeași operațiune timp de 20 de secunde. Dar experiența utilizatorului este cu totul alta.
Cel mai rău este așteptarea fără informații
Oamenii percep mult mai prost așteptarea atunci când nu știu dacă sistemul face ceva deloc.
Facem clic. - Nimic.
Facem clic a doua oară. - Încă nimic.
Funcționează sistemul?
S-a blocat?
Trebuie să dăm refresh?
A fost trimis formularul?
Putem închide fereastra?
Este momentul în care utilizatorul începe să se lupte cu aplicația.
Iar când utilizatorul începe să se lupte cu sistemul, apar alte probleme.
Reîmprospătarea paginii.
Retrimiterea formularului.
Duplicate.
Apeluri către suport.
Erori.
Sesizări inutile.
Și timpul de lucru al altor persoane...
De aceea, informarea utilizatorului despre starea operațiunii nu este un detaliu cosmetic. Este parte din proiectarea unui sistem eficient.
Și uneori aplicația așteaptă în locul omului
Acesta este probabil cel mai interesant caz.
Sistemul cere ca omul să facă o acțiune pe care tehnologia ar putea-o realiza automat.
Angajatul preia date dintr-un sistem.
Le mută în altul.
Verifică o condiție.
Copiază rezultatul.
Trimite un mesaj.
Schimbă statusul.
Așteaptă.
Confirmă.
Transferă datele mai departe.
Și face asta de câteva zeci de ori pe zi.
Nu există o defecțiune.
Nu există o eroare.
Sistemul funcționează conform presupunerilor.
Doar că presupunerile au fost greșite.
Automatizarea nu trebuie să însemne inteligență artificială.
Uneori, cea mai mare automatizare înseamnă pur și simplu să faci sistemele să nu mai necesite de la om transferul manual de informații între ele.
Arhitectura are un impact direct asupra timpului de așteptare al utilizatorului
În acest stadiu ajungem la aspectele tehnice.
Dacă aplicația este alcătuită din mai multe servicii, fiecare apel poate introduce o întârziere. Dacă sistemul preia de fiecare dată aceleași date dintr-un API extern, se poate lua în calcul cache-ul. Dacă raportul recalculează de fiecare dată milioane de înregistrări de la zero, poate fi nevoie de o altă strategie de generare a datelor. Dacă utilizatorul trebuie să aștepte o operațiune care nu trebuie executată imediat, se poate lua în calcul procesarea asincronă. Dacă mai multe procese fac aceeași muncă, poate problema este în arhitectură.
Aici UX, performance și software architecture încep să se împletească.
Designerul vede problema utilizatorului.
Analistul vede procesul.
Programatorul vede codul.
Arhitectul vede dependențele.
Un sistem bun ar trebui să combine toate cele patru perspective.
Nu orice operațiune trebuie accelerată
Și asta este important.
Uneori, compania investește mulți bani în optimizarea unei operațiuni care apare o dată pe zi.
Între timp, o altă activitate, realizată de 50 de persoane de câteva zeci de ori pe zi, rămâne practic neatinsă.
De aceea, înainte de optimizare merită să știm: ce optimizăm de fapt și pentru cine?
Nu e vorba ca fiecare ecran să se deschidă în 100 de milisecunde.
Este vorba ca sistemul să fie rapid acolo unde viteza are importanță de business.
Dacă raportul financiar se poate genera timp de 15 secunde o dată pe zi, poate că nu este o problemă. Dacă motorul de căutare al clienților răspunde în 4 secunde la fiecare acțiune a agentului de vânzări, situația arată complet diferit.
Performance ar trebui evaluat în contextul frecvenței, criticității și costului unei anumite acțiuni.
Cum găsești adevăratul blocaj?
În loc să-i întrebi doar pe programatori: "De ce aplicația este lentă?"
merită să începi de la utilizatori: "Arată-mi cum îți faci treaba."
Nu: "Ce este inconfortabil pentru tine?"
Ci doar:
"Arată-mi cum pregătești oferta."
"Arată-mi cum gestionezi reclamația."
"Arată-mi cum introduci un client nou."
"Arată-mi cum închizi comanda."
Și atunci, de multe ori, ies la iveală lucruri care nu se văd în cod.
Excel.
Notepad.
Al doilea monitor.
Copierea datelor.
Verificarea manuală.
Telefoane.
Deschiderea a cinci taburi.
Reîmprospătarea paginii.
Așteptarea unui e-mail.
Întrebarea unui coleg.
Acolo se află adesea adevăratul blocaj.
O aplicație bună nu doar răspunde repede
O aplicație bună îți permite să-ți faci treaba repede.
Este o diferență subtilă, dar fundamentală.
Poți avea o aplicație foarte eficientă tehnic, care îi cere utilizatorului zeci de clicuri. Poți avea o interfață frumoasă, care ascunde un proces complicat. Poți avea o arhitectură excelentă, care nu rezolvă problema reală de business. Și poți avea un sistem care, tehnic, nu este campion la performanță, dar îi permite angajatului să facă în cinci minute ceva ce înainte dura o jumătate de oră.
De aceea, o companie de software nu ar trebui să privească aplicația exclusiv prin prisma codului.
Codul este mijlocul. Scopul este un business care funcționează eficient.
Înainte să optimizezi serverul, măsoară omul
Merită să reții această propoziție.
Dacă utilizatorii se plâng că aplicația este lentă, nu începe automat prin a crește puterea serverului.
Mai întâi verifică întregul proces.
Cât durează sarcina?
Câte ecrane trebuie parcurse?
Câte date introduce utilizatorul manual?
De câte ori rescrie aceleași informații?
Între câte sisteme trebuie să comute?
De câte ori așteaptă?
La ce așteaptă?
Știe că sistemul încă lucrează?
Poate o parte din muncă să fie executată automat?
Datele pe care le avem deja sunt cerute din nou de la om?
Abia atunci merită să cobori un nivel mai jos și să verifici API-ul, baza de date, infrastructura, cache-ul, cozile sau arhitectura aplicației.
Pentru că uneori problema chiar se află în cod.
Dar alteori se află între ecran și scaun.
Și atunci cea mai bună optimizare nu este un server mai rapid.
Este un sistem mai bine proiectat.
Cel mai lent element al aplicației tale poate fi un om.
Iar rolul unei companii de software bune nu este să facă omul să dea mai repede clic.
Rolul unei companii de software bune este să facă astfel încât să fie nevoie să dea mai puține clicuri.
