zbieraniewymagan

O dwuznaczności w zbieraniu wymagań za pomocą wywiadu

Posted by admin

Wstęp

Czy tego chcemy, czy tego nie chcemy to spośród wielu różnych technik zbierania wymagań jest jedna która zawsze będzie wykorzystywana najczęściej. Jest nią wywiad. Ma ona swoje plusy(jak bezpośredni kontakt), ale ma też swoje minusy (jak czasochłonność). No i ma też swoje pułapki (takie jak dwuznaczność w rozmowie).

I dzisiaj chcę trochę napisać właśnie o tej dwuznaczności(zainspirowany czytaniem książki zbierającej prelekcje z 24 konferencji inżynierii wymagań która odbyła się w Utrechtcie w 2018 roku – do zakupienia tutaj – nic z tego nie mam po prostu polecam lekturę).

O dwuznaczności

Na dwuznaczność (a właściwie to jej unikanie) kładzie się bardzo duży nacisk w przypadku wymagań już spisanych w formie specyfikacji. I słusznie, bo jakby nie patrzeć dwuznaczne wymaganie ma kluczowy wpływ na to czy dane rozwiązanie będzie dobre czy nie. Jednak zapominamy o tym, że dwuznaczność w tekście pisanym pochodzi od słów i rozmów(najpierw ludzie ze sobą się komunikowali potem od pisma obrazkowego przeszliśmy do alfabetu 😉 )

No i tutaj czasem może pojawić się problem. W większości przypadków doświadczony analityk wyłapuje większość takich dwuznaczności i zadaje odpowiednie pytania uszczegóławiające (lub parafrazuje to co mówi dana osoba). Niestety wywiady mają to do siebie, że są intensywnymi rozmowami gdzie interesariusze przekazują bardzo dużo informacji w stosunkowo krótkim odstępie czasu i czasami się zdarzy, że nie uda nam się wyłapywać wszystkich dwuznaczności. A jakie są ryzyka? No jest ich sporo. Przykładowo:

  • Możemy czegoś nie zrozumieć, czyli dana osoba tłumaczy jakąś rzecz i my nic z tego nie zrozumiemy,
  • Możemy zrozumieć coś częściowo np. rozumiemy główny proces, ale nie zrozumieliśmy jednego z podprocesów który jest kluczowy dla głównego procesu.
  • Możemy coś zrozumieć inaczej niż inna osoba np. dla danego słowa lub zestawu słów może być wiele znaczeń i każde z tych znaczeń może być sensowne w danym kontekście.
  • Możemy wszystko zrozumieć odpowiednio, aczkolwiek informacje które pozyskaliśmy są niekompletne ponieważ w rozmowie poruszaliśmy niektóre sprawy w postaci rzeczownika bez punktu odniesienia (znane i nielubiane powiedzenie typu powinniśmy wyświetlić „dane”, ale nie określiliśmy, co pod tym słowem się kryje)

Sama chęć pochylenia się nad tym tematem w moim przypadku została wzmocniona faktem, że nie spotykam się na co dzień z sytuacją gdzie sama czynność zbierania wymagań jest w jakikolwiek sposób walidowana. Oczywiście walidujemy wymagania same w sobie, stosujemy checklisty, stosujemy przeglądy, prototypy itd. ale w przypadku samego zbierania wymagań często kończymy z ślepym zaufaniem do swojej pracy.

Propozycja przeglądu wywiadu

Ciekawą propozycję dla tego problemu zaproponowano na wcześniej wspominanej konferencji przez specjalistów z Uniwersytetów w Australii oraz Stanach Zjednoczonych(Paola Spoletini, Alessio Ferrari , Muneera Bano, Didar Zowghi,
and Stefania Gnesi. Kennesaw State University, Swinburne University of Technology, University of Technology Sydney). Zaproponowali oni metodę którą przetestowali na studentach i polegała ona na 4 prostych krokach:

  1. Nagrywanie całego wywiadu(oczywiście za zgodą osób nagrywanych),
  2. Przesłuchanie wywiadu przez analityka który go przeprowadzał pod kątem dwuznaczności(oczywiście ze spisaniem protokołu swojej pracy),
  3. Przesłuchanie wywiadu przez drugiego analityka który nie uczestniczy w procesie pod kątem dwuznaczności niezależnie od przesłuchania analityka z pkt. 2(oczywiście ze spisaniem protokołu swojej pracy),
  4. Dalszy kontakt z klientem w celu wyjaśniania pojawiających się nieścisłości.

