Chce != potrzebuje

Ciężki chleb powszedni związany z wymaganiami to… nie uleganie koncertowi życzeń. Użytkownicy dużo chcą, czasem biznes chce nawet za to zapłacić ale… No właśnie, czy jest tu ale? Może IT powinno się cieszyć, że ma robotę?

Kogo słuchać?

To może zacznijmy od tego, od kogo zbierać wymagania? Użytkownik końcowy, użytkownik kluczowy a może właściciel biznesowy? Nie ma idealnej odpowiedzi i na pewno trzeba wysłuchać wszystkich, którzy w temacie są zainteresowani (czyli pozostałych interesariuszy, których nie wymieniłam także ;)). Zwłaszcza w agile kładzie się nacisk na słuchanie użytkownika, ale… No właśnie jest ale. Nie mówię, tu że użytkownik końcowy powinien zostać pominięty, aczkolwiek należy pamiętać że w większości wypadków systemy informacyjne to zespół naczyń połączonych i trzeba widzieć szerzej niż tylko swój kawałek aplikacji. Użytkownik kluczowy powinien w tym względzie być bardziej „uświadomiony” i przesiać wymagania z koncertu życzeń pod względem merytorycznym. Choć istnieje jeszcze przypadek, gdy użytkownik ani końcowy ani kluczowy nie ma nic do powiedzenia i system jest zdominowany przez właściciela biznesowego (święte jego prawo, płaci to wymaga). Jeśli za tym kryje się wizja i przy okazji dana osoba doskonale zna potrzeby użytkowników, to może tragedia się nie wydarzy. Aczkolwiek jak to jest trochę balansowanie na krawędzi przepaści (nie polecam, nawet dla osób lubiących sporty ekstremalne).

Może poprzestańmy na tym, że wysłuchać trzeba wszystkie strony. 

Co wybrać?

Kategoryzacja i wybór tego co jest do zrobienia to inna kwestia. Ciężkim kawałkiem jest wybranie tych elementów które faktycznie przybliżają biznes do osiągnięcia celu biznesowego. Jeszcze ciężej przekonać biznes, że ich wymarzona funkcjonalność nie jest potrzebna… Zaraz, zaraz – wróćmy do początku. Czy nie powinniśmy być szczęśliwi że mamy co robić, a nie odsiewać pomysły?! Odpowiedź brzmi NIE. Jak jesteśmy działem IT wewnętrznym – to zależy nam przecież aby firma nie marnotrawiła pieniędzy. Jak jesteśmy zewnętrzną firmą IT – to zależy nam na tym, aby klient był zadowolony. A nie będzie zadowolony jak dostanie funkcjonalności z których nie korzysta a do tego obraz rozpaczy dopełni  odpowiednio wysoka faktura…

Po co?

Analityk omnibusem nie jest, więc warto aby zadawał magiczne pytanie: „po co” (dlaczego to wiemy, aplikacja ma pomagać albo zarabiać, albo ciąć koszty*, wyjątek stanowią aplikacje urzędów których celem istnienia jest irytowanie petentów </joke>). Jak wiemy po co, to możemy zamodelować odpowiednie rozwiązanie. Plus doradzić co generuje koszty, a nie przybliża nas do osiągnięcia celu biznesowego (tak, tak – po to aby to wyrzucić do kosza, albo chociaż przesunąć na koniec kolejki do zrobienia i liczyć po ciuchu że z czasem upór na wykonanie danej funkcjonalności mnie). 

Podsumowanie w dwóch słowach: „po co?”. 

* ułatwienie pracy wlicza się w to. Pracownik który sprawniej wykonuje zadania (szybciej, robi mniej błędów itp.) ma większą wydajność i większe moce przerobowe. Jeśli to jest pracownik który był „wąskim gardłem” to według teorii łańcucha krytycznego, odciążenie go spowoduje szybsze wykonanie pracy. Nie wgłębiając się w teorie bardziej: wszystko sprowadza się do pieniędzy :)

Małe porównanie

Ciąg dalszy nastąpił :)

Teraz mega skrótowo najważniejsze (moim skromnym zdaniem) elementy wspólne

1.       Business Analyst i Project Manager

a)      Czas + budżet + zakres => planuje Project Manager, ale wchodzi to w skład analizy. Dlaczego? Bo projektując rozwiązanie nie bacząc na ograniczenia jesteśmy zawsze skazani na porażkę.  Dodatkowo często z uwagi na ograniczenia właśnie zakres projektu musi być dobrze skonsultowany z klientem biznesowym, co za tym idzie – musi się to wiązać z opracowaniem odpowiednich wymagań.

Sławny trójkąt ograniczeń :)

