IT i biznes: Warto nie odpuszczać w dążeniu do porozumienia

Model HL Tech

W HL Tech od początku obraliśmy kurs na wzmocnienie sprawności IT. Odrzucamy model, w którym biznes inicjuje, a IT jedynie realizuje. HL Tech aktywnie wspiera Hargreaves Lansdown w kreowaniu nowoczesnych narzędzi biznesowych. Zarząd firmy zdecydował, że w Polsce znajdziemy najlepszych ekspertów, którzy zrewidują rozwiązania w Bristolu, zaplanują i wdrożą usprawnienia, a następnie będą rozwijać i doskonalić systemy. Takie podejście pozwala nam tworzyć rozwiązania, które będą wzorem dla konkurencji. Koncepcję IT jako centrum kosztów u nas wyeliminowano.

Model działania HL Tech

Współpraca IT i biznesu jako partnerów, a nie zleceniodawcy i wykonawcy. Przykładem jest aktywne współtworzenie narzędzi biznesowych przez IT.

Ten model pracy motywuje specjalistów IT. Daje im szersze pole manewru niż w wielu firmach, realny wpływ na projekty, wybór technologii i wizerunek firmy. W efekcie dostarczają rozwiązania wysokiej jakości, satysfakcjonujące biznes, co umacnia dalszą współpracę. Te założenia nie są wyjątkowe, więc dlaczego nie zawsze przynoszą oczekiwane rezultaty?

Ryzyko przeoczenia

Pamiętaj: W każdym modelu współpracy, brak jednego kluczowego elementu może zniweczyć całość. Nikt rozsądny i z dobrą intencją nie usunie tego elementu świadomie. Jednak łatwo przeoczyć szczegół, pozornie błahy detal… Pojedynczy element zaczyna subtelnie tracić na jakości, pociągając za sobą kolejne, aż finalnie cała konstrukcja przestaje działać.

W Hargreaves Lansdown (HL) systemy są podzielone na cztery główne grupy, każda bazująca na innej technologii, a niektóre języki programowania są już wiekowe. Można by przypuszczać, że HL Tech w Polsce ma za zadanie reanimować archaiczne systemy, ale to błędne przekonanie. Zdarza się, że kandydaci do pracy nie wierzą, że te systemy mogą być w tak dobrej kondycji. Wielu z nich ma za sobą karierę zbudowaną na zmianie pracy co 2-3 lata, z podobnym schematem: globalna firma w kłopotach, Polska jako źródło wykwalifikowanych specjalistów za konkurencyjną cenę, presja czasu, przepisanie systemu i jego utrzymanie. Dla programistów to często oznacza monotonię, a wkrótce potem cięcia kosztów i redukcję etatów. Gdy tłumaczę, że tym razem ma być inaczej, widzę sceptycyzm. Firma chce inwestować w najnowsze technologie i nie obawia się zmian, nawet tuż po wdrożeniu, jeśli dostrzeżemy potencjał ulepszeń.

Analogia Mercedesa

Wracając do porównań, czym porusza się HL? Moim zdaniem to zadbany Mercedes Benz W124. Lakier w idealnym stanie, silnik V8 osiągający 100 km/h w poniżej 6 sekund, komfort jazdy. Któż nie chciałby takiego klasyka w garażu? Jednak zdajemy sobie sprawę, że za kilka lat taki pojazd nie wjedzie do centrum miasta, a wkrótce potem zastąpią go pojazdy autonomiczne. Czym zatem jest oprogramowanie tworzone w HL Tech? Trudno o motoryzacyjny odpowiednik. Nie wiemy, co wyprze pierwszą generację samochodów autonomicznych. Może coś przypominającego pojazd z kreskówki o Jetsonach?

Mercedes Benz W124

Analogia do systemów HL – klasyka, zadbane, ale wymagające modernizacji w obliczu przyszłych wyzwań. Przykład: Ograniczenia wjazdu do centrów miast, rozwój autonomicznej jazdy.

