Wymagania w projektach IT

1,2,3.. start.

A tym startem dla tematu wymagań jest.. problem. A dokładniej problem biznesowy. Problemy nas przerażają, prawda? To coś z czym większość z nas nie chce mieć do czynienia. Bo.. po co?

Ale zastanów się. Jak możesz coś rozwiązać, czy osiągnąć cel, skoro nie wiesz CO jest przyczyną? Gdzie leży nasze „dlaczego”?

Problemy, a dokładniej problemy biznesowe, opisują potrzebę i nasz cel biznesowy, które będą ROZWIĄZANE przez wytworzony produkt.

Problem to po prostu potrzeba.

Problem częściowo opisuje to co chcesz osiągnąć. A częściowo z czego chcesz zrezygnować.

Problem to część rozwiązania. Bo rozwiązanie ma go zlikwidować. Ale jak pozbyć się coś, czego istnienie wypieramy? I jak to się ma do wymagań?

Czym są wymagania?

Definicja, która brzmi dość sensownie i można ją znaleźć w książce „Inżynieria wymagań w praktyce” brzmi:

Warunek lub umiejętność potrzebna interesariuszowi , by rozwiązać dany problem biznesowy lub osiągnąć określony cel

Spróbujmy to uprościć.

Wymagania wyrażają potrzeby interesariuszy. Mówią o ich oczekiwaniach. Wymagania stanowią część rozwiązania czyjegoś problemu. Bo jeszcze dokładniej definiują cel, który chcemy razem osiągnąć. A jeśli potrafimy jasno sprecyzować to czego chcemy, to już połowa sukcesu.

Czyli wymagania, to po prostu bardziej szczegółowy opis problemu. Warunków jakie musimy spełnić, umiejętności jakich potrzebujemy, żeby nasz problem „znikł”. Albo zamienił się na coś co nam sprzyja. Wymagania po prostu pomagają nam w znalezieniu rozwiązania.

Rodzaje wymagań

Istnieje kilka klasyfikacji, porządkujących rodzaje wymagań. Krótko opiszę Wam te najbardziej popularne, które udało mi się do tej pory poznać. Zastrzegam, że dotyczą one głównie projektów IT.

Podział na wymagania projektowe i produktowe

  • Wymagania projektowe, czyli te, które są związane z procesem wytwarzania produktu oraz jego ograniczeniami. Definiują one ustalenia pomiędzy klientem a dostawcą dotyczące tego, jak wytwarzanie produktu czy jego utrzymanie będzie realizowane. Nie stanowią one części specyfikacji wymagań. Są one zazwyczaj udokumentowane jako plany projektowe, plany zarządzania jakością czy SoWy (z ang. Statement of Work, czyli taka „deklaracja pracy”).
  • Wymagania produktowe dotyczą samego produktu i dzielą się na:
    • funcjonalne opisujące „co produkt ma robić„, czyli funkcje/ zachowania produktu, oraz
    • niefunkcjonalne wyjaśniające jak produkt realizuje swoje funkcje.

Podział dotyczący różnych rodzajów szczegółowości wymagań

Ten podział dobrze pokazuje jak wyglądają poszczególne poziomy czy etapy analizy wymagań.

Wymagania biznesowe

Są wynikiem analizy przedsiębiorstwa, czyli poszukiwania odpowiedzi na pytania dotyczące celów, potrzeb, misji samej organizacji. Są one, najprościej mówiąc, definicjami celów czy potrzeb firmy. Czyli dlaczego inicjujemy dany projekt i do czego dążymy. Warto również wprowadzić tu sposoby czy wskaźniki dotyczące postępu prac.

Wymagania interesariuszy

Wymagania biznesowe są następnie uszczegóławiane z perspektyw różnych osób biorących udział w projekcie i ich oczekiwań. Czyli są to wymagania dotyczące potrzeb, jakie mają konkretni interesariusze oraz ich „relacji” z produktem. Tego jak będzie on wpływał na ich pracę oraz jak oni będą go używać.

