Jednym z bardziej nielubianych przeze mnie aspektów projektu BI jest tworzenie tzw. "mockups" (nie wiem, jakie polskie słówko pasowałoby tu najlepiej), czyli takich udawanych, statycznych obrazków pokazujących jak, z grubsza, mógłby wyglądać docelowy raport, przy bieżących założeniach projektowych.
Taki mockup musi być zrobiony z aktualnych (prawdziwych!) danych, ponieważ jego odbiorcą jest użytkownik biznesowy, który dane kuma, i któremu nie mogę wcisnąć podróby. A więc trzeba te wszystkie źródłowe dane powyciągać z systemu / -ów i wkopiować w ów nieszczęsny mockup.
Ponadto, mockup powinien zawierać kilka "ujęć" tego samego raportu, w zależności od wybranego scenariusza. Jeżeli raport jest prosty, może wystarczyć jedno ujęcie, ale na ogół trzeba zrobić kilka, ze strzałkami prowadzącymi od jednego ujęcia do drugiego, i z opisem co gdzie kliknięto i tak dalej. Robota żmudna i raczej niewdzięczna. A najgorsze jest to, że czasem użytkownik końcowy myśli, że to jest faktyczny obraz końcowego produktu i potem ma pretensje, gdy ten końcowy produkt różni się od mockup-u.
W czym się taki mockup robi?
Można na kartce A4, ołówkiem. Można w Wordzie. Można w Excelu. Można nawet (jak się ma czas i chęć) zbudować go z tymczasowych danych, w faktycznym docelowym środowisku raportującym. Wsioryba. Chodzi wyłącznie o wizualizację koncepcji.
Nudy...
Te slowko to: makiety.
A mniej dosłownie, ale w duchu extreme programming można by chyba też użyć: prototypy 🙂
Skoro jest 'pseudokod', to może 'pseudoraport' ?