Uwaga: Zwinne metodyki projektowe jako recepta na sukces to kolejny stereotyp, który u nas nie dominuje. „Chcemy być nowocześni, wdróżmy Agile”. Doskonale, ale ilu z nas wdrożyło Scruma w pełni? Często mamy jedynie „elementy” zwinnych metodyk. Kluczowe jest jednak całościowe wdrożenie, inaczej to nie zadziała. Znam firmy, które efektywnie wykorzystują zalety Agile, ale żaden z pracowników nie powie, że to proste. Często system szwankuje, bo ktoś zrezygnował, nie dokończył zadania, stworzył fuszerkę.

Sabotaż menedżerski

Jak jeszcze można zepsuć dobry proces i relacje? W swojej karierze byłem świadkiem, jak menedżerowie, obawiając się o posadę lub w ramach korporacyjnych intryg, sabotowali nawet najlepsze inicjatywy. Zaczyna się niewinnie: „nie odezwę się na telekonferencji”, „jest piątek”, „chcę do domu, po co ta dyskusja”, „wstydzę się zabrać głos po angielsku” itd. Unikajmy takich osób.

„Największym wrogiem postępu nie jest ignorancja, lecz iluzja wiedzy.”

Zapamiętaj: Jako młody kierownik projektu, zostałem zaproszony na telekonferencję przez dyrektora, z jeszcze wyższym dyrektorem (EMEA Global Director to tylko skrót jego tytułu). Byłem świadkiem sceny, w którą trudno mi było uwierzyć: jeden nie rozumiał, z czego się tłumaczy, a drugi nie chciał pomóc, tylko przerywał i krzyczał. Wykorzystując przerwę, wtrąciłem: „Może ja wyjaśnię?”. Zacząłem wprowadzenie, ale wyższy rangą mi przerwał: „Jest problem! Trzeba go rozwiązać! Nie działa!”.

Odparłem: „Proponuję układ: da mi Pan 3 minuty bez przerywania, a ja problem rozwiążę”. Gdy przechodziłem do sedna, ponownie mi przerwano. Powiedziałem: „Umówiliśmy się, że nie przerywamy. Problem, o którym mówimy, pojawił się dwa dni temu, wczoraj został rozwiązany, poprawka jest przetestowana i jeszcze dziś wieczorem awaryjnie trafi do użytkowników. Potencjalne straty finansowe, o których wszyscy mówicie, nie wystąpiły i nie ma powodu do wzajemnych oskarżeń”.

Cisza. Usłyszałem kilka razy „dziękuję za wyjaśnienia, wszystko jasne”.

Dialog i zaufanie

Wyobraźmy sobie, że takie sytuacje zdarzają się kilka razy w tygodniu. Ile moglibyśmy osiągnąć, gdyby nad tym zapanować? Jak wiele zależy od prostej komunikacji? Uczymy się tego na pierwszych lekcjach języka polskiego. Szkoda, że zapominamy o podstawach.

Gdzie tkwi problem? Gdy poprosiłem „dużego” dyrektora o nieprzerywanie, „mniejszy” podskoczył, chcąc odebrać mi telefon. Bał się otwartej rozmowy z przełożonym… To była cenna lekcja. Dodajmy do tego środowisko multikulturowe i dwa światy: IT i biznes. Wniosek: upewnijmy się wielokrotnie, czy druga strona nas rozumie.

Komunikacja w IT i biznesie

Klucz do sukcesu relacji. Przykładem jest unikanie niejasności i wielokrotne upewnianie się o zrozumieniu.

Innym razem przejąłem dział wsparcia IT dla biznesu za granicą. Historia tej relacji była długa i burzliwa, z brakiem zaufania po obu stronach. Liczba zgłaszanych błędów rosła lawinowo. Zespół IT jako przyczynę wskazywał ciągle zmieniające się, nieprzemyślane wymagania: „nie możemy zamknąć specyfikacji, a system musiał ruszyć, bo klient…”, słyszałem. Klasyka. Zaogniona sytuacja, brak dialogu, koszty bagatelizowane. Potrzebny był szybki „reset”. W trakcie lotu do europejskiej stolicy rozmyślałem, jak w jeden dzień zbudować zaufanie i nauczyć programowania. Następnego dnia, po krótkim wprowadzeniu, wyznałem szczerze, że nigdy nie doświadczyłem tak negatywnej atmosfery pracy i że to donikąd nie prowadzi. Oświadczyłem, że przeszłość mnie nie interesuje, ale na początek przedstawię, czym zajmuje się mój departament w Polsce. Szukałem prostej analogii, zrozumiałej dla wszystkich. Aby zbudować dom, potrzebna jest wizja. Za słaby fundament – mały dom, a błędy wykryte na etapie dachu podwajają koszty. Brak łazienki – to klęska. Po tym pytaniu dostrzegłem zainteresowanie i pozory zrozumienia. Na koniec dodałem, że po południu będą ze mną programować. Nie uwierzyli…

