Od roli technicznej do analizy biznesowej. 3 rzeczy, których nauczyłam się, zmieniając podejście

3 marca, 2021 Katarzyna Jezierska

Dla skoncentrowanego na hurtowniach danych analityka systemowego, jakim byłam przez większość swojej kariery zawodowej, zmiana na stanowisko analityka biznesowego była nie lada wyzwaniem. Po ponad dwóch latach pracy w takiej roli w PGS Software jestem przekonana, że moje doświadczenie w większej mierze pomogło, niż przeszkadzało. Niemniej jednak, ja i mój zespół włożyliśmy mnóstwo wysiłku w to, aby moja zorientowana na techniczne rozwiązania głowa, stała się przydatna w codziennej pracy.

 

Czego nauczyłam się w tym czasie? Co zdziwiło mnie najbardziej w procesie analizy biznesowej?
Jeśli Ty także myślisz o przebranżowieniu się z analityka systemowego na biznesowego, mam nadzieję, że moje doświadczenia ułatwią Ci wejście w tę coraz popularniejszą rolę.

 

Na początek małe wyjaśnienie: „analityk systemowy” może oznaczać wiele różnych ról. W moim przypadku było to projektowanie produktów bazodanowych, takich jak procesy ETL, wyspecjalizowane data marty czy warstwy danych źródłowych. Moimi klientami byli głównie użytkownicy techniczni tych produktów: specjaliści od raportowania, inżynierowie modelowania danych czy specjaliści data governance. Większość produktów, z którymi pracowałam, w ogóle nie miała interfejsu użytkownika.

 

Lekcja nr 1: Po drugiej stronie jest prawdziwy człowiek

 

Nie jest tak, że podczas prototypowania procesów ETL nie zdawałam sobie sprawy, że „użytkownik” oznacza osobę. Oczywiście wiedziałam, że istnieją wysoko wykwalifikowani profesjonaliści używający produktów, które pomagałam budować. Wiedziałam też, że niektórzy użytkownicy dostarczają dane, które będziemy przetwarzać – gromadzić, czyścić i przekształcać – do dalszej analizy.

Teraz miałam budować rozwiązania tylko dla tej drugiej grupy.

Zmiana podejścia z „istot ludzkich dostarczających surowe dane do oprogramowania” na osoby, które wspieramy w ich działaniach, wymagała ode mnie poważnej gimnastyki umysłowej.

 

Absolutną nowością było myślenie nad działaniami użytkownika, umieszczanie ich w szerszym kontekście i badanie, w jaki sposób produkt może pomóc.

 

Nie wspominając już o tym, że używanie produktu nie powinno być samo w sobie uciążliwe. Tutaj kudosy dla Michałą Bączka, pierwszego UX Designera, z którym miałam okazję pracować. Dzięki jego pasji i cierpliwości, szybko przeszłam od udawania, że z produktu korzystają roboty, do łatwego identyfikowania wzorców, które wymagają dopracowania, aby zapewnić użytkownikom lepszy user experience. Oprócz biegłości w krytykowaniu propozycji UX, co oczywiście było kolejnym krokiem w zostaniu prawdziwym analitykiem biznesowym 😉 , nauczyłam się zadawać nowe pytania, które pomagają w budowaniu rozwiązania.

 

Te pytania, które niespodziewanie dla mnie okazały się tak krytyczne w projektowaniu produktów, to:

1. Jak często będzie wykonywane to działanie? Czy użytkownik powtarza je codziennie, czy tylko raz w roku?

2. Jak często ten użytkownik korzysta z rozwiązania? Czy towarzyszy mu ono w codziennym życiu, czy tylko sporadycznie musi do niego sięgnąć?

3. Czy dana aktywność może i powinna być podzielona na kilka etapów? Jeśli tak – jaki podział będzie optymalny? Jak upewnić się, że użytkownik jest świadomy, że jest w trakcie większego procesu i na jakim jego etapie?

4. Czy użytkownik będzie miał łatwy dostęp do tej funkcji? Czy powinniśmy taki zapewnić, a może funkcjonalność jest dedykowana zaawansowanym użytkownikom?

5. Czy realizacja kolejnych kroków w procesie będzie intuicyjna? Czy dla podobnych czynności użyte są podobne wzorce?

Powyższy fragment to tylko wybór wskazówek, które otrzymałam podczas współpracy z projektantami UX, projektantami UI i bardziej doświadczonymi kolegami.

Dzięki nim zrozumiałam, jak ogromną domeną w obecnym projektowaniu produktów jest UX experience.

Nadal nie jestem zbyt pewna swojej wiedzy o doświadczeniach użytkowników i cieszę się, że pracuję z najlepszymi specjalistami w tej dziedzinie.

Najcenniejszą lekcją dla mnie było zaakceptowanie faktu, że po drugiej stronie produktu znajduje się człowiek – ze wszystkimi jego zmaganiami, bólami i motywami. I to właśnie człowiek powinien być w centrum zainteresowania przy budowaniu produktu.

 

 

Lekcja nr 2: Proces jest większy niż produkt

Kiedy już uwzględniłam prawdziwą osobę w mojej wizji tworzenia oprogramowania, z zaskoczeniem zdałam sobie sprawę, że nie wszystkie jej działania są częścią produktu. Ponieważ spędziłam poprzednie lata, pracując wyłącznie na danych wejściowych dostarczanych przez użytkowników, niemal szokujące było odkrycie, że proces biznesowy jest zazwyczaj tylko częściowo wspierany przez oprogramowanie. Innymi słowy, dane, nad którymi pracowałam, były dostarczane w ramach większego procesu biznesowego.

