No wiem, że chłopcy-adżajlowcy mówią, że analityka nie ma w Scrum Guide. Temu poświęciłem krótkie wystąpienie nt. wszystkich patologii pseudozwinności. Dzisiaj skupię się tylko na analityku/analityczce z prostego powodu: w ostatnim roku wprowadziłem w zespołach, z którymi pracuję rolę analityka i to działa tak superdobrze, że mam zamówienia na więcej. Trzeba to jednak zrobić z głową i dzisiaj o tym.
Lejek sprzedażowy
Najpierw obrazek, potem cała reszta:
To jest lejek sprzedażowy. Myślę, że koncepcja obiła Ci się o uszy, ale jeśli nie, to zwięźle streszczam. Przypuśćmy, że chcesz sprzedać 100 dresów z kreszu. Nie wszyscy, których zapytasz będą chętni bykupić. Mogą na przykład preferować dresy z 4 paskami. Musisz zatem przedstawić ofertę kupna np. 1000 osobom, a z nich 500 osób będzie poważnie zainteresowanych. Z tych 500 dres przymierzy może 200, a ostatecznie kupi 100 osób. Na każdym kolejnym etapie sprzedaży zostaje coraz mniej osób chętnych do wydania pieniędzy. Gdybyśmy liczbę osób reprezentowali graficznie za pomocą odcinków o długości 1000mm, 500mm, 200mm, 100mm, to jeśli położymy je równolegle obok siebie powstanie coś takiego:
Przypomina to trochę lejek. Reprezentuje prawidłowość procesu sprzedażowego od oferty do płatności i dlatego nazywa się lejkiem sprzedażowym.
Biznes siedzi na górze lejka. W biznesie czas płynie szybko, bo więcej się dzieje. Walczą tam o przychód, o prowizje, o płynność. Zanim zlecą jedną rzecz do IT, sami muszą przerobić ich ze kilkadziesiąt. Przerobić to znaczy: ocenić, oszacować, sprawdzić czy ma sens biznesowy. IT natomiast bierze jedną zleconą rzecz i rozdłubuje ją do ziarnistości atomu, bo tak trzeba, aby coś porządnie zrobić.
Jednym z pomysłów na uporządkowanie współpracy pomiędzy biznesem a IT, jest wstawienie pomiędzy nich analityka, który będzie tłumaczył z biznesowego na systemowe i odwrotnie.
Pytanie killer brzmi: kto w tym układzie ma najbardziej przerąbane? No, pewnie, że analityk! Z opisanego wyżej stylu pracy biznesu oraz IT wynika, że biznes będzie miał do analityka pretensje, że analizuje za wolno. IT będzie miało pretensje, że analizuje zbyt niedokładnie. Współczuję :(
A może zespół analityków?
Powszechnym rozwiązaniem problemu niewystarczających mocy przerobowych analityka, jest leczenie objawowe, czyli: zatrudnijmy więcej analityków. Niestety mamy do czynienia z układem z dodanim sprzężeniem zwrotnym, który działa tak:
Zespół analityków jako wydzielona jednostka w organizacji ma sens, gdy:
- pracujecie dla klientów zewnętrznych i analitycy są w projektach u różnych klientów,
- pracujecie dla klientów wewnętrznych, analityków jest wielu i trzeba o nich zadbać.
Oba powyższe rozwiązania pomogą zająć się rozwojem analityków oraz standardami ich pracy. W innych przypadkach polecam zatrudnianie analityków na budżecie managera zespołu, dla którego analityk pracuje. Ostatecznie o standardy pracy może dbać nieformalne community of practice w organizacji.
Uciec z lejka sprzedażowego
W opisanym na początku przykładzie analityk jest interfejsem pomiędzy biznesem a IT. Słowo "interfejs" po polsku tłumaczy się jako "międzymordzie". No zastanów się, czy chcesz być międzymordziem? :)
Pierwszym zadaniem analityka jest ucieczka z lejka sprzedażowego:
Jednym zdaniem: analityk zamiast pośredniczyć, powinien być wzmacniaczem współpracy między biznesem i IT.
Poniżej precyzuję konkretnego różnice pomiędzy dwoma opisanymi miejscami analityka w procesie dostarczania.
| jesteś międzymordziem, gdy | jesteś wzmacniaczem, gdy |
|---|---|
| spisujesz oczekiwania od każdego z interesariuszy, a potem przygotowujesz dla zespołu backlog prac | pomagasz interesariuszom ustalić wspólny cel, a w sprawie szczegółowych wymagań organizujesz warsztat z biz-IT |
| organizjesz spotkania z grupą > 4 interesariuszy, gdzie oni mówią, a Ty piszesz albo nagrywasz | organizujesz to spatkanie tak, by pracowali interesariusze, a ty trzymasz się roli moderatora, który dba o wartościowy output warsztatu |
| masz wielu interesariuszy o sprzecznych priorytetach i starasz się zadowolić wszystkich, albo samodzielnie podejmujesz decyzję o kolejności realizacji prac | moderujesz interesariuszy tak, aby to oni dogadali się między sobą co do priorytetu prac |
| wbjasz taski do backloga | ustalasz z zespołem i PO, kto będzie wbijał taski do backloga |
| przygotowujesz zespołowi kompletną specyfikację wymagań | wykorzystujesz refinement, aby przewarsztatować z zespołem wymagania; razem produkujecie karteczki, a potem na ich podstawie opracowujesz specyfkację |
| przygotowujesz dokumentację techniczną (powykonawczą lub na koniec sprintu) | opracowujesz standard tworzenia dokumentacji technicznej najbardziej odpowiedni do kontekstu, w którym pracuje zespół; dbasz dokumentacja była kompletna |
| jesteś jedyną osobą reprezentującą interesariuszy, z którą widuje się zespół | w razie potrzeby organizujesz spotkania/warsztaty z interesariuszami albo specjalistami biznesowymi |
| wyjaśniasz zespołowi cele i założenia biznesowe | pomagasz odpowiednim interesariuszom sformułować cele i założenia biznesowe; przygotowujesz ich do wyjaśnienia ich zespołowi |
Proroctwo :)
Kilka lat temu występowałem na Business Analyst Meetup we Wrocławiu i powiedziałem między innymi coś takiego: (...) niedawno Microsoft kupił GitHub i trenuje swoje algorytmy AI. Przewiduję, że niedalekiej przyszłości rola developerów straci na znaczeniu. Zawsze jednak będzie potrzeba ludzi, którzy poruszają się na granicy różnych domen, rozumieją i biznes i technologię. Analitycy będą w cenie.
I proszę bardzo - proroctwo zaczyna się sprawdzać. Tak, jak wspomniałem na początku, obserwuję, że na nowo odkrywa się rolę analityka.