Programowanie na żywo

Zadanie było proste: oszacować czas (koszt) pisemnego pomnożenia dwóch liczb: czterocyfrowej i trzycyfrowej (wymaganie biznesowe). Czasy były zróżnicowane, ale poprosiłem o wykonanie działania. Średnio +50% do deklarowanego czasu. Zauważyłem, że klient (oni) byłby bardzo niezadowolony. Lekcja: programowanie wymaga czasu. Presja i eskalacja nie przyspieszą procesu.

1. Oszacowanie czasu mnożenia liczb.
2. Wykonanie działania pisemnego.
3. Porównanie deklarowanego czasu z rzeczywistym.

Warto wiedzieć: Powtórzyliśmy ćwiczenie.

Doświadczeni „programiści” przezornie dodali +50% i zapas. Zadałem nowe działanie, tym razem z trudniejszymi cyframi (5-9). Czas wykonania wzrósł, pojawiły się błędy. Lekcja nr 2: wymagania muszą być precyzyjne. Nic nie jest oczywiste, nie możemy się niczego domyślać.

Teraz pewni siebie, zaangażowani, powtórzyliśmy ćwiczenie. Zażartowałem, że teraz z pewnością dobrze oszacują. Użyłem wszystkich cyfr. Start. Obserwując ich pracę, mniej więcej w połowie obliczeń, powiedziałem: „Pomyliłem się w wymaganiach, zamiast 6 ma być 4 w ostatniej kolumnie”. W deklarowanym czasie nikt nie skończył, a w pośpiechu wyniki były błędne. To efekt nieprzemyślanych, zmieniających się wymagań. Trzeba ich unikać, ale będą się zdarzać. Istotne, by rozumieć konsekwencje. „Przecież to tylko jedna cyfra” – już nigdy nie usłyszałem takiego komentarza.

Udało się. Poprosiłem o podobną edukację mojego zespołu z ich strony. Tydzień później delegacja spędziła wiele godzin, poznając problemy operacji finansowych. Efekt był fenomenalny. Zmieniliśmy listę zadań, priorytetem stały się zadania ważne, a nie te zgłaszane przez najgłośniejszych. Udrożnienie systemu zajęło rok, ale w atmosferze współpracy. Można?

Bezsensowny proces

W HL Tech każdy nowy pracownik spędza tydzień w Bristolu. Przez pierwsze trzy dni niemal nie rozmawiamy o IT. Uczymy się biznesu, ryzyk biznesowych, źródeł naszego wynagrodzenia. Każdy musi znać swoją rolę w podstawowej działalności firmy. Nie traktujemy IT oddzielnie. Zaangażowanie, traktowanie firmy jak własnej jest kluczowe. Osoby, dla których praca to tylko odbicie karty i odtwórcze zadania, u nas się nie odnajdą.

Nie bójmy się zmian. Kolejna historia to ilustruje. Klientem była duża instytucja państwowa. Na jednym z pierwszych spotkań, w kameralnym zespole, uczestniczyłem jako analityk. Pani naczelnik opisywała proces, który… szczegóły są zbędne.

Ważne: „Szanowni Państwo, ten proces jest bez sensu, z czasów bez komputerów. Może go zmienimy?”.

Zmiana ustawy

Przypomniał mi się wykład o strategii win-win. Mogłem doliczyć do wyceny kilkaset tysięcy (skomplikowany proces) i przejść dalej, ale chciałem stworzyć dobry produkt, służący Polakom, więc zaproponowałem uproszczenie. „Nie da się” – usłyszałem – „tak jest w przepisach”. „W jakich? Gdzie to zapisano? Kto wie?”. „Pani Zosia będzie wiedziała”. Przerwa. Nie odpuszczam! „Sprowadźcie panią Zosię”. Po 20 minutach: „Aaa, tak robimy od zawsze. Jak zaczynałam pracę, już tak było, ale rozporządzenia nie ma”.

