Blog IT – Mateusz Mrozewski

Jakiś czas temu umieściłem dwa posty: marudzenie część 1 i część 2. Dziś kolejna część.

Temat 3: jeden projekt, wielu dostawców.

W "nasz" projekt było zaangażowanych wiele stron:

1. Oczywiście był klient - duża ubezpieczalnia.
2. Klient zlecał prace firmie, która jest czymś w rodzaju zgrupowania firm IT.
3. To zgrupowanie zatrudnia jedną firmę, która zajmuje się administracją bazami i serwerami aplikacji.
4. Firma z punktu 3 operuje na sprzęcie i aplikacjach z jednej firmy oraz częściowo systemach operacyjnych z innej firmy.
5. Same serwery stoją fizycznie w różnych miejscach, częściowo w serwerowniach jeszcze innej firmy.
6. Integrację ze starym systemem po części zapewnia kolejna firma - odpowiedzialna za wystawienie "interfejsu" ze starego systemu.
7. Testy wykonuje jeszcze kto inny.
8. Projekt aplikacji wykonała osoba z jeszcze innej firmy, też zatrudnionej przez firmę z punktu 2.
9. A implementację robiliśmy my (też zatrudnieni przez punkt 2)
10. Czy wspominałem o tym, że część naszych testerów i programistów to kontraktorzy?

Lista całkiem długa (ciekawe o kim zapomniałem). Do czego to prowadzi? Przede wszystkim do utrudnionej komunikacji. Niby XXI wiek, mamy telefony, e-maile, nadal potrafimy chodzić i mówić. A jednak nie jest tak łatwo, gdyż osoby pracujące nad tym projektem w różnych firmach mają często też inne obowiązki, więc nie są tylko i wyłącznie dedykowani do tego projektu. Powstaje tutaj problem znalezienia wspólnego fragmentu wolnego czasu.

I tak np. gdy potrzebowałem coś od adminów, wysyłałem emaila i czekałem, aż ktoś będzie miał chwilkę, żeby mi odpowiedzieć. Często włączał się w dyskusje ich szef, który nie akceptował zgłoszeń przez email i kazał mi wrzucać zgłoszenia przez ich system do obsługi zgłoszeń. Z jednej strony to rozumiem, gdyż kiedyś pracowałem w zespole, który takie zgłoszenia realizował i wiem jak ważne jest posiadanie systemu do zarządzania zgłoszeniami. Z drugiej strony ważne jest też, aby taki system nie wprowadzał dodatkowych komplikacji w komunikacji. Przykładowo, założenie nowego indeksu mogło pójść dwoma ścieżkami:

• krótki mail bezpośrednio do admina, jest szansa, że odpowie w godzinę lub dwie
• i metoda "właściwa": zgłoszenie mojemu kierownikowi tego problemu. On z kolei jak znajdzie chwilkę czasu wrzuci to do systemu zgłoszeń , o którym przed chwilą pisałem (tak tak, mają do niego dostęp tylko kierownicy). Następnie kierownik adminów może to komuś przypisze, a wtedy ten ktoś to zrobi - pewnie ze dwa dni miną, a samo zadnie wykonuje się w 5 minut maks.

Innym problemem jest proces decyzyjny - nikt nie może sobie ot tak czegoś zmienić, wszystko musi być ustalone z innymi, zatwierdzone, przegadane, podpisane. I tak powstają spotkania, na które przychodzi kilkanaście osób i dyskutują przez godzinę, czy faktycznie trzeba ten indeks założyć. Takie spotkania mają dość mocne podłoże formalne - chodzi o odpowiedzialność, wypełnianie zobowiązań z kontraktów, ustalenie co leży w czyim zakresie obowiązków i najważniejsze to rozliczanie się za to. Więc jeśli chodzi o pieniądze, to poważna sprawa. Ale z drugiej strony, jeśli system się "wali" i użytkownicy nie mogą z niego korzystać, to trzeba działać, a nie rozmawiać. Common Sense. Naprawmy to, a potem pogadamy co zrobiliśmy.

Najbardziej drażniącym efektem ubocznym było to, że wszystkie problemy były zwalane na nas, bo to my robiliśmy implementację. Nie wypieram się błedów, popełniliśmy ich trochę, ale dołożyliśmy wszelkich starań, aby wszystkie naprawić. Natomiast wytykanie palcem bez sprawdzenia przyczyny błędu jest trochę irytujące. Musieliśmy przez to często poświęcać sporo czasu na namierzanie nie naszych błedów. Ok, może mieliśmy do tego najlepsze kompetencje (skromność), ale dużo lepsza byłaby atmosfera w projekcie, gdybyśmy zamiast "to na pewno wasz błąd, naprawcie" usłyszeli "czy moglibyście nam pomóc w rozwiązaniu tego problemu". Nie mówiąc już o "dziękuję" na koniec W końcu wszyscy pracujemy wspólnie nad wspólnym projektem W ten sposób nasze morale by się podniosły (jesteśmy doceniani), a jakość też by się poprawiła.

Czy ktoś z Was ma doświadczenie z równie złożonym środowiskiem? Jeśli tak, to jakie macie doświadczenia?

IT, projekt