Upraszczając. Najczęściej projekt rozpoczyna rozmowa. Głównie zarządzających. Następnie mamy rozmowę analityka z interesariuszem którą głównie nazywamy zbieraniem wymagań. I te pierwsze rozmowy są kluczowe. Jak tu pojawią się błędy zbierania wymagań to z dużym prawdopodobieństwem całe przedsięwzięcie może być porażką.
No i tutaj dużo zależy od analityka czyli od nas. Jak analityk jest utalentowany, posiada odpowiednie umiejętności to potrafi zadawać odpowiednie pytania i prowadzić sesje zbierania wymagań w taki sposób żeby pozyskać odpowiednie informacje.
No i znowu trafiłem na ciekawe badanie przeprowadzone na Kennesaw State University. Badanie co prawda przeprowadzone na studentach ale jak zapoznałem się z wynikami to zauważyłem schematy w które sam wpadałem i uważam je za wartościowe.
Badanie
Jak wyglądała metodologia? Wzięto studentów 3 i 4 roku(38 osób) którzy brali udział w zajęciach związanych z UX. Studentów podzielono na dwie grupy(analityków i klientów). Klienci dostali zadanie wyobrażenia sobie nowatorskiej aplikacji komputerowej którą by stworzyli i mieli na to tydzień. Druga grupa została przeszkolona z tego jak przeprowadzać sesje zbierania wymagań, jakie są techniki itd. Podczas sesji zbierania wymagań studenci mogli korzystać z notatek i materiałów pomocniczych.
Następnie przeprowadzono wywiady. Wywiady wykonano w tym samym czasie i wszystkie nagrywano. Wywiady były nieustrukturyzowane z racji że analityk nic nie wiedział o planowanym systemie. Wynikiem badania było 18 wywiadów. Jeden wywiad odrzucono ponieważ plik nagrania był uszkodzony.
Wywiady zostały niezależnie przeanalizowane przez 3 osoby.
- Profesjonalnego analityka
- Prowadzącego zajęcia
- Jednego researchera związanego z dziedziną zbierania wymagań.
Każdy z ekspertów miał w ciągu 2 tygodni dostarczyć listę gdzie znalazł błędy zbierania wymagań. Następnie eksperci przeprowadzili warsztaty aby zderzyć ze sobą swoje opinie, wypracować spójną listę błędów oraz rekomendację ich poprawy. Na sam koniec wynik pracy oceniał niezależny ekspert(w postaci profesora) w celu sprawdzenia czy kryteria oceniania zostały dobrane prawidłowo.
Błędy zbierania wymagań
Wynikiem tego badania była lista błędów zbierania wymagań które popełniano. Przejdźmy przez nie.
1. Błędne rozpoczęcie rozmowy
Jest to błąd zbierania wymagań który sam bardzo często popełniałem. Przy rozpoczęciu rozmowy z interesariuszem naturalną reakcją każdego jest zadanie pytania w stylu:
„Ale o co chodzi?”
Albo inne tego typu w stylu „Opowiedz mi o swoim pomyśle”. I są to naturalne reakcje każdego człowieka. Chcemy zrozumieć co dany interesariusz chce zrobić i jaki jest jego cel biznesowy.
No i to jest błąd.
W przypadku zadawania takiego pytania dostaniemy odpowiedzi związane z rozwiązaniem jakie dany interesariusz sobie w głowie wymyślił. Dostaniemy odpowiedzi typu
„Bo ja chce żeby system X zrobił XYZ”
Albo inne związane z tym jakiego systemu dany interesariusz oczekuje.
Dlaczego to jest błąd? Dlatego że takie rozpoczęcie rozmowy od razu prowadzi do tego że skupiamy się na systemie, skupiamy się na rozwiązaniu. Skupiamy się na tym jak jechać a nie na tym gdzie chcemy dojechać.
No i tutaj pojawiały się problemy. W każdym wywiadzie w badaniu poza tymi gdzie interesariusz był na tyle świadomy żeby dać kontekst biznesowy skupiono się od razu na rozwiązaniu. Cel biznesowy został domniemany.
Jak z tego wyjść?
Zamiast zadawać pytania w stylu „O co chodzi?” zadajemy pytanie w stylu „Co chcemy osiągnąć dzięki tej aplikacji?”, „Po co chcemy zrobić daną aplikację/funkcjonalność?”. Od razu skupiamy się nie na tym co aplikacja ma robić. Skupiamy się na tym co w danej organizacji chcemy usprawnić. Skupiamy się na tym jaki jest kontekst.
2. Brak zwracania uwagi na niejednoznaczne stwierdzenia
Każdy z nas prowadząc rozmowę w jakiś sposób odkodowuje wiadomość przekazaną przez daną osobę. Często jest tak że interesariusz wykorzystuje określone pojęcia które mają określone znaczenie. My to znaczenie znamy(lub nie znamy lub wydaje nam się że je znamy a może ono oznaczać coś innego).
Zwracanie uwagi na takie pojęcia i ich tłumaczenie z interesariuszem bardzo często prowadzi do odkrywania informacji które są nieznane dla analityka. Niestety w przedstawionych badaniach bardzo często ten błąd popełniano gdzie analityk robił założenia i zakładał znaczenie danych słów.
3. Brak odkrywania celów
Ten błąd jest następstwem błędu pierwszego. Od razu skupiamy się na rozwiązaniu a nie skupiamy się na tym jaki jest cel tego całego przedsięwzięcia. Koniec końców możemy trafić w sytuację gdzie robimy coś co nie jest nam potrzebne lub jest potrzebne ale zrobiliśmy to w bardzo kosztowny sposób.
Nie odkrywając celu biznesowego odpowiedzialność za cały sens developmentu przekładamy na barki interesariusza. A jak przekładamy to na barki interesariusza to po co my jesteśmy w tym projekcie? Po to żeby zostać skrybą?
Inną kwestią jest fakt że często możemy trafić na sytuację gdzie jesteśmy analitykiem do istniejącego już sytemu. Wtedy interesariusze przychodzą do nas z konkretnym wymaganiem żeby zrobić daną rzecz. I tutaj też wpadamy w pułapkę nieodkrywania celów. Jak z niej wyjść? Najprościej jest odkrywać problemy jakie się kryją za danym wymaganiem. Ewentualnie skupiamy się na celu. Zawsze jak rozmawiam z kimkolwiek to mam w głowie dwa słowa.
- CEL
- Kontekst
Najpierw chce poznać cel i kontekst. Potem chce się dowiedzieć co chcemy zmieniać i tworzyć.
4. Pomijanie kwestii ustalania innych interesariuszy i użytkowników systemu
Ten błąd często pojawia się z racji jednej heurystyki. Ludzie bardzo często skupiając się na rozwiązaniu zapominają o tym że pracują w organizacji i robią zmianę w organizacji. Cała zmiana ma być dostosowana do organizacji. Nie do interesariusza czy do użytkownika systemu.
Przez to w momencie gdy przychodzi do nas osoba która zaczyna opowiadać o rozwiązaniu my od razu zapominamy o tym że to rozwiązanie może być też dla innych. A istnieje bardzo wysokie prawdopodobieństwo że interesariusz myśląc o rozwiązaniu nie pomyślał o innych. Przecież też się skupiał na rozwiązaniu.
W przedstawionym badaniu ten błąd wyszedł jak na dłoni. Badanymi byli ludzie którzy skupiali się na UX. Pytania o interesariuszy kończyły się na użytkownikach końcowych. Zapominali w 100% o tym że:
- W organizacji mogą być procedury
- Działanie na systemie może być do kogoś raportowane
- Wynik działania systemu może być danymi wejściowymi dla innego systemu
Zapominano o interesariuszach.
5. Brak brania pod uwagę ograniczeń projektowych
Kolejnym było brak pytania o ograniczenia projektowe. Nikt nie myśli o budżecie, terminie zasobach ludzkich. Jakoś to będzie. W badaniu Analitycy nie zwracali uwagi na budżet i ograniczenia projektowe nawet gdy już wyraźnie było widać że zaczynamy budowę rakiety kosmicznej.
Wiadomo że podczas pierwszych rozmów warto jest skupiać się na celu biznesowym a nie na budżecie. Jednak wymagania muszą być możliwe do realizacji. I tutaj poznanie ograniczeń projektowych jest kluczowe.
Podsumowanie
Niby badanie na studentach. Niby podstawowe dobre praktyki a jednak te błędy zbierania wymagań widziałem też w pracy zawodowej u każdego początkującego analityka. Tak to już jest. Poznać dobre praktyki to jedno a wdrożyć je w życie to drugie.
