Pytanie to wraca jak bumerang. Z reguły, gdy słyszę słowo “analityk” w kontekście projektów związanych z tworzeniem oprogramowania pojawia się ktoś, kto “zbiera wymagania”. Z reguły “analityka” wypuszcza się do przyszłych użytkowników, którzy prześcigają się w pomysłach na temat tego  jakie to oprogramowanie ma być. Niestety to sponsor projektu, pierwsze co robi najczęściej, to wskazuje kogoś z przyszłych użytkowników (a z reguły cały ich zespół) jako “źródło informacji o wymaganiach”. Takie podejście zalecają także, w swoim interesie, dostawcy oprogramowania. Użytkownicy, nie mając (z reguły) pojęcia jaki cel ma projekt (poza tym, że to dla nich to oprogramowanie), nie tylko puszczają wodze wyobraźni zmieszane ze swoimi dotychczasowymi doświadczeniami, ale także ucieleśniają swoje pomysły by jednocześnie stronić od odpowiedzialności. Nie będąc specjalistami ani w dziedzinie inżynierii oprogramowania ani zarządzania, nie są w stanie weryfikować propozycji dostawcy, przyjmują więc bezkrytycznie.

Formę ekstremalna przybiera to zjawisko administracji publicznej, a co gorsza idzie w jeszcze gorsza stronę. Spójrzmy na argumenty za zmianami w ustawie PZP:

Przeprowadzenie jednego postępowania [projektowanie i wykonanie, przyp. mój] jest dużym ułatwieniem dla zamawiających, ale jego skutki mogą się okazać niezadowalające.

Możliwość objęcia jednym zamówieniem prac projektowych i budowlanych, a tym samym uniknięcie konieczności przeprowadzania dwóch odrębnych postępowań o udzielenie zamówienia, jest dużą zaletą dla zamawiających. Tym zapewne należy tłumaczyć popularność zamówień typu ?zaprojektuj i buduj?.

Również opracowanie programu funkcjonalno-użytkowego niewątpliwie wymaga mniejszego nakładu sił, środków i czasu niż stworzenie dokumentacji projektowej oraz specyfikacji technicznej wykonania i odbioru robót budowlanych potrzebnych w przypadku udzielania zamówień typu ?wybuduj?. Zamawiającym wygodniej jest przerzucić na wykonawców obowiązek opracowania projektu i innych potrzebnych dokumentów. (Zamówienia typu ?zaprojektuj i buduj? według nowych zasad -….)

W zasadzie cała ta argumentacja sprowadza się do: “zamawiający nie chce niczego robić ani brać jakiejkolwiek odpowiedzialności”. Z uwagi na to, że taka forma jest także bardzo korzystna dla wykonawców (sami sobie stawiają wymagania) otrzymujemy konstrukcję: urząd wydaje nie swoje pieniądze, całość prac merytorycznych (poza opracowaniem SIWZ) przerzuca na dostawcę, który tym samym projektuje sam dla siebie i przyjmuje potem za to pieniądze. W zasadzie nie było by problemu gdyby nie to, że my – obywatele – za to wszystko płacimy:

Rozmowa z Jarosławem Żelińskim: Sami wymyślą, sami zrobią i sami ocenią. Skąd tak duże różnice między efektami informatyzacji prywatnych firm a informatyzacją urzędów? (Informatyzacja administracji, czyli najlepszy sposób na totalną klęskę | Forsal.pl – Giełda, Waluty, Finanse).

Jak widać problem jest znany nie od dziś, a mimo to powstają ustawowe pomysły zmierzające w tę gorszą stronę.

W tym kontekście przytoczę pewien urzędowy wątek. Ostatnio głośno się zrobiło o “nadużywaniu dostępu do informacji publicznej”. Ciekawa dyskusja na temat rozgorzała na stronach VaGla.pl (fragmenty):

incognitus: Pozostaje zatem pytanie dlaczego wszelkie urzędy wszystkiego automatycznie nie publikują w BIP? Jak by to było robione z automatu to prawdopodobnie takie czynności techniczne byłyby łatwiejsze i szybsze dla urzędu, niż publikowanie wybiorcze, a później odpowiadanie na setki wniosków o udostępnienie. […]

xpert17: Odpowiedź wynikająca z teorii zarządzania jest prosta – urząd nie ma żadnego interesu, żeby wykonywać coś łatwiej i szybciej. Wręcz przeciwnie, statystyczny urzędnik (może nawet podświadomie) będzie tak realizował swoje zadania, żeby wszystko odbywało się jak najdłużej i angażowało jak najwięcej ludzi – dzięki temu uzasadnia sens istnienia swojego miejsca pracy. Gdyby wszystko “z automatu” trafiało do BIP, mogłoby się okazać, że w dziale zajmującym się wymyślaniem przyczyn odmowy udzielania informacji publicznej jest przerost zatrudnienia. […]

Nieco sarkastyczna powyższa odpowiedź niestety niesie pewne wyjaśnienie tej sytuacji. Tak więc patrząc na powyższe: czy ma sens by wymagania na oprogramowanie dla urzędu pisali urzędnicy? Czy da się zrobić oprogramowanie lepsze? Zapewniam, że da się:

