Ten, kto ma informację, ma władzę. A ten, kto ma władzę, czuje się bezpieczny - również wtedy gdy lud zaczyna domagać się wyciągania konsekwencji za krzywdy wyrządzone w wyniku nieudolnego wykorzystania informacji.

Jakości nie da się dodać do oprogramowania na chwilę przed jego udostępnieniem. Komunał? Być może tak, a przynajmniej w pierwszym odruchu, gdy do naszych uszu dochodzą takie wyznania - właśnie tak się nam wydaje. A jednak to, że o jakości zaczyna się myśleć dopiero w końcowych fazach opracowywania systemów informatycznych, objawia się już na początku ich wykorzystania - mniejszym bądź większym wyrazem zawodu użytkowników i innych interesariuszy, twierdzących, że: "to wcale nie tak miało być". Kiedy niezadowolenie jest raczej większe niż mniejsze, możemy stanąć przed problemem, jakże ostatnio popularnej, lustracji. I być może dowiemy się nawet, że ktoś tam czegoś nie wiedział, a powinien wiedzieć. I być może też polecą za to jakieś głowy: zwykłych szeregowców, bo nie wiedzieli, albo szefów, bo nie wiedzieli, że tamci nie wiedzą lub, co gorsza, wiedzieli, ale nic z tym nie robili. I może nawet część niezadowolonych interesariuszy zostanie pocieszona taką krwawą rozprawą, w ferworze zemsty zapominając o rzeczywistych problemach. Pieniądze jednak zostały wydane, choć może nawet pal licho pieniądze - te odchodzą i przychodzą, jednak czasu, który minął, odzyskać już się nie da.

Samolustracja

Dzięki lustracji możemy dowiedzieć się wielu interesujących rzeczy, pozwalających na inne zapatrywanie się na przyszłość. Możemy uczyć się na cudzych błędach. Dzięki lustracji możemy poznawać rzeczywiste zamysły interesariuszy, pokazujące motywacje, dla których rzeczy nie do końca oczywiste zostały zrobione tak, a nie inaczej. Możemy dowiedzieć się dlaczego dokonano wydatków, dla których poniesienia dziś już trudno znaleźć uzasadnienie. Lustracja jest jednak działaniem z zewnątrz, i to do tego wymuszonym. Nie oczekujmy więc, aby była lubiana przez tych, którzy mają być jej poddani. Tym bardziej, kiedy wiadomo, że chodzi o polowanie na czarownice.

Ale istnieje pewien trend na poddawanie się samolustracji, tj. na ujawnianie wyników swoich prac po ich zakończeniu i zatwierdzeniu do dalszego wykorzystania. Jest ona wówczas sprzedawana pod hasłem polityki jawności i/lub przejrzystości.

Działania tego nie można potępiać, bo bez wątpienia jest to krok w bardzo dobrą stronę, aczkolwiek tylko mały krok i bywa, że wykonywany jedynie w charakterze zasłony dymnej, której celem jest odciągnięcie uwagi zainteresowanych od innych działań. Chwalimy się naszymi sukcesami, kiedy nabieramy przekonania, że i w oczach innych mogą okazać się osiągnięciami. A jeśli coś nam nie wyjdzie? Wolimy zachować to dla siebie. A jeżeli w trakcie prac żyjemy w przekonaniu, że ich wyniki mają być ujawnione? Całe przedsięwzięcie zaczyna się rozciągać w czasie, ponieważ jedna wewnętrzna weryfikacja i korekta goniona jest przez następne. Nie możemy przecież udostępniać "chłamu", bo co by sobie o nas ludzie pomyśleli? A ludzie, niestety, potrafią być okrutni i bezwzględni, i niechętnie przyjmują do wiadomości fakt, że o wiele łatwiej jest krytykować, nawet konstruktywnie, niż samemu coś stworzyć.

Samolustracja ma zatem na celu przysporzenie sławy tym, którzy się obnażają, albo też odsunięcie od nich podejrzeń. Bez wątpienia zmusza do zwiększonego wysiłku (większe nakłady na przeglądy i testy), ale nie pozwala na wykonywanie podejmowanych działań zdecydowanie szybciej i jednocześnie zdecydowanie lepiej. A to staje się możliwe dzięki polityce jawności od pierwszego wejrzenia - wielkiemu odkryciu społeczności open source.

Deficyt oczu

