Jak przygotować się do budowy dashboardu? Nie bój się pytać!

cze 20, 2022

Business Intelligence

Wizualizacja Danych

W tworzeniu analiz wizualnych kluczowe jest dobre zdefiniowanie i zebranie wymagań już na początku projektu. Doprecyzuj je za pomocą pytań, bo to oznaka profesjonalizmu – zwłaszcza tam, gdzie na drodze staje żargon branżowy.

W budowaniu dashboardu, czyli analizy wizualnej, współpraca przy zbieraniu informacji musi być kompleksowa. Zespół projektowy składa się zazwyczaj z osób związanych z IT, które dbają o jakość danych, oraz osób reprezentujących biznes, które mówią, czego potrzebują. Rolą osoby, która zbiera wymagania, jest dojście do tego, co tak naprawdę jest potrzebne, a co nie. Tylko wtedy użytkownik końcowy dostanie narzędzie, którego potrzebuje – i którego nie trzeba będzie wielokrotnie poprawiać, a w sytuacjach kryzysowych wywracać w nim całej logiki działania.

Krok pierwszy: przekuj życzenia na konkrety

Na etapie planowania trzeba przekuć oczekiwania użytkownika względem warstwy wizualnej i funkcjonalnej na konkretne pytania biznesowe. Jak się do tego zabrać? Już na początku warto zdefiniować pewne warunki brzegowe, a następnie przejść do szczegółowych elementów. Nawet brief funkcjonalny nie zawsze zawiera wszystkie potrzebne wskaźniki, które będą dawać odpowiedzi na pytania krytyczne z punktu widzenia użytkownika. To dlatego warto dodatkowo zapytać osobę, która będzie ostatecznie korzystała z tego raportu, jakie decyzje będzie na jego podstawie podejmowała. Jeżeli tego nie zrobimy, to może się okazać, że będzie trzeba przeorganizować całą koncepcję rozwiązania lub zmienić technologię.

Przykładowo, klient zamawia stworzenie raportu dziennego, tzn. pokazującego dane za dzień poprzedni. Po otrzymaniu gotowego rozwiązania użytkownik decyduje jednak, że do analizy potrzebuje także możliwości wyboru dowolnego zakresu dat i prosi o „wyklikanie” zmian. Z jego perspektywy taka modyfikacja jest niewielka, natomiast z punktu widzenia technologii może wydłużyć czas projektu i pociągnąć za sobą większe koszty.

Krok drugi: ustal logikę działania rozwiązania

Aby uzyskać pierwsze wskazówki odnośnie logiki, na jakiej rozwiązanie będzie oparte, a także upewnić się, czy w pierwotnych wymaganiach czegoś nie brakuje, trzeba przeformułować odpowiedzi użytkownika na konkretne miary, które będzie pokazywało narzędzie. Przykładowo, gdy wiemy, że użytkownik chce zidentyfikować największe źródła kosztów i je ograniczyć albo zdecydować, który kanał marketingowy jest najbardziej efektywny i gdzie warto najbardziej inwestować, na kolejnym etapie – analitycznym – możemy ustalić sposób liczenia KPI.

Aby dashboard miał sens i działał szybko, musimy wiedzieć, nie tylko jak dany wymiar jest liczony, ale także skąd brane są dane i czy źródła, z których pochodzą, są w ogóle dostępne. Warto też sprawdzić, jaka jest jakość źródeł, ponieważ jeżeli te elementy nie będą wysokiej jakości, to budowanie dashboardu na ich podstawie może po prostu nie mieć sensu. Aby przeanalizować, czy wszystkie dane są przygotowane, poproś o ich próbkę. Lepiej, żeby ewentualne niespodzianki pojawiły się na początku projektu – niż na końcu.

Aby zespół deweloperski mógł dobrać odpowiednią logikę działania i technologię, trzeba też określić poziom szczegółowości analizy. Podpowiedź znajdziemy w sposobie, w jaki użytkownik ma z niego korzystać. Czy będzie to operacyjny dashboard dla handlowca, któremu wystarczy widok ogólny sytuacji przed wyruszeniem w teren, czy raczej narzędzie dla analityka, który będzie wchodził w szczegóły i dociekał „dlaczego?”.