b)      Harmonogramowanie => teoretycznie też PM ale… zwłaszcza pracując w agilowych metodologiach BA musi mieć przynajmniej świadomość który modułu kiedy ma być gotowy. Inna kwestia że to właśnie BA wie jaką wartość biznesową mają poszczególne elementy dla klienta, a z tego także wynika kolejność wdrożenia.

c)       Analiza ryzyka/zarządzanie ryzykiem => trochę analogicznie jak w poprzednich podpunktach. Teoretycznie to PM uwzględnia ryzyka w karcie projektu. Z drugiej strony BA także powinien je uwzględnić spisując wymagania i zostawiający tym samym „wyjście” awaryjne gdyby dane ryzyko wystąpiło (np. mamy system finansowy, zagrożeniem jest zmiana przepisów prawnych która wpływa na sposób wyliczania podatków – ryzyko wystąpienia tego zdarzenia jest tak duże, że w wymaganiach powinno być to uwzględnione na tyle, aby przynajmniej nie usztywnić systemu w tym zakresie).

źródło: dilbert.com

2.       Business Analyst i UX Designer

a)      Obserwacja pracy użytkownika w celu dobrania rozwiązania => obie osoby to robią J W przypadku BA przygląda się on raczej całemu procesowi, aczkolwiek samej aplikacji także. Na etapie zbierania wymagań często zdarzają się takie dotyczące użyteczności. Jak w firmie nie ma dedykowanego projektanta to BA się nimi zajmuje.

źródło: http://muharikah.com

b)      Wymagania co do funkcjonalności =>  chyba nie wymaga komentarza ;) No może BA bardziej skupia się na merytorycznym aspekcie związanym z celem powstania systemu, niż na tym jak rozmieścić kontrolki co do pixela ;)

żródło: http://ideas2action.pl

c)       Prototyp – często jako narzędzie wspomagające komunikacje jest wykorzystywany prototyp. Głownie aby sprawdzić czy wszystkie wymagania są spełnione ;) aczkolwiek wymaga to także zaprojektowania interakcji – więc element wspólny z projektantem jest.

źródło: http://www.bindulski.pl

3.       Business Analyst i Product Owner

Jak dla mnie granica jest tu bardzo cienka. Na oko BA jest bardziej po stronie biznesu a PO bardziej po stronie IT. Aczkolwiek to zależy :) Jako że jestem tym i tym, to wolałabym się nie wypowiadać w kwestii różnic ;)

Tak na koniec: myślę że nie warto przykładać wagi do nazwy stanowiska. Jest to kwestia czysto definicyjna, więc równie dobrze można by je nazwać „zielony słonik” i byłoby to równie jasne jak niektóre obecne nazwy ;) Zdecydowanie lepiej skupić się na wymaganych kompetencjach i umiejętnościach. A to może także spróbuję niebawem dla was rozszyfrować ;) 

Definicja to podstawa!

Czym się zajmuje Analityk IT na naszym polskim podwórku?

Temat prezentacji na ostatnim GGC został zainspirowany przez +Agnieszkę Leśniewską . Agnieszka bowiem zapytała mnie czymże to ja zajmuje się w pracy jako Analityk Systemów Informacyjnych i czy jest to, to samo co Analityk Systemowy. Tak zaczęła się moja przygoda z próbą zdefiniowania cóż na Polskim podwórku oznacza analityk.

Jak możecie się domyślić – co firma to inna definicja. Aczkolwiek można wyodrębnić pewien zbiór zawodów które można wrzucić do „jednego” wora: Analityk, Analityk IT, Analityk Systemów Informacyjnych, Analityk Systemowy, Analityk Biznesowy czasem Specjalista IT i Konsultant IT (zależy od opisu stanowiska oczywiście ;)).

A jak przy  zawodach byłam, to zanurkowałam także w zawodach pokrewnych (często występujących solo): UX Designer, Project Manager, Product Owner. Dlaczego nazwy w języku obcym? Bo tłumaczeń jest równie dużo jak w przypadku business analyst a szkoda czasu i papieru (nawet tego elektronicznego) na roztrząsanie różnic ;)

Dlaczego podałam te zawody? Ano dlatego, ze zaobserwowałam wiele elementów wspólnych

W moim przypadku raczej to wygląda tak:

Głownie z uwagi na to że pełnię rolę Product Ownera w Scrumie i dlatego że nie mamy dedykowanych ról Project Managera i UX designera – a ktoś tą robotę musi robić. Także robię niczym mała mróweczka pracowicie wszystko (mrowca w gwarze to mrówka, więc pasuje do mnie jak ulał ;)), przynajmniej jeśli chodzi o „moje” projekty. Może to odrobinę tłumaczy dlaczego zainteresowałam się kiedyś  HCI;) Elementy wspólne pomiędzy rolami zawsze istnieć będą, ale w zależności od firmy będą na siebie bardziej lub mniej zachodzić.

Ciąg dalszy nastąpi...