Tech Life2020.12.02 5 min. czytania
Analityk Biznesowy – specjalista, którego chcę, czy może taki, którego potrzebuję?
Z tego artykułu dowiesz się:
- Jaka jest rola analityka biznesowego w procesie tworzenia aplikacji mobilnych i systemów informatycznych?
- Dlaczego najbardziej oczywiste rozwiązania nie zawsze są najlepsze?
- Jakie korzyści może wnieść analityk biznesowy w proces projektowy?
Oprogramowanie jest obecne na co dzień w naszym życiu i jest to fakt. Tak naprawdę ciężko obecnie wyobrazić sobie nasze życie bez laptopa i/lub telefonu. A co za tym idzie bez aplikacji i systemów informatycznych. Powstaje coraz więcej aplikacji, które wspierają biznes w różnych obszarach, ale także odpowiadają na nasze codzienne potrzeby. Często nawet nie zdajemy sobie sprawy, że jakaś aplikacja jest nam potrzebna. A tu proszę, chwilę jej poużywamy i już nie widzimy możliwości życia bez niej. Co jednak w przypadku, gdy potrzebujemy czegoś więcej – bardziej specjalistycznego? Albo w przypadku, gdy potrzebujemy tylko fragmentu istniejącej aplikacji i nie chcemy płacić za jej całość, ponieważ wiemy, że będziemy wykorzystywać tylko 20% jej możliwości.
W takim przypadku warto poszukać firmy, która dla nas taką aplikację wykona. Billennium posiada wieloletnie doświadczenie w dostarczaniu rozwiązań informatycznych i może pochwalić się naprawdę pokaźnym portfolio specjalistów.
Idealnie, jeśli dokładnie wiemy czego chcemy i jaki system będzie nam potrzebny. Gorzej, jeśli takiej wiedzy nie posiadamy. Albo mamy już swoją wizję, jednak w trakcie jej realizacji okazało się, że kolejnych tematów przybywa w zatrważającym tempie i w efekcie tracimy z oczu nasz podstawowy cel. W takich przypadkach chcielibyśmy, aby ktoś nam pomógł i coś doradził. W końcu nie każdy jest dobry we wszystkim. I jeśli coś wykracza poza nasz obszar zainteresowań, to będziemy szukali najlepszego z najlepszych – fachowca, który nam pomoże. Pytanie tylko: czy jeśli znajdziemy profesjonalistę, który dostarczy nam dokładnie to, o co prosiliśmy to, czy będziemy zadowoleni? Co, jeśli okaże się, że dostaliśmy coś, czego nie potrafimy używać, ponieważ nie jest dla nas? Takich sytuacji chcielibyśmy uniknąć.
Czy, to co chcę jest jednocześnie tym, czego potrzebuję?
Zastanówmy się czy “chcę” i “potrzebuję” w kontekście tworzenia aplikacji i systemów odpowiadających na konkretne potrzeby biznesowe możemy używać wymiennie? Często ludzie postrzegają informatykę jako zło konieczne: “Wiem, że tego potrzebuję. Ale ja tego nie rozumiem i to jest trudne”. Na studiach miałem wykładowcę, który powtarzał: “Szanowni Państwo, jeśli nie potraficie wytłumaczyć złożonych zagadnień w sposób prosty, to znaczy, że ich nie rozumiecie”. Moim zdaniem jest to bardzo prawdziwe. Zastosujmy to w takim razie w naszym przypadku i nadajmy informatyce bardziej ludzką twarz.
Przyjmijmy, że potrzebujemy czegoś co pozwoli nam przemieścić się z domu do miejsca pracy. Jedną z możliwości może być samochód. Mój kolega ma własny samochód, który pozwala mu dostać się z domu do pracy. A tak w ogóle to nawet z pracy do domu… No to już idealnie! Wniosek prosty: ja także chcę samochód. Pytanie brzmi, czy rzeczywiście potrzebujemy samochodu? Może w naszym przypadku wystarczy tylko rower, ponieważ odległość do pracy nie jest duża i dbamy o środowisko?
I tu właśnie dochodzimy do sedna: nie zawsze to co chcemy jako klient, jest tym czego tak naprawdę potrzebujemy. Innymi słowy nie zawsze najbardziej oczywiste rozwiązanie, jest tym najlepszym, uwzględniającym wszystkie nasze potrzeby i oczekiwania. Bardzo dobrze, jeśli mamy czas i możliwości na przeanalizowanie takiego zagadnienia samemu i podjęcia właściwej decyzji. Co jednak w przypadku, gdy temat jest bardziej złożony, a nam brakuje wiedzy/doświadczenia/czasu do podjęcia właściwej decyzji? W końcu nie chcę jako klient płacić za coś czego nie będę używał. Chciałbym, aby ktoś mi pomógł. Przedstawił za i przeciw, możliwe scenariusze i koszty. Tak, abym mógł świadomie podjąć decyzję. I tu właśnie na scenę wchodzi nasz Analityk Biznesowy. Na potrzeby tego artykułu pozwolę sobie używać skrótu BA (od angielskiego Business Analyst).
Zadaniem BA w projekcie informatycznym jest przede wszystkim wparcie klienta i zapewnienie, że system, który zostanie mu dostarczony będzie dokładnie tym, którego “potrzebuje”. A niekoniecznie tym jaki myślał, że “chce”. BA działa niezależnie od technologii używanej do zbudowania systemu. Skupia się głównie na zrozumieniu potrzeb klienta. Określeniu jaki problem ma rozwiązać nowy system, czego do tej pory brakowało, czy są jeszcze inne potrzeby, na które ma odpowiadać? I w końcu najważniejsze: co sprawiło, że klient postanowił szukać nowego narzędzia? Tylko rozumiejąc problem z jakim klient do nas przychodzi będziemy w stanie zaproponować właściwe rozwiązanie. I to tak naprawdę tylko tyle. A może aż tyle?
Zrozumienie potrzeby to dopiero początek drogi
W końcu, gdyby określenie czego jako klient potrzebuję było takie proste, to nie potrzebowałbym specjalisty do tego. Cóż… nie zawsze jest to tak proste. W końcu nie chodzi tylko o to, aby określić co jest potrzebne. To jest dopiero początek. Bardzo ważny początek, ale jednak tylko początek. Rozumiejąc podstawową potrzebę jaka kryje się za tym, że klient poszukuje systemu mamy dopiero punkt wyjścia. Potrzeba to jedno, natomiast w parze z nią idą również wymagania. A tych może być naprawdę wiele. Nawet z pozoru proste wymaganie jak np. prezentacja planu dnia w kalendarzu, może dotykać wielu obszarów na wielu różnych płaszczyznach. Możemy na przykład potrzebować integracji z innym systemem, aby pobrać z niego kalendarz. Często posiadamy swój kalendarz prywatny i zawodowy. Niejednokrotnie pracując z kilkoma klientami takich kalendarzy mamy więcej, ponieważ u każdego z nich utrzymujemy osobny. I nagle okazuje się, że z prostego wymagania wychodzi nam szereg innych, mniej lub bardziej złożonych. Jednocześnie nic nie możemy pominąć, bo przecież wszystko jest dla mnie jako klienta istotne. I to również jest zadanie BA. To właśnie ta osoba pomoże w zebraniu wszystkich wymagań, ich zdefiniowaniu, spisaniu i uporządkowaniu. A także zadba o to, aby każde z nich zostało właściwie obsłużone.
Rzecz o priorytetach
Czy wszystkie moje wymagania jako klienta są ważne? Oczywiście, że tak! Czy coś możemy pominąć? Oczywiście, że nie! Sytuacja, w której coś nieświadomie pominiemy jest niedopuszczalna. Celowo używam tutaj słowa “nieświadomie”. To właśnie BA ma mieć świadomość tego co system ma robić i na jakie potrzeby odpowiadać. Powiedzieliśmy już sobie, że wszystkie wymagania są ważne. Pytanie czy wszystkie musimy zrealizować od razu? No może już niekoniecznie. Wymagania można podzielić na takie, bez których aplikacja nie ma racji bytu oraz takie, bez których możemy korzystać z programu, ale nie będzie to przyjemne. Mogą być również wymagania, które warto zrealizować, ale w sumie to możemy się chwilę bez nich obejść. I możemy to tak priorytetyzować na wiele różnych sposobów. Czy ja jako klient muszę wiedzieć jak to zrobić i o tym pamiętać? Nie. To jest zadanie BA, aby pomóc klientowi podjąć te niejednokrotnie trudne decyzje. W końcu, jeśli czegoś teraz nie zrobimy to tego nie będzie, a ja jako klient chciałbym mieć wszystko. A jednocześnie chciałbym to mieć, a nie czekać w nieskończoność aż system zostanie mi dostarczony. Co z tego, że firma dostarczy mi mój wymarzony system za X lat. Ja go potrzebuję teraz, ponieważ za X lat moje potrzeby mogą być już diametralnie inne.
W takim razie musimy określić czy wszystkie wymagania są jednakowo ważne. Co możemy dostarczyć później, a co jest niezbędne od samego początku. BA pomaga również w uporządkowaniu wymagań, nadaniu im priorytetów i ułożeniu ich w logicznej kolejności. Taką spójną listę funkcji systemu nazywamy backlogiem produktu. I to właśnie BA odpowiada za jego zbudowanie.
Budowanie backlogu i zarządzanie nim jest złożonym tematem, który zasługuje na oddzielny artykuł. Dlatego też pozwolę sobie przerwać w tym momencie i krótko podsumować.
Czy BA jest specjalistą, którego warto angażować w projekt informatyczny?
Najważniejsze moim zdaniem jako analityka z 11-letnim doświadczeniem nie jest to, żeby klient kupił system. Priorytetem dla mnie jest, aby klient był zadowolony z zakupionego systemu. Cieszę się bardzo, gdy widzę, że rozwiązanie, nad którym pracowaliśmy wspólnie z klientem jest używane. Niezmiernie mi miło, gdy słyszę od użytkowników, że ten system jest dla nich, że jest prosty i realizuje dokładnie to czego potrzebowali. Szczerze? Właśnie wtedy czuję, że dobrze wykonałem moją pracę jako BA. I to jest ten moment, w którym przekonuję się, że rzeczywiście jako BA jestem potrzebny.