IT – historie (nie)zwykłe, część II

Druga część mrocznych historii z branży IT. Tym razem rzecz będzie o prawdziwych piratach, kontraktorach i spotkaniu z przeznaczeniem.

Baterie sprzedawane oddzielnie

Epizod I – piraci level master

Lata prosperity, powstaje portal porównujący kredyty i oferty finansowe. Rozwiązanie jest unikatowe zbudowane przez kilku absolwentów poważanej szkoły ekonomicznej w oparciu o wyrafinowane algorytmy autorskiego pomysłu. Podobnych rozwiązań w Polsce jeszcze nie było. Ekonomiści niekoniecznie są również programistami, więc do zbudowania oprogramowania zatrudniają firmę informatyczną. Powstaje portal i biznes się rozkręca.

Po krótkim czasie pojawiają się podmioty, które zaczynają świadczyć podobną usługę w podejrzenie znajomy sposób co pierwsza porównywarka. Co się stało?

W metrze spotykam kolegę, który zna sprawę i on zadaje mi pytanie:co powinno było znaleźć się w umowie, żeby firma została właścicielem kodu? Cóż, prawnikiem nie jestem, ale wydaje się, że przeniesienie praw autorskich i przekazanie kodów źródłowych na rzecz zleceniodawcy – jak tego umowa nie ustala, to przeniesienia praw nie ma.

Epizod II – jedyny właściwy dostawca

Wielka firma telekomunikacyjna, czasy też zamieszchłe. Informatyzacja wre, są to lata wielkich szans, ale też wielkich przekrętów. W firmie uruchamiane są duże systemy, oparte o mainframe’y i drogie bazy danych. Jednym z tych nowych systemów jest system do rozliczania klientów. Wydawać by się mogło, że poza systemami pracującymi blisko sieci jest to najistotniejszy system w firmie.

Mijają lata. W ramach działalności operacyjnej IT podejmowane są decyzje o dywersyfikacji dostawców, ale zaraz… z systemem rozliczania tak się zrobić nie da, bo… firma nie ma praw własności do kodu, ani licencji pozwalającej na przejęcie tego prawa i tylko jeden dostawca może go rozwijać. Drogo będzie kosztowała wymiana systemu, oj bardzo drogo – ale w ostatecznym rozrachunku może i tak będzie się bardziej opłacać niż bycie nadal dojną krową dla dostawcy.

Smutna sprawa, ale co zrobić – zanim zlecisz pracę programistom, pogadaj z firmą doradczą lub prawnikiem, które doradzi Ci jak skonstruować umowę. Wszelkie algorytmy najlepiej opatentuj lub udokumentuj, że są twoim pomysłem. Zwróć uwagę, czy kupując rozwiązanie informatyczne, nabywasz rownież prawa do kodu i wprowadzania modyfikacji.

Skauci

Kolejny projekt, jeszcze w dodatku to nie pomysł naszego kierownictwa, ale jakiś geniuszy z drugiej strony kanału. Specjalistów szkoda do tego oddawać, szczególnie etatowców, bo i tak guzik z tego będzie, a z resztą to już trzecie podejście. Co zrobić? Najlepiej załatwić kontraktorów. Zrobią robotę, a jak nie zrobią, to się na nich zwali winę i tyle.

Efekt jest tego taki, że spotkania nie kończą się żadnymi decyzjami, notorycznie wyłazi brak wiedzy po stronie osób reprezentujących zamawiającego. Na porządku dziennym jest spychanie na kontraktorów odpowiedzialności za realizację zadań koniecznych do wykonania po stronie zamawiającego.

Kontraktorzy zatrudnieni do projektu po stronie klienta są jak turyści. Przyjechali, pozwiedzają, zrobią zdjęcia i znikną. Jedynie pojedyncze jednostki dbają o swoją markę i będą robiły co tylko w ich mocy, żeby wyjść z sytuacji z twarzą – jedak jeżeli większośc to tripsterzy, to nic już nie się da zrobić. Marsz ku klęsce.

Pan tu nie stał

