Cześć, nazywam się Kirill Belyavsky, pracuję jako analityk biznesowy w SoftServe i łączę to ze stanowiskiem menedżera usług w biurze analiz biznesowych SoftServe.
Jako analityk biznesowy pracuję nad projektami, uczestniczę w działaniach uznaniowych i przedsprzedażowych, przeprowadzam audyty i doradzam w projektach, aby zapewnić naszym klientom najlepszą obsługę w zakresie analizy biznesowej. A jako kierownik ds. usług w firmie dbam o to, aby nasi analitycy czuli się komfortowo, aby mieli wszystko, czego potrzebują do pracy i rozwoju. Ponadto prowadzę wykłady na kursach, przemawiam na spotkaniach i konferencjach oraz uczestniczę w webinarach.
Artykuł jest napisany dla początkujących analityków biznesowych, aby pokazać realia projektów IT i dać jak najwięcej praktycznych porad. Wszystko, co zamierzam powiedzieć, opiera się na osobistym doświadczeniu i doświadczeniu kolegów, których miałem szczęście poznać.
Dzień pracy analityka biznesowego
Dzień pracy BA odbywa się w co najmniej trzech wymiarach
Weźmy na przykład najbardziej powszechne obecnie podejście do opracowywania oprogramowania: scrum lub podobne podejście, w którym występują interwały czasowe, iteracje zwane sprintami.
Dzień pracy analityka biznesowego odbywa się jednocześnie w przeszłych, teraźniejszych i przyszłych sprintach, a jego zadaniem jest ciągłe balansowanie na krawędzi wszystkich trzech wymiarów:
- W bieżącej iteracji BA pomaga zespołowi wdrożyć wymagania sprintu: odpowiada na pytania, wyjaśnia kwestie i towarzyszy zespołowi w procesie opracowywania wymagań.
- W ostatniej iteracji wymagania są wdrażane na nowo – funkcjonalność, która została niedawno opracowana i przekazana klientowi. W bieżącym sprincie klient może teraz zadać wiele pytań dotyczących funkcjonalności lub uzyskać opinie użytkowników. To również zostanie omówione z BA.
- Przyszłość – BA jest zobowiązany spojrzeć w przyszłość, a nawet przewidzieć kilka wariantów „jutra”, ponieważ już teraz pisze i wyjaśnia wymagania oraz definiuje aspekty rozwiązania, które zostaną wdrożone za kilka tygodni.
W jaki sposób działania powinny być podzielone i w jaki sposób są one w rzeczywistości rozdzielane
Dzień pracy BA składa się w 60% z komunikacji: wielokrotne rozmowy ze wszystkimi, odpowiadanie na listy, pytania, rozmowy z klientem, zespołem, menedżerami. 20% czasu pozostaje na dokumentację i analizę.
Dzień pracy BA – podział zadań, jak powinien wyglądać
I 20% czasu to bardzo mało, zwłaszcza jeśli chodzi o analizę. W rezultacie obraz jest inny. Formalnie nadszedł koniec dnia pracy, ale BA nie może wyłączyć głowy i powiedzieć: „Wystarczy, skończyliśmy z analizą na dziś”. I nadal myśli o aspektach rozwiązania lub innej funkcji służącej do realizacji potrzeb biznesowych klienta. Niemożliwe jest wyłączenie się pod koniec dnia.
Dzień pracy BA – podział zadań w rzeczywistości
Nieregularne godziny pracy wynikają również z faktu, że outsourcerzy współpracują z klientami z innej strefy czasowej, częściej z Ameryki. Rozmawiasz z klientem wieczorem, a potem, gdy u nas jest noc, po drugiej stronie praca wrze – a rano nawarstwia się mnóstwo komunikacji.
Prowadzi to do szybkiego wypalenia, więc wprowadziłem dla siebie kilka zasad, które sprawiają, że dzień pracy jest bardziej produktywny.
Zasady efektywnego dnia pracy
Od razu powiem, jak sprawdzić, czy dzień pracy jest efektywny, czy nie. Jeśli w ciągu dnia masz pół godziny, aby usiąść, obejrzeć YouTube, zagrać w grę na telefonie, napić się kawy i nie ma „pożaru”, nikt cię nie szuka, nie ma otwartych spraw – wtedy dzień pracy jest efektywny.
Głównym wskaźnikiem efektywności analityka biznesowego jest dostępność wolnego czasu po zakończeniu zadań. Aby osiągnąć taki stan, stosuję 6 zasad, które pomagają mi zrobić to, co zaplanowałem, bez rozciągania dnia pracy w nieskończoność i bez wypalenia.
1. Nie omawiaj wymagań tylko z jednym członkiem zespołu
W trakcie rozwoju, wymagania są zazwyczaj dzielone na części. W scrumie jest to User Story. Nad jedną historią pracują co najmniej dwie osoby, np. programista i tester, który przetestuje tę funkcjonalność. Zwykle jest ich nawet trzech: tester, programiści backendu i frontendu. Najpierw jeden członek zespołu przyjdzie do BA z pytaniami dotyczącymi bieżącej historii, następnie inny zada własne pytania, a potem przyjdzie trzeci. Następnie uczestnicy zaczną rozwiązywać sprawy między sobą, nie będą się zgadzać, wrócą do BA – w końcu komunikacja zajmie dużo czasu.
Dlatego w projektach mówię: ” Koledzy, przychodźcie wszyscy na raz”. Oznacza to, że wszystkie osoby pracujące nad jedną historią muszą przyjść i porozmawiać ze mną osobiście lub online.
Zdalnie tworzymy osobny czat w Teams lub na Slacku dla każdej historii w sprincie i dodajemy osoby, które będą nad nią pracować. Dalej komunikacja odbywa się w jednym kanale na jedno pytanie. Uczestnicy czatu widzą pytania i odpowiedzi BA, informacje nie są tracone, a czas zostanie zaoszczędzony. Jest wiele historii, ale specjalistów jest mniej, więc są pogrupowani – pracowali nad jedną, przeszli do drugiej.
Jeszcze zanim pracowaliśmy zdalnie, kiedy wszyscy pracowali w tym samym pokoju i ludzie przychodzili do mnie w sprawie historii, mówiłem: „Przyprowadź innych, którzy pracują nad tą historią, a potem porozmawiamy”.
Jeśli mocno trzymasz się tej zasady, przynosi to wiele dobrego, ponieważ oszczędza czas wszystkim uczestnikom.
2. Przygotuj agendę z kodem czasowym dla spotkania
Nie myśl tylko o agendzie, ale zapisz ją i trzymaj się zaplanowanego czasu. Jest to oczywista rada, jednak w praktyce często widzę, że BA nie przygotowują agendy i nie kodują czasu spotkania.
Kodem czasowym nazywam przydział czasu dla każdego elementu. Na przykład w godzinnym spotkaniu, 15 minut zostanie przeznaczone na pierwszy punkt, 10 minut na drugi, 20 minut na trzeci i tak dalej, w zależności od złożoności poruszanych tematów.
Ważne jest, aby analityk biznesowy odpowiednio ułatwiał spotkania, aby pozostać w ramach zaplanowanych tematów. Upewnij się, że uczestnicy nie są przytłoczeni: jeśli dyskusja się przeciąga, zaproponuj przejście do następnego pytania i omówienie tego w innym czasie.
Wstępna agenda i kody czasowe to świetne sposoby na zaoszczędzenie czasu, ale z jakiegoś powodu nie wszyscy z nich korzystają.
3. Unikaj spotkań, które mogły mieć formę wiadomości e-mail.
W firmach jest wiele spotkań, nie trzeba chodzić na wszystkie. Z reguły, z grzeczności, młodzi BA uczestniczą we wszystkich spotkaniach pod rząd, starając się być na nich obecni. Jednak analityk biznesowy jest również zapraszany z grzeczności (aby się nie obraził) lub na wszelki wypadek (gdyby się przydał).
Aby sprawdzić, czy twoja obecność jest potrzebna, zadaj sobie pytanie:
- Czy stworzę jakąś wartość dla reszty spotkania?
- Czy to spotkanie stworzy wartość dla mnie?
Jeśli odpowiedź na oba pytania brzmi „nie”, to nie musisz iść na to spotkanie.
Jak powiedzieć „nie”? Zapytaj osobę, która Cię zaprasza, czego oczekuje, jaką wartość powinieneś wnieść na spotkanie. Jeśli nie potrafi odpowiedzieć, nie powinieneś iść na takie spotkanie.
Możesz odmówić wprost: „Wiem, że to ważne, ale nie mam teraz czasu. Proszę o napisanie protokołu ze spotkania na koniec zebrania, przeczytam go później”.
4. Unikaj wielozadaniowości
Moim zdaniem wielozadaniowość nie istnieje. Nikt nie może robić dwóch rzeczy w tym samym czasie. Nawet jeśli przychodzisz na spotkanie z laptopem i jednocześnie piszesz maila i słuchasz tego, co się dzieje. Tak naprawdę nie dzieje się to w tym samym czasie, ciągle przełączasz się z pisania e-maili na słuchanie i z powrotem. Samo przełączanie zajmuje czas, zakłóca koncentrację, a później prowadzi do komplikacji.
W przypadku zadań lubię stosować metodę pomodoro. Polega ona na skupieniu się na zadaniu przez 20-30 minut bez rozpraszania się innymi czynnikami (wiadomościami, połączeniami itp.). 30 minut to niewielki odcinek czasu i nic się nie stanie, jeśli nie odpiszesz natychmiast na wiadomość na Messengerze.
Metoda pełnej koncentracji na jednym zadaniu sprawdza się szczególnie dobrze w pracy zdalnej, ponieważ jest tam więcej czynników rozpraszających.
5. Stwórz artefakty, które mogą być ponownie wykorzystane
Jak to wygląda w praktyce. Na przykład, przygotowuję prezentację na temat wartości biznesowej pewnej funkcji. Najpierw używam jej dla klienta i w ten sposób sprawdzam: czy rozumiem potrzeby biznesowe, czy mam właściwy przepływ?
Omawiamy prezentację z klientem, a ja ją nieco poprawiam. Następnie przedstawiam tę samą prezentację zespołowi, gdy przygotowujemy historię i omawiamy funkcjonalność. Zadają pytania, a ja wprowadzam kolejne poprawki do materiału. Później można go użyć w wymaganiach, zmieniając niuanse.
Innym przykładem jest zapisywanie wyników spotkania. Jeśli mają to być wymagania, zapisz je od razu tam, gdzie przechowujesz wymagania. Nie musisz najpierw zapisywać podsumowania na papierze, a następnie wysyłać go pocztą lub umieszczać w innym miejscu. Staraj się nie umieszczać tych samych rzeczy w różnych miejscach, nie mnóż źródeł.
W moich projektach staram się tworzyć wymagania wielokrotnego użytku, czyli takie, które można ponownie zastosować. Pomysł jest podobny do systemów projektowych, z których korzystają projektanci.
System projektowy to zestaw komponentów, zasad, przepisów i narzędzi, które opisują, jak komponent powinien wyglądać i działać, aby programista mógł go używać bez konieczności ponownego tworzenia.
Wymagania mogą być również ponownie wykorzystane, jeśli w produkcie występuje podobne zachowanie: zachowanie podczas zapisywania zmian, zawartość podobnych formularzy i elementów, zestawy standardowych błędów i tak dalej.
Temat ponownego wykorzystania wymagań jest na tyle interesujący i przydatny, że warto poświęcić mu osobny artykuł.
6. Wymagaj informacji zwrotnej
Często zdarza się, że ludzie źle zrozumieli i zrobili coś nie tak, a BA mówi: „Przecież napisałem e-maila/na czacie/w confluence” lub ” Przecież podałem te informacje w wymaganiach”.
Jednakże, jeśli BA napisał, to nie oznacza, że to na pewno zostało przeczytane ze zrozumieniem. Analityk biznesowy powinien zatem zapytać ludzi, czy widzieli to, co zostało napisane i czy są gotowi omówić te informacje.
Ważne jest, aby upewnić się, że wszystko zostało przeczytane; pozwoli to zaoszczędzić czas na późniejszych etapach. Zdarza się, że programiści nie czytają uważnie wymagań analityka biznesowego i wracają do zadawania pytań na bardzo późnym etapie.
Kiedy BA po prostu zakłada, że programiści zobaczą, co jest potrzebne na czas, zasadniczo polega na niepotwierdzonych informacjach, które uważa za prawdziwe.
Podsumowanie
Aby krótko podsumować zasady w jednej liście:
- Przedyskutuj wymaganie ze wszystkimi uczestnikami, którzy nad nim pracują;
- Organizując spotkanie, ustal z góry, co chcesz omówić i ile czasu zajmie każda kwestia;
- Unikaj uczestniczenia w „niepotrzebnych” spotkaniach;
- Skup się na jednym zadaniu na raz;
- Twórz artefakty, które można ponownie wykorzystać;
- Upewnij się, że właściwi uczestnicy przeczytali i zaakceptowali to, co napisałeś.