analizawymagan

Niepewność wymagań biznesowych. Jak zaradzić?

Posted by admin

Niepewność w pozyskiwaniu wymagań na samym początku projektu to naturalna kolej rzeczy. Zawsze po pierwszych sesjach zbierania wymagań biznesowych pojawia się niepewność czy na pewno dobrze rozumiemy cel oraz czy uwzględnione są wszystkie wymagania.

Niepewność wymagań biznesowych jest uznawana za główny powód niepowodzeń w inżynierii wymagań. Wysoki poziom niepewności nie pozwala na wybór odpowiedniej architektury rozwiązania przez to naraża cały projekt na bardzo duże ryzyko. W końcu istnieje duże prawdopodobieństwo wyboru nieodpowiedniego rozwiązania.

W tym wpisie postaram się przedstawić najczęściej stosowane sposoby na zmniejszanie niepewności wymagań biznesowych. Zapraszam do lektury.

Niepewność wymagań biznesowych

Oczywiście jak to już na moim blogu bywa nie obyło by się bez podkładu naukowego i tutaj podobnie znalazłem materiał z konferencji gdzie wykonano research i uwzględniono materiały z w sumie 166 różnych źródeł:

  • 74 konferencji
  • 54 czasopism branżowych
  • 16 Warsztatów
  • 9 Sympozjów
  • 7 różnych rozdziałów z książek
  • 2 raportów
  • 2 forów
  • 2 newsletterów

Wynikiem tego przeglądu było zestawienie najczęściej stosowanych technik przy pokonywaniu niepewności wymagań biznesowych. Poniżej wykres które podejście do radzenia sobie z niepewnością wymagań biznesowych było najczęściej rekomendowane:

Niepewność wymagań biznesowych. Zestawienie technik minimalizacji niepewności
Niepewność wymagań biznesowych. Zestawienie technik minimalizacji niepewności

Sposoby na niepewność wymagań biznesowych

Ewidentnie najpopularniejszym sposobem na niepewność wymagań biznesowych jest „Przegląd i analiza” czyli znana i lubiana walidacja wymagań o której będzie kolejny wpis na blogu dlatego przejdźmy do kolejnych punktów na wykresie.

Modelowanie

Zebrałem modelowanie do jednego punktu(modelowanie celu, modelowanie ryzyka zmiany, modelowanie procesu zarządzania wymaganiami i UML). Model ma kilka cech które każdy z nas dobrze zna:

  • Jest to uproszczony obraz badanej rzeczywistości
  • Służą do zmniejszania złożoności opisywanych zjawisk
  • Służą do lepszego zrozumienia rzeczywistości

W ogólnym rozrachunku poza tym że modele pomagają odbiorcy w zrozumieniu zagadnienia, to model pomaga analitykowi poukładać wiedzę o wymaganiach w głowie. A to prowadzi do mniejszej niepewności w wymaganiach bo jak będzie coś niespójnego to model jest szczery i od razu pokazuje Ci że coś jest nie tak.

Modelowanie UML każdy zna. Modele ryzyka wykraczają poza zakres mojej wiedzy ale chcę przypomnieć o modelu celu na który pierwszy raz natknąłem się w podręcznikach do certyfikacji IREB i jak je zobaczyłem to oczy mi się zaświeciły bo nie trzeba ciągle stosować SMART. Dodatkowo jest super sposobem na zrozumienie po co coś chcemy zrobić. I dzięki temu mamy o wiele mniejszą niepewność wymagań biznesowych.

Modelowanie Celu

Modelowanie celu to rysowanie takich fajnych drzewek które mają dwa rodzaje rozgałęzień. Rozgałęzienie AND(I) i rozgałęzienie OR(lub). Na samym początku wpisujemy główny cel biznesowy i potem dajemy czynniki danego celu.

niepewność wymagań biznesowych. Model celu
Modelowanie celu

Aby to lepiej zrozumieć zróbmy przykład. Poniżej nawigacja samochodowa.

niepewność wymagań biznesowych. model celu przykład

Jak się ma niepewność wymagań biznesowych do modelowania celu? No ma się w taki sposób że jak zaczynamy rozbijać cel na czynniki pierwsze to zmniejszamy prawdopodobieństwo tego że jakiś czynnik pominiemy.

Logika rozmyta jako lek na niepewność wymagań biznesowych?

Logika rozmyta to łącznik pomiędzy maszyną a człowiekiem. Dla maszyny wszystko jest zerojedynkowe albo coś jest albo czegoś nie ma. A dla człowieka jest coś lepsze, gorsze, szybsze, wolniejsze, fajniejsze itd. Nie określamy rzeczy w sposób wymierny. A maszyna tego wymaga.

I prof. Lofti Zadeh to zauważył i opisał. I takim sposobem możemy opisywać nasze cechy według liczb z przedziału 0-1. I jak to się ma do niepewności w wymaganiach biznesowych? No ma się w taki sposób że powstał szereg różnych rozwiązań, badań oraz implementacji tego jak określić na ile pewni jesteśmy danego wymagania. Przez to w naszym badaniu logika rozmyta jest tak wysoko. Robiąc research natrafiłem na 4 sposoby implementacji gdzie na różne sposoby wprowadzało się do systemu różne czynniki i w wyniku zwrotnym dostawało się poziom niepewności wymagania biznesowego.