Poziomy szczegółowości wymagań [na podstawie Inżynieria wymagań w praktyce]

Wymagania rozwiązania

Opisujące pożądane cechy rozwiązania, zarówno funkcjonalne, jak i niefunkcjonalne (w przypadku oprogramowania). Będą one bazą dla szczegółowych projektów rozwiązania oraz planów wdrożenia.

Wymagania przejścia

Definiujące cechy, jakie musi mieć rozwiązanie, aby możliwe było przejście ze stanu obecnego do docelowego. Są one potrzebne tylko do momentu osiągnięcia stanu przyszłego – potem nie są już konieczne.

Kto się tym zajmuje?

Pierwsza rola, która automatycznie pojawia się w mojej głowie to.. analityk biznesowy. Ale szukając odpowiedzi w literaturze, spotkałam się z określeniem „inżynier wymagań„, a także „analityk systemowy„. Rola określana jako inżynier wymagań odnosi się do całego procesu inżynierii wymagań. Takiej osoby, która zajmie się wszystkimi rodzajami wymagań. Tylko jak znaleźć osobę, która będzie miała na tyle szeroką wiedzę, aby zająć się wszystkimi aspektami dotyczącymi wymagań? Trochę nie potrafię sobie tego wyobrazić.

Analityk systemowy będzie natomiast nakierowany na właściwości systemu, który ma powstać, żeby zaspokoić potrzeby klienta. Ale sam produkt, mający odpowiednie funkcje, nie zawsze będzie spełniał nadrzędny cel. Niekoniecznie będzie przynosił wartość klientowi i jego organizacji. Może mieć znikome znaczenie dla biznesu.

Z mojego doświadczenia wynika, że najczęściej spotykamy się z analitykiem biznesowym.

To właśnie analityk biznesowy jest odpowiedzialny za uzyskanie, ewentualne negocjacje, analizę, udokumentowanie i opiekowanie się wymaganiami. To właśnie ta osoba ma kontakt z klientem i przed nią stoi trudne zadanie zdefiniowania czego tak naprawdę klient potrzebuje. A następnie przedstawienie wniosków pozostałym interesariuszom w formie wymagań i uzyskanie ich akceptacji.

I w większości firm nie spotkamy inżyniera wymagań czy analityka systemowego. Spotkamy za to analityka biznesowego, który będzie (a przynajmniej powinien) współpracować nie tylko z klientem, ale też z całym zespołem. Z programistami, testerami czy architektami. Po to, żeby uszczegółowić wymagania, dowiedzieć się czy z punktu widzenia np. programistów dane wymaganie jest wykonalne.

Myślę, że to właśnie cały zespół realizujący dany projekt jest odpowiedzialny za wymagania. A analityk biznesowy, jako swego rodzaju reprezentant i koordynator, zbiera to wszystko razem i przedstawia w taki sposób, żeby było zrozumiałe i klarowne, zarówno dla klienta, jak i innych interesariuszy.

Ale to moja obserwacja. Możecie się z nią nie zgadzać.

Wymagania a projekty

Aby w ogóle rozpocząć projekt powinniśmy wiedzieć do czego dążymy i co chcemy zrealizować. Więc wymagania są niejako podstawą do rozpoczęcia takiego przedsięwzięcia. Dobry fundament w postaci jasno sprecyzowanych wymagań wpływa na wszystkie części projektu. Przykładem może być np. zarządzanie ryzykiem. Wiedząc dokładnie jakie kryteria ma spełniać produkt, w dużej mierze minimalizujemy ryzyko dostarczenia „nie tego co wyobrażał sobie klient”. Ponadto, konkretne wymagania, mogą również wnosić ryzyko do projektu (np. konieczność używania nowoczesnej technologii do jego stworzenia).

