IT i biznes. Warto nie odpuszczać

W relacji IT z biznesem kluczowe znaczenie ma twardy kark, aby twardo przeć do wyklarowania, co jest najlepsze dla firmy. Nie odpuszczać wyłożenia swoich racji i zrozumienia drugiej strony. Michał Głowiński, szef HL Tech, spółki technologicznej obsługującej brytyjskiego potentata ubezpieczeń emerytalnych, dzieli się swoim podejściem do relacji technologii z biznesem.

Wciąż słyszymy, że „IT nie rozumie biznesu” lub „biznes nie rozumie IT”. A ile zrobili Państwo, żeby to zmienić? Pewnie wciąż za mało. Przedstawię kilka typowych sytuacji korporacyjnych, które mogą zniszczyć karierę, a nawet firmę, a w najlepszym wypadku narazić ją na pokaźne straty finansowe. Przykłady pochodzą ze świata IT, ale bez problemu można znaleźć analogie w każdej innej branży.

Na początek przyjrzyjmy się, jaką wiedzę w danej dziedzinie posiadamy. Każdemu wydaje się, że wybudować dom to nic skomplikowanego. Wiemy przecież, jak to się robi, możliwe, że widzieliśmy nawet ten proces krok po kroku. Blok mieszkalny? To kilka razy więcej materiału. A wieżowiec biurowy na kilkadziesiąt pięter? Zapewne kolejne kilka, kilkadziesiąt razy więcej materiału. Drugi najwyższy budynek w Warszawie – Warsaw Spire – 180 metrów nad ziemią, pewnie ma lepsze materiały i ktoś to dobrze policzył, ale wciąż proces ten jest w zasięgu naszej wyobraźni. Silnik, koła, karoseria itd. O rozrządzie silnika czy skrzyni biegów CVT wydaje nam się, że wiemy wszystko. Samochód jest w naszych głowach. Z modą jest podobnie.

A informatyka? Programowanie? To ciągle młoda dziedzina. Czy posiadamy tak okrzepłe standardy inżynierii? Świat finansów nie jest wiele starszy. Czy każdy człowiek wie, jak działają mechanizmy giełdy? Co trzeba zrobić, żeby wyprodukować grę na telefon komórkowy?

Wspólny język to jeden z ważniejszych elementów sukcesu. Przytoczę więcej przykładów; niektóre z nich przez analogię do bardziej znanych dziedzin inżynierii. Zależy mi, by przedstawić, czym dla mnie jest dobra współpraca. Oprócz motoryzacji i budownictwa chętnie stosuję odniesienia do prostych działań matematycznych.

Otoczenie

W mojej obecnej firmie od początku postawiono jeden cel: uczynić sprawne IT jeszcze sprawniejsze. Zamiast często spotykanego modelu: biznes-pomysłodawca i siła robocza IT, HL Tech wspiera realnie Hargreaves Lansdown w wytwarzaniu nowoczesnych narzędzi dla biznesu. Zarząd firmy założył, że w Polsce są najlepsi specjaliści do przeprowadzenia audytu rozwiązań działających w Bristolu, którzy zaplanują, co i w jaki sposób można zmienić, następnie to wykonają, a wprowadzone rozwiązanie będą rozwijać i udoskonalać. Przy takich założeniach otrzymamy narzędzia, których konkurencja będzie nam zazdrościć przez długi czas. Pojęcie IT, jako centrum kosztowego, zostało wyeliminowane.

Taki model motywuje pracowników IT. Mogą więcej zdziałać niż w innych firmach, mają realny wpływ na projekty, wybór technologii, kreowanie wizerunku firmy. Dzięki temu dostarczają dobre rozwiązania, z których biznes jest zadowolony, więc chce z nimi współpracować. Nie są to założenia obce innych organizacjom. To dlaczego nie wszędzie działają?

W dowolnym modelu współpracy wystarczy, że zabraknie jednego elementu i całość przestanie działać. Nikt przy zdrowych zmysłach i dobrej woli nie wyjmie świadomie tego elementu, żeby zburzyć całość. Ale być może odpuści szczegół, niepozorny detal… Jeden z elementów zacznie się w niewidoczny sposób degradować, pociągnie za sobą kolejne, a z czasem całość przestanie działać.

Obecnie w Hargreaves Lansdown (HL) systemy można podzielić na cztery grupy. Każda z nich jest w innej technologii, niektóre języki programowania powstały wiele lat temu. Mogłoby się wydawać, że HL Tech w Polsce ma uratować coś, co ledwo działa, ale tak nie jest. Czasem nawet kandydaci do pracy w naszej firmie nie wierzą, że te systemy mogą być utrzymywane w tak dobrym stanie. Ich kariera zawodowa to zmiana firmy co dwa czy trzy lata. Zawsze był ten sam scenariusz: globalna firma ma problemy, w Polsce dobrzy specjaliści za rozsądną cenę, pod presją czasu przepiszą system i zapewnią jego utrzymanie. Dla osób przy produkcji oprogramowania oznaczało to zawsze nudę, a za chwilę cięcie kosztów i zmniejszenie liczby pracowników. Kiedy tłumaczę, że tym razem ma być inaczej, widzę na twarzach zdziwienie. Firma chce inwestować w najlepsze technologie, ale nie boi się wprowadzania zmian nawet dzień po wdrożeniu, jeżeli wiadomo, że można coś zrobić jeszcze lepiej.

Wracając do analogii, czym jeździ HL? Moim zdaniem jest to zadbany Mercedes Benz W124. Lakier w nienagannym stanie, silnik V8, który rozpędza samochód do 100 km/h w niecałe 6 sekund, wygoda. Kto nie marzy o takim klasyku w garażu? Jednak wiemy, że nawet taka perełka nie wjedzie za kilka lat do centrum miasta, a jeszcze za chwilę zostanie wyparta przez samochody autonomiczne. Czym jest więc software, który powstaje teraz w HL Tech? Tutaj o wiele trudniej jest mi podać odpowiednik motoryzacyjny. Nie wiemy, co zastąpi pierwszą generację samochodów autonomicznych. Może coś przypominającego pojazd z kreskówki o rodzinie Jetsonów?

Zwinna metodyka projektowa jako źródło sukcesu to kolejny stereotyp, który u nas nie obowiązuje. Chcemy być nowocześni, przejdźmy z modelu kaskadowego na coś lekkiego. Świetnie, ale kto z Państwa odpowie twierdząco na pytanie o wdrożony Scruma? Mamy w wybranych miejscach „jego elementy”. Podstawą metodyki jest jej wdrożenie w całości, bo inaczej nie działa. Znam firmy, które prawidłowo wykorzystują dobrodziejstwo zwinnych metodyk. I żaden z pracowników nie powie, że to jest proste. Często nie działa, bo ktoś odpuścił, nie zrobił swojej pracy do końca, powstał bubel.

Ludzie

Jak jeszcze można zniszczyć dobry proces i dobrą relację? Widziałem w swojej karierze menedżerów, którzy robili dziwne rzeczy w obawie o swoje posady albo w walce o korporacyjne wpływy, zabijając przy tym nawet najlepsze inicjatywy. Zaczyna się niepozornie: „nie odezwę się na telekonferencji”, „jest piątek”, „chcę do domu, po co dyskusja”, „wstydzę się włączyć w dyskusję w obcym języku” itd. Omijajcie szerokim łukiem takich ludzi.

Jako młody kierownik projektu zostałem kiedyś zaproszony przez jednego z dyrektorów na telekonferencję z jeszcze większym dyrektorem (EMEA Global Director to tylko początek jego oficjalnego tytułu). Obserwowałem spotkanie i nie wierzyłem: jeden nie miał pojęcia, z czego się tłumaczy, a drugi nie chciał mu pomóc, tylko przerywał wszystkim obecnym i pokrzykiwał. Korzystając z przerwy między kolejnymi słowami dyskusji, wtrąciłem: „To może ja wytłumaczę”. Zrobiłem mały wstęp, wyższy rangą przerwał mi: „Ale jest problem! Trzeba go rozwiązać! Nie działa”.

Odpowiedziałem: „Może umówmy się tak: dasz mi 3 minuty i nie będziesz mi przerywał, a ja ten problem rozwiążę”. Gdy przechodziłem do meritum, przerwano mi kolejny raz. Powiedziałem: „Umawialiśmy się, że sobie nie przerywamy. Problem, o którym toczy się dyskusja, wystąpił dwa dni temu, został rozwiązany wczoraj, a poprawka w oprogramowaniu została przetestowana i jeszcze dziś wieczorem w trybie awaryjnym trafi do użytkowników. Potencjalna strata finansowa, o której wszyscy mówicie, nie zaistniała i nie musicie się przerzucać odpowiedzialnością”.

Cisza. Usłyszałem od kilku osób „dziękuję za wyjaśnienia, wszystko jasne”.

Wyobraźmy sobie, że taka sytuacja powtarza się w firmie kilka razy w tygodniu. Ile ciekawych rzeczy można zrobić, w jakim miejscu można się znaleźć, gdyby nad tym panować. Ile może zdziałać prosta komunikacja? Uczą o tym na jednej z pierwszych lekcji języka polskiego w szkole podstawowej. Szkoda, że zapominamy o podstawach.

Gdzie jest problem? Kiedy poprosiłem tego „dużego”, żeby nie przerywał, to „mniejszy” podskoczył jak oparzony, żeby mi wyrwać telefon. Zwyczajnie bał się otwarcie rozmawiać z przełożonym…
Sporo mnie to nauczyło. Dodajmy do tego środowisko multikulturowe oraz dwa światy nazywane IT i biznes. Sugestia: upewnij się kilka razy, że druga strona cię rozumie.

Innym razem przejąłem obszar odpowiadający za wsparcie IT biznesu za granicą. Historia tego związku była długa i burzliwa. Całkowity brak zaufania po obu stronach. Liczba zgłoszonych błędów w systemie rosła z prędkością uniemożliwiającą zapamiętanie aktualnego wyniku. Jako źródło problemów zespół wskazuje ciągle zmieniające się wymagania, które są zupełnie nieprzemyślane, „nie możemy zamknąć specyfikacji, a system musiał ruszyć, bo klient…”, usłyszałem. Klasyka gatunku. Zaogniona sytuacja, brak dialogu, o kosztach nikt już nie myśli. Potrzebny „reset”, i to szybko. Podczas kolejnego lotu do jednej z europejskich stolic myślałem, jak zbudować zaufanie i nauczyć produkcji oprogramowania w jeden dzień. Następnego dnia, po krótkim przedstawieniu, nie mając wiele na obronę sytuacji, powiedziałem w prostych słowach, że widziałem wiele, ale takiej atmosfery pracy nigdy do tej pory nie spotkałem i że nigdzie nas to nie zaprowadzi. Nie interesuje mnie to, co było, ale na dobry początek w oderwaniu od realiów projektu opowiem, czym się zajmuje mój departament w Polsce. Szukam prostej analogii, która trafi do uczestników spotkania. Żeby wybudować dom, potrzebujemy przynajmniej wizji. Zrobimy za mały fundament, to będzie za mały dom, a jak się pechowo zorientujemy na etapie dachu, to koszty wzrosną dwukrotnie. Jak zapomnimy o łazience, to czy jednak ponosimy koszt tej porażki, czy stawiamy toy toya w ogródku na wiele lat? Po ostatnim pytaniu już lepiej – interesują się i udają, że rozumieją. Na zakończenie dodałem, że popołudniu będą ze mną programować. Nie uwierzyli...

Poprosiłem o wykonanie prostego zadania. Gdyby ktoś nie pamiętał, przypomniałem zasady. Proszę oszacować czas (koszt) pomnożenia pisemnego na kartce dwóch liczb, pierwsza ma 4 cyfry, druga 3 cyfry (wymagania biznesowe). Nie pamiętam, jakie czasy padły, ale poprosiłem o wykonanie działania. Wykonanie średnio +50% do czasu zadeklarowanego. Mój komentarz był taki, że klient, w domyśle: oni, jest bardzo niezadowolony. Lekcja uczy, że programowanie wymaga czasu. Presją i eskalacją nie przyspieszą procesu.

Powtarzamy ćwiczenie.

Wszyscy doświadczeni „programiści” przezornie dorzucają +50% i jeszcze trochę na zapas. Odsłaniam nowe działanie do wykonania. Tym razem zamiast cyfr od 1 do 5, przeważają 5 do 9. To bardziej skomplikowane. Wszyscy popłynęli oczywiście z czasem. Zdarzyły się też błędy w wynikach. Lekcja nr 2 uczy, że wymagania muszą być precyzyjne.
Nie ma nic oczywistego, niczego nie możemy się domyślać.

Teraz wszyscy już pewni swego. Olbrzymie zaangażowanie, ekscytacja, powtarzamy ćwiczenie. Sam żartuję, że teraz chyba już wyszacują dobrze. Uczciwie wykorzystałem wszystkie możliwe cyfry. Zaczynamy. Obserwuję, co się dzieje i tak mniej więcej, kiedy wszyscy są w okolicy połowy obliczeń, powiedziałem: „Wiecie co, pomyliłem się w wymaganiach, jedna cyfra to 4 zamiast 6”, oczywiście w pierwszej kolumnie od prawej. W zadeklarowanym czasie nikt sobie nie poradził, a w rozwiązaniach przygotowanych w zdenerwowaniu na próżno było szukać poprawnego wyniku. To nieprzemyślane wymagania, zmieniające się w trakcie projektu. Trzeba ich unikać, ale będą się zdarzały. Jednak ważne, żeby rozumieć konsekwencje. „Przecież to tylko jedna cyfra” – nigdy więcej nie usłyszałem już takich komentarzy.

Uff... wygrałem. Poprosiłem o podobną edukację mojego zespołu z ich strony. Tydzień później spora reprezentacja spędziła wiele godzin, pracując w różnych obszarach operacji finansowych, aby poznać ich problemy życia codziennego. Efekt był fenomenalny. Zmieniliśmy listę zadań. Priorytet otrzymały zadania ważne, a nie te zgłoszone osoby, które głośno krzyczą. Udrożnienie całego systemu zajęło blisko rok, ale w atmosferze przyjaźni i współpracy. Można?

W HL Tech każdy pracownik obowiązkowo spędza tydzień w Bristolu na początku pracy. Przez pierwsze trzy dni niemalże nie ma prawa rozmawiać o IT. Uczymy się, jak działa biznes, jakie są ryzyka biznesowe, skąd pochodzą nasze wynagrodzenia. Każdy pracownik musi wiedzieć, jaka jest jego rola w podstawowej działalności firmy. Nie traktujemy IT odrębnie.
Zaangażowanie, traktowanie firmy jak swojej własnej, jest kluczowe. Osoby, których najważniejszym zadaniem jest odbicie karty w pracy i wykonanie odtwórczych zadań, tu się nie odnajdą.

Kultura, procesy, bagaż historyczny

Nie bójmy się zmian. Kolejna ciekawa historia, którą dobrze zapamiętałem, świetnie to obrazuje. Klientem jest duża instytucja państwowa. Jedno z pierwszych spotkań, początki, mały zespół, mam przyjemność uczestniczyć nietypowo w roli analityka. Pani naczelnik opisuje, co trzeba zrobić, żeby... szczegóły są naprawdę zbędne:

„Szanowni Państwo, ale ten proces jest zupełnie bez sensu, pochodzi z czasów, kiedy nie było komputerów. Może go zmienimy?”.

W tle przypomina mi się wykład ze studiów o strategii win-win. Przecież mógłbym dodać do wyceny kilkaset tysięcy (proces skomplikowany) i przejść dalej, ale jednak chcę zrobić dobry produkt, coś, co będzie służyło wszystkim ludziom w Polsce, proponuję uproszczenie. „Nie da się” – słyszę – „tak jest w przepisach”. Odpowiadam: „A w jakich? Czy możecie podać, gdzie to jest zapisane? Kto z Państwa wie?” Pada uwaga: „Pani Zosia będzie wiedziała”. Proszę o przerwę. Nie odpuszczam! Ściągnijcie panią Zosię. Mija 20 minut. Jest: „Aaa, robimy tak od zawsze. Jak zaczynałam pracę, to już tak robiliśmy, ale na to nawet rozporządzenia nie ma”.

Ręce opadają. Myślicie, że to koniec? Kilkadziesiąt minut później analogiczna sytuacja. Wołamy pana Kazia. Dumny prezentuje przepis ustawy z 1968 r., a mówimy w kontekście centralnego systemu komputerowego projektowanego w XXI wieku, który nigdy nie powinien odzwierciedlać papierowej logiki. Walczę dalej: „Drodzy Państwo, ale mamy inne czasy, zmieńmy ten proces na nowocześniejszy”. Przerwali w pół zdania: „Ale to trzeba ustawę zmieniać!”. Odpowiedziałem: „ A ile to kosztuje? Bo chyba mniej niż dostosowanie systemu. Nie wspominając o tysiącach godzin urzędników i obywateli, którzy będą korzystać z przestarzałego procesu”.

Kiedy system był wdrażany byliśmy po dwóch zbiorczych zmianach ustaw, takich rozmów mieliśmy dziesiątki, ale skończyliśmy z sukcesem. Gdyby którykolwiek z analityków odpuścił chociaż na chwilę, to takie zawahanie kosztowałoby każdorazowo kilkadziesiąt tysięcy złotych i podobną sumę każdego roku użytkowania systemu. Pomnożone przez liczbę procesów, mamy szkołę lub kawałek drogi.

Innowacyjność

Hargreaves Lansdown w 1981 r. zainwestował pierwsze zarobione pieniądze w komputery osobiste. W czasach, kiedy konkurencja prowadziła księgowość funduszy inwestycyjnych w zeszycie w kratkę, a klientów szukała w książkach telefonicznych, byliśmy firmą, która zyskiwała przewagę każdego dnia. Do dziś rynek „private pension”, po naszemu: trzeci filar emerytalny, należy w ok. 40% do nas. 30 lat temu firma była zarządzana w sposób, który dziś szumnie określilibyśmy mianem „IT driven” tylko dlatego, że ktoś wysłuchał argumentów za i przeciw i podjął świadomą decyzję. Nie była to decyzja łatwa, bo jeden komputer kosztował tyle, ile mały samochód.

Oczywiście odważne decyzje niosą ze sobą duże ryzyko. Nie zachęcam do ryzyka ponad miarę, ale ile razy nie pozwala się pracownikom na wprowadzenie ich pomysłów? Ludziom, którzy znają najlepiej proces, bo pracują z nim codziennie.

Ile razy zabijamy genialne pomysły, bo „w grupie” korporacyjnej nie wolno czegoś zrobić? Bo w kulturze kraju, z którego pochodzi firma, coś może być źle przeczytane – a wystarczy chwilę porozmawiać i wyjaśnić.

Ku przyszłości

Zaczęliśmy od współpracy z klientem i współpracy z biznesem. Dotknęliśmy trochę kwestii relacji z pracownikami czy kwestii doboru narzędzi. W każdym z tych obszarów można pójść na kompromis, ale tylko pod warunkiem, że jest to świadoma decyzja. Inaczej rozpocznie się powolny rozkład organizacji. Nie wolno odpuszczać, rezygnować z tego, co jest ważne, ulegać otoczeniu. To moja dewiza, którą staram się dzielić ze współpracownikami.

Te poglądy to wypadkowa charakteru, wychowania, 15 lat doświadczenia zawodowego w różnym otoczeniu, strefach geograficznych, z różnymi kontrahentami i zespołami, ale również wpływ kilku mentorów. Jeden z nich, z zawodu prezes, podpowiedział, żeby uzupełnić edukację we właściwym momencie i rozsądnie doradzał mi przed podjęciem trudnych decyzji dotyczących kariery. Inny, dla którego nie istniało słowo: porażka, pokazał, że można dać szansę – miałem szansę sprawdzić, czy uda się nie popełniać błędów, które obserwowałem wcześniej u swoich przełożonych. Jeszcze inna wyjątkowo zimna postać utwierdziła mnie, że warto się odważnie rozpędzić, zamiast od czasu do czasu podbiegać do przodu, myśleć prosto i nie bać się decydować.

Mam okazję pracować w Hargreaves Landsdown, firmie, która dokładnie zna opisaną odwagę zawodową. W centrali firmy w Bristolu każdy z ponad tysiąca pracowników traktuje firmę jak swoją własną, jest zaangażowany i zrezygnuje ze swojego pomysłu tylko wtedy, jeżeli w trakcie dyskusji wypracuje z zespołem jeszcze lepsze rozwiązanie. Jednym z takich pomysłów Dave’a Daviesa było stworzenie HL Tech w Polsce, jako ramienia technologicznego. Dokładnie rok od rozpoczęcia projektu jesteśmy w warszawskim biurowcu WarsawSpire, grupa zapaleńców żądnych nowoczesnych technologii i rozwijania biznesu, powiększająca się z każdym tygodniem. Nasi programiści i testerzy kończą przygotowanie narzędzi, analitycy wspólnie z koleżankami i kolegami z brytyjskich zespołów operacyjnych określają pierwsze zadania. Wszyscy się cieszą z kultury start-upu i są gotowi do ciężkiej pracy z uśmiechem na twarzy.

Szanowni Państwo, życzę odwagi, nie poddawajcie się, rozmawiajcie prostym językiem, nie bójcie się krytyki. Te małe rzeczy i te kilka przykładów przekładają się na wielkie sukcesy i pieniądze. Myślimy, że tylko wielkie inicjatywy tak mogą? Polecam historie małych start-upów, które swoją odwagą i prostotą wiele osiągnęły. Oczywiście pojawią się komentarze, że na początku w małej organizacji jest zawsze łatwiej lub że nie możemy akceptować zbyt dużego ryzyka. Zgoda, ale tym bardziej doceńmy te małe sprawy. Pozwólmy ludziom pracować, wysłuchajmy ich pomysłów. Znów proste slogany? To czemu w swojej firmie wciąż słyszysz: „IT nie rozumie biznesu” lub „biznes nie rozumie IT”?

Michał Głowiński na jednym z pięter Warsaw Spire, w którym będzie pracować HL Tech.

Michał Głowiński na jednym z pięter Warsaw Spire, w którym będzie pracować HL Tech.

O Autorze

Michał Głowiński spędził całe swoje życie zawodowe w IT. Połowę tego czasu poświęcił na rozwój oprogramowania w sektorze finansowym, a drugą połowę wdrażał i używał oprogramowania od dostawców. Do niedawna odpowiadał za portfolio aplikacji Generali Assistance w 33 krajach na świecie. Wcześniej pracował w informatycznym ośrodku IT pracującym dla Ministerstwa Spraw Wewnętrznych, budując od zera 130-osobowy, sprawnie działający departament rozwoju oprogramowania – co było swego czasu sensacją. Pracował w dużych organizacjach finansowych Citigroup i Aviva. Karierę zaczynał w ComArch, jednym z czołowych dostawców oprogramowania.

Ukończył studia magisterskie z inżynierii oprogramowania na Politechnice Poznańskiej oraz MBA na Akademii Koźmińskiego.

Poza pracą uwielbia świeże powietrze. Zimą spędza każdą wolną chwilę na snowboardzie, a latem bierze udział w biegach przełajowych z przeszkodami. Często wraca za kierownicę samochodu rajdowego.

Od pół roku jest dyrektorem zarządzającym HL Tech. Firma usług finansowych Hargreaves Lansdown z siedzibą w Bristolu w Wielkiej Brytanii na początku 2017 r. otworzyła w Polsce swój oddział zajmujący się rozwojem oprogramowania na wewnętrzne potrzeby.

Oddajemy głos Michałowi Głowińskiemu, aby mógł przedstawić przepis na relacje IT z biznesem, co w jego przekonaniu jest wyróżnikiem konkurencyjnym jego organizacji.

„W HL Tech zatrudniamy już ponad 30 osób, a do końca roku będzie nas przynajmniej 50. Co nas wyróżnia? Perfekcyjna współpraca IT z biznesem. Spróbuję udowodnić, że kluczem jest walka o dobrą relację pomiędzy oboma światami, pomiędzy poszczególnymi zespołami. Menedżerowie często odpuszczają tę dbałość: a to praprzyczyna porażek projektów i wojny między IT a biznesem” – mówi Michał Głowiński.