We własnej pracy widzę, że analitycy biznesowi popełniają te same błędy na początku projektu. Dlatego w tym artykule zebrałem praktyczne porady z doświadczenia mojego i moich kolegów: jakie kroki analityk biznesowy podejmie na starcie, zwiększą prawdopodobieństwo pomyślnego zakończenia projektu. Celem tych wskazówek jest przygotowanie młodszego IA do realiów projektów IT.
Pierwszą rzeczą, którą należy zrobić przed zanurkowaniem w pracę, jest ocena, jak bardzo złożony będzie projekt. Wstępna ocena pomoże przewidzieć ryzyko i przygotować się na trudności.
Oceń złożoność projektu
Aby zrozumieć złożoność, wygodnie jest sklasyfikować projekty według typu klienta, wielkości projektu, rodzaju umowy i metodyki. W każdej z tych kategorii istnieje wariant łatwiejszy i bardziej złożony.
Typ klienta
Łatwiej byłoby współpracować z ISV – Independent Soft Vendor, czyli firmą, która sama produkuje oprogramowanie. Do tej kategorii można zaliczyć również STARTUP. ISV zatrudniają do swojej pracy dodatkowych wykonawców-wędrowców, często z Ukrainy, Białorusi i Rosji.
Łatwiej jest nawiązać kontakt i porozumieć się z klientami typu ISV, ponieważ znają oni specyfikę produkcji oprogramowania, posługują się terminologią techniczną i rozumieją wszystkie niuanse.
Trudniejsza jest współpraca z klientami typu Enterprise. Zazwyczaj są to duże organizacje lub firmy, które nie są w świecie IT, np. fabryka, sieć szpitali, czy prawdziwy biznes, który zdecydował się na cyfryzację.
Klient Enterprise angażuje Twoją firmę jako sprzedawcę do wdrożenia pożądanego rozwiązania: optymalizacji procesów, wdrożenia funkcji lub całkowitej cyfryzacji przedsiębiorstwa.
Enterprise firm jest trudniejsze z dwóch powodów:
- Nie rozumieją, jak pisze się oprogramowanie, nie wiedzą, czym jest SDLS, i w zasadzie nie powinni. Ich podejście brzmi: zapłaciliśmy pieniądze – zróbcie właściwe rozwiązanie.
- W dużych organizacjach jest więcej biurokracji: zatwierdzeń, polityk, dodatkowych niuansów i samych interesariuszy.
Wielkość i terminy
Łatwiej jest poradzić sobie z projektem krótkoterminowym, w którym uczestniczy niewielu interesariuszy: jeden przedstawiciel po stronie klienta i mały zespół do realizacji celów projektu.
Projekt długoterminowy, który wymaga kilku zespołów deweloperskich i wielu interesariuszy po stronie klienta, jest zaliczany do projektów złożonych. Im więcej jest zespołów, tym bardziej potrzebna jest komunikacja i stała synchronizacja wszystkich zaangażowanych.
Rodzaj umowy
Prosty to Dedicated Team, zwany też Time and Material. W tym przypadku zespół pracuje nad produktem – a firma dostaje wynagrodzenie za czas przepracowany przez zespół. Załóżmy, że zespół pracował przez miesiąc i wystawiono rachunek. Rachunek zostaje zapłacony, zespół kontynuuje pracę, a miesiąc później dostaje kolejny rachunek.
Kontrakt Time and Material jest dość prosty, bo nie ma żadnych konkretnych ograniczeń: zespół pracuje, tworzy produkt i dostaje wynagrodzenie.
Trudniejsza jest praca z Fixed Price. Ten typ kontraktu oznacza, że ustalonej cenie towarzyszy ustalony termin dostarczenia przez zespół uzgodnionego dzieła.
Z Fixed Price przychodzi trudność, która jest specyficzna dla pracy VA: Scope Creep – rozprzestrzenianie się zakresu pracy.
Dlaczego zdarza się Scope Creep:
Uzgodniłeś z klientem pewien zakres, jest jasny termin zakończenia projektu, ustalony koszt – prace się rozpoczęły. Ale potem klient zaczyna generować dodatkowe „życzenia” lub funkcjonalności, a analityk biznesowy zdaje sobie sprawę, że trzeba zrobić więcej niż planowano. Zakres prac zwiększa się, ale zazwyczaj termin pozostaje taki sam i cena również.
Zadaniem ВA w tej sytuacji jest jak najwcześniejsze zidentyfikowanie rzeczy związanych ze scopingiem. Czasami trzeba będzie ostro komunikować się z klientem, próbując odrzucić nowe wizje lub nalegając, że dodatkowe wymagania nie zostały sprecyzowane, więc trzeba przesunąć termin.
Metodologia
Istnieją dwie główne linie metodyk stosowanych przy tworzeniu projektów: Agile i Waterfall.
Obie metodyki mają prawo bytu, choć w projektach outsourcingowych powszechne jest obecnie podejście zwinne, w którym rozwijamy produkt iteracyjnie: w sprintach trwających od 2 do 4 tygodni. Na koniec każdego sprintu klient otrzymuje przyrostowy produkt i może z nim natychmiast pracować: używać go, zbierać informacje zwrotne itp.
Waterfall jest mniej elastyczny, ponieważ produkt końcowy i rozwiązanie są zdefiniowane z góry, a zespół musi je zaimplementować w jak największej ilości szczegółów. Wymagania w Waterfall są długo zbierane i weryfikowane do ostatniego przecinka, zanim jeszcze rozpocznie się rozwój.
Ścisłe podejście jest ważne dla produktów, w których koszt błędu jest wysoki, jak np. oprogramowanie dla maszyny wykonującej laserowe operacje oczu.
Podejście w tym przypadku nie brzmi: szybko napisz aplikację i oddaj ją do użytku, a jeśli podczas operacji wydarzy się coś złego, zespół mówi: „Cóż, feedback nie jest zbyt dobry, ale w następnej wersji dokończymy ją, przerobimy i ponownie rozwiniemy”.
W sytuacji, w której koszt błędu jest wysoki, sposobem pracy jest Waterfall: długo trwa opisywanie wszystkich możliwych wymagań, następnie wymagania są audytowane i certyfikowane, a dopiero potem wdrażane. W podejściu sztywnym trudniej się pracuje: koszt błędu jest wyższy i wszystko musi być uwzględnione przy pierwszym podejściu, na etapie pisania wymagań.
Podsumujmy krótką wycieczkę po kategoriach projektów:
- Najprostszą opcją będzie projekt ISV lub Startup, z małym zespołem i krótkim czasem realizacji.
- Projekty złożone odnoszą się do klientów Enterprise, długoterminowych projektów z dużą liczbą interesariuszy.
Po zrozumieniu przez analityka biznesowego kontekstu projektu, należy zrozumieć swoje obowiązki i pracować z oczekiwaniami.
Zrozumieć swój obszar odpowiedzialności
Zanim stworzysz właściwe oczekiwania wobec ВA od reszty uczestników, musisz sam zrozumieć, co ВA robi na projekcie i jak podzielone są obowiązki w zespole.
Za jakie zadania odpowiedzialny jest BA
- analizuje potrzeby biznesowe, kontekst, interesariuszy;
- gromadzi wymagania;
- zarządza wymaganiami;
- komunikuje wymagania;
- jest odpowiedzialny za zawartość produktu;
- nadzoruje zadania związane z akceptacją funkcjonalności.
Podsumowując, analityk biznesowy jest odpowiedzialny za wszystkie zadania związane z wymaganiami, scopingiem, zawartością produktu i akceptacją funkcjonalności. Czasami jednak w projektach analitykowi biznesowemu przydzielane są inne zadania, które nie są specyficzne dla tej roli.
Czego ВA nie powinien robić:
- Podział zadań pomiędzy deweloperów (zdecyduj, który deweloper powinien wykonać dane zadanie).
- Równomierne obciążenie zespołu pracą.
- Zobowiązanie zespołu – obietnica zespołu dotycząca wykonania określonej funkcjonalności, typowa dla agile i scrum. Na przykład zespół obiecuje, że zrobi pewną część funkcjonalności do następnej iteracji.
- Podejmowanie decyzji technicznych, bo za to odpowiadają inne osoby.
- Liczenie czasu (ile czasu ktoś poświęcił na dane zadanie) i różne raportowanie.
- Dystrybucja wynagrodzeń i premii.
Z mojego doświadczenia wynika, że działania, które nie są typowe dla roli ВA, nie tylko przeszkadzają w wykonywaniu bezpośrednich obowiązków, ale także prowokują konflikty.
Jeśli ВA jest zaangażowany w zespół, utrudni to zarządzanie wymaganiami: analityk dostosuje wymagania do obietnicy zespołu lub nie przyjmie zobowiązania, wiedząc, że wymagania zawierają rzeczy, z którymi ВA się nie zgadza.
Aby uniknąć sytuacji, w których ВA nie wypełnia swoich obowiązków, należy od razu dowiedzieć się, czego oczekuje się od analityka biznesowego w danym projekcie.
Praca z oczekiwaniami
Nieumiejętne zarządzanie oczekiwaniami będzie prowadzić do błędów w komunikacji, wzajemnego niezadowolenia i konfliktów. Błędne wyobrażenia o roli ВA mogą pojawić się po stronie analityka biznesowego, zespołu lub PM.
Aby zrozumieć oczekiwania na początku projektu, należy przejść przez trzy kroki: podstawową analizę interesariuszy, wyjaśnienie oczekiwań z PM, budowanie oczekiwań z zespołem i klientem.
Przeprowadzić podstawowy stakeholder analysis
Analiza wszystkich interesariuszy i powiązań między nimi jest jedną z pierwszych rzeczy, jakie BA robi na projekcie. Od pierwszych dni pracy analityk biznesowy dowiaduje się o:
- strukturę zespołu i liczbę osób, z którymi BA będzie pracować;
- strukturę zarządzania – kto i komu raportuje;
- klienta – jakie jest jego zaplecze, oczekiwania i priorytety.
W normalnej sytuacji PM będzie onboardował analityka biznesowego i odpowiadał na pytania. Jeśli tak się nie stanie, musisz być proaktywny w poszukiwaniu odpowiedzi, ponieważ analiza interesariuszy zapewnia ważny kontekst, z którego wynika reszta decyzji BA dotyczących oczekiwań.
Zrozumienie oczekiwań PMa
Analityk biznesowy ma najczęściej do czynienia z PM, ponieważ jest on główną osobą odpowiedzialną za projekt. Zadaniem PMа jest realizacja projektu zgodnie z umową, dotrzymanie terminu, budżetu, zakresu prac i jakości.
Aby osiągnąć cel, PM potrzebuje od analityka biznesowego dwóch globalnych rzeczy:
- Backlogu, wypracowanego na wiele horyzontów do przodu. Przez horyzont rozumiemy sprinty lub jakieś przedziały czasowe.
- Stałego obciążenia zespołu pracą.
Na każdym konkretnym projekcie PM będzie miał dodatkowe oczekiwania. Jeśli analityk biznesowy nie wyjaśnił na starcie, jak kierownik przedstawia obowiązki ВA, nie da się później uniknąć konfliktów.
Jak dowiedzieć się, na co czeka PM:
- Umów się na spotkanie w cztery oczy i poproś o powiedzenie wprost, jak PM widzi pozycję BA w projekcie i za co analityk biznesowy powinien być odpowiedzialny.
- Poproś o sformułowanie informacji w krótkiej formie: na tablicy, papierze, w mailu.
Jeśli informacja lub odpowiedź na pytanie nie jest tylko zaklęta, ale wypunktowana, osoba będzie musiała wybrać konkretne i zrozumiałe sformułowania. To bardzo dobra metoda: sprawdza się w pracy z klientami i z każdym interesariuszem.
Dlaczego nie może wystarczyć opis stanowiska, tylko trzeba rozmawiać z PM?
Opis stanowiska pracy jest zazwyczaj zbyt ogólny. Nie jest też podstawowym opisem stanowiska pracy, który ma firma, bo on też jest wyrwany z kontekstu. A Ty potrzebujesz konkretów, zrozumienia czego konkretny PM oczekuje od konkretnego BA na konkretnym projekcie.
Jeśli Twoje oczekiwania z pozycji osoby odpowiedzialnej nie pokrywają się z wizją PM – lepiej od razu się o tym dowiedzieć. W przeciwnym razie może się okazać, że PM i zespół oczekują od Ciebie czegoś, o czym nie wiesz i na tym gruncie zaczynają się konflikty.
Pozycja BA nie jest czymś maksymalnie precyzyjnym i ostatecznym, nie ma „wzorcowego BA”. Obowiązki zależą w dużej mierze od kontekstu projektu, klienta, firmy. Dlatego koniecznie trzeba wyjaśnić sytuację na samym początku współpracy z PM i zespołem, jeśli chce się uniknąć konfliktów.
Tworzenie oczekiwań z zespołem i klientem
Kiedy jest już zrozumienie, czego PM oczekuje od analityka biznesowego – trzeba stworzyć oczekiwania z zespołem i klientem, czyli wyjaśnić, co BA będzie robił, za co będzie odpowiedzialny. Młodzi analitycy biznesowi często zaniedbują ten krok, ponieważ myślą, że wszyscy już wiedzą, co robią na projekcie.
W rzeczywistości możesz mieć zespół lub część zespołu, który nigdy nie pracował z BA lub pracował w zupełnie innym środowisku, gdzie od BA wymagano innych rzeczy. Klient również czasami nie rozumie, co analityk biznesowy jest dla i co robią na projekcie.
Jak BA może kształtować oczekiwania:
- Zrób krótką prezentację i poproś zespół o 15 minut na opowiedzenie o sobie i swojej roli w projekcie. Powiedz, czym będziesz się zajmował, jaką wartość wniesiesz do projektu i dlaczego dobrze jest mieć w projekcie analityka biznesowego.
- Wyjaśnij zasady współpracy z Tobą. Mogą być one dość zróżnicowane.
Zamiast podsumowania: 5 wskazówek, jak nie zawalić swojego pierwszego projektu
- Nie bój się mówić głośno, jeśli czegoś nie rozumiesz. Kiedy nowicjusze przychodzą do projektu, wydaje im się, że powinni umieć zrobić wszystko na raz, więc starają się wykonać każde zadanie bez zadawania „zbędnych” pytań.
- Nie bój się prosić o pomoc na wczesnym etapie. Jeśli czujesz, że możesz nie być w stanie czegoś zrobić, podnieś rękę i powiedz: „Chłopaki, chyba nie dam rady zrobić tego samemu, potrzebuję pomocy”. Albo: „Nie rozumiem czegoś, potrzebuję pomocy”.
Z reguły nowi koledzy starają się jak mogą, by rozwiązać problem na własną rękę, aż do momentu, gdy jest już naprawdę za późno. A kiedy BA kończy się stwierdzeniem, że nie mógł wykonać zadania, to już dużo trudniej jest pomóc.
Kilka słów o tym, czym jest „paraliż analityczny”. Jest to wysoki stopień niepewności, który paraliżuje proces refleksji. Sytuacja pojawia się, gdy widzimy kilka opcji, z których wszystkie wydają się mieć taką samą wartość, więc podjęcie decyzji jest niemożliwe: „Powinienem wziąć tę część wymagań, ale wszystko zależy od tej, a ona też nie jest jasna. A jeśli zajmiesz się tym drugim, to też zależy od czegoś innego”.
Nie da się podjąć ostatecznej decyzji i siedzimy sparaliżowani.
Dobrym sposobem na uniknięcie paraliżu analitycznego jest rozwiązanie, które mój znajomy nazywa „typowym błędem”.
Na przykład chcesz coś omówić z klientem, jakieś zadania, pytania, ale klient mówi:
– Słuchaj, to jeszcze w ogóle nie jest jasne, zróbmy to później.
I na tym można poprzestać. Ale lepiej zrobić coś i pokazać to klientowi na podstawie swoich założeń – opis wymagań, schemat, rysunek. To będzie „typowe zło”. Przynieś to i powiedz:
– Ja to widzę w ten sposób. Jak myślisz – jest czy nie jest?
Prawdopodobnie nie zostaniesz poinformowany:
– Nie chcę tego widzieć, zróbmy to później.
Ale oni spojrzą na to i zapytają:
– To w ogóle nie jest w porządku, to jest w porządku tutaj, zmień to.
W tym momencie staje się mniej więcej jasne, co należy zrobić i można powoli wychodzić z paraliżu.
- Jasno informuj o zagrożeniach, gdy zauważysz jakiekolwiek podejrzenia. Jak najwcześniej powiadom wszystkich zainteresowanych o zagrożeniach. Im wcześniej to zrobisz, tym mniej problemów może potencjalnie wystąpić.
- Co najważniejsze, pamiętaj, że jest prawie niemożliwe, aby projekt zakończył się niepowodzeniem w pojedynkę – jest to „wysiłek zespołowy”. Projekt nie może się nie udać z powodu jednej osoby. Musisz to zrozumieć, wykonywać swoją pracę i nie denerwować się, że może się nie udać tylko z twojego powodu.