Jarek Żeliński: wystarczy “dobrze opisać wymagania” na system elektronicznego obiegu dokumentów z “właściwą” obsługa metadanych i publikacja w BIP będzie “automatyczna”, problem w tym, że (powołując się na przedmówcę) żaden urzędnik nie napisze takich wymagań – i to jest jeden z powodów mojego zdania: nie ma żadnego sensu, żeby wymagania na oprogramowanie pisał/dyktował (i wszelkie inne idiotyczne metody zbierania wymagań bazujące na tym co powie user) jego przyszły użytkownik! A jest to “standard” nie tylko w urzędach. (Umowa między KPRM a brandADDICTED na wsparcie komunikacyjne | prawo | VaGla.pl Prawo i Internet).

Bo cóż może powstać w Urzędzie, jeżeli będziemy stosowali zasadę: użytkownik stawia wymagania? A na przykład możemy zobaczyć fragment przepisu kulinarnego w Centralnej Bazie Orzeczeń Sadów Administracyjnych (polecam lekturę całego artykuły na VaGla.pl), tu tylko moje zdanie na ten temat:

Te powyższe ośmieszające treści to moim zdaniem efekt złego projektu oprogramowania służącego do anonimizacji, gdzie nie tylko operacja copy-paste powinna być zablokowana, ale sam proces powinien być tak zaprojektowany by, z natury mylący się człowiek, miał jak najmniej okazji by się mylić. Po trzecie, system anonimizacji dopuszczający ingerencję w treść orzeczeń po ich uprawomocnieniu to masakra, to megabubel, autora tego oprogramowania. (Centralna Baza Orzeczeń Sądów Administracyjnych +1 ząbek czosnku | prawo | VaGla.pl Prawo i Internet).

Ale niestety, to są skutki  stosowania metody polegającej na prowadzeniu analiz wymagań metodą “zbierania wymagań od przyszłych użytkowników”, nie wyobrażam sobie by tą metodą powstał inny system anonimizacji niż ten, który powstał.

A jak to robić?

Wpadła mi niedawno w oko rewelacyjna w swojej prostocie definicja roli analityka, pojawiła się na jednej z wielu dyskusji o wymaganiach w serwisie LinkedIn (źr. http://www.its-all-design.com/a-graphical-functional-specification-part-1/):

(analityk, współpracując z osobami zainteresowanymi realizacją celów projektu – interesariusze – tworzy specyfikację wymagań/rozwiązania, która interesariusz wdroży do realizacji swoich celów).

Warto zwrócić uwagę na to, że tu także nie ma mitycznego “usera”. Cel biznesowy projektu ma ktoś uzależniony od wyników projektu. Skoro więc “urząd nie ma żadnego interesu, żeby wykonywać coś łatwiej i szybciej. Wręcz przeciwnie…” nasuwa się pytanie: jaki ma więc sens by urzędnicy, którzy potencjalnie nie mają żadnego interesu w tym, by usprawniać swoją pracę, tworzyli wymagania na oprogramowanie, które powinno im usprawnić pracę?

Analizy wymagań nie tylko w administracji są prowadzone, jako wywiady i spis życzeń przyszłych użytkowników. Czasami te “pseudo analizy wymagań” to bełkot będący spisem żądań pracowników a ich interesie. Osobiście byłem kiedyś świadkiem, jak tak zwany “analityk wymagań” (dla mnie człowiek dyktafon a nie analityk) pewnego lidera IT w tym kraju, zapisał w dokumentacji wymagań, pod dyktando szefowej sekretariatu: “system powinien pozwalać na podpisywanie w sekretariacie dokumentów decyzji administracyjnych z pomocą przeterminowanego podpisu elektronicznego” (chodziło o wygodę tej pani), masakra. Zrobiłem raban, obrażona pani z sekretariatu stwierdziła, że ona jest w tym projekcie ekspertem dziedzinowym i ona dyktuje nie ja. Ten zapis jednak wyleciał (polazłem do jej szefa), na mnie była skarga bo “nie potrafię pracować w zespole”.

Być może więc za specyfikowanie wymagań na oprogramowanie powinny odpowiadać urzędy centralne od razu po tym, jak nałożą jakiś ustawowy obowiązek na podległe im urzędy? Wtedy mamy “osobę” analityka, który wykona analizę nowej ustawy i opracuje wymagania na oprogramowanie. Firma, która wygra przetarg, zapewne w ramach swojej analizy i opracowania koncepcji rozwiązania, popyta urzędników o jakieś szczegóły w rodzaju wewnętrzna organizacja pracy urzędu, struktury obowiązków i kompetencji itp. ale nie o to co urzędnik ma robić a czego nie!

I dokładnie takie samo podejście polecam firmom: szanowni członkowie zarządów i rad nadzorczych, zanim wybierzecie produkt lub wykonawce oprogramowania, jako interesariusze własnych projektów, zlećcie analizę i  opracowanie specyfikacji i dopiero potem pozwalajcie własnym Waszym pracownikom decydować o Waszych firmach, jeżeli już, to niech to będą przynajmniej Wasze wyższe kadry kierownicze.