Przy użyciu istniejącej technologii możliwe jest stworzenie systemu, który wyznaczyłby oficjalne wyniki tuż po wyborach, i to o wiele taniej, niż za 500 tys. zł, które kosztował system obsługujący ostatnie wybory do Europarlamentu. To, że przetargi na publiczne systemy informatyczne rozstrzygane są za tak duże kwoty – i to mimo tego, że cena jest zazwyczaj głównym kryterium – wynika z ryzyka, które musi ponieść wykonawca. Ryzyko to bierze się w znacznej mierze ze sposobu, w jaki tworzone są systemy informatyczne w Polsce (i na świecie).

Nieco ponad rok temu, 1 października 2013 roku, zgodnie z harmonogramem, w Stanach Zjednoczonych uruchomiony został portal HealthCare.gov. Portal miał służyć Amerykanom do zakupu przez internet ubezpieczenia zdrowotnego. Należało stworzyć własne konto, zalogować się, a następnie wybrać odpowiedni pakiet. Z powodu błędów technicznych, podczas pierwszego tygodnia, tylko 1% zainteresowanych zdołało zarejestrować się na portalu.

Początkowe koszty stworzenia HealthCare.gov szacowane były na 93,7 miliona dolarów, w trakcie realizacji wzrosły do 292 milionów, w sierpniu tego roku mówi się już o 1,7 miliarda kosztów, związanych z utworzeniem i obsługą portalu. A pierwsza wersja powstała ponoć dużo wcześniej i taniej, w środowisku Open Source, tylko potem jakoś zniknęła.

Jak sondy kosmiczne

Takie korporacje jak Google, Facebook, Twitter, czy Amazon, wprowadzają zmiany we własnym oprogramowaniu stopniowo, na zasadzie mikroaktualizacji (często codziennych), przeprowadzanych przez małe grupki programistów. Powszechną praktyką jest też wdrażanie nowych funkcjonalności najpierw u niewielkiej grupy użytkowników i dopiero, gdy okaże się, że działają one poprawnie, wdrażanie ich u wszystkich. Dla Google i innych wielkich graczy szczególnie ważne jest ciągłe i bezawaryjne działanie własnych systemów, dlatego nie doprowadzają to takich sytuacji, w jakich znajdują się sondy kosmiczne.

Twórcy sond kosmicznych muszą przewidzieć wszystkie potencjalne niebezpieczeństwa, na jakie narażone są sondy z dala od Ziemi. Budowaniu sond towarzyszą żmudne analizy, kompleksowe testy najdrobniejszych mechanizmów i najbardziej trywialnych kawałków kodu. To między innymi dlatego budowa i wysłanie sondy kosmicznej kosztuje tak dużo i zajmuje tak dużo czasu. Raz wystrzelona nie może zawieść.

Przetargi na rządowe systemy informatyczne kończą się tak dużymi kwotami, ponieważ tego typu systemy są traktowane jak sondy kosmiczne. Prawie nigdy nie są testowane w praktyce. Użytkownicy nie mają żadnego wpływu na ich rozwój.

Systemy są dostarczane zgodnie z harmonogramem, a potem okazuje się, że część funkcjonalności działa inaczej, niż spodziewał się klient, czy użytkownik, a część psuje się, jeśli scenariusz wykorzystania odbiegnie nieco od założeń ze specyfikacji.

Jest to jak najbardziej normalne. Systemy informatyczne są często tworem na tyle złożonym, że wykraczają poza zdolności poznawcze człowieka. Nie ma takiego programisty, który od razu napisałby system wyborczy bezbłędnie. Nie ma takiego systemu informatycznego, który jest bezbłędny.

Czasami – tak jak w przypadku upublicznionego fragmentu kodu systemu wyborczego – można mówić o typowej fuszerce i braku doświadczenia programisty. Albo o niewystarczającym doświadczeniu firmy, która zajęła się implementacją. Najczęściej winne takich spektakularnych wpadek są jednak inne czynniki, które szczególnie uwidoczniły się zarówno w przypadku naszego niechlubnego systemu wyborczego, jak i słynnego za oceanem HealthCare.gov. Wiele problemów wynika po prostu ze złego podejścia, z podejścia “sondy kosmicznej”.

Podział odpowiedzialności

Podczas rozwijania systemu wyborczego pojawiła się jeszcze jedna okoliczność, która przyczyniła się do częściowej porażki projektu. Zgodnie z doniesieniami prasowymi ogłoszony w listopadzie 2013 roku przetarg na Platformę Wyborczą 2.0 okazał się łamać 11 artykułów ustawy o zamówieniach publicznych. Nie jest w tej chwili ważne, dlaczego ten przetarg został unieważniony, ani dlaczego został ogłoszony tak późno (skoro same procedury przetargowe na takie kwoty trwają miesiącami).