Open source kojarzony jest, i słusznie, z pracą programistów - bo to właśnie oni tworzą ów source, czyli kod źródłowy oprogramowania. Koncepcja ich jest dosyć prosta i polega na tym, że nie czynią swych powinności w całkowitym zamknięciu i tajemnicy przed światem, a wręcz przeciwnie, na bieżąco i każdego dnia dzielą się tym co wykonali z innymi, licząc na to, że:

1. Znajdzie się, gdzieś tam, przynajmniej jeden pasjonat-użytkownik (a znajdują się setki, a nawet tysiące), spragniony zapoznania się z nową funkcjonalnością programu, który natychmiast przekaże swoje pochlebne bądź krytyczne uwagi, a te pozwolą na utrzymanie właściwego kierunku rozwoju.

2. Znajdzie się gdzieś tam, przynajmniej jeden pasjonat-programista (a znajdują się dziesiątki, a nawet setki), chcący przekazać swoje uwagi odnośnie do technicznej strony wewnętrznych rozwiązań zastosowanych w oprogramowaniu, albo też dostarczający gotowe fragmenty kodu źródłowego, o jaki oprogramowanie może zostać rozbudowane, lub jaki może zastąpić obecne, słabsze jego elementy.

Wykorzystanie takiego sprzężenia zwrotnego jest podstawą rozwoju programów opensource'owych i właśnie dzięki temu jakość w tych produktach pojawia się już na początku ich wytwarzania. Pierwsza z tych cech leży również u podstaw bardziej tradycyjnego, choć również wciąż jeszcze nielubianego (lub mylnie interpretowanego) iteracyjnego podejścia do produkcji oprogramowania: "szybko dostarcz użytkownikowi coś, co uzna za przydatne, a dzięki temu otrzymasz cenne wskazówki odnośnie do kolejnych wydań i będziesz mógł poprawić to, co już przygotowałeś, bo jest jeszcze na to czas".

Deficyt oczu

Czyż nie jest to piękna idea? Niestety, nawet jeśli się z nią zgodzimy, to w przypadku produkcji oprogramowania dedykowanego, w projektach realizowanych na zamówienie, bardzo trudna do zrealizowania. A wszystko w związku z deficytem oczu. W organizacjach zamawiających projekty informatyczne można znaleźć i pasjonatów-użytkowników, i pasjonatów-programistów - tyle że zjawisko takie ma charakter marginalny i nie powinno się na nim bazować. Zamawiający, a przede wszystkim przyszli użytkownicy nie przepadają za iteracyjnym cyklem produkcyjnym, bo z ich punktu widzenia jest to nigdy niekończąca się faza testów, które muszą realizować obok wykonywania swoich codziennych obowiązków. O wiele wygodniej jest czekać na koniec projektu, skupić się wówczas wyłącznie na testowaniu i jeśli coś nie będzie tak, lustrować i karać. A czas, którego nie da się odzyskać? To wina programistów!

Testowanie nowego oprogramowania jest dla użytkowników trudne, ponieważ mają poddawać weryfikacji coś, co nie do końca rozumieją. Użytkownicy nie rozumieją własnych, choć najczęściej przez informatyków zapisywanych, wymagań na systemy, a tu jeszcze każe się im mówić, czy przedłożone aplikacje są zgodne z tymi wymaganiami. Jeśli dysponują szczegółową specyfikacją testów - testują machinalnie, ale i wówczas trudno jest im zapomnieć o tym, jak dziś realizują swoje funkcje i wciąż przywołują tę pamięć, dziwiąc się temu czemuś, co zostało im przekazane. Samo oprogramowanie zaczyna budzić emocje - takie, jakie mają pozytywny wpływ na jego rozwój - dopiero wówczas gdy zaczyna być na serio wykorzystywane. To oczywiście istota podejścia iteracyjnego, ale gdzież są ci, którzy tak robią? Takich emocji nie wywołują też specyfikacje wymagań. Może więc każemy ludziom przykładać oczy do złych rzeczy?

Przyłożyć oczy do procesów

Pozytywny wpływ na losy przedsięwzięcia, w wyniku którego do organizacji ma zostać wprowadzone nowe oprogramowanie (choć nie zawsze towarzyszą temu pozytywne emocje interesariuszy), ma jawność opracowywania nowych wersji procesów. Jest to rzecz, którą wszyscy jesteśmy w stanie zrozumieć.

