Software architecture

Czy miałeś tak kiedyś, że pracowałeś nad czymś, byłeś w to zaangażowany, a na końcu to wylądowało w śmietniku? Coby to nie było, czy ciasto, które okazało się zakalcem, czy projekt IT — jest to bolesne. W przypadku projektów IT jednym z większych punktów zapalnych są wymagania biznesowe. Oczywiście same wymagania biznesowe są dobre, więc będę bardziej precyzyjny:

• brak wymagań

• niedostateczne wymagania

• błędne wymagania

• niejasne wymagaania

Te wszystkie rzeczy powyżej mogą spowodować, że projekt zakończy się niepowodzeniem. To, że wyląduje w śmietniku jest jednym z najgorszych scenariuszy. Niepowodzenie może też oznaczać większy koszt wytwarzania albo dłuższy termin.

Jest pewna zależność między zbieraniem wymagań biznesowych, a inżynierią:

Inżynieria jest trudna, gdy nie ma jasno sprecyzowanych wymagań. Developerzy muszą zastanawiać się jak coś ma działać, zamiast myśleć o tym, jak rozwiązać konkretny sposób technicznie. Koszt pracy się zwiększa, a termin wydłuża. W tym przypadku można założyć, że zbieranie wymagań było łatwe, ponieważ nie poświęciliśmy na nie dostatecznie dużo czasu.

Zebranie konkretnych i jasnych wymagań i udokumentowanie ich wymaga czasu oraz ludzi z odpowiednimi umiejętnościami. Można więc powiedzieć, że jest to trudne, natomiast to później procentuje — inżynieria jest prosta. Developerzy nie muszą się zastanawiać jak coś ma działać, pracują efektywniej, a szansa, że końcowy projekt pójdzie do śmietnika maleje.

Można się zastanawiać co się bardziej opłaca: czas poświęcony na analizę biznesową, czy development na bazie kiepskich wymagań. Dojrzałe firmy, które spieprzyły już X projektów doskonale wiedzą, co się bardziej opłaca.

---

Kompletne wymagania biznesowe

Co to znaczy że wymagania są dobre, czy tak jak napisałem wyżej: konkretne?

Przede wszystkim wymagania muszę być jasne i zrozumiałem dla wszystkich uczestników projektu. Muszą być też spójne, czyli nie mogą mieć konfliktów z innymi wymaganiami. Wymaganie można uznać za kompletne, jeśli zostało potwierdzone przez klienta lub sponsora projektu.

---

Zakres projektu vs. zakres produktu

Wymagania biznesowe muszą być udokumentowane, nie oznacza to jednak, że mają być wyryte w kamieniu i nigdy się nie zmienić. Mówiąc wprost — wymagania biznesowe mogą się zmieniać w trakcie pracy. W dzisiejszych czasach zespoły są (albo muszą być) zwinne i reagować na te zmiany. W takich zespołach zazwyczaj jest manager projektu, który jest odpowiedzialny za:

• plany wdrożenia

• monitorowanie i koordynację prac

• raportowannie do szefa

• replanowanie

Podsumowując: manager projektu jest odpowiedzialny za zakres tego projektu, a czy jest odpowiedzialny za zakres produktu? Możesz zapytać co mam na myśli przez zakres produktu? Już tłumaczę:

• wymagania biznesowe

• kryteria akceptacyjne

• plan zarządzania wymaganiami

W idealnym świecie to analityk biznesowy jest odpowiedzialny za zakres produktu, natomiast często można spotkać się z sytuacją, że jedna osoba ogarnia to i to. No cóż, każdy się godzi na swój los i toczy swoją… kulkę.

---

Business requirements document

Dobrą praktyką na dokumentowanie wymagań biznesowych jest sporządzenie dokumentu BRD (Business Requirement Document), który tłumaczy cele biznesowe i potrzeby na wymagania biznesowe. Taki dokument często odnosi się do innego zwanego Product Vision Document (jeśli oczywiście jest jakaś wizja produktu ;-)). BRD jest zgodny ze standardami obowiązującymi w organizacji oraz z metodologią developmentu. Dokument ten jest źródłem prawdy o wymaganiach i potrzebach biznesowych.

Udokumentowane wymagania opisują co projekt lub funkcjonalność ma robić i są niezależne od rozwiązań. Rozwiązanie wymyślamy później, tak żeby zaspokoić wymagania.

---

Stakeholderzy

Stakeholderzy jest to takie słowo, które trudno przetłumaczyć na język Polski. Są to wszyscy ludzie, którzy są zaangażowani w projekt, czyli mogą to być:

• klienci

• sponsorzy

• użytkownicy

• inzynierowie

Stakeholderzy są źródłem wymagań, więc pierwszym krokiem w zbieraniu wymagań jest zrobienie listy stakeholder i określenie, kim są, czym się zajmują i jaka jest ich rola w projekcie.

Następnie dobrze jest ustalić za co konkretni stakeholderzy są odpowiedzialni i jakie jest ich zainterewoanie w projekcie np. jeden będzie chciał zredukować koszty, a inny poprawić jakość produktu i doświadczenie użytkownika.

Kluczową rzeczą jest też ustalenie jak bardzo wpływowi są stakeholderzy i czy mają pozytywny, czy negatywny wpływ na projekt i resztę ludzi. W trakcie zbierania wymagań może pojawić się wiele konfliktów, które trzeba będzie rozładowywać.

---

Metody zbierania wymagań

Jest znanych wiele metod zbierania wymagań biznesowych i zapewne na każdą z nich mógłbym poświęcić osobny artykuł:

• warsztaty

• brainstorming

• wywiady

• ankiety

• przegląd istniejącej dokumentacji

• przegląd istniejącego interfejsu

Dwie ostanie, czyli przegląd istniejącej dokumentacji i interfejsów polegają na wyłuskaniu wymagań z czegoś, co już istnieje, natomiast pozostałe techniki polegają głównie na zadawaniu pytań, tylko w różnej formie. Najciekawsze pytania, jakie można zadać w procesie zbierania wymagań zamieszczam poniżej:

• Jaki cel jest/będzie osiągnięty dzieku używania produktu/procesu?

• Jak definiujesz sukces?

• Jak inaczej można osiągnąć ten cel?

• Jakie awarie powodują największ ból?

• Jeśli mógłbyś użyć magicznej różdzki i zmienić ten proces/produkt to jakby wyglądał?

---

Podsumowanie

Pozyskiwanie wymagań jest trudne i czasochłonne, natomiast posiadanie udokumentowanych i kompletnych wymagań ułatwia pracę, szczególnie rozproszonych zespołów. Zbieranie wymagań może być łatwe – jeśli się do tego nie przyłożysz i to olejesz. Wtedy za to inżynieria będzie trudna i kosztowna.

Nie ma drogi na skróty.

Żródła

Jeśli chcesz poczytać więcej u zbieraniu wymagań biznesowych polecam tą książkę “Unearthing Business Requirements: Elicitation Tools and Techniques”.