Przejdź do głównej zawartości

Chodzenie po wodzie i realizacja wymagań są proste tylko w jednym przypadku, jeśli jedno i drugie jest zamrożone!

Dziś trochę o przygotowaniach do certyfikatu z Inżynierii Wymagań REQB.

Dlaczego Inżynieria Wymagań ?, bo od tych nieszczęsnych wymagań wszystko się zaczyna. 😉
Źle zdefiniowane wymaganie będzie się mścić przez cały okres trwania projektu, dlatego tak ważne jest, żeby znać i umieć stosować metodyki związane z poprawnym definiowaniem i zarządzaniem wymaganiami.

Z pomocą biegnie Inżynieria Wymagań!

Uznałam, ze skoro i tak dużo o tym czytam to poprzygotowywuje się do certyfikatu REQB.
Egzamin REQB (Requirements Engineering Qualification Board) jest przeznaczony dla osób, które pracują z wymaganiami na systemy informatyczne.

Wiedza, którą należy posiadać, aby móc podejść do egzaminu obejmuje Sylabus znajdujący się na stronie reqb.pl
Zagadnienia, z którymi możemy się „spotkać” w trakcie egzaminu to:

  • Podstawy inżynierii wymagań
  • Proces inżynierii wymagań
  • Pozyskiwanie wymagań
  • Analiza i modelowanie wymagań
  • Specyfikacja i opis wymagań
  • Walidacja wymagań
  • Zarządzanie wymaganiami i zmiana wymagań
  • Usprawnianie procesu inżynierii wymagań


Dziś chciałabym skoncentrować na temacie związanym z Zarządzaniem projektu wg REQB.

Swoją wiedzę czerpałam z sylabusa, książki, oraz kursu e-learningowego „Specjalistów Analizy”.

Warto zastanowić się dlaczego Inżynieria Wymagań jest tak ważna dla poprawnego przebiegu projektu.

Jak tak człowiek się głębiej zastanowi, stwierdzi, że bardzo ciężko pracuje się jeśli nie ma określonych jasnych i mierzalnych celów. No bo każdy, ale to absolutnie KAŻDY będzie je interpretował tak jak będzie mu wygodnie 😉. Nie ma siły, tam gdzie jest człowiek tam jest opinia i interpretacja!
Trudno jest tworzyć dobry produkt, jeśli mamy do czynienia z nieprecyzyjnymi wymaganiami lub takimi, które totalnie nie spełniają kryteriów i POTRZEB (bo ta potrzeba jest najważniejsza-zawsze i wszędzie!) interesariuszy.

Zatem warto zwrócić uwagę gdzie możemy uniknąć błędów korzystając z dobrodziejstw inżynierii wymagań:
  
Koncepcja projektu- tu należy poprawnie określić interesariuszy/klientów/użytkowników tworzonego przez nas systemu. Warto skoncentrować się na wizji, POTRZEBACH i oczekiwaniach naszych potencjalnych odbiorców. Dobrze przeprowadzona koncepcja pozwala na ustalenie wymagań biznesowych wysokiego poziomu, które będą stanowić podstawę planowania projektu.  

Negocjacje kontraktu/umowy- podstawowym celem jest nawiązanie relacji między dostawcą a klientem i wypracowanie porozumienia. Negocjacje mają na celu określenie zasobów i kosztów związanych z implementacją wymagań na podstawie wcześniej przygotowanych wymagań wysokopoziomowych.

Definicja projektu- w inżynierii wymagań znajdziemy między innymi definicje ról, czynności, zadań czy dodatkowych procesów. Na podstawie dobrze przygotowanej definicji możemy zacząć tworzyć. Na tym etapie można zacząć tworzyć wstępny projekt biznesowy rozwiązania, co w konsekwencji pozwoli na ustalenie szkieletu architektury docelowej.

Realizacja projektu – no jakby nie było, jedna z bardziej pracochłonnych części tworzenia produktu. Warto tu skupić się na przygotowaniu precyzyjnych specyfikacji, które będą stanowiły podstawę do dalszych prac wytwórczych. Celem tej fazy jest stworzenia produktu zgodnego z założeniami i przyjętymi wymaganiami.


Niestety… nawet najlepiej przygotowana Inżynieria Wymagań nie uchroni nas przed błędami, które pojawiają się w trakcie procesu analitycznego. Te, które wg REQB pojawiają się najczęściej to:

Niejasne cele biznesowe- Znacie to ? „chcemy system, w który powinien zawsze działać” -.-‘ no i weź się człowieku nie zdenerwuj 😉 a jak jeszcze poprosisz o doprecyzowanie to usłyszysz, że przecież to jest OCZYWISTA OCZYWISTOŚĆ i po co ja w ogóle chce wiedzieć coś więcej! Ma działać i już 😉 Tylko moi drodzy Biznesowcy (tak, jeśli któryś kiedyś tu trafi) jeśli cele zostaną źle zdefiniowane to żaden analityk, nawet najbardziej doświadczony nie jest w stanie stworzyć poprawnych, jasnych i mierzalnych wymagań. Choćby robił stójki na ogonie, zawsze wyjdzie jakiś babol! 😊. Dlatego cel przede wszystkim! i to taki, na podstawie którego każdy wyciągnie jasne i spójne wymagania😊