Krok trzeci: wyjaśnij slang branżowy

Osoby pracujące w organizacji uważają, że to, o czym mówią, jest dla każdego zrozumiałe. Ale kiedy wchodzimy w specyfikację raportu, uspójnienie definicji, czasem różnie rozumianych po stronie klienta, to musimy dokładnie wiedzieć, co znaczy każdy termin. Zawsze dobrze jest zadać pytanie „co to dla ciebie znaczy?”. Definicje, które wydawałoby się, powinny być dość jednoznaczne, potrafią się bardzo różnić w zależności od organizacji i jest to zupełnie normalne.

Przykładowo, w raporcie sprzedaży leków może się okazać, że to, co analitycy zrozumieli jako „leki”, użytkownicy rozumieli jako leki OTC i produkty specjalnego przeznaczenia żywieniowego oraz kilka innych rodzajów produktów, a nie jako RX, czyli leki wydawane na receptę. Z kolei w raporcie sprzedaży zagranicznej kolumna „Sales” wcale nie musi wskazywać ostatecznej wartości sprzedaży, ponieważ istnieje inna, gdzie wartości sprzedaży są skorygowane o kursy lokalnych walut. W innym przypadku marża może być nazwana zyskiem. Gdy błąd wyjdzie na jaw, może się okazać, że cała logika rozwiązania przestanie działać i będzie trzeba wrócić do punktu wyjścia. Gdy pojawia się rozbieżność danych, zaczyna się brak zaufania, a to zawsze kończy się źle.

Krok czwarty: znajdź właściwe osoby

Zanim ruszą prace projektowe, dowiedz się, do kogo można się zwrócić z konkretnymi pytaniami dotyczącymi danych. Najbardziej komfortowy jest kontakt z bezpośrednim użytkownikiem końcowym. Można wtedy podejrzeć, jak pracuje – i zrozumieć, co zrobić, aby ulepszyć jego pracę z danymi, i gdzie mogą być jakieś pułapki.

Jednak im bardziej rozbudowana organizacja z większą strukturą, tym takich osób będzie więcej – nie tylko użytkownik biznesowy, ale także analityków systemów i administratorów serwerów. W takim przypadku bardzo przydaje się pośrednik wewnątrz organizacji. Podobnie, jeżeli powstaje raport dla zarządu, to bardziej komfortowe jest zwracanie się z zestawem pytań do osoby na stanowisku asystenckim. Jednak może to powodować, że informacja będzie zniekształcona. W takim przypadku najlepiej co jakiś czas potwierdzać preferencje dotyczące wizualizacji danych z użytkownikiem końcowym, nawet na wysokim stanowisku, żeby zyskać pewność.

Na koniec: nie bój się pytać!

Wymagań nie da się zebrać i dokładnie określić za jednym zamachem. Warto zacząć od pokazania użytkownikom tych elementów, które powinny się w tej specyfikacji znaleźć. Dodatkowo tak przygotować dashboard, żeby w przyszłości dało się wprowadzić nowe funkcjonalności. Początkujący analitycy i osoby wchodzące do branży czasem boją się zadawać proste pytania, ponieważ obawiają się, że zostaną ocenieni jako mało profesjonalni. Nic bardziej mylnego! Doprecyzowywanie wymagań w zbieraniu danych i informacji świadczy o profesjonalizmie, szczególnie kiedy użytkownicy posługują się skrótami wewnętrznymi.

Analityk z jednej strony powinien rozumieć wyzwania IT i jego ograniczenia, ale z drugiej strony znać oczekiwania biznesu. Ważne są notatki ze spotkań i potwierdzenia wszystkich ustaleń w mailu. Niczego nie zakładaj! Na początku każdej pracy upewnij się i sprawdź, czy dobrze się rozumiecie, aby nie popełnić poważnego błędu.

Jeżeli zaciekawił Cię temat przygotowania do budowy dashboardu, zapraszamy do przesłuchania odcinka naszego podcastu Pogromcy Pie Chartów – Jak przygotować się do budowy dashboardu?. To na podstawie tej rozmowy powstał artykuł. Poznasz tam jeszcze więcej przykładów i argumentów, które umożliwią Ci lepsze przygotowanie się do nowego zadania.