Została kasa w budżecie na ten rok, więc trudno przegapić okazję. Firma ma dwa serwery pod silnik kolejek znanego producenta. Serwery są juz leciwe, a przedłużanie utrzymania na nie jest kosztowne. W budżecie przewidziano sporo pieniędzy na modernizację sprzętu, więc dlaczego by nie kupić nowego serwera, wyjdzie taniej niż umowa serwisowa na dwa stare.

Serwer jest już w drodze, przyjeżdża piękna maszyna z nowym wydajnym OS-em, ale nagle okazuje się, że… na zakupionym serwerze oprogramowanie serwera kolejek w bieżącej wersji produkcyjnej nie działa! Trzeba podnieść wersję oprogramowania serwera kolejek, żeby użyć nowego serwera. Nie byłoby wielkiej tragedii, gdyby istniała pełna regresja automatyczna dla systemów, które z serwera kolejek korzystają – ale testów regresji jak na razie nikt nie stworzył, a testy manualne to koszt ponad pół miliona złotych.

Szukam, sprawdzam… jest firma w Stanach, która zrobiła port bieżacej wersji używanej w firmie na wersję OS-a na nowym serwerze, ale ta firma nie nazywa się tak fajnie na trzy litery, jak poprzedni gwarant.

Dzwoni do mnie dyrektor działu integracji, jestem lekko spięty, tłumaczę rzeczowo co można zrobić… Cisza w słuchawce, chyba nie chciałbym być na jego miejscu w tej chwili.

Nemesis

Mega projekt niesiony na fali kredytobiorców. Firma zamawiająca rozwija się znakomicie. Dodatkowym impulsem do rozwoju jest prawie darmowy dostęp do licencji na oprogramowanie klasy enterprise wynikający z włączenia organizacji w dużą grupę europejską.

Firma postanawia iść z duchem czasu i za namową architektów wprowadzić SOA. Dlatego też wybiera z listy dostępnych licencji oprogramowanie z etykietką SOA i kupuje sprzęt pod to oprogramowanie na system produkcyjny w ramach realizowanego projektu. Pojawia się jednak problem, bo zarówno wykonawca projektu, jak i nikt inny w firmie na SOA się nie zna. Co gorsze, kogo by nie zapytać z kierownictwa firmy, to o SOA ma własne zdanie i własną wizję pracy w zakresie integracji systemów. Wybór systemu odbywa się w oparciu o prezentacje dostawców oraz według dość specyficznej wizji osoby zamawiającej. Programiści natomiast się brzydzą dotykać nowej platformy integracyjnej, bo oprogramowanie z naklejką SOA jest całkowicie wspak ich rozumieniu pracy jako programistów – robi się jakąś konfigurację, wykonuje jakieś klikanie, zamiast kodowania w swoim ulubionym edytorze. Kto by to chciał robić?

Projekt trwa, ale zmieniają się warunki biznesowe – kredyty już się nie sprzedają tak łatwo, a inwestycja przestaje spełniać business case. Oprogramowanie i serwer integracyjny już jest, więc pozostaje go używać, tylko jak?

Po wielu wewnętrznych bataliach zostaje podjęta decyzja w firmie o uzupełnieniu kompetencji, ludzie idą na szkolenia, ale nadal nie wskazano konkretnych odpowiedzialnych za rozwój platformy. Wykonawca projektu zaczyna pracę bez wytycznych, nie znając się na architekturze SOA i uczy się na własnych błędach. Tymczasem w firmie znikają ludzie, odchodzą z pracy. Nad platformą krąży klątwa i mówi się, że kto jej dotknie, ten znika.

Znajdują się śmiałkowie co zaczynają obchodzić używanie platformy wprowadzając usługi pisane w Javie, czyli zgodne z tym, na czym większość ludzi w firmie się zna. Niestety widmo braku zrozumienia czym jest SOA i wypracowania podejścia do prostego zarządzania usługami jest trudny do przeskoczenia, co sprawia, że nieład rośnie, a ludzi pozostaje coraz mniej.

Historie powyżej przedstawione miały miejsce w rzeczywistości. Opis przypadków nie ma na celu postawienia nikogo w złym świetle, a zostały one spisane ku przestrodze i uciesze czytelnika. Życie z pewnością dopisze kolejne historie…