Ponieważ wcześniej pracowałam głównie w bankowości, dobrym przykładem może być proces wnioskowania o kredyt.
Dla mnie liczył się tylko wynikowy zestaw danych: kompletny wniosek kredytowy i sposób jego rozpatrzenia. W tamtych czasach nie obchodziło mnie, ile czasu Administrator kredytu potrzebuje na zebranie wszystkich danych potrzebnych do złożenia wniosku, uzyskania wstępnej punktacji, dodania bardziej istotnych informacji w celu podjęcia ostatecznej decyzji kredytowej. Pracowałam nad wynikowym zestawem danych i nie musiałam zadawać sobie takich pytań.

Teraz znalazłam się w zupełnie odwrotnej sytuacji – miałam koncentrować się na produkcie, który wspierał proces; a nie takim, których korzysta z wyników procesu.

Miałam do czynienia z zestawem zupełnie innych czynników, które należy wziąć pod uwagę, myśląc o tym, jak produkt będzie używany.

Udało mi się zaakceptować poniższe koncepty:

1. Proces biznesowy nie bez powodu nazywany jest procesem; często zdarza się, że wymaga czasu i nie jest efektem jednorazowej czynności.

W pracy nad projektowaniem produktu oznacza to, że trzeba pomóc użytkownikowi odnaleźć się w procesie. Ponadto ważne jest, aby zdefiniować najważniejsze dla użytkownika informacje, aby ten mógł szybko odnaleźć się w wieloetapowym zadaniu.

2. Nie wszystkie działania będą możliwe do odtworzenia w oprogramowaniu.

To banalne stwierdzenie, jednak podczas tworzenia rozwiązania często zapominamy, że istnieje świat poza komputerem. Wracając do przykładu wniosku kredytowego – między klientem a Administratorem Kredytowym odbywa się rozmowa. Zazwyczaj będzie to spotkanie twarzą w twarz, bez żadnego trwałego śladu w oprogramowaniu. Nie tylko wpływa to na oś czasu procesu odzwierciedloną w produkcie, ale też na to, jakie działania użytkownik zaloguje w systemie. Dodatkowo oznacza to, że trzeba się pogodzić z istnieniem innych źródeł danych nieustrukturyzowanych.

3. Produkt to nie koniec historii.

Jakkolwiek chcielibyśmy myśleć inaczej, rozwiązania, które tworzymy, są najczęściej raczej środkiem niż celem. Oczywiście wszystkie zebrane dane mogą służyć do weryfikacji wydajności, sprawdzania zgodności, raportowania lub prostych statystyk. Jednak głównym celem jest pomoc naszemu użytkownikowi w osiągnięciu jego celu.

 

Dołącz do zespołu analityków biznesowych w PGS Software

 

Lekcja nr 3 Niedoskonałość produktu

 

Kilkuletnie doświadczenie, które zdobyłam jako analityk systemowy, dostarczyło mi dwóch bardzo ważnych narzędzi:

1. Podstawowego zrozumienia, jak można wdrożyć wymagane rozwiązanie, jaki jest względny koszt różnych podejść i które z nich będą zgodne z istniejącą architekturą lub funkcjonalnościami;

2. Silnego przywiązania do tworzenia reużywalnych wzorców standaryzacji w całym rozwiązaniu – dla mnie konikiem zawsze było dbanie o spójność formatów danych.

Chociaż oba wymienione podejścia są bardzo cenne w mojej codziennej pracy i mocno wierzę, że moje wcześniejsze doświadczenie zawodowe było kluczowe, wszystko ma swoją cenę.

Intuicja, która pozwala mi na rozróżnienie rozwiązań łatwych od trudnych, często sprawia, że chcę zanadto upraszczać budowane rozwiązanie. Oczywiście, proponowanie „tańszych”, uproszczonych rozwiązań jest rozsądne, ale to nie powinno być głównym kryterium podczas projektowania produktu.

Budujemy produkt, aby wspierać określone procesy lub w inny sposób dostarczać wartość klientowi. I do tego zawsze należy dążyć, a nie upraszczać za wszelką cenę.

Innymi słowy – omawiając potrzebę biznesową, w centrum uwagi musi być potrzeba biznesowa, a nie jej rozwiązanie.

Podobnie jest z ponownym wykorzystaniem tego, co już jest używane w produkcie. Takie podejście jest jak najbardziej pożądane, ale musi być poprzedzone potwierdzeniem, że to, co dostarczymy, spełni swoje zadanie. Jak wspomniałam, często zwracam uwagę na format danych. Podczas pracy z surowymi danymi irytowałam się widząc, co chwilę różne wersje danych księgowych. Czasami wartość była podawana jako liczba całkowita a czasami jako liczba z podwójną lub potrójną cyfrą. Wtedy nie rozumiałam jeszcze, że dane pochodziły z różnych etapów procesu, gdzie wymagana dokładność kwoty zależała od procesu biznesowego i często była podyktowana zewnętrznymi regulacjami. Podsumowując, spójność formatu danych nie powinna być ważniejsza niż biznesowe wymagania.

 

Sprawdź ->>> Jak zbierać wymagania biznesowe w IT. 

 

Ode mnie wymagało to sporo wysiłku, ale zmieniając rolę z technicznej na biznesową, kluczowa jest także zmiana przedmiotu naszego zainteresowania. Powinien nim być wspierany proces, zaspokajana potrzeba użytkownika a nie rozwiązanie samo w sobie.

Najważniejsza jest tutaj zmiana priorytetów w myśleniu i pogodzenie się z tym, że produkt może nie być technicznie i logicznie doskonały.

Chociaż zawsze warto o to walczyć.

Kontakt z autorką: Katarzyna Jezierska

Najnowsze wpisy