Opis nowej wersji procesu opowiada, jak - w kolejnych krokach - organizacja, rękoma swoich pracowników zamierza dostarczać wartości swoim klientom. Niektóre z tych kroków, możliwe że wszystkie, planuje się wesprzeć nowym oprogramowaniem, albo też nowymi lub zmienionymi funkcjami już wykorzystywanego oprogramowania. Miejsca, w których mają być zastosowane aplikacje, są od razu źródłem wymagań na system informatyczny, ale o tym nawet nie musimy wspominać użytkownikom. Niech dyskutują o nowym podejściu do swojej pracy, o związanych z nim przepływach informacji, o swoich nadziejach i lękach.

Z opisu procesu - jeśli tylko będziemy pamiętać, że każdy jego krok, w stanie idealnym, jest potrzebny tylko dlatego, aby możliwa była realizacja kroków następnych, a krok ostatni jest tylko po to, aby w pełni zaspokoić konkretną potrzebę klienta organizacji - widać jak na dłoni wszelkie odstępstwa od ideału, wynikające z żądań poszczególnych interesariuszy. Każdy interesariusz - a szczególnie ten mający silną pozycję, np. właściciel czy sponsor - może żądać, aby coś było tak jak on sobie tego życzy. Ma prawo. Mając wystarczająco dużo par oczu, można jednak dowiedzieć się, że proces rzeczywiście mógłby mieć znacznie prostszy przebieg. Osoba odpowiedzialna za opis procesu może (powinna/musi) mieć doskonałe koncepcje, ale może też szybko się do nich przywiązywać i przez to przestawać zauważać inne możliwości. A czasem wystarcza tylko mały impuls zewnętrzny, aby przedstawiona propozycja została całkowicie przebudowana, dając znacznie korzystniejszy wynik. Rzecz w tym, aby sięgać po takie impulsy, i to odpowiednio wcześnie, i to odpowiednio często. Tak, by nie dawać sobie szans na zagalopowanie się w swoich koncepcjach.

Krytyka - weźmy pod uwagę tylko tę konstruktywną, bo wystawiając się publicznie musimy być przygotowani i na najgorsze obelgi - też może być różna. Jest prezentowana przez ludzi i nasz stosunek do krytyki może być uzależniony od tego jaki mamy stosunek do samych krytyków. Nie chodzi więc o poddawanie wyników swoich prac niezależnej krytyce pojedynczych osób, a o otwartą dyskusję na temat proponowanych rozwiązań. Do dyskusji takiej należy dopuścić możliwie wiele osób, możliwie wielu profesji: właściciela procesu, jego uczestników (w tym wszystkich, przyszłych użytkowników oprogramowania), informatyków, którym mogłoby zostać udzielone zamówienie, a nawet klientów organizacji (przypis 1). Najlepiej też, gdy opinia każdej osoby jest natychmiast ujawniana pozostałym zainteresowanym. Tylko tak może się rodzić prawdziwa jakość.

To może się nie podobać

Nie ma recepty idealnej i chociaż ta daje doskonałe perspektywy organizacji, która dzięki IT może realizować swoje cele w lepszy sposób, to może mieć ona również wielu wrogów. Dając ludziom możliwość wypowiedzenia się na temat przyszłości procesów, odbieramy im szansę na późniejsze zaklinanie się, że nic nie wiedzieli, albo też, że nie rozumieli wymagań na system. Znacznie trudniej jest też w takiej sytuacji przepchnąć swoje, wątpliwe z punktu widzenia organizacji, pomysły. Samo publiczne wypowiadanie się też może być dla niektórych interesariuszy trudne, tak jak trudno jest niektórym autorom zaakceptować postulat ujawniania wyników swoich prac. Boimy się krytyki, ponieważ boimy się śmieszności i potępienia. I w końcu też jakże bardzo jesteśmy przywiązani do swojej mądrości. Jeśli się nią podzielimy, to czy sami nie będziemy już mniej znaczyć?

<hr>1 Wydajność procesów może stanowić o przewadze konkurencyjnej organizacji nad organizacjami dostarczającymi takich samych wartości, a zatem utrzymanie w tajemnicy zasad pracy może mieć równie istotne znaczenie. To, jak z opinii swoich klientów mogą skorzystać organizacje nastawione na zysk, jest osobnym zagadnieniem. Dla jednostek administracji publicznej powinien być to przymus.

<hr>Robert Ganowski jest analitykiem procesów w firmie METODA sp. z o.o.