Najwolniejszym elementem Twojej aplikacji może być... człowiek.
Kiedy firma mówi, że jej aplikacja jest wolna, pierwsza reakcja jest zazwyczaj bardzo techniczna. Trzeba sprawdzić serwer. Bazę danych. API. Zapytania SQL. Cache. Infrastrukturę. Rozmiar plików. JavaScript. Czas odpowiedzi poszczególnych usług.
I bardzo słusznie. Technical performance ma ogromne znaczenie.
Tylko że czasami wszystkie wykresy wyglądają dobrze, serwer odpowiada szybko, aplikacja ładuje się w rozsądnym czasie, a użytkownicy nadal mówią: "To trwa za długo."
I wtedy pojawia się ciekawsze pytanie. Może aplikacja wcale nie jest wolna. Może po prostu zmusza człowieka do czekania.
2 sekundy odpowiedzi, 20 minut pracy
Wyobraźmy sobie pracownika, który musi przygotować ofertę dla klienta.
System działa sprawnie. Każdy ekran otwiera się szybko. Nie ma błędów. Serwer odpowiada niemal natychmiast.
Tylko żeby przygotować ofertę, pracownik musi: otworzyć klienta, przejść do zamówienia, skopiować numer produktu, otworzyć drugi moduł, wyszukać produkt, przepisać dane, wrócić do pierwszego ekranu, wybrać kategorię, przejść do kolejnej zakładki, pobrać ceny, ręcznie sprawdzić rabat, skopiować wynik do Excela, a następnie ponownie przepisać go do systemu.
Każda pojedyncza operacja może trwać kilka sekund.
Technicznie wszystko działa świetnie. Tylko że cały proces zajmuje 20 minut.
I właśnie tutaj klasyczne rozumienie wydajności przestaje wystarczać.
Bo użytkownika nie interesuje przede wszystkim czas odpowiedzi API. Interesuje go czas potrzebny do wykonania zadania.
Technical performance to dopiero początek
Wydajność systemu można mierzyć na wiele sposobów.
Możemy analizować czas odpowiedzi serwera, czas ładowania widoku, zapytania do bazy, wykorzystanie pamięci, obciążenie procesora czy opóźnienia pomiędzy usługami.
To są bardzo ważne metryki. Ale istnieje jeszcze druga warstwa.
Perceived performance, czyli wydajność postrzegana przez użytkownika.
A jeszcze szerzej można spojrzeć na operational performance - czyli to, jak szybko i sprawnie człowiek jest w stanie wykonać realne zadanie przy użyciu systemu.
I właśnie na tej ostatniej warstwie firmy bardzo często tracą najwięcej czasu. Bo można zbudować niezwykle szybką aplikację, która nadal będzie powolnym narzędziem pracy.
Najwolniejszy system to czasami siedem ekranów
Załóżmy, że pracownik obsługuje reklamację.
System wymaga siedmiu kroków.
Najpierw otwarcia klienta.
Potem zamówienia.
Następnie produktu.
Później formularza reklamacyjnego.
Potem kategorii problemu.
Następnie decyzji.
Na końcu potwierdzenia.
Każdy ekran ładuje się w 0,5 sekundy.
Z punktu widzenia developera wszystko może wyglądać bardzo dobrze. Ale użytkownik wykonał siedem przejść, siedem razy zmienił kontekst i siedem razy musiał zastanowić się, co zrobić dalej.
Jeżeli takich operacji wykonuje dziennie kilkadziesiąt, problem przestaje być kwestią wygody. Staje się kosztem. I nie chodzi tylko o czas spędzony przed ekranem. Dochodzi zmęczenie, liczba pomyłek, konieczność poprawiania danych, przerwane zadania i rosnące obciążenie pracownika.
Formularz z 40 polami nie jest szybki tylko dlatego, że się szybko otwiera
To jeden z klasycznych przykładów.
Formularz otwiera się błyskawicznie. - Świetnie.
Tylko użytkownik musi wypełnić 40 pól.
Część informacji firma już posiada.
Część można pobrać z CRM.
Część można wyliczyć.
Część zależy od wcześniejszych odpowiedzi.
A mimo to system pyta człowieka o wszystko jeszcze raz.
Wtedy problemem nie jest performance aplikacji.
Problemem jest projekt procesu i interfejsu.
Dobry system powinien wykorzystywać dane, które już posiada.
Jeżeli klient podał adres dostawy przy wcześniejszym zamówieniu, dlaczego pracownik ma wpisywać go ponownie? Jeżeli system zna firmę klienta, dlaczego użytkownik ma ponownie wybierać jej dane? Jeżeli odpowiedź na pierwsze pytanie wyklucza połowę kolejnych pól, dlaczego wszystkie są widoczne od początku?
Czasami najlepszym sposobem na przyspieszenie aplikacji nie jest optymalizacja kodu. Jest usunięcie pracy, której użytkownik nie powinien wykonywać.
Najdroższy jest czas człowieka pomnożony przez skalę
Jedna dodatkowa minuta może wydawać się niczym.
Pracownik wykonuje operację 5 razy dziennie. - 5 minut.
W skali miesiąca robi się z tego ponad 1,5 godziny.
Ale co, jeśli robi to 20 osób? Co, jeśli operacja występuje 30 razy dziennie? Co, jeśli dotyczy całego działu? Co, jeśli system będzie używany przez kolejne pięć lat?
Wtedy pojedyncza minuta przestaje być minutą. Staje się kosztem operacyjnym.
Dlatego projektując system dla firmy, warto pytać nie tylko: "Ile trwa odpowiedź serwera?"
ale również: "Ile czasu człowiek potrzebuje, żeby zakończyć zadanie?"
To są dwa zupełnie różne pytania.
System może być szybki, a proces wolny
To jeszcze szerszy problem.
Wyobraźmy sobie proces zakupowy w firmie.
- Pracownik składa wniosek.
- System zapisuje go natychmiast.
- Ale później musi czekać na akceptację przełożonego.
- Przełożony dostaje wiadomość.
- Otwiera system.
- Sprawdza dokument.
- Przekazuje go do finansów.
- Finanse sprawdzają budżet.
- Potem ktoś musi zaakceptować zamówienie.
Technicznie aplikacja może działać perfekcyjnie. A proces trwa trzy dni.
Czy możemy powiedzieć, że aplikacja jest szybka?
Technicznie - być może.
Biznesowo - pracownik czeka trzy dni.
I właśnie dlatego projektowanie systemów biznesowych wymaga spojrzenia poza sam interfejs. Trzeba zobaczyć cały przepływ pracy.
"Proszę czekać" też jest elementem UX
Jest jeszcze jeden ciekawy przypadek.
Czasami system rzeczywiście wykonuje długą operację.
Generuje raport.
Przetwarza duży plik.
Synchronizuje dane.
Wysyła wiele rekordów do zewnętrznego API.
Uruchamia skomplikowany proces.
Nie zawsze da się sprawić, żeby trwało to sekundę. Ale można sprawić, żeby użytkownik wiedział, co się dzieje.
To ogromna różnica.
Komunikat: "Ładowanie..."
jest czymś zupełnie innym niż: "Przygotowujemy raport. Przetworzono 72% danych. Możesz zamknąć okno - raport będzie gotowy w tle."
W drugim przypadku użytkownik dostaje informację, kontrolę i przewidywalność.
To właśnie jeden z elementów perceived performance.
System może nadal wykonywać tę samą operację przez 20 sekund. Ale doświadczenie użytkownika jest zupełnie inne.
Najgorsze jest czekanie bez informacji
Człowiek znacznie gorzej odbiera oczekiwanie, kiedy nie wie, czy system w ogóle coś robi.
Klikamy. - Nic.
Klikamy drugi raz. - Nadal nic.
Czy system działa?
Czy zawiesił się?
Czy trzeba odświeżyć?
Czy formularz został wysłany?
Czy możemy zamknąć okno?
To moment, w którym użytkownik zaczyna walczyć z aplikacją.
A kiedy użytkownik zaczyna walczyć z systemem, pojawiają się kolejne problemy.
Odświeżanie strony.
Ponowne wysyłanie formularza.
Duplikaty.
Telefony do supportu.
Błędy.
Niepotrzebne zgłoszenia.
I czas pracy kolejnych osób...
Dlatego informowanie użytkownika o stanie operacji nie jest kosmetycznym dodatkiem. Jest częścią projektowania wydajnego systemu.
A czasami aplikacja czeka za człowieka
To chyba najciekawszy przypadek.
System wymaga, żeby człowiek wykonał czynność, którą technologia mogłaby wykonać automatycznie.
Pracownik pobiera dane z jednego systemu.
Przenosi je do drugiego.
Sprawdza warunek.
Kopiuje wynik.
Wysyła wiadomość.
Zmienia status.
Czeka.
Potwierdza.
Przenosi dane dalej.
I robi to kilkadziesiąt razy dziennie.
Nie ma awarii.
Nie ma błędu.
System działa zgodnie z założeniami.
Tylko że założenia były złe.
Automatyzacja nie musi oznaczać sztucznej inteligencji.
Czasami największą automatyzacją jest po prostu sprawienie, żeby systemy przestały wymagać od człowieka ręcznego przenoszenia informacji między sobą.
Architektura ma bezpośredni wpływ na to, ile czeka użytkownik
Na tym etapie dochodzimy do kwestii technicznych.
Jeżeli aplikacja składa się z wielu usług, każde wywołanie może wprowadzać opóźnienie. Jeżeli system za każdym razem pobiera te same dane z zewnętrznego API, można rozważyć cache. Jeżeli raport za każdym razem przelicza miliony rekordów od początku, być może potrzebna jest inna strategia generowania danych. Jeżeli użytkownik musi czekać na operację, która nie musi zostać wykonana natychmiast, można rozważyć przetwarzanie asynchroniczne. Jeżeli kilka procesów wykonuje tę samą pracę, być może problem leży w architekturze.
To właśnie tutaj UX, performance i software architecture zaczynają się ze sobą łączyć.
Projektant widzi problem użytkownika.
Analityk widzi proces.
Programista widzi kod.
Architekt widzi zależności.
Dobry system powinien połączyć wszystkie cztery perspektywy.
Nie każdą operację trzeba przyspieszać
To również ważne.
Czasami firma inwestuje duże pieniądze w optymalizację operacji, która występuje raz dziennie.
Tymczasem inna czynność, wykonywana przez 50 osób kilkadziesiąt razy dziennie, pozostaje praktycznie nietknięta.
Dlatego przed optymalizacją warto wiedzieć: co właściwie optymalizujemy i dla kogo?
Nie chodzi o to, żeby każdy ekran otwierał się w 100 milisekund.
Chodzi o to, żeby system był szybki tam, gdzie szybkość ma znaczenie biznesowe.
Jeżeli raport finansowy może generować się przez 15 sekund raz dziennie, być może nie jest to problem. Jeżeli wyszukiwarka klientów odpowiada przez 4 sekundy przy każdej operacji handlowca, sytuacja wygląda zupełnie inaczej.
Performance powinien być oceniany w kontekście częstotliwości, krytyczności i kosztu danego działania.
Jak znaleźć prawdziwe wąskie gardło?
Zamiast pytać tylko programistów: "Dlaczego aplikacja jest wolna?"
warto zacząć od użytkowników: "Pokaż mi, jak wykonujesz swoją pracę."
Nie: "Co jest dla Ciebie niewygodne?"
Tylko:
"Pokaż mi, jak przygotowujesz ofertę."
"Pokaż mi, jak obsługujesz reklamację."
"Pokaż mi, jak wprowadzasz nowego klienta."
"Pokaż mi, jak zamykasz zamówienie."
I wtedy często wychodzą rzeczy, których nie widać w kodzie.
Excel.
Notatnik.
Drugi monitor.
Kopiowanie danych.
Ręczne sprawdzanie.
Telefony.
Otwieranie pięciu zakładek.
Odświeżanie strony.
Czekanie na maila.
Pytanie kolegi.
To właśnie tam często znajduje się prawdziwe wąskie gardło.
Dobra aplikacja nie tylko odpowiada szybko
Dobra aplikacja pozwala szybko wykonać pracę.
To subtelna, ale fundamentalna różnica.
Można mieć bardzo wydajną technicznie aplikację, która wymaga od użytkownika kilkunastu kliknięć. Można mieć piękny interfejs, który ukrywa skomplikowany proces. Można mieć świetną architekturę, która nie rozwiązuje rzeczywistego problemu biznesowego. I można mieć system, który technicznie nie jest rekordzistą wydajności, ale pozwala pracownikowi zrobić w pięć minut coś, co wcześniej zajmowało pół godziny.
To właśnie dlatego software house nie powinien patrzeć na aplikację wyłącznie przez pryzmat kodu.
Kod jest środkiem. Celem jest sprawnie działający biznes.
Zanim zoptymalizujesz serwer, zmierz człowieka
To zdanie warto zapamiętać.
Jeżeli użytkownicy narzekają, że aplikacja jest wolna, nie zaczynaj automatycznie od zwiększenia mocy serwera.
Najpierw sprawdź cały proces.
Ile czasu zajmuje zadanie?
Ile ekranów trzeba przejść?
Ile danych użytkownik wpisuje ręcznie?
Ile razy przepisuje te same informacje?
Na ile systemów musi się przełączać?
Ile razy czeka?
Na co czeka?
Czy wie, że system nadal pracuje?
Czy część pracy może zostać wykonana automatycznie?
Czy dane, które już posiadamy, są ponownie pobierane od człowieka?
Dopiero wtedy warto zejść poziom niżej i sprawdzić API, bazę danych, infrastrukturę, cache, kolejki czy architekturę aplikacji.
Bo czasami problem rzeczywiście znajduje się w kodzie.
Ale czasami znajduje się pomiędzy ekranem a krzesłem.
I wtedy najlepszą optymalizacją nie jest szybszy serwer.
Jest lepiej zaprojektowany system.
Najwolniejszym elementem Twojej aplikacji może być człowiek.
A rolą dobrego software house'u nie jest sprawić, żeby człowiek szybciej klikał.
Rolą dobrego software house'u jest sprawić, żeby musiał klikać mniej.