Słabe wymagania, czyli takie które są niejasno sprecyzowane lub niemierzalne, przyczyniają się do chaosu w projekcie. A co za tym idzie do wytworzenia miernego produktu końcowego.

Skracanie czasu analizy może doprowadzić do pominięcia niektórych wymagań, a co za tym idzie do realizacji niepoprawnego projektu rozwiązania. To doprowadzi do problemów przy odbiorze produktu. A wprowadzanie zmian w końcowej fazie projektu to.. ogromne koszty.

Klienci bardzo często sami nie potrafią wyrazić tego czego chcą albo nawet nie wiedzą czego chcą. I czego tak naprawdę potrzebują. Bo jest duża różnica między „chcę”, a „potrzebuję”. To taki typowy problem, jak „chcę czekoladę, ale potrzebuję schudnąć 5 kg”. Doskonale obrazuje, że nie zawsze to czego chcemy idzie w parze z tym, czego w rzeczywistości potrzebujemy. Co przyniesie nam większą wartość w dłuższej perspektywie.

Dlatego poświęcenie czasu na analizę wymagań klienta, dobre zrozumienie go, „pomoc” w dotarciu do tego, czego tak naprawdę potrzebuje powinno być jednym z priorytetów w początkowych etapach projektu. A w trakcie jego trwania – warto upewniać się, że „jesteśmy na dobrej drodze” i konfrontować rzeczywiste wyniki prac z oczekiwaniami klienta.

Jak zadbać o wymagania?

Przeznaczyć odpowiednią ilość czasu na ich zdefiniowanie. Nie pomijać analizy wymagań w celu skrócenia czasu trwania projektu. Myślę, że już wyleczyliśmy się z podejścia, że proces analizy wymagań (i testowanie) ma znikomą wartość dodaną dla wytworzenia produktu.

Włączyć cały zespół w proces analizy wymagań. Myślę, że bardzo dobrym pomysłem jest angażowanie członków zespołu do zadań, które są powiązane z zadaniami, które będą bezpośrednio należą do „zakresu obowiązków”. Czyli, np. angażowanie programistów i testerów do przeglądów wymagań i specyfikacji. Testerzy zweryfikują wymagania i produkty pod kątem tego, czy będzie je można w jakikolwiek sposób sprawdzić (przetestować). Programiści natomiast to czy istnieją realne możliwości implementacji wymagań.

Nie bój się prosić o pomoc. Jeżeli czego nie rozumiesz – pytaj. I zapisuj. Większość osób chętnie wytłumaczy Ci dane zagadnienie, ale nie lubi się powtarzać. Więc pytaj i notuj odpowiedzi od nich otrzymane.

Dokumentuj wymagania i ustalenia. Jeżeli nie chcesz usłyszeć na koniec projektu, że czegoś brakuje, „to nie to, czego chciałem” i nie posiadać nawet jednego dowodu na to, że takie były ustalenia to dokumentuj to co do tej pory zostało uzgodnione i włączone do specyfikacji wymagań. A potem wysyłaj ustalenia do akceptacji i dbaj o to, żeby łatwo było Ci się do nich dostać. Dodatkowo, dzięki zapisywaniu wymagań, możesz śledzić ewolucję produktu i..jego progres.

Kilka słów na koniec..

Wymagania pomagają nam w znalezieniu rozwiązania. Sprawiają, że jesteśmy bliżej. Bliżej klientów i ich potrzeb. Bliżej zespołu i ich budowania relacji. Bliżej poznawania i rozwoju swoich talentów i umiejętności.

Analiza wymagań pozwala na identyfikację problemów z jakimi będziemy się mierzyć w projekcie. A to już spora wartość umożliwiająca nam znalezienie drogi do rozwiązania i zakończenia projektu z sukcesem.

Działaj. Ale najpierw przeanalizuj czy zmierzasz we właściwym kierunku.

Cieszę się, że chcesz być bliżej projektów 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *