Mówimy, że analityk stoi między biznesem a IT. Często przychodzi nam wtedy do głowy obraz ludzi rozmawiających innymi językami, a analityk, jako tłumacz, stoi pośrodku. Spokojnie i sielankowo? To zależy od tłumaczenia.
Przypomina mi się tu jak na jednej z konferencji chwilami z większym napięciem i podziwem niż na gwiazdę wieczoru, patrzyłam na tłumacza tłumaczącego „na żywo”. Facet był niesamowicie sprawny i choć z ust płynął zgrabnie ujęty i sensowny wątek, to na twarzy było widać wysiłek maksymalnego skupienia i pot. Kilka tysięcy ludzi nagrodziło tłumacza takimi brawami, że przekroczyliby skalę oklaskomierza z Od przedszkola do Opola 😉
Dziś jednak o czymś jeszcze trudniejszym niż tłumaczenie symultaniczne. O analityku jako negocjatorze, rozjemcy konfliktów, arbitrze w samym ogniu kryzysu.

Biznes kontra IT

Bo to, że rozumiemy i umiemy przetłumaczyć obie strony, to nie wszystko. Konflikty interesów – to dopiero zabawa.
Stanąłeś pewnie kiedyś w obliczu takiego dylematu. Oto biznes napotyka problem i żąda szybkiego i taniego rozwiązania. Co więcej, czasem wręcz podsuwa proste rozwiązanie. IT już skręca, kiedy słyszy o kolejnym rozwiązaniu na taśmę klejącą, na gumę do żucia, podpórkę do podpórki, workaround do workarounda, obejście na gazomierzu. Już i tak zgodzili się na zbyt wiele pozwalając na wcześniejsze niewłaściwe rozwiązanie. Ale wtedy była kryzysowa sytuacja. I mieliśmy to przecież później wyprostować. A teraz mamy brnąć dalej w to bagno zaciągając jeszcze większy dług technologiczny.
„Co radzisz?” – możesz zapytać kolegę programistę, projektanta, architekta, który ma łeb na karku i pomysły na dobre rozwiązania. Powie Ci pewnie najlepsze, co wie i może kilka innych propozycji. OK. „A w ile to zrobicie?”. I tu pada liczba PD, SP czy czego tam kilku-, kilkunasto-, kilkudziesięciokrotnie większa niż koszt workarouda.

Klops

Taki oto klops: z jednej strony masz biznes, który bardzo potrzebuje szybkiego rozwiązania. Rozumiesz ich. Tym bardziej, jeśli system działa już produkcyjnie. Wiesz, że to hamuje ich biznes albo dokłada ogrom pracy „na piechotę”, przez co nie mają czasu na ważniejsze rzeczy. Rozumiesz ten ból. Jak wytłumaczyć im, że zamiast rozwiązania, które na prędce wymyślili, żeby dopomóc IT, IT proponuje jednak coś o wiele droższego, na co poczekają długie tygodnie zamiast kilku dni? A w dodatku nie zauważą żadnej funkcjonalnej różnicy?
Z drugiej strony masz IT, które chce rozwijać i utrzymywać system zgodnie z dobrymi praktykami. Żeby mieć poczucie, że robią coś dobrego, z czego mogą być zadowoleni, dumni. A przy okazji oszczędzić sobie nerwicy przy wprowadzaniu późniejszych zmian albo, co gorsza, naprawianiu krytycznych defektów pod presją czasu, wkurzonych przełożonych i użytkowników. Rozumiesz ich. Czujesz ten ból. Chcesz też, żeby mieli najpiękniejszy kod, najbardziej optymalny, elegancki i cokolwiek sobie wymarzą. Bo wiesz, że to działa, ułatwia później pracę i oszczędza Ci wysłuchiwania narzekań i wezwań do decouplingu 😉 Jesteś po ich stronie. Jak wytłumaczyć im, że mają zrobić po raz kolejny obejście, mimo, że wszyscy wiedzą, że zbliżamy się niebezpiecznie do granicy absurdu w kodzie? Bo nie ma czasu, nie ma budżetu. A mieliśmy to w końcu wyprostować… Ale po raz kolejny inne rzeczy są pilniejsze.
I ci z biznesu pewnie niektórzy rozumieją IT. Rozumieją, że nie można w nieskończoność kleić na taśmę, bo nam w końcu coś pierdyknie. I że późniejsze zmiany to prawdziwie karkołomne wyzwanie. Z czasem jest coraz trudniej i dłużej. Jak przy wyciąganiu kolejnej belki z wybrakowanej już wieży Jenga.
I ci z IT też niektórzy dobrze rozumieją, że biznes ma problem, ma na głowie swoich wkurzonych klientów. Stoją z robotą. Bezradnie czekają aż ich IT uratuje w tej trudnej sytuacji.
Tylko biznes rozumie siebie nieco bardziej 😉 Bo to do nich będą zgłaszać się wkurzeni klienci, oni będą spędzać godziny na przeklepywanie danych w excelu, choć dotąd mieli to w sekundę pod jednym przyciskiem. I IT rozumie siebie nieco bardziej, bo ten system to ich dzieło. To oni będą musieli żyć z tymi workaroudami. To oni później będą wprowadzać zmiany i rozwiązywać defekty borykając się ze straszliwie zagmatwanym kodem i wkurzonymi tymi, co stoją nad nimi i pytają czemu to tak długo trwa.
Jak żyć? Można powiedzieć, że „rozwiążmy to teraz szybko, a później zrobimy tak, jak należy”. Tylko, że to „później” czasem nigdy nie nadchodzi.
Kiedyś kolega zażartował: „Słuchajcie, może ja tam dorzucę kilka sztucznych pętli, żeby to się wykonywało dłużej. Bo jak zobaczą taki skok jakości z tego szybkiego fixa, to już nie będą chcieli wdrożyć tego właściwego rozwiązania.”. Pośmialiśmy się. Ale wykrakał. Po kilku tygodniach faktycznie pojawiają się pytania „No to po co teraz to robić? Przecież działa. Jest OK. Nikt nie narzeka. Zostawmy to. Są pilniejsze rzeczy. A taka zmiana to przecież dodatkowy czas i ryzyko”.
Za to nam płacą? Za szukanie argumentów?
Z drugiej strony, jakbyś miał płacić za lepsze naprawienie samochodu nie 500 zł, ale 5 000 zł, 10 000 zł, bo tak będzie lepiej i ryzyko, że się nie popsuje ta i inne rzeczy zmniejszy się z 5% do 2%, a Ty jako kierowca nie odczujesz poza tym różnicy, to co byś zrobił?

Jak to rozwiązać?

Można umawiać się na szybkie rozwiązania i później rozwiązania docelowe.
Można powoływać specjalne role osób, które dbają o znajdowanie takich miejsc i poprawianie jakości, refactoring. Przeznaczyć na takie akcje budżet, czas. Byle działało to sprawnie, a nie na 5% etatu. Zresztą, pewnie programiści najlepiej wiedzą jak sobie radzą ze spłacaniem takich długów.
Można śledzić zgłoszenia incydentów i powiązywać je z przyczynami, a potem sprawdzać ile problemów bierze się z takiego szybkiego łatania dziur. Przytoczenie konkretnych przypadków z historii lepiej przemówi do wyobraźni. Pokaż biznesowi ryzyka, potencjalne skutki, najlepiej wymierne, w walucie, którą operują. Jednak poza abstrakcyjnymi wywodami, pokaż też co już się zepsuło w przeszłości, jak wiele już stracili, bo podejmowali takie a nie inne decyzje. To też najlepiej w czasie, walucie. Ile kosztuje ich zła jakość. Jak źle jest teraz a jak dobrze może być, kiedy i za ile. Zbierz dane od architektów, projektantów, liderów zespołów.
Może znów wiele pytań, mało odpowiedzi, ale tak to jest w analizie : ) Nie ma jednej odpowiedzi. Ile projektów, firm, systemów, ludzi, nastawień, przekonań, tyle różnych wyjść. Próbuj, co działa u Ciebie. Czego już próbowałeś?
Czasem można też dopuścić, że business is business i pozostać na poziomie „dość dobre” zamiast tego „bardzo dobrego”. W końcu to oni są klientami. Znają ryzyko. Podejmują decyzje.