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”.
