No cóż, analiza biznesowa to nie tylko IT. Projektów z poza tej dziedziny mam mało, to raczej rodzynki. Prawdopodobnie dlatego, że “analiza wymagań” kojarzy się najczęściej z oprogramowaniem a to duży błąd. Dlaczego? Cóż, wymagania to wymagania, są uniwersalne i nie muszą być od razu “informatyczne”. Ale metody analizy pozostają te same, o ile chce się je zastosować. Po co? Jak zawsze: by uniknąć ryzyka złego wyboru, złej decyzji.

Mamy przykład z życia wzięty:

Nowoczesne wozy trafiły do komend w: Katowicach, Bielsku-Białej, Sosnowcu, Pszczynie, Rudzie Śląskiej, Zabrzu, Rybniku, Zawierciu, Tarnowskich Górach i Częstochowie.

Okazuje się jednak, że APRD mają poważną wadę: z wnętrza nie można sterować zamontowanym na dachu masztem oświetleniowym. Nocą są więc bezużyteczne. Co prawda policjanci mogliby wspiąć się na wysoki na trzy metry dach i przesuwać reflektory ręcznie, ale nie pozwalają na to przepisy BHP, bo na dachu nie ma barierek chroniących funkcjonariuszy przed upadkiem. (źr. Kolejny nieprzemyślany zakup w policji.)

Czy już kojarzycie? 🙂 Oczywiscie: poległa analiza wymagań! Mam dziwne przeczucie, że tak zwany Opis Przedmiotu Zamówienia został wykonany metodą “co byście chcieli Policjanci, opiszcie to Wam kupimy”. No usiedli i opisali. W zasadzie zrobili błąd, który regularnie robią osoby specyfikujące wymagania na cokolwiek (oprogramowanie także): nie testują wymagań! A wystarczyło najpierw opisać jaki cel Policja chce osiągnąć tym zakupem, określić w jakich przypadkach (jakie zdarzenia) będzie ten samochód wykorzystywany, stworzyć model procesów inicjowanych przez każde w tych zdarzeń, wskazać czynności konieczne do wykonania, zapisać je jako wymagania.

Gdyby ktoś to dobrze zrobił to albo sterowanie reflektorem z wnętrza albo barierka była by w wymaganiach. A tak …

Komenda wojewódzka zapytała producenta, czy mógłby w każdym z APRD zamontować barierki. Okazało się, że tak, ale odpłatnie.

Nawet nie wiem co napisać na zakończenie. …