Zmieniające się wymagania-Usłyszałam na jednym z wykładów, że chodzenie po wodzie i realizacja wymagań są proste tylko w jednym przypadku, jeśli jedno i drugie jest zamrożone! 😉 i to jest święta prawda. Te zmieniające się wymagania mają zazwyczaj jeden wspólny mianownik – niejasne cele…. (będę o tym pisać w kółko, ale ten cel ma znaczenie😉 ). Często niejasne cele wynikają z nieznajomości dziedziny biznesu klienta przez personel dostawcy, a wiedza branżowa wg mnie jest kluczowa to dobrze formułowanych wymagań.

Niejasne odpowiedzialności – Prawda jest taka, że szczególnie w małych firmach ten podział odpowiedzialności jest … najłagodniej rzecz ujmując, bardzo średni. Jeśli nikt nie wie, kto za co jest odpowiedzialny to próba komunikacji prawdopodobnie skończy się SuperKlapą, bo każdy będzie nas odsyłał do kolejnego pokoju, kolejnej osoby, na inne piętro i tak będziemy się kręcić w kółko próbując znaleźć kogoś, kto jest odpowiedzialny za dany obszar.

Różnica pomiędzy oczekiwaniami klienta a treścią projektu- zestawienie marzeń z rzeczywistością nie zawsze musi być problematyczne i bolesne 😉 Jeśli systematycznie walidowane są produkty projektu pod kątem spełnienia oczekiwań klienta to jest spora szansa, że nie będzie aż tak drastycznie, jak mogłaby wskazywać statystyka 😉 Warto korzystać z testów przyrostu produktów, monitorować przebieg tworzenia projektu, być na bieżąco z rozwojem działań nad rozwiązaniem. Wtedy ryzyko, że coś pójdzie nie tak minimalizujemy prawie do zera.



Niewystarczające zaangażowanie klienta-No tu sprawa się troszkę komplikuje, klienci często zakładają, że ich udział w projekcie wygląda następująco. Uzgodnienie wymagań-> długo, długo nic -> odbiór produktu. A prawda jest taka, że jeśli ten klient będzie współpracował z dostawcą to dużo sprawniej można rozwiązywać problematyczne zagadnienia. Jak zmienić nastawienie klienta ? najlepiej działa zasada kija i marchewki 😉 trzeba pokazać naszemu odbiorcy, że sukces wspólnego rozwiązania jest wprost proporcjonalny do zaangażowania wszystkich interesariuszy 😊 Jeśli on się nie zaangażuje to straci kupę czasu i kupę kasy 😉

Definicja projektu z niemożliwymi do osiągnięcia terminami / Nieprecyzyjne szacowanie wysiłku lub (i) kosztów projektów– Takie przypadki trafiają się w tych mniejszych firmach, które startują na trudnym rynku IT. Chęć bycia konkurencyjnym za wszelką cenę niestety zbiera żniwa w trakcie realizacji zadań. Zbyt mała ilość zasobów i presja czasu powodują, że ludzie niechętnie pracują w takich projektach, bo zaczynają sobie zdawać sprawę, że ktoś kto układał harmonogram nie ma doświadczenia, nie szanuje ich czasu wolnego (często prace wykonywane po godzinach w nieludzkich porach). Niestety problemy czysto kierownicze bardzo rzutują na prace zespołów, dlatego drodzy managerowie, konsultujcie się z tymi, którzy będą dla Was te prace wykonywać, bo może okazać się, że te 3 MD to tak naprawdę 20 a to drastycznie zmienia postać rzeczy 😉

Nieprecyzyjne szacowanie wpływu zmian wymagań na inne obszary produktu – w ostatnim teście, który rozwiązywałam w ramach kursu „Specjalista Analizy” padło pytanie: Klient poprosił Cie o usunięcie jednego parametru. Za kilka dni wpada błąd krytyczny, który odwołuje się do parametru, który usunąłeś, nad czym musisz popracować ? – odpowiedź brzmi: nad myśleniem systemowym. Należy zdawać sobie sprawę, że wszystko w systemie jest ze sobą jakoś połączone (oczywiście są samoistniejące twory, ale nie mówimy tu o takim przypadku). Minimalizowanie takich zjawisk odbywa się poprzez zrobienie odpowiedniej analizy wpływu, która umożliwia ocenę zakresu i ryzyka wdrożenia. Niestety w wielu przedsiębiorstwach/projektach tej analizy nie wykonuje się wcale, a może wiązać się z tym szereg zupełnie nikomu niepotrzebnych błędów.

Brak możliwości śledzenia – i nie mówimy tu o nałogowych stalkerach, czy nagabywaniu niewinnych ludzi ale o braku identyfikacji relacji pomiędzy wymaganiami a innymi artefaktami projektowymi. A to w swoich konsekwencjach może być bardzo zgubne na wynik projektu. Należy pamiętać, że brak możliwości śledzenia jest sporym problemem, który może bezpośrednio wpływać na efektywność procesu zarządzania zmianami.   

Komentarze

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,