W tej chwili ważne jest to, że już na poważnie zaczęło brakować czasu. Prawdopodobnie ogłoszenie od nowa tak dużego przetargu zajęłoby zbyt dużo czasu. W lutym 2014 rozpisano więc kilka mniejszych przetargów. Między innymi na “Zaprojektowanie i wykonanie witryn internetowych wyników głosowania i wyników wyborów wraz z prowadzeniem i administrowaniem” za 209 tys. zł i “Zaprojektowanie, wykonanie i rozbudowę modułów wyborów do Parlamentu Europejskiego, wraz z administrowaniem i utrzymaniem” za niespełna 500 tys. zł. Co ciekawe, mimo że cena stanowiła 70% krtyterium oceniania, z dwóch ofert, które napłynęły, wybrano tę droższą o około 100 tys. zł.

Tym samym doprowadzono do zbliżonej sytuacji, w jakiej znalazło się rok wcześniej HealthCare.gov. Rozdzielono odpowiedzialność na podprojekty. A w konsekwencji:

Nikt tak w zasadzie nie był odpowiedzialny za sukces projektu.

Utrudniono komunikację pomiędzy osobami zaangażowanymi w projekt.

Rozdzielenie odpowiedzialności jest jednym z lepszych sposobów na porażkę projektu. W końcowej fazie projektu HealthCare.gov brało udział ponad dwadzieścia przedsiębiorstw. Nasz projekt nie miał takiej skali, ale samo rozdzielenie odpowiedzialności – zwłaszcza w sytuacji, kiedy zaczynało brakować czasu – już zwiastowało, że coś pójdzie nie tak.

Trójkąt ograniczeń

Jedną z żelaznych zasad zarządzania projektami jest tzw. trójkąt ograniczeń. W klasycznej wersji takiego trójkąta projekt rozpatrywany jest w trzech wymiarach: zakresu, czasu i budżetu. Wymiary te są ze sobą ściśle powiązane. Aby skrócić czas trwania projektu, można próbować zaangażować większe środki (budżet), albo ograniczyć zakres (np. zrezygnować z kilku funkcjonalności). Aby zwiększyć zakres, najprawdopodobniej potrzeba większych środków i więcej czasu.

Stwierdzenie w przypadku naszego systemu wyborczego, że wystarczyłoby mieć piętnastu programistów, zamiast pięciu jest jednak bardzo naiwne. Zależności między poszczególnymi wymiarami w trójkącie ograniczeń nie są takie proste.

To czas był główną przeszkodą, a nie zasoby ludzkie. Często dołożenie osoby do projektu informatycznego skutkuje wydłużeniem czasu realizacji, co bierze się między innymi ze znacznego nakładu, który należy ponieść na wdrożenie się w projekt.

W dodatku w dużych zespołach znacznie utrudniona jest komunikacja. Wykładniczo wzrasta liczba możliwych interakcji pomiędzy ludźmi. Jeśli zespół składa się z trzech osób, mogą rozmawiać ze sobą w sumie trzy pary osób. Przy czterech osobach tych par jest już sześć. Przy pięciu – dziesięć, a przy piętnastu osobach, jak to było sugerowane, może ze sobą rozmawiać już sto pięć różnych par.

Przy dużych grupach osób, które są zorgranizowane hierarchicznie, wydłuża się z kolei czas komunikacji. Zanim coś nowego zostanie ustalone, informacja o tym musi przejść przez zwierzchników. Im więcej stopni w hierarchii, tym większy nakład na komunikację (a także tym większe zniekształcenie komunikatów), niż w przypadku interakcji bezpośrednich.

Zazwyczaj można przyspieszać czas tworzenia projektu, zwiększając liczbę zaangażowanych osób, ale tylko do pewnego stopnia.

Pracując nad projektem, programista dopiero po pewnym czasie nabiera określonej płynności w tworzeniu kodu. Najpierw konieczne jest zapoznanie się z problemem, zrozumienie wymagań klienta, czy zrozumienie kodu, który wcześniej został utworzony przez innych zatrudnionych programistów. Są to na tyle nietrywialne rzeczy, że panuje przekonanie, że wprowadzenie programisty w późnym etapie projektu, prowadzi nawet do wydłużenia czasu jego realizacji.

Osobną kwestią są relacje pomiędzy poszczególnymi wymiarami trójkąta ograniczeń. Zwykle, w przypadku opóźnień i narzuconego terminu zakończenia projektu, rozmawia się z klientem, żeby zrezygnować z mniej ważnych funkcjonalności. Albo jeśli nie można zrezygnować z funkcjonalności, rozmawia się o wydłużeniu terminu. Jest to podejście rozsądne, ale w przetargach publicznych – nie do pomyślenia. Czas, budżet i zakres – wszystko musi być niezmienne.

Dlaczego przetargi organizowane są tak, a nie inaczej

Wynika to zarówno z interesów zleceniodawcy, jak i z interesów wykonawcy. W interesie zleceniodawcy jest to, aby jak najmniej czasu poświęcić na projekt. Rzadko zdarza się – choć ostatnio chyba coraz częściej – że klient jest faktycznie zaangażowany w tworzenie produktu, że przedstawiciele klienta na bieżąco komunikują swoje potrzeby i mają uwagi do powstającego oprogramowania.

