Przychodzi taki moment, w którym trzeba podjąć decyzję na podstawie liczb, a liczby siedzą w pięciu różnych miejscach. Ruch w Google Analytics. Zgłoszenia w formularzu. Nieprzeczytane w skrzynkach. Opinie w wizytówce Google. Wzmianki w mediach. Każde z osobna da się sprawdzić w dwie minuty, ale nikt nie sprawdza pięciu paneli co kwadrans.
Zaczyna się wtedy klasyczny rytuał: ktoś co godzinę zbiera dane do arkusza, wkleja zrzuty na czat i pisze podsumowanie. Po dwóch dniach nikt już nie wie, która wersja arkusza jest aktualna.
Robimy to inaczej. Składamy jednorazowy panel z danych, które i tak mamy, i wystawiamy go ludziom, którzy podejmują decyzje.
Dlaczego arkusz nie wystarcza
Arkusz jest świetny do liczenia. Jest fatalny jako wspólny obraz sytuacji, bo ma trzy wady.
Nie odświeża się sam. Ktoś musi pamiętać o aktualizacji, a przy gorączkowym tygodniu pamięta coraz rzadziej.
Nie mówi, co jest ważne. Dwadzieścia kolumn wygląda tak samo. Nie widać, że jedna z nich właśnie wzrosła czterokrotnie.
Nie prowadzi do działania. Widzisz liczbę 41, ale nie wiesz, które to konkretnie zgłoszenia i gdzie je otworzyć.
Panel rozwiązuje wszystkie trzy. Odświeża się w tle, koloruje odchylenia od normy i z każdej liczby robi link do listy, z której ta liczba powstała.
Aplikacja w Intum, nie osobne narzędzie
W Intum jest moduł Noe, w którym aplikacja to po prostu strona HTML ze swoim adresem w Twoim serwisie. Nie stawiasz serwera, nie kupujesz licencji na narzędzie BI, nie prosisz nikogo o wdrożenie.
Dane do panelu trafiają przez API, do prostej bazy w Noe. Zbiera je skrypt uruchamiany cyklicznie: pyta Analytics o ruch, Intum o zgłoszenia i pocztę, zewnętrzne API o to, czego akurat potrzebujesz, i zapisuje jedną migawkę. Front czyta ostatnią migawkę i rysuje.
Taki podział ma znaczenie. Przeglądarka nie odpytuje pięciu systemów naraz, więc panel otwiera się natychmiast, a limity API zużywa jeden skrypt raz na kilka minut, nie każdy oglądający.
Co da się wpiąć
Wszystko, co ma API i token. W praktyce najczęściej idą tam:
Dane o ruchu z Analytics, razem z podziałem na kanały i widokiem “kto jest na stronie teraz”. Formularze z Intuma, z rozbiciem na tematy i listą ostatnich wypełnień. Skrzynki pocztowe, policzone ilościowo: ile czeka, ile z tego dotyczy jednej sprawy, jak długo czeka najstarsza wiadomość. Opinie z wizytówki Google. Wzmianki w mediach z narzędzi SEO. Logi z brzegu sieci, jeśli akurat interesuje Cię ruch automatów.
Osobna uwaga o poczcie: panel liczy wiadomości z listy, a nie otwiera ich pojedynczo. Otwarcie wiadomości przez API oznaczyłoby ją jako przeczytaną i zabrałoby zespołowi znacznik “nowe”. Panel ma pokazywać kolejkę, a nie po cichu jej kasować.
Na jedną sprawę albo na stałe
Panel ad hoc powstaje wokół jednego pytania i ma krótkie życie. Trwa tydzień, dwa, do końca akcji. Potem można go skasować i nikt za nim nie zatęskni, bo zrobił swoje.
Panel stały odpowiada na pytanie, które wraca co miesiąc: jak idzie sprzedaż, jak wygląda obsługa, gdzie uciekają klienci.
Różnica jest głównie w dyscyplinie. Przy panelu na jedną sprawę nie ma sensu dopracowywać układu przez tydzień. Przy panelu stałym warto, bo ktoś będzie w niego patrzył co rano przez rok.
Cztery rzeczy, które decydują o tym, czy ktoś tego używa
Norma obok liczby. Sto zgłoszeń nic nie znaczy, dopóki nie wiesz, że zwykle jest dwadzieścia. Przy każdej pozycji pokazujemy medianę ze spokojnego okresu i kolorujemy odchylenia.
Link z każdej liczby. Klikasz “41 nieprzeczytanych” i jesteś na tej liście, a nie w wyszukiwarce. To jedna z tych drobnic, które decydują o tym, czy panel jest używany, czy tylko oglądany.
Wiek danych. Na górze widać, o której powstała ostatnia migawka, a jeśli jest starsza niż kilkanaście minut, to na czerwono. Panel, który cicho zamarł, jest gorszy niż brak panelu.
Kolejność. Najważniejsze na górze, tło na dole, sekcje pogrupowane. Panel, który powstawał przez doklejanie kolejnych rzeczy, po tygodniu wymaga przewijania na ślepo.
Dostęp
Aplikacja prywatna jest widoczna po zalogowaniu do Intuma. Kiedy to za mało, bo panel ma trafić do wąskiej grupy, dokładamy dwie warstwy: listę osób, dla których widok się renderuje, i szyfrowanie samej migawki, tak żeby dane w bazie nie były czytelne bez hasła podanego przy wejściu.
To rozsądny kompromis między “wysyłam zrzuty ekranu na czat” a “zamawiamy wdrożenie z rolami i uprawnieniami”.
Ile to trwa
Pierwsza działająca wersja, z kilkoma kaflami i jednym wykresem, powstaje w godzinę. Kolejne źródła dokłada się po kilkanaście minut każde, bo cała robota to napisanie zapytania do API i dorysowanie tabeli.
Najwięcej czasu zabiera nie kod, tylko ustalenie, które liczby faktycznie są potrzebne do decyzji. Warto zacząć od pięciu i dokładać dopiero wtedy, gdy ktoś o coś zapyta drugi raz.
Podsumowanie
Dashboard nie musi być projektem. Jeśli dane są już w systemach, do których masz dostęp przez API, to zebranie ich w jeden obraz jest kwestią godziny, a nie kwartału.
W Intum robi się to aplikacją Noe: skrypt zbiera migawkę, strona ją rysuje, ludzie dostają adres. Panel na jedną sprawę kasujesz po akcji. Panel, który się przyjął, zostaje i staje się miejscem, do którego zespół zagląda codziennie.