Zacznę nietypowo, bo od… ostrzeżenia. Jeżeli jesteś miłośnikiem Scruma i kilkukrotnie przestudiowałeś Scrum Guide, traktując go jako swego rodzaju biblię, po przeczytaniu mojego artykułu możesz poczuć, jakbyś zderzył się ze ścianą. Moje obserwacje na temat pracy w zwinnych metodologiach, przedstawione w tym tekście, nie do końca mają odzwierciedlenie w tym, co mówi Scrum Guide. Zaciekawiłem Cię? Pora na konkrety.
Zanim przyjrzymy się podobieństwom, które łączą pracę analityka biznesowego oraz Product Ownera, przypomnijmy sobie definicje obu ról.
Kim jest analityk biznesowy?
Często można spotkać się ze stwierdzeniem, że ta rola to swego rodzaju most między światem IT a biznesem. A co mówi o niej nasza analityczna biblia, czyli BABOK Guide (tak, my analitycy, tak jak „scrumowcy”, mamy swoją biblię!)?
BABOK Guide dosyć „zwinnie” podchodzi do tematu, mówiąc, że analityk biznesowy to osoba, która przeprowadza analizę biznesową (zgodnie z zasadami Babok Guide), niezależnie od stanowiska zajmowanego w organizacji. Oczywiście, rynek również zdefiniował rolę analityka i wymagania dla kandydatów: oczekuje się od nich zarówno twardych, jak i miękkich kompetencji (serdecznie polecam artykuł o kompetencjach miękkich w analizie biznesowej “Kompetencje miękkie analityka biznesowego”).
Jednak osoby zajmujące inne stanowiska również mają minimalny zestaw kompetencji, umożliwiających przeprowadzenie podstawowej analizy biznesowej. Są to np.:
- Business Architect,
- Data Analyst,
- Product Manager,
- Requirements Engineer,
- Product Owner.
Trudno jednoznacznie odpowiedzieć na to pytanie. Moim zdaniem, łatwiej byłoby opisać, czym tak naprawdę analityk się nie zajmuje. To pokazuje, jak pojemna jest rola analityka i jak rozwija się wraz z rozwojem technologii oraz zróżnicowaniem projektów, w których my, analitycy, pracujemy.
Wracając do BABOK Guide: czytamy w nim, że głównym zadaniem analityka biznesowego jest przekształcenie potrzeby biznesowej w produkt poprzez jak najlepsze zdefiniowanie wymagań biznesowych i zaprojektowanie rozwiązania dostarczającego jak największą wartość dla użytkownika końcowego.
Tyle teorii. A jak praca analityka wygląda w praktyce?
To zależy od naturalnych predyspozycji osoby zajmującej się analizą biznesową. Dla przykładu: w Craftware może spełniać się w jednej z trzech specjalizacji, które wyodrębniliśmy w dziale analizy biznesowej w odpowiedzi na oczekiwania rynku. Są to:
- analiza biznesowa,
- analiza biznesowo-systemowa,
- analiza systemowa.
Nawiązując do tezy, którą postawiłem: dlaczego tak trudno zdefiniować zakres odpowiedzialności analityka biznesowego? Wymienione powyżej obszary analizy pomagają to zrozumieć.
Analityk biznesowy skupi się głównie na tym, aby dany problem rozwiązać poprzez opisanie go procesem. Nie będzie “wchodził” od razu w obszary techniczne i szukał rozwiązania w postaci systemu IT.
Na drugim biegunie jest analityk systemowy: osoba z zacięciem technicznym, z predyspozycjami i umiejętnościami do bardziej technicznej analizy problemu. Zaproponuje zatem użytkownikom wsparcie przy użyciu systemu informatycznego.
Najczęstsze i najbardziej uniwersalne jest połączenie wymienionych specjalizacji – analityk biznesowo-systemowy. Taki specjalista na początku analizy skupi się na procesach biznesowych i ewentualnych obszarach do usprawnień, w następnej kolejności przejdzie do szukania rozwiązania, opierającego się na implementacji/adaptacji systemu informatycznego.
Więcej o tym, jak pracuje analityk biznesowy, możesz przeczytać w artykule “Analiza biznesowa w projekcie IT – z kim pracuje analityk?”.
Niezależnie od obszaru specjalizacji, duże znaczenie mają naturalne predyspozycje osoby pełniącej tę rolę. Wspomniałem wcześniej o kompetencjach miękkich: to właśnie one stanowią core i są kluczowe dla tej roli. Można powiedzieć, że są bazą dla kompetencji technicznych. Właśnie te naturalne predyspozycje decydują o tym, czy analityk sprawdzi się również w roli Product Ownera. Ale o tym za chwilę…
Kim jest Product Owner?
Zobaczmy, jak rolę Product Ownera definiuje Scrum Guide.
Czytamy w nim, że celem wszystkich działań Product Ownera jest maksymalizacja wartości produktu na koniec każdego ze sprintów. Do głównych obowiązków Product Ownera zalicza się zarządzanie backlogiem produktu (ang. Product Backlog). Odbywa się to przez:
- jasne, zrozumiałe zdefiniowanie elementów backlogu produktu,
- szerzenie wizji produktu,
- priorytetyzację zadań,
- optymalizację pracy zespołu deweloperskiego (ang. Development Team),
- transparentność oraz dostępność backlogu.
W teorii, Product Owner może sam wykonywać zadania z backlogu produktu lub delegować je zespołowi deweloperskiemu (zdecydowanie częściej występująca sytuacja), jednak to zawsze on pozostaje odpowiedzialny za wynik pracy zespołu.
W „czystym” Scrumie rola Product Ownera może być odgrywana tylko przez jedną osobę. Nie będę wchodził szczegółowo w kompetencje Product Ownera – na naszym blogu są dwa artykuły, które opisują jego rolę oraz jego narzędzia pracy: “Kim nie jest Product Owner?” oraz “Podstawowe narzędzia pracy Product Ownera”. To, co do tej pory opisałem, wystarczy do analizy porównawczej analityka biznesowego oraz Product Ownera.
To co z tym Scrumem… ?
Ideą tego artykułu jest pokazanie, jak w rzeczywistości wygląda praca analityka biznesowego w Scrumie. Chcę podkreślić, że jestem wielkim fanem tego, co zwinne metodologie zarządzania wnoszą do projektu – a wnoszą, moim zdaniem, wiele dobrego.
Projekty, w których mam przyjemność pracować, są coraz częściej prowadzone zgodnie ze Scrumem – a przynajmniej tak deklarują menedżerowie wyższego szczebla zarządzania, zlecający dany projekt. To natchnęło mnie, aby podzielić się przemyśleniami, jak Scrum jest implementowany u różnych klientów i jak rola analityka biznesowego przeplata się z jedną z ról, które wyszczególnia Scrum – rolą Product Ownera.
Za implementację tego, co zostało zdefiniowane (przynajmniej w praktyce przez Product Ownera) w backlogu odpowiada Development Team. Według Scrum Guide, “nazwy” ról w Development Team nie są zdefiniowane, a sam zespół powinien być samoorganizujący się oraz „cross-functional”. W praktyce wygląda to tak, że niemal w każdym zespole deweloperskim znajdziemy oddzielne role, takie jak programista backendu, programista frontendu, tester, analityk biznesowy. Każdą z nich możemy również zdefiniować na podstawie poziomu doświadczenia. Najczęściej spotykana hierarchia to: junior, regular, senior.
Częstym „nadużyciem”, jakie zaobserwowałem w projektach komercyjnych, jest wykorzystywanie roli Scrum Mastera jako swego rodzaju Project Managera. Czy tak powinno być? Nie wiem – moja wiedza i kompetencje nie pozwalają mi odpowiedzieć na to pytanie. Chcę tylko zwrócić uwagę, że Scrum Master w rzeczywistości nie odpowiada tylko za (oczywiście w dużym uproszczeniu) dopilnowanie, aby dostarczanie produktu odbywało się w „duchu” Scruma. Często w portfolio jego obowiązków znaleźć można takie zadania, jak:
- setup zespołu,
- zarządzanie budżetem,
- zarządzanie timelinem projektu,
- odpowiedzialność za wyniki pracy zespołu.
Coraz większymi krokami zbliżamy się do sedna artykułu – różnic pomiędzy rolą analityka biznesowego a Product Ownera.
Czy w dzisiejszych czasach analityk biznesowy = Product Owner?
Mój artykuł zacząłem od opisania podstawowych obowiązków analityka biznesowego (uwzględniając specjalizacje w ramach tej roli) oraz Product Ownera. Chciałem pokazać, jak cienkie są granice między poszczególnymi rolami w projektach IT oraz jak łatwo je zamazać.
Podkreślę to, o czym już wspomniałem: nie każdy analityk może odnaleźć się w roli Product Ownera i jest to ściśle związane z predyspozycjami oraz zainteresowaniami osoby na tym stanowisku. Z moich obserwacji wynika, że osoby o profilu analityka biznesowo-systemowego – roli, którą już wcześniej zdefiniowałem jako najbardziej uniwersalną – najczęściej sprawdzają się w roli Product Ownera.
Predyspozycje do wykonywania tej roli to jedno, ale jakie oczekiwania stawiają nam klienci?
Coraz częściej podczas budowania zespołu projektowego oczekiwania stawiane analitykowi pokrywają się z tymi, które według Scrum Guide stawia się Product Ownerowi. Skoro można mieć 2 w cenie 1, to czemu nie?!
W Craftware staramy się jak najlepiej odpowiadać na oczekiwania klientów i zapotrzebowanie rynku. Nasi analitycy, którzy mają predyspozycje do roli Product Ownera, podnoszą kwalifikacje w tym kierunku i potwierdzają je certyfikatami. Klienci mają dzięki temu pewność, że współpracują z osobami kompetentnymi do wykonywania tego typu zadań.
Bo czym tak naprawdę my analitycy zajmujemy się w projektach?
- Zbieramy wymagania.
- Dokumentujemy je w formie, która jest zrozumiała dla wszystkich stron: biznesu oraz zespołu technicznego.
- Rozumiemy cel przyświecający budowaniu danego systemu.
- Mamy poczucie odpowiedzialności za produkt końcowy oraz za wartość produktu, jaką powinniśmy dostarczyć z każdą iteracją.
Gdy dodamy do tego kilka technik oraz narzędzi, którymi posługuje się Product Owner, widzimy, że granica między tymi rolami zaciera się coraz bardziej. Tytułowy analityk biznesowy XXI wieku jest w 100 procentach przygotowany do roli Proxy Product Ownera, którą nieoficjalnie i tak coraz częściej odgrywa.
- Senior System-Business Analyst/Team Leader
-
Certyfikowany Analityk Biznesowo-Systemowy z ponad 8 letnim doświadczeniem komercyjnym w branżach: finansowej oraz farmaceutycznej. Fanatyk zwinnych metodologii oraz dzielenia się wiedzą i prowadzeniem szkoleń z zakresu Analizy Biznesowej i Product Ownership.