Cała zabawa związana z słuchaniem wywiadu ma być protokołowana i wykonana z pamiętaniem o kilku zasadach a te zasady to

  • Wykonanie przesłuchania na zasadach inspekcji (czyli systematyczna ocena z uwzględnieniem konkretnych cech, czyli w naszym przypadku wyłapywania dwuznaczności)
  • Skupienie się na wyłapywaniu słabych punktów w wywiadzie (nie na tym co jest dobrze lub co źle, tylko na tym jakie informacje musimy jeszcze pozyskać od interesariuszy)
  • Sporządzenie ustrukturyzowanego protokołu z przesłuchania wywiadu(o strukturze w dalszej części postu)

Metoda przeglądu wywiadu

Cała metoda przeglądu wywiadu została opisana prostą procedurą którą przedstawiam poniżej:

1. Utwórz arkusz kalkulacyjny z kolumnami Czas, Fragment, Pytanie

2. Rozpocznij słuchanie nagrania. W przypadku gdy nie masz czasu nagrania uruchom również stoper. Za każdym razem jak ktoś lub coś ci przeszkodzi w słuchaniu, zatrzymuj nagranie oraz zatrzymuj stoper. Gdy rozpoczynasz ponowne słuchanie to rozpocznij słuchanie od momentu przerwania.

3. Zatrzymaj słuchanie za każdym razem gdy klient powie coś, co jest niejasne, dwuznaczne albo nie ma dla ciebie sensu. Zatrzymaj się za każdym razem gdy w danym momencie zadałbyś pytanie klientowi w stylu

– Co to oznacza? (czyli nie zrozumiałeś znaczenia tego co usłyszałeś)

– W jakim celu robimy XYZ? (czyli nie zrozumiałeś po co jest robione to co usłyszałeś)

– Czy możesz coś więcej opowiedzieć o XYZ? (czyli dany temat został omówiony zbyt ogólnikowo)

– Powiedziałeś że rzecz X oznacza A, ale tutaj oznacza B. Możemy to uszczegółowić? (czyli to co usłyszałeś wcześniej przeczy temu, co słyszysz teraz)

– Czy mówiąc o X masz na myśli A czy B? (czyli mamy sytuację gdy dane pojęcie jest homonimem -> dla leni to samo słowo o dwóch różnych znaczeniach)

– Myślałem o tym w sposób XYZ. Czy nie mam racji? (czyli sytuacja gdy nie jesteśmy pewni czy dobrze rozumiemy i chcielibyśmy sparafrazować to, co nam przekazał interesariusz)

4. Za każdym razem gdy zatrzymujesz nagranie to dodajesz wiersz w arkuszu kalkulacyjnym wpisujesz czas nagrania, fragment wypowiedzi który sprawił, że pojawiło się w twojej głowie pytanie oraz wpisujesz pytanie.

A jak wyglądał eksperyment?

Nasi eksperci z uniwersytetów przeprowadzili badanie na 42 studentach którzy byli co najmniej po 3 latach studiów z kierunków powiązanych z wytwarzaniem oprogramowania(inżynieria oprogramowania, technologia informacyjna, programowanie gier komputerowych). Studenci zostali wprowadzeni w tajniki przeprowadzania wywiadu podczas eksperymentu używali notatek i materiałów pomocniczych.

Grupę podzielono na dwie części. Jedna część to analitycy a druga to klienci. Ćwiczenie polegało na zasymulowaniu sytuacji gdzie tydzień przed eksperymentem powiedziano do grupy klientów:

„Pomyśl przez tydzień o aplikacji mobilnej którą chciałbyś zaimplementować. Twój budżet to 30tys. dolarów. Jeśli nie masz pomysłu na aplikację w ramach danego budżetu to weź jedną z aplikacji w telefonie i pomyśl o zmianach do tej aplikacji w ramach budżetu”.

Następnie po tygodniu równocześnie przeprowadzono wszystkie wywiady. Wywiady trwały maksymalnie 30minut. Pozostawiono dowolność jeśli chodzi o sposób ich przeprowadzania. Celem wywiadów było przygotowanie listy wstępnych wymagań biznesowych które miały być udokumentowane w formie user stories na poziomie szczegółowości pozwalającej na wycenę ile czasu i programistów wymaga zaimplementowanie konfiguracji wymagań.

Po wykonaniu wywiadów przeprowadzono odsłuchania nagrań. Analityk odsłuchiwał swoje nagranie a klient odsłuchiwał nagranie innej grupy której nie znał w roli drugiego analityka. Zasady przeprowadzania przeglądu przedstawiłem wcześniej.