W pewien sposób jest to nawet uzasadnione. Zazwyczaj klient ma na głowie tyle innych zadań, że jego podejście – raz opisałem wymagania, więc oczekuję produktu na koniec – nawet jeśli jest krótkoterminowe, intuicyjnie wydaje się słuszne. Tylko znów: systemy informatyczne są często tak złożone, że nie sposób ich tworzyć w oderwaniu od klienta.

Po drugiej stronie znajduje się wytwórca. Wymagania dotyczące oprogramowania ustalane są na górze, pomiędzy prezesami, czasami coś do powiedzenia mają analitycy, podobno kiedyś jakiś programista rozmawiał z klientem. Oczywiście przesadzam, moje doświadczenie mówi, że nawet programiści rozmawiają z klientami i ustalają z nimi, w jaki sposób ma działać wytwarzany produkt. W rzeczywistości biznesowej funkcjonują też całkiem sprawnie tzw. iteracje, które polegają na tym, że kolejne funkcjonalności dostarczane są stopniowo.

Czym innym jest jednak rzeczywistość biznesowa, a czym innym rzeczywistość przetargowa. W przypadku współpracy pomiędzy dwiema instytucjami, które potrzebują systemu informatycznego dla efektywniejszego uzyskiwania przychodu, najważniejsze jest to, żeby dany system spełniał swoją rolę. Innymi słowy, dla firm ważne jest to, żeby system informatyczny funkcjonował tak, aby wspierać ich działalność biznesową. (Osobną kwestią, której nie będę tu poruszał, są projekty finansowane z funduszy unijnych).

Rzeczywistość przetargowa jest całkiem inna, bo nie sterują nią rzeczywiste potrzeby biznesowe, a dokumentacja. Przedsiębiorca jest wrogiem organizatora przetargu. Trzeba się przed nim zabezpieczyć na wszelkie możliwe sposoby. Ogłoszenie przetargowe musi zawierać najdrobniejsze szczegóły dotyczące funkcjonalności tworzonego systemu, żeby tylko wszystko zostało zorganizowane zgodnie z zamysłem zamawiającego. Budżet zostaje ustalony w momencie rozstrzygnięcia przetargu, termin jest z góry określony. Wszystkie elementy trójkąta ograniczeń są narzucone.

Tymczasem tworzenie oprogramowania, to w każdym przypadku rozwiązywanie złożonego problemu, który wszyscy – programiści, analitycy, kierownicy, nawet klient – rozwiązują po raz pierwszy. W trakcie rozwoju systemu zawsze dojdzie do sytuacji, w której okaże się, że coś należy zrobić inaczej, niż zakładało się na początku. Jeśli klient (albo użytkownik) sam przez jakiś czas nie spróbuje pracować z jakąś testową wersją systemu, nie pozna wystarczająco swoich potrzeb. A potem nagle, po zakończeniu projektu okaże się, że coś poszło nie tak.

Zleceniodawca zabezpiecza się rozbudowaną dokumentacją, wykonawca naraża się na ryzyko, że w projekcie dużo trzeba będzie zmienić w stosunku do tego, co zakładano na początku, albo po prostu, że wykonanie czegoś okaże się dużo trudniejsze, niż początkowo zakładano. I właśnie to ryzyko kosztuje. Właśnie to ryzyko powoduje, że przetargi publiczne na systemy informatyczne rozstrzygane są za tak duże pieniądze. Podejrzewam, że dlatego też nikt nie zgłosił się do przetargu, kiedy został po raz pierwszy ogłoszony.

Przedsiębiorca myśli rozsądnie, zabezpiecza się, przezornie zawyżając koszty (często słusznie). Organizator przetargu także myśli rozsądnie; często sam nie korzysta z danego systemu, a niepoprawnie działający system nie wiąże się dla niego z realnymi stratami. W interesie organizatora przetargu publicznego jest szczegółowe udokumentowanie wymagań.

To zaś zajmuje mnóstwo czasu, a potem efekt w połowie nadaje się do kosza. Nie przez wzgląd na złą wolę, ani brak kompetencji. Przez to, że systemy informatyczne są czymś bardzo złożonym i nie sposób przewidzieć tego, jakie powinny być naprawdę.

Kto jest winny

Żeby zrozumieć problem, należy przyjrzeć się motywacji każdego z podmiotów, zaangażowanych w przetarg na system wyborczy. Nie winiłbym ani wykonawcy podsystemu, który nie zadziałał, ani zlinczowanej i zdymisjonowanej Komisji. Każdy postępuje zgodnie z własnymi interesami, każdy chce się zabezpieczyć, nikt przecież nie zepsuł systemu wyborczego celowo.

Obwinianie jednej, albo drugiej strony jest bardzo chwytliwe, jednak nie pozwoli rozwiązać problemu. Jest on znacznie głębszy, niż mogłoby się wydawać i tkwi w samej organizacji przetargów publicznych.

Sam nie mam recepty, sam nie wiem, w jaki sposób można naprawić istniejący system. Ale być może pierwszym krokiem do rozwiązania problemu jest jego zrozumienie, zamiast ślizgania się po płytkich wyjaśnieniach.

W grudniu pojawiła się informacja, że nowy system wyborczy nie będzie realizowany w ramach przetargu. Być może to jest krok w dobrą stronę.