W swojej pracy jako analityk często spotykam się z różnymi sposobami zbierania wymagań od interesariuszy. Mamy analityków którzy:
-narzucają swoje rozwiązania interesariuszom,
-pracują jak dyktafon dla programistów,
-odkrywają potrzeby rozwiązań,
-robią wszystko po trochu.
Analitycy narzucający rozwiązania
Często są to osoby które pracowały kiedyś jako programiści lub parali się programowania. Jest to osoba która w trakcie rozmowy z klientem/interesariuszem już myśli i zastanawia się nad tym jak ma system wyglądać i już tworzy rolę i zastanawia się jak to zaprogramować.
Jest to spowodowane tym że mamy naleciałości programistyczne. Wstyd się przyznać ale też byłem takim analitykiem jak zaczynałem swoją pracę. Tym bardziej się to objawiało jak zaczynałem sobie programować po godzinach.
Niby nie programowałem zawodowo ale wystarczyło kilka miesięcy nauki programowania, nauczenia się wzorców projektowych i już wpadłem w ten wirus nieskupiania się na rozmówcy i jego potrzebach tylko na systemie i łatwości danego rozwiązania z mojej perspektywy
Analityk-dyktafon
Jest to osoba która jedyne co robi to zapisuje to co dany użytkownik końcowy lub interesariusz mu powiedział. Prowadzi to do tego że mamy system który dana osoba sobie wyobraziła lecz nie koniecznie go chciała.
W przypadku analityka-dyktafona natrafiamy na wiele problemów w przypadku współpracy z firmą zewnętrzną która wytwarza oprogramowanie na podstawie otrzymanego dokumentu wymagań. Dostawca takiego oprogramowania zakłada że dany dokument został zaprojektowany na podstawie potrzeb i bezkrytycznie tworzy system na podstawie dokumentu.
Następnie pojawia się sytuacja że po wdrożeniu na testy danego rozwiązania użytkownik końcowy patrzy na to co otrzymał i jest niezadowolony z rezultatu. Dostawca się zakrywa dokumentem i zaczyna się boksowanie. Kto ma rację. Burzy to współpracę a co gorsza psuje dobre systemy które zamiast pomagać to przeszkadzają.
Oczywiście są też softwarehouse którzy dostarczają swoich analityków lub zwyczajnie zadają odpowiednie pytania przed wdrożeniem(i chwała im za to) lecz niestety są też tacy co tego nie robią(i to nie jest ich wina).
Analityk nakierowany na potrzeby
Dobra bo niepotrzebnie się tu rozpisałem o relacjach na linii dostawca-klient ale to jest idealny przykład jak zła analiza potrafi zepsuć projekt. Przejdźmy więc do ostatniego typu analityka czyli roboczo go nazwijmy „Potrzebowiec”
Jeśli jakaś organizacja zgłasza potrzebę na oprogramowanie. To jest to zjawisko w którym sama nazwa wskazuje jest ukryta potrzeba.Ta potrzeba to jest:
a) chęć rozwiązania/uniknięcia problemu
b) chęć optymalizacji lub automatyzacji
c) chęć osiągnięcia jakiejkolwiek korzyści.
W sytuacji gdy rozmawiamy z interesariuszem to rozmowa przeważnie wygląda tak że jesteśmy zagadywani na śmierć przez taką osobę ponieważ każda z tych osób ma już swoją wizję na temat tego jak miałby wyglądać idealny system który rozwiąże wszystkie bolączki i ugotuje obiad.
Zadaniem analityka-potrzebowca jest odkrycie dlaczego taka osoba chce zrobić dane rozwiązanie czyli na dobrą sprawę jaka potrzeba się kryje za tym żeby powstało takie rozwiązanie a nie inne.
Oczywiście nie chodzi tutaj o to aby „odciskiwać swoje piętno” na wszystkich rozwiązaniach bo to nie w tym rzecz. Chodzi o to czy na pewno potrzebujemy:
-nowych ról,
-skomplikowanych przeliczeń,
-wodotrysków,
-integracji z różnymi systemami,
-innych drogich rzeczy(nie że niby te powyższe są drogie po prostu wpisałem cokolwiek aby był content ;] )
Aby zrobić funkcjonalność która polegać będzie na tym pobieramy z bazy i wyświetlamy daną w wskazanym miejscu.
Cały proces polega na tym żeby zidentyfikować co jest celem i jaka potrzeba się za tym kryje. Nie przepalajmy pracy programistów(którzy nie są tani) na coś czego tak naprawdę nikt nie potrzebuje(a często nie jesteśmy świadomi tego że ekran który wydaje się dla nas idealny będzie potrzebny tylko po to żeby go zobaczyć).
Jak odkryć potrzebę?
Potrzebę odkryjemy zadając odpowiednie pytania. I na tym powinienem zakończyć tą sekcję. Ale z racji że żyjemy w czasach że wszystko chcemy i mamy instant to podrzucę parę gotowców które nie działają w każdej sytuacji ale niech będzie:
– Co motywuje Ciebie do tego że zgłosiłeś się z potrzebą takiej funkcjonalności?
– Na kogo brak takiego rozwiązania ma negatywny wpływ?
– Z jakiego powodu chcesz takie rozwiązanie?
– W jakim celu …?
– Niezatapialne i niepodważalne „Po co?”
Podsumowanie
Patrząc na świat IT odnoszę wrażenie że za bardzo patrzymy w świat dobrych praktyk, wykresów, modeli i dokumentów a nie skupiamy się na najważniejszym czyli na tym że oprogramowanie jest produktem.
Produkt jest przez nas kupowany głównie dlatego że spełnia on nasze potrzeby.