Ocena wyników

Wyniki podzielono na kilka kategorii

  • Dwuznaczności wykryte, tylko podczas wywiadu (AI)
  • Dwuznaczności wykryte, tylko przez przesłuchującego analityka który przeprowadzał wywiad (AR)
  • Dwuznaczności wykryte, tylko poprzez przesłuchującego analityka który nie przeprowadzał wywiadu (RR)
  • Dwuznaczności wykryte przez obu analityków podczas odsłuchu (ARRR)
  • Dwuznaczności wykryte podczas wywiadu(przez analityka) oraz podczas odsłuchu przez przesłuchującego analityka który nie przeprowadzał wywiadu (AIRR)

Jakie były wyniki? Na 2 uniwersytetach były różne. Najpierw wyniki z KSU(Kennesaw State University)

Wykres prosto z konferencji (wyniki KSU)

Jak ładnie widać na wykresie:

  • Na samym wywiadzie analityk wyłapywał 32% dwuznaczności (AI+AIRR)
  • Na wywiadzie + słuchaniu tylko przez analityka wyłapywano 63% dwuznaczności (AI+AIRR+ AR+ ARRR)
  • Analityk przeprowadzający wywiad nie wyłapywał 37% dwuznaczności.

Moim zdaniem sporo. Pokazuje jak istotna jest walidacja wywiadu przez drugą osobę.

Dane z University of Technology Sydney są moim zdaniem mniej reprezentatywne, bo nie chce mi się wierzyć w to, że odsłuchujący wyłapywał aż 50% dwuznaczności(chociaż badający tłumaczą to faktem, że w KSU mocniej skupiono się na przeszkoleniu uczestników pod kątem dwuznaczności w wymaganiach, dlatego więcej jej wyłapywali w wywiadzie)

Wykres prosto z konferencji (wyniki UTS)

Jakie wnioski?

Odsłuchiwanie wywiadów moim zdaniem może dać sporo nowych, dodatkowych informacji i może być źródłem wielu pytań uszczegóławiających. Można wykryć sporo dwuznaczności i patrząc po procenach(nawet jeśli je zaniżymy, bo wiadomo, że test na studentach to nie jest test na profesjonalistach) to można znacząco zmniejszyć ryzyko niepowodzenia projektu(albo przynajmniej zmniejszyć ilość reworku programistów) z racji walidacji pracy analityka od samego początku pracy.

Bardzo ciekawym aspektem jest odsłuchiwanie drugiej osoby. Widać, że druga osoba która słucha nagrań potrafi zasiać ziarno niepewności i może wspomóc we wczesnym wykrywaniu błedów. Dodatkowo spojrzenie świeżym okiem może pomóc znaleźć nowe, proste i co najważniejsze skuteczne rozwiązania dla interesariuszy.

Z minusów metody to na pewno:

  • Uzyskanie zgody na nagrywanie wywiadów(gdzie wiadomo nie każdy człowiek może zareagować na to pozytywnie. W mojej opinii warto tutaj trochę sprzedać to nagrywanie językiem korzyści)
  • Czasochłonność stosowanej metody może wydawać się duża.
  • Znalezienie analityka niezaangażowanego w projekt który będzie miał chwilę i ochotę zwalidować twoją pracę może być niemałym wyzwaniem.

Ciekawy jestem waszej opinii. Jak się zapatrujecie na taką technikę? Ktoś już pisał coś w tej sprawie na jakimś polskim blogu? Ktoś stosował taką metodę w praktyce? Z nagrywaniem się spotykałem, ale z odsłuchem drugiej osoby już nie.

Jak temat wydaje Ci się ciekawy to byłbym wdzięczny za udostępnienie w celu dotarcia do większej liczby osób. Dzięki 🙂

Źródła

Requirements Engineering: Foundation for Software Quality 24th International Working Conference, REFSQ 2018, Utrecht, The Netherlands, March 19-22, 2018

Chcesz zostać Analitykiem IT? Kliknij w baner poniżej

DARMOWA checklista jakości wymagań!

Zapisz się na listę mailową a dam Ci za darmo checklistę jakości wymagań biznesowych.

Uzupełnienie powyższego pola stanowi zgodę na otrzymywanie od analizowac.pl newslettera zawierającego treści marketingowe. Zgodę można wycofać w każdym czasie. Wycofanie zgody nie ma wpływu na zgodność z prawem przetwarzania dokonanego przed jej wycofaniem.