Pamiętaj: Ręce opadają. Koniec? Nie. Po kilkudziesięciu minutach analogiczna sytuacja. Wołamy pana Kazia. Prezentuje przepis ustawy z 1968 r., w kontekście systemu komputerowego XXI wieku, który nie powinien odwzorowywać papierowej logiki. Walczę: „Mamy inne czasy, zmieńmy proces na nowoczesny”. Przerwa: „Ale to trzeba zmieniać ustawę!”. Odpowiedziałem: „Ile to kosztuje? Chyba mniej niż dostosowanie systemu. Nie licząc tysięcy godzin urzędników i obywateli korzystających z archaicznego procesu”.

W trakcie wdrażania systemu dokonaliśmy dwóch zbiorczych zmian ustaw. Takich dyskusji były dziesiątki, ale zakończyliśmy sukcesem. Gdyby analityk ustąpił, wahanie kosztowałoby dziesiątki tysięcy złotych jednorazowo i rocznie. Pomnożone przez liczbę procesów – szkoła lub droga.

Inwestycja w komputery

Hargreaves Lansdown w 1981 r. zainwestował pierwsze zarobione pieniądze w komputery osobiste. Gdy konkurencja prowadziła księgowość funduszy w zeszytach, a klientów szukała w książkach telefonicznych, HL zyskiwał przewagę. Dziś rynek „private pension” (trzeci filar emerytalny) w 40% należy do nas. 30 lat temu firma była „IT driven”, choć tak tego nie nazywano. Ktoś wysłuchał argumentów i podjął świadomą decyzję. Trudną, bo komputer kosztował tyle, co mały samochód.

„Innowacja to dostrzeganie zmian jako szansy, a nie zagrożenia.”

Blokowanie pomysłów

Odważne decyzje niosą ryzyko. Nie zachęcam do ryzyka na wyrost, ale ile razy blokujemy pomysły pracowników, którzy najlepiej znają proces, bo z nim pracują na co dzień?

• Blokowanie pomysłów pracowników: strata potencjału innowacji.
• Obawa przed ryzykiem: stagnacja i brak rozwoju.
• Kultura korporacyjna hamująca inicjatywy: ograniczenie kreatywności.

Zauważ: Ile genialnych pomysłów zabijamy, bo „w grupie” korporacyjnej czegoś nie wolno? Bo w kulturze kraju firmy coś może być źle odebrane – wystarczy porozmawiać i wyjaśnić.

Kompromis i rozwój

Zaczęliśmy od współpracy z klientem i biznesem, poruszyliśmy relacje z pracownikami i dobór narzędzi. W każdym obszarze można pójść na kompromis, ale świadomie. Inaczej zacznie się destrukcja organizacji. Nie wolno rezygnować, odpuszczać ważnych kwestii, poddawać się presji otoczenia. To moja dewiza.

Podsumowując: Te przekonania są wynikiem charakteru, wychowania, 15 lat doświadczenia w różnorodnych środowiskach, strefach geograficznych, z różnymi kontrahentami i zespołami, oraz wpływu mentorów. Prezes doradzał mi w edukacji i trudnych decyzjach zawodowych. Inny mentor pokazał, że „porażka” nie istnieje i warto dawać szanse. Chłodny umysł utwierdził mnie, że warto działać odważnie, myśleć prosto i podejmować decyzje.

Startupowa kultura

Pracuję w Hargreaves Landsdown, firmie znanej z odwagi zawodowej. W Bristolu każdy z tysiąca pracowników traktuje firmę jak własną, angażuje się i rezygnuje z pomysłu dopiero po wypracowaniu lepszego rozwiązania z zespołem. Jednym z tych pomysłów Dave’a Daviesa było stworzenie HL Tech w Polsce, jako zaplecza technologicznego. Rok po starcie projektu, w Warsaw Spire, grupa entuzjastów technologii i rozwoju biznesu rośnie z tygodnia na tydzień. Programiści i testerzy kończą narzędzia, analitycy z brytyjskimi zespołami operacyjnymi definiują zadania. Wszyscy cieszą się startupową kulturą i gotowością do ciężkiej pracy z uśmiechem.