W projektach hardware’owych, czyli takich, w których przedmiotem jest stworzenie fizycznie istniejącego urządzenia pojawia się problematyka ograniczeń. W angielskiej literaturze używa się terminu dimensioning, który przetłumaczyłem wprost na wymiarowanie projektu. Takim projektem często zarządza się przez ograniczenia, ale od początku.
Zarządzanie wymaganiami bywa szalenie istotne, ale i pomijane. Istotne, gdy nie wiemy, jak wymagania osiągnąć, bo nie znamy odpowiedniej technologii bądź istnieją konflikty wymagań, których nie potrafimy rozwiązać z marszu. Bywa też krytyczne, gdy istnieje ryzyko, że zamawiający nie dogada się z wykonawcą i dzieło, które powstanie na końcu nie spełni właśnie wymagań. Taka sytuacja występuje w tak odległych branżach, jak budownictwo i programowanie.
Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d
Wymagania mają naturę hierarchiczną. To znaczy, gdy klient je podaje mogą na początku wyglądać niczym lista życzeń i zażaleń, ale w miarę ich analizy wyłania się zwykle struktura.
Rolą zespołu projektowego jest zebranie wymagań i skonstruowanie na ich podstawie struktury, która będzie wykonalna, uzasadniona biznesowo, optymalna kosztowo, wartościowa dla klienta.
Jednak na ogół, gdy zespół buduje rozwiązanie ze znanych klocków technologicznych, to wiele rzeczy staje się oczywistych w momencie zdefiniowania wymagań – albo coś się da zrobić, albo nie, albo zadziała tak, jak chce tego klient, albo nie.
Sytuacja wygląda inaczej w projekcie eksploracyjnym. W tym wypadku zespół odkrywa często, co się da, a co nie. Więc moment między udokumentowaniem wymagań, a stwierdzeniem, że tak może dostarczyć rozwiązanie, które je uwzględnia jest często bardzo odwleczony w czasie. Przez długi okres życia projektu wiadomo, jakie są wymagania i nie wiadomo, czy uda się je dowieźć. Aby zapadło w pamięć, określę to zjawisko przepaścią wykonalności (feasibility chasm).
Z tych powodów formalne dokumentowanie wymagań i śledzenie, na ile zespołowi udaje się zasypać przepaść wykonalności staje się krytyczne akurat w trakcie odkrywania.
Wymagania dzielimy w gigantycznym uproszczeniu na:
- Biznesowe – jakie rezultaty biznesowe mają być osiągnięte dzięki rozwiązaniu, np. produkt powinien sprzedawać się w ilości 100 stuk miesięcznie, firma dzięki nowym kompetencjom powinna wygrać przetarg.
- Funkcjonalne – co rozwiązanie ma oferować dla użytkownika, w jaki sposób ma wchodzić z nim w interakcję, np. system musi wyświetlać określone dane, detektor ma wykrywać zdefiniowane zachowanie, użytkownik powinien móc wykonać z urządzeniem określoną pracę,
- Niefunkcjonalne – wszystkie pozostałe, np. rozwiązanie ma mieć pobór prąd mniejszy niż założony pułap, rozwiązanie musi stosować określone zabezpieczenia.
W najprostszym przypadku może mieć formę listy wymagań zapisanych w postaci product backlogu inspirowanego Extreme Programming i Scrum. Backlog się szczególnie sprawdzi, gdy owa lista nie jest za długa, wymagania są mocno niezależne, czyli zależności między nimi nie destabilizują prowadzenia projektu i gdy większość wymagań jest funkcjonalna (zwykle zapisywana w postaci historyjek). Siłą takiego podejścia do dokumentacji wymagań jest to, że łatwo zarządzać priorytetami, lista (o ile krótka) jest przejrzysta i wymagania automatycznie reprezentują zakres prac. Słabością jest brak uwzględnienia zależności między wymaganiami oraz przy bardziej złożonych rozwiązania utożsamienie wymagań z zadaniami, podczas gdy relacja między nimi może mieć charakter wiele do wielu. Przykładowo mogę mieć wymaganie, że każdy dokument ekran systemu musi mieć możliwość pobrania w formacie PDF. To wymaganie będzie zrealizowane za pomocą całej listy zadań powiązanych z poszczególnymi ekranami. Z drugiej strony zadanie indeksowania i wyszukiwania dowolnych treści może spełnić wymagania dotyczącej wyszukiwania klientów, ofert, dokumentów, raportów, obrazków itd.
Rejestr wymagań może mieć też formę słownego opisu, jaki na przykład oferuje oprogramowanie Confluence, Nuclino, Notion lub po prostu Word lub tabelka w Excel. Mocną stroną takiego podejścia jest utrzymywanie dokumentacji wymagań, która z czasem może stać się dokumentacją rozwiązania. Łatwiej jest śledzić zmiany i śladować (tak, śladować, od angielskiego terminu tracing) pochodzenie wymagań. Słabością natomiast jest to, że wymagania nie stają się zadaniami w projekcie. Aby zaplanować zadania, trzeba najpierw z wymagań stworzyć koncepcję rozwiązania, a potem zdekomponować ją na prace. No i taka lista nie przeliczy automatycznie zależności między wymaganiami.
Wreszcie rejestr wymagań może być bazą wiedzy, w której poszczególne rekordy zawierają pojedyncze wymagania, a pomiędzy nimi występują zależności. Takie podejście sprawdza się, czy występuje bardzo wiele powiązań między wymaganiami oraz pilnować trzeba ograniczeń rozwiązania. Przykładowo każdy moduł rozwiązania może dodawać masę do całości, a ogólne ograniczenie narzuca na projekt limit wagi. Jeżeli chcemy tak podejść do dokumentowania wymagań, to musimy zastosować dedykowane rozwiązanie, jak Valispace. Można w nim zdefiniować siatkę zmiennych ograniczających produkt finalnych w różnych obszarach, a następnie przeprowadzić modelowanie matematyczne różnych kombinacji wymagań. Istnieje pewna klasa projektów innowacyjnych, w których poszczególne elementy rozwiązania są tak ciasno powiązane, że trudno rozwija się je bez wpływu na kształt całości. Wyobraźmy sobie konstrukcję satelity albo łazika marsjańskiego.
Finalny produkt powinien spełniać szereg parametrów takich, jak: maksymalna masa, wielkość całego urządzenia, pobór prądu, wielkość panelu słonecznego, pojemność baterii, czułość anten itd. Te parametry często są narzucane na starcie i wynikają z celów strategicznych danego programu, a czasem zespół dąży po prostu do maksymalizacji parametru.
Przykładowo z grubsza mikrosatelitę można zdekomponować na kilka głównych elementów, np.: system zasilania, komputer, elektronika, napęd, ładunek, czujniki, oprogramowanie, układ komunikacyjny. Czasem, jak w przypadku projektu skonstruowanego przez studentów z Imperial College, z którymi miałem szansę współpracować, pojawiają się dodatkowe elementy, jak na przykład żagiel słoneczny.
Zaprojektowanie dowolnego elementu natychmiast wpływa na kształt pozostałych. Mniejsza bateria będzie miała mniejszą masę, ale będzie głębiej się rozładowywać i może nie zapewnić prądu do czasu kolejnego obrotu satelity wokół Ziemi. Większy panel solarny szybciej naładuje satelitę, ale zajmie więcej miejsca i dociąży cały ładunek. Zauważmy, że takie przeciąganie za krótkiej kołderki wymagań nakłada się na tradycyjne ograniczenia projektowe, jak czas, koszt, kompetencje zespołu, czy jakość.
Tego typu sytuacja pojawia się częściej w projektach wytwarzających tzw. hardware, niż oprogramowanie lub projektach nowych produktów i usług, gdzie głównym wyzwaniem jest satysfakcja potencjalnego klienta, a wydajność, skalowalność, czas reakcji, SLA są wykładnikami kosztu rozwiązania. Na potrzeby projektów o dużej liczbie wewnętrznych powiązań między wymaganiami opracowano podejście nazwane SBCE.
