Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości “map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. […] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem 🙁
Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej “jak wdrożyć to co mamy” a nie “jak rozwiązać problem użytkownika”).
Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.
Swego czasu na jednej z konferencji o analizie wymagań, mówiłem o potrzebie zrozumienia funkcjonowania analizowanej organizacji (firmy):
…wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania i zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP).
Analiza biznesowa to etap opisu (zrozumienia) modelowanej organizacji (modele procesów itp.). Potem, powstaje model rozwiązania, którym jest nie raz własnie oprogramowanie, jego logika (patrz powyższy cytat) to “obiektowy model dziedziny systemu”, a nie jakiś diagram klas nafaszerowany atrybutami i pozbawiony operacji bo jest dokładnie odwrotnie…
Pierwszym etapem analizy, bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim…
Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze “słownikiem biznesowym”: biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.
Dwa lata temu cytowałem: Jakie są najczęstsze problemy w nieudanych projektach? [...] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania…
Obecne ustawy idą w kierunku ustalania metody projektowania systemów teleinformatycznych, opisywania ich szczegółów, metod powstawania. Po co na poziomie ustawy definiować np. pojęcie minimalnych wymagań skoro nie zdefiniowano tego minimum? To już elementy metodyki specyfikowana i tworzenia oprogramowania. Znacznie lepiej by było, gdyby powstał dokument będący np. metodyką dla projektów finansowanych ze środków publicznych. Po co tworzyć ustawowy proces tworzenia systemów teleinformatycznych?
Wydaje mi się, że stwierdzenie czy jakikolwiek dokument spełnia ustawowe “minimalne wymagania dla systemu teleinformatycznego” jest niemożliwe bo jak? Jakim testem? Co miało by być wzorcem dla audytu?
Ma jednak sens moim zdaniem, by wymagania na systemy były dokumentowane w postaci testów akceptacyjnych. Te są wymierne i “zerojedynkowe”. Nie udawałoby się prawnikom dostawców oprogramowania wykazywać zgodności dostarczonego oprogramowania z wymaganiami w postaci OPZ (Opis Przedmiotu Zamówienia) w brzmieniu np. “system ma być wygodny w użyciu” bo każdy go jakoś tam jest wygodny. Należało by w drodze takich testów stwierdzić, czy oprogramowanie daje pożądane efekty. Tu nie będzie pola do popisu dla interpretacji prawnych, często niejednoznacznych zapisów w OPZ-tach.
I na koniec: ustawodawca w moich oczach wykazuje, że nie ma kompetencji by tworzyć prawo. Zamiast tworzyć reguły, zaczyna opisywać konkretne metody ich realizacji a to zły kierunek. Po drugie te zbyt szczegółowe regulacje w ustawach wyglądają często na efekty złego lobbingu dostawców technologii. Może warto, by przy rządzie powstał jakiś THINK TANK ukierunkowany na systemowe, całościowe podejście do IT w administracji publicznej. Myślę, że Analiza Systemowa i [[Architektura Korporacyjna]], jako całościowe podejście, a nie lokalne w poszczególnych urzędach, jest na to sposobem. Niestety chyba nie mamy w rządzie kompetentnych ludzi…
recepta na porażkę:
Wymagania zbieraj wyłącznie jako efekt burz mózgów i wywiadów z przyszłymi użytkownikami oraz ich przełożonymi, niech wszyscy spiszą je w postaci tabeli np. w arkuszu kalkulacyjnym i edytorze tekstu. Organizuj długie spotkania warsztatowe, po których powstają kolejne wiersze w tabelach. Wszystkie dodatkowe ustalenia załatwiaj mailem ad-hoc. Tak powstałą listę nazwij Wymagania i daj do realizacji.
Projekty informatyczne to zawsze nowy cel i nowa droga ale dobrze znane środowisko. Dlatego wzorce jak najbardziej mają sens, ale nie recepty bo te tu nie mają zastosowania. Antywzorce, hm…, znamy statystyki i mimo to stale podejmowane sa nowe projekty, w których kluczową metodyką pracy jest warsztat-dyktafon, to czy zapisujemy to jako slajdy prezentacji czy z pomoc nawet bardzo dobrego narzędzia CASE nie ma żadnego znaczenia jeżeli faktycznie zapisujemy jedynie to, opis i obrazki, co podyktuje Święty User.
Na zakończenie jedno zdanie: pojawienie się metod zwinnych (rok 2001, Agile Manifesto) nie zmieniło tej czarnej statystyki nawet o jotę, więc nic wskazuje na to, że są one w czymkolwiek lepsze. Wiadomo zaś, że stosowanie metod formalnych jest bardzo skuteczne ale kosztowniejszej od opisanych wyżej maili, arkuszy i tekstów. Jednak jeżeli średnie przekroczenie kosztów dochodzi do 200% to znaczy, że jednak metody formalne są per saldo znacznie tańsze… a są stosowane tam, gdzie “ryzyko jest duże” a przynajmniej ryzyko nie jest ignorowane. Czemu jednak tak rzadko stosuje się metody formalne? Bo jest różnica pomiędzy wiedzieć a umieć… Jeżeli więc ktoś mówi, “nie rób tego tak, bo to się raczej nie uda” (powyższe statystyki) to warto tego posłuchać i zapytać o pozostałe 20% bardziej udanych projektów.