Jak w przypadku AGD logika rozmyta się fajnie sprawdza tak w wymaganiach biznesowych nie widziałem ani nie słyszałem żeby ktokolwiek to u siebie wdrożył. Wdrożyłeś? Napisz do mnie. Chętnie poznam twoje doświadczenia w tym modelu 🙂

Wymagania „Agile”

Nie będę ukrywał. To mnie zaciekawiło. Zaciekawiło mnie z racji tak niskiego poziomu w tym zestawieniu. Z racji popularności w wymaganiach Agile mamy wiele podejść i logika nakazuje myśleć że agile sam w sobie powinien być wysoko. A tu jak widać nie. Może przy researchu materiału przyjęto kryteria które mocno zawęziły sposoby na niepewność wymagań albo wrzucono je do jednego wora wraz z walidacją wymagań. Ciężko stwierdzić. Jednak chcę poruszyć jedną rzecz. Jest nią Stacey Complexity Model. Nawet stworzyłem ten model po polsku na potrzeby wpisu 🙂

niepewność wymagań biznesowych. stecey complexity model
niepewność wymagań biznesowych – stacey complexity model

W przypadku gdy mamy 1 to można implementować wymagania. Gdy mamy 2 zespół może już samemu uszczegóławiać wymagania. A gdy jest 3 i więcej to należy dalej zmniejszać niepewność wymagań biznesowych. W przypadku gdy mamy większe skomplikowanie technologiczne to należy rozbić zadanie na mniejsze podzadania. W przypadku wymagań należy je uszczegóławiać.

Jak widać sam wykres nie jest jakoś mocno mierzalny i zespół sam musi określać niepewność. No ale tak to już z tą niepewnością bywa. Tylko w przypadku logiki rozmytej przyjmowano czynniki które określały poziom niepewności ale moim zdaniem to nie zdaje egzaminu bo nie da się stworzyć idealnej checklisty do każdego projektu.

Moim zdaniem najlepiej stworzyć checklistę razem z zespołem i na jej podstawie badać poziom niepewności wymagania(Jak czytasz dużo moich postów to zauważyłeś że uwielbiam checklisty ;)).

Model Kano

Kolejna rzecz która prawdopodobnie jest w pierwszej pozycji na wykresie. A ta rzecz zawsze zmienia postrzeganie wymagań przez początkujących to Model Kano. Użyjemy do prezentacji nie za pięknego obrazka mojego autorstwa 🙂

model kano
niepewność wymagań biznesowych – model kano

Wyróżniamy na tym wykresie trzy rodzaje wymagań:

  • Wymagania „programowe”
  • Wymagania „podprogramowe”
  • Wymagania „nadprogramowe”

*to są moje autorskie nazwy. Prawdopodobnie przetłumaczono je inaczej z angielskiego w innych miejscach

Wymagania programowe to te które przedstawił nam interesariusz i jest ich świadomy. Jeśli chodzi o wymagania podprogramowe to te które interesariusz uznał za „oczywiste” i ich nam nie przedstawił. Wymagania nadprogramowe to te których interesariusz nam nie przedstawił i nie jest ich świadomy. Po wdrożeniu wymagań nadprogramowych nasz modelowy interesariusz jest cały w skowronkach(oczywiście jak wszystkie wymagania programowe i podprogramowe są spełnione). No i ta niebieskobiała łuna o nazwie czasu oznacza że w czasie te wymagania ulegają przeobrażeniu. Z nadprogramowych do programowych a z programowych do podprogramowych. Logiczne. Do dobrego człowiek się szybko przyzwyczaja 🙂

Wszyscy początkujący analitycy bazują na wymaganiach programowych. Świadomość istnienia wymagań podprogramowych i nadprogramowych to game changer który całkowicie zmienia podejście do zbierania wymagań. Jeśli nam zależy na tym żeby projekt był sukcesem, to z wielkim zaangażowaniem podejdziemy do faktu że każdy robi jakieś założenia i zakłada oczywiste dla niego(ale nie dla nas i dla programistów) rzeczy. Będziemy chcieli dowiedzieć się więcej niż tylko to co nam interesariusz przekazał, zaczniemy szukać dwuznaczności w prostych stwierdzeniach. Zaczniemy ANALIZOWAĆ WYMAGANIA.

I dzięki temu drastycznie zmniejszymy niepewność wymagań biznesowych.

Podsumowanie

Niepewność wymagań biznesowych to fajne zagadnienie które w moich oczach jest niestety słabo mierzalne. Tak jak pisałem w przypadku Agile, każdy musi wypracować sobie sam sposób na określenie niepewności wymagań biznesowych. Temat jest trochę pomijany. Może z racji że niepewność jest określana na podstawie doświadczenia danej osoby? Może z racji braku świadomości jak w modelu kano? A może dlatego że jak zwalidujesz wymagania to uznajesz że jesteś ich w 100% pewny? Albo jak pracujesz w korpo to jak masz okejkę na mailu to jesteś kryty?

Ciężko stwierdzić. Widać że systemowego podejścia tutaj nie ma(albo ja go nie widzę). Ale jak widzisz takie podejście to gorąco zachęcam do kontaktu i komentowania na facebooku. Chętnie poszerzę swoje horyzonty 🙂

Źródła

SZKOLENIE "Czy zawód Analityk IT jest dla mnie?"

Zapisz się na listę mailową a prześlę za darmo szkolenie Czy zawód Analityk IT jest dla mnie? Co muszę umieć żeby być Analitykiem IT?