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.
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
Prześlij komentarz