Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają “zwinną”, że “nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy – tak właśnie radzimy sobie z nieprzewidywalnością wymagań”.

Przypomnę: wymagania to “warunki jakie coś musi spełnić aby było przydatne” (sł. j.polskiego PWN), jak mam tu rozumieć “brak wymagań na początku projektu”, skoro jego – projektu – celem jest wytworzenie czegoś przydatnego? Co to znaczy “wymagania dzisiaj są nieprzewidywalne”? To znaczy chyba tylko to, że zamawiający kompletnie nie ma pojęcia po co rozpoczyna projekt! (Co nie raz niestety bywa prawdą).

Niedawno miałem kolejne spotkaniu z pewnymi “developerami” i co mogę po nim powiedzieć? Otóż warto się uczyć i czytać, bo wtedy Ci ludzie, wiedzieli by, że nie należy mylić wymagań z cechami rozwiązania (dotyczy to także zamawiających i namawiam ich do korzystania z usług profesjonalistów) i źle jest, gdy ktoś taki (nie dostrzegający tych różnic) robi wodę z mózgu nabywcom oprogramowania. Prawdą jest, że skoro nie powstało rozwiązanie, to nie znamy wszystkich jego cech i odkryjemy je (powstaną) w toku prac nad jego tworzeniem. Nie prawdą jest jednak, że nie znamy wymagań na początku projektu z powodów jak powyżej, a jeżeli faktycznie ich nie znamy, to co i po co robimy?! (i to jest pytanie do tych, którzy zamawiają oprogramowanie!).

Warto więc poznać troszkę tej “wstrętnej, nie mającej nic wspólnego z praktyką”, teorii co pozwoli lepiej się komunikować i nie wciskać nikomu kitu, zaś w kwestii prostego słownictwa typy, wymaganie czy cecha, gorąco polecam po prostu poznanie ojczystego języka… 😉

Generalnie wymaganiem (nazywam je “biznesowym”) jest pomysł lub oczekiwanie “biznesu”, np. “system ma usprawnić obsługę zapytań ofertowych”, “system ma pozwalać na archiwizowanie wszystkich  zapytań i ofert w sposób pozwalający na łatwe dotarcie do każdego dokumentu”, itp. (to prawdziwe zapisy z pewnego projektu). Są wymagania? Są! Co teraz? Popatrzmy na “klasyczny” tok analizy specyfikowania wymagań po prawej stronie. taki diagram można zobaczyć na niemalże każdym szkoleniu z tego zakresu, jednak na mało którym, usłyszycie jak przeprowadzić ową “walidację” (sł j.polskiego: walidacja ?ogół czynności mających na celu zbadanie odpowiedniości, trafności lub dokładności czegoś?). 

Sam przegląd wymagań nic nie daje, one mają być spójne, kompletne i niesprzeczne. Sam przegląd pozwoli co najwyżej sprawdzić spójność i niesprzeczność, a kompletność? Właśnie po to się robi analizę procesów: tworzymy model działania firmy, by po pierwsze upewnić się, że wiemy i rozumiemy jak ona działa, a potem na tej podstawie ocenić, czy wymagania są kompletne (zakres projektu, czyli wymagania, faktycznie obejmują wszystkie te działania firmy, które chcemy by były nim objęte).

Tak więc można nie znać szczegółów przyszłego produktu i projektu zarazem, w końcu powstaje on – jego kolejne cechy – np. iteracyjnie, ale całość, jako projekt, powinna być znana w kwestii “do czego ma to służyć i jak”.  Nikt rozsądny nie podejmie się budowy wieżowca, nie mając pojęcia ile docelowo ma mieć pieter i do czego posłuży każde z nich… na pałę to zbijamy raczej budę dla psa lub stodołę (cyt. E.Yourdon ;)), ale faktycznie nie ma sensu szczegółowe planowanie wystroju wnętrz przed zakończeniem budowy całej konstrukcji.

Tu więc także rada dla zamawiających oprogramowanie: kompletnie pozbawione sensu jest pisanie na początkowym etapie analizy wymagań czegoś w rodzaju “system, podczas wystawiania faktury, powinien pozwalać na wybór, z rozwijanej listy uruchamianej prawym klawiszem myszy, listy kontrahentów i produktów” (to także cytat z pewnej specyfikacji).  Jest to zupełnie nieuprawniona i przedwczesna próba projektowania rozwiązania. Po pierwsze są inne metody podpowiadania na ekranie, po drugie, kontrahent i produkty mogą się np. podpowiadać z treści, wcześniej wprowadzonego, zamówienia. po trzecie jest jeszcze masa innych możliwych rozwiązań i wybór najlepszego to rola projektanta developera.

W tym momencie, na zakończenie, polecam artykuł z ubiegłego roku, gdzie opisałem taksonomię wymagań: Produkty w procesie analizy wymagań.

____

(dodane po pytaniu czytelnika)

[czytelnik] Jak radzić sobie z wymaganiami, które pojawiają się w trakcie realizacji projektu?

[autor] Po dobrze przeprowadzonej analizie jest ich na prawdę mało. Z racji tego, że mogą się jednak pojawić, warto przed rozpoczęciem realizacji projektu opisać i zatwierdzić z klientem, procedurę zarządzania zmianą zakresu projektu (który bywa nie raz załącznikiem do umowy), klient powinien czuć ciężar takich zmian. Dobrą praktyką jest także, by zakresem projektu (wprowadzaniem zmian do specyfikacji wymagań) zarządzał ktoś trzeci, nie będący ani zamawiającym ani wykonawcą, z uwagi na konflikty interesów (zamawiający ma tendencje do poszerzania zakresu bez zwiększania budżetu a wykonawca dokładnie odwrotnie), polecam by autor wymagań był osobą z zewnątrz, i jako trzecia strona, sprawował tak zwany nadzór autorski, wtedy staje się przy okazji mediatorem przy próbach wprowadzania zmian (to sprawdzona metoda w branży budowlanej i nie tylko).

Jeżeli jednak zakres projektu nie istnieje, to obawiam się, że nie ma na to: odkrywanie wymagań w toku projektu, sposobu.