Zarządzam zdolnością firmy do wypełniania zobowiązań kontraktowych

Z Piotrem Tencerem, dyrektorem Software Engineering i szefem Warsaw Technology Center w IGT w Polsce, rozmawiamy o:

• realizowanych projektach przez tzw. grupę wdrożeniową, rozwoju kariery w IGT,
• zapewnieniu odpowiednich zasobów do planowanych projektów, zmianie w sposobie ich realizacji,
• zarządzaniu produktywnością grup oraz narzędziach, które są dziś niezbędne w pracy zespołów IGT.

W Warsaw Technology Center pracuje ok. 300 pracowników, w tym niemal 200 programistów. Wszyscy podlegają Tobie?

Sprawuję nadzór organizacyjny nad centrum technologicznym, zlokalizowanym w Warszawie. Część z naszych pracowników (między innymi: testerzy oprogramowania, grupa produktowa, analitycy biznesowi, administracja) ma swoich bezpośrednich przełożonych w innych krajach, czasem na innych kontynentach, dlatego niezbędny jest ktoś na miejscu, kto zadba o codzienny komfort ich pracy. Natomiast w sposób bezpośredni podlega mi ponad 300 osób – są to inżynierowie oprogramowania, pracujący na całym świecie, w tym oczywiście w Polsce.

Czym dokładnie zajmuje się grupa wdrożeniowa?

Pamiętam, jak mój nowy szef zadał mi kiedyś podobne pytanie – Piotrze, czym ty się zajmujesz na co dzień? Odpowiedziałem, że są to głównie trzy rzeczy. Po pierwsze, zarządzam zespołem w taki sposób, abyśmy mogli dostarczyć w terminie projekty, które mamy w planie. To jest nasza teraźniejszość.

Po drugie, odpowiadam za przyszłość zespołu, czyli rozwój grupy wdrożeniowej. Dotyczy to m.in. wsparcia w rozwoju kariery pracujących w tym zespole inżynierów. Wiadomo, że są to osoby, które muszą, ale przede wszystkim lubią się uczyć. My zaś musimy im tę możliwość zapewnić, aby chcieli dla nas pracować.

Trzeci obszar, to przyszłość firmy. Zarządzam zespołem w taki sposób, aby ta liczna grupa osób była przygotowana na to, że gdy w ofercie IGT pojawią się nowe rozwiązania, to będzie ona gotowa realizować oparte na nich wdrożenia. W związku z tym, mój zespół włącza się w pracę nad nowymi produktami, wnosząc swoje doświadczenie z realizacji różnych projektów.

Na tym głównie polega moja praca. Można powiedzieć w skrócie, że zarządzam zdolnością firmy do wypełniania zobowiązań kontraktowych, w tym stosunkiem posiadanych zasobów do oczekiwań, związanych z realizowanymi projektami.

Bardzo dobrym podsumowaniem pracy menedżera jest słynny cytat: „Leadership is not about being the best. Leadership is about making everyone else better”. Tak też postrzegam swoją rolę. Pomagam członkom zespołu osiągnąć sukces, bo jeśli oni go osiągną, to odniesie go też firma.

Czy te 300 osób w Twoim zespole również jest rozrzuconych na sześciu kontynentach?

Dokładnie to na pięciu. To „geograficzne rozproszenie” jest celowym działaniem biznesowym, ale wynika też z naszej historii. Na początku firma IGT stawiała mocno na realizację projektów w siedzibach klientów. Dziś to się trochę zmieniło. Musimy być blisko loterii, które funkcjonują w różnych strefach czasowych, praktyczne jest zatem, by nasi pracownicy byli w niedalekich lokalizacjach. Dlatego rozłożyliśmy nasze centra technologiczne w tak wielu różnych miejscach na świecie. Nasze projekty nie są obecnie prowadzone w siedzibie klienta, są w dużej mierze realizowane zdalnie, ale nadal pracujemy w tym samym trybie czasowym, co współpracujące z nami loterie.

Czy to znaczy, że zespoły pracują nad wspólnymi projektami, tyle że Polacy przekazują niedokończone zadania do Stanów Zjednoczonych, a te z kolei do kolegów w Azji?

Nasza strategia zakłada, że każdy klient wspierany jest najczęściej z dwóch lokalizacji. Staramy się również tak organizować pracę grupy wdrożeniowej, aby co najmniej jeden z zespołów obsługujących danego klienta znajdował się w jego strefie czasowej. Na przykład nasz zespół w Finlandii nie jest liczny, ale za to jest najbliżej klienta. Są na tak zwanej pierwszej linii. Druga grupa pracuje w Warszawie.

Jak planuje się potrzebne zasoby do zaplanowanych prac? Wdrożenia nowych wersji systemów loteryjnych IGT raczej nie następują w regularnych odstępach czasu.

Najważniejsze jest to, aby przełożyć nasze możliwości na plan biznesowy. Najlepiej ustalić go z naszym zespołem, zajmującym się rozwojem biznesu. Jego pracownicy wiedzą, gdzie toczą się przetargi, jaka jest szansa na ich rozstrzygnięcie i kiedy powinny się zakończyć.

W kolejnym kroku przypisujemy każdemu projektowi priorytet. Ważne jest to, aby uzgodnić ten priorytet z innymi działami, nie tylko w ramach zespołu technologicznego.

Dzięki temu każdy w organizacji wie, jaka jest lista projektów, na których się skupiamy.

Wtedy zaczyna się to, co lubię najbardziej – matematyka. Możemy policzyć mniej więcej jakie – w każdym z tych projektów – będzie zapotrzebowanie na kompetencje i liczbę członków, oddelegowanych do nich zespołów. Kiedy już to wiemy, są dwie strategie postępowania.

Po pierwsze, możemy dostosowywać działania do posiadanych zasobów. Wówczas próbujemy zmienić harmonogram projektów, dla których nie mamy wystarczających zasobów, ewentualnie w ogóle z nich zrezygnować. Drugie podejście, to ustalenie ze zleceniodawcami każdego z projektów, że zwiększamy budżet na ich realizację i zatrudniamy dodatkowe osoby.

Zazwyczaj są to zewnętrzni konsultanci zatrudniani na czas projektu. Rdzeń zespołu pozostaje zaś stały i znajduje się w organizacji. Dzięki temu nasi pracownicy mają poczucie kontroli nad całością wdrożenia.

Która metoda zazwyczaj wygrywa?

Mieszana. Najważniejsza część analizy dotyczy ustalenia, które projekty i w jakiej kolejności będą przez nas realizowane. Po tym etapie wiemy co – jako grupa wdrożeniowa – mamy do zrobienia.

Oczywiście, życie jest zmienne i pełne niespodzianek (śmiech). Niektóre przetargi wygrywamy, innych nie. Jedne projekty są realizowane w terminie, inne – nie z naszej winy – przesuwane. Tej zmienności musimy się podporządkować. Pomaga w tym elastyczne działanie.

A propos dostosowywania zasobów do potrzeb. Produktywność jest dziś – jak mówi wielu moich rozmówców – swego rodzaju Świętym Graalem w IT. Da się nią jakoś zarządzać?

Określenie Święty Graal bardzo pasuje do produktywności. Wszyscy jej szukają, ale nikt nie znajduje. Dla każdego menedżera wyższego szczebla produktywność wydaje się najprostszą rzeczą. Każdy chciałby mieć projekt zrealizowany taniej, szybciej, lepiej.

Wiadomo, że mamy 5 aspektów zarządzania projektami, które możemy zmieniać w miarę potrzeb. Są to: harmonogram, liczba godzin poświęconych na projekt, jego rozmiar, dostarczona jakość i produktywność. Z tych pięciu rzeczy, tylko zwiększenie produktywności pozwala na jednoczesną poprawę pozostałych czterech. W innym przypadku trzeba zawsze coś poświęcić.

Są oczywiście narzędzia, które pomagają zwiększyć produktywność. My w jednym z zespołów używamy np. platformy Blue Optima. Jest to dobre narzędzie, ale trzeba pamiętać, że najłatwiej jest go użyć, gdy tworzymy jakiś produkt od początku.

Tymczasem w grupie wdrożeniowej w znacznym stopniu realizujemy wdrożenia już istniejących produktów. Mamy sporo komponentów, bardzo zróżnicowanych, korzystających z naprawdę szerokiej gamy technologii.

Trudno jest zatem ujednolicić realizowane projekty. A każde narzędzie usprawniające wymaga standaryzacji. Stąd problem z zastosowaniem rozwiązań optymalizujących naszą produktywność.

W jaki więc sposób zarządzacie produktywnością w grupie wdrożeniowej?

Staramy się robić to poprzez eliminację strat w procesie tworzenia oprogramowania. Wiadomo przecież, że gdy pojawia się błąd, ktoś musi go naprawić, przetestować „łatkę”, a następnie wdrożyć na produkcję. Stworzyliśmy nawet odpowiednie hasło: wdrażamy systemy, a nie defekty. Staramy się je jak najwcześniej usunąć, a najlepiej zapobiegać ich powstawaniu.

W związku z tym, że używamy tak dużo zróżnicowanych technologii, trudno jest wybrać jeden model, który by nas wsparł. Podchodzimy zatem do problemu od strony procesu dostarczania projektu. Oczywiście na bieżąco go optymalizujemy, bazując na uwagach od zespołu. Jeśli ktoś uważa, że proces mu przeszkadza, to nie znaczy, że to on jest „problemem”, tylko należy poprawić proces.

Kiedyś DevOps miał sprawić, że będzie mniej błędów. Ci sami ludzie mieli rozwijać i utrzymywać dostarczane oprogramowanie, a nie chcieli przysparzać sobie zbyt dużo dodatkowej pracy w tym drugim etapie.

DevOps de facto wprowadził automatyzację w wielu procesach wytwarzania oprogramowania. Przykładem może być CI/CD (Continuous Integration/Continuous Delivery – przyp. red.). Jest to w zgodzie z moją opinią, że pracownicy w dziale jakości powinni zajmować się rzeczami ciekawymi, a nie nudnymi.

Jak zautomatyzujemy nudne, ale konieczne do wykonania zadania, to pracownicy mogą zająć się czymś ciekawszym. Być może nawet odnaleźć ewentualne błędy w projekcie, które mogłyby przeszkodzić w zrealizowaniu go o czasie i w założonym budżecie. W jakości mamy termin: testowanie eksploracyjne. Oznacza on, w dużym skrócie, swego rodzaju formę „przejścia się po aplikacji” w poszukiwaniu błędów, co często jest najefektywniejszą metodą.

Tego typu działania znacząco wpływają też na wspomnianą produktywność.

Czy w IGT zautomatyzowano już część, tych najnudniejszych procesów?

Tak. Rozwijamy np. narzędzia do automatycznego testowania. Choć bagaż technologii nie pozwala nam wybrać jednego rozwiązania dla tak bardzo zróżnicowanych produktów. Wykorzystujemy więc kilka metod automatyzacji testów. Niekiedy są one wręcz przeznaczone dla konkretnego klienta. Automatyzacja dotyczy także procesu CI/CD.

Myślicie o wykorzystaniu narzędzi, takich jak Git- Hub Copilot czy Amazon Code Whisperer?

Pracujemy nad metodologią zastosowania tych technologii. Jest to gorący temat dla wszystkich zespołów deweloperskich. Zastanawiamy się, w których miejscach możemy te narzędzia zastosować. Ale mniej patrzymy na modę, a bardziej na potencjalne zwiększenie produktywności.

Nasi pracownicy mają możliwość proponowania nowych narzędzi, które ich zdaniem pozwolą im bardziej efektywnie pracować. Zwiększa to elastyczność środowiska pracy, w którym funkcjonują. Większa elastyczność idzie zaś w parze z większą produktywnością.

Większość pracowników IT pracuje zdalnie i niespecjalnie chce wrócić do biura. Czy to dla Was problem? Jak oceniacie ich produktywność?

Kiedy zaczynałem swoją pracę w IGT wiele lat temu, pracowaliśmy w formule kolokacji. Realizowaliśmy projekt w konkretnym miejscu, dla konkretnego klienta. Do tego miejsca wysyłani byli pracownicy, tworząc fizycznie lokalny zespół pracujący nad danym projektem.

Z biegiem lat przestaliśmy kolokować zespoły. Łączyliśmy w grupy projektowe ludzi z dwóch lub więcej biur IGT i tym samym siłą rzeczy praca naszych rozproszonych zespołów stała się zdalna. W organizacji przyjęła się praca w tym modelu. Doświadczenia te bardzo przydały się, gdy przeszliśmy całkowicie na pracę zdalną w czasie pandemii.

Amazon jakiś czas temu przedstawił badania na ten temat. Wynikało z nich, że produktywność pracowników pracujących zdalnie się nie obniżyła. Dowiodły one jednak, że jednocześnie spadła ich kreatywność. Ludzie najwięcej pomysłów mają, kiedy pracują wspólnie, a nie, gdy widzą się przez chwilę na kolejnych wideokonferencjach.

Jak to wygląda w IGT?

Po pierwsze, kiedyś biuro było miejscem pracy. Teraz jest miejscem spotkań, gdzie ludzie przychodzą po to, aby porozmawiać i pobudzić kreatywność, której utraty się obawiamy. Jak zmieni się funkcja biura, to pracownicy będą chętniej do niego przychodzić. Jesteśmy właśnie na etapie wyboru nowej siedziby lub zmiany aranżacji obecnej. Na pewno zadbamy o to, by było więcej przestrzeni na spotkania zespołów.

Po drugie, wyzwaniem jest zbudowanie więzi z firmą, pracowników pracujących zdalnie. Widzieliśmy to na przykładzie tych, których zatrudnialiśmy w pandemii. Dlatego dziś, gdy nowa osoba przychodzi do pracy w IGT, staramy się ustalić, w jakie dni pojawi się w biurze, aby miała okazję spotkać się i pracować z osobami, które mogą przekazać jej swoją wiedzę.

Na czym dokładnie polega praca Waszego zespołu?

Pracujemy nad wdrożeniami u klientów i wykorzystujemy nabyte doświadczenia, współpracując z grupą, odpowiedzialną za rozwój naszych produktów. To działa w dwie strony. Do nas również przychodzą jej członkowie po radę, na przykład czy to, co proponuje zespół architektów i dział rozwoju, będzie dobrym rozwiązaniem z punktu widzenia wdrożenia.

Osoby z mojego zespołu – jeśli nie realizują jakiegoś projektu – pracują nad rozwojem nowych produktów. Dzięki temu uczą się nowych technologii. Pozwala mi to lepiej zarządzać zespołem i zaspokajać „głód” wiedzy. Nawet jeśli ktoś jest zaangażowany przez jakiś czas w bardziej skomplikowany projekt, to później ma okazję skorzystać ze swoich doświadczeń i zająć się nowymi rzeczami, pracując z najnowszymi technologiami.

Jak planuje się w takim inżynierskim zespole ścieżkę kariery?

Mamy dwie ścieżki kariery – bardziej techniczną, tzw. Professional, i tzw. Management, związaną z kierowaniem zespołami. Pojawiają się też szanse przejścia do innego zespołu w ramach IGT, np. do architektury.

Możliwości rozwoju są bardzo zróżnicowane. Często pracownikom opowiadam historię, że u nas jest jak na peronie, na który podjeżdżają pociągi. Każdy oferuje możliwość dokonania zmiany w karierze. Wiadomo mniej więcej, gdzie on jedzie. Ale też jest niewiele czasu na decyzję, czy do niego wsiąść, czy nie. Muszą również pamiętać, że na naszej „stacji” nie ma ściśle określonego rozkładu jazdy. Nie wiadomo więc, kiedy pojawi się kolejny skład i dokąd nas zabierze.

Jaki jest tego powód?

To skutek tego, do czego doprowadziliśmy my wszyscy pracują- cy w szeroko pojętym IT. Dobrze podsumowuje to stwierdzenie Oscara Wilde’a – „Biurokracja rozszerza się, aby zaspokoić potrzeby rosnącej biurokracji”. Stworzyliśmy tyle technologii, narzędzi i języków, że teraz przydałby się ktoś, kto pomoże nam nad tym wszystkim zapanować.

Kiedyś IGT pracowało nad podziałem dużych, monolitycznych systemów loteryjnych, na mniejsze części, które można w sposób dużo bardziej elastyczny wdrażać. Docelowo miały być też udostępniane w chmurze. Czy projekt ten jest kontynuowany?

Tak. Mamy wielu klientów, u których wdrażane rozwiązania są mocno dostosowane do konkretnych wymagań. Technologii, na których bazują, jest równie dużo. Dlatego chcemy stworzyć nieco bardziej zarządzalne moduły naszego oprogramowania. Każdy dotyczący konkretnego produktu, który odpowiada na biznesowe potrzeby klienta.

Ostatnio miałem rozmowę o Developer Experience, w kontekście dostarczania programistom, aby ułatwić im pracę, tzw. platform inżynieryjnych. Czy ich używacie?

Zastanawiamy się nad ich użyciem. Wielość technologii generuje mnogość narzędzi. Jeśli nasze produkty zorganizujemy w bardziej spójne elementy, to będziemy mogli wskazać członkom zespołu, że oto mają dostęp do przeznaczonej dla konkretnego produktu, platformy narzędziowej. Idealnie byłoby, gdybyśmy mogli zrobić jedną platformę dla wszystkich produktów, języków i technologii, oferowanych w naszym portfolio.

Co taka platforma inżynieryjna powinna zawierać?

Mogą być w niej zawarte wszystkie narzędzia, które służą danemu zespołowi do wytworzenia produktu końcowego. Może być więc czysto inżynieryjna, ale równie dobrze mogą się na niej znaleźć inne rozwiązania i usługi wspomagające pracę zespołu programistów. Za wcześnie jest jednak, aby mówić o szczegółach.

Czy jakiś klient dokonał już migracji na te nowe, modułowe wersje rozwiązań IGT?

Generalnie nie tworzymy produktu dla niego samego. Jak już w niego inwestujemy, to zawsze stoi za tym konkretny projekt i klient. Tak więc mamy już za sobą kilka wdrożeń rozwiązań chmurowych w Stanach Zjednoczonych i w Europie. Zazwyczaj, gdy klient szuka sposobu na rozbudowę oferty, proponujemy mu gotowy moduł odpowiadający na tę potrzebę.

W efekcie nasze projekty z wdrożeniowych będą przekształcać się bardziej w integracyjne. Główny nacisk kładziony będzie na integrację istniejących, samodzielnych i w pełni funkcjonalnych produktów.

Zmiana podejścia do projektów rodzi też nowe wyzwania. W związku z tym będą potrzebne nowe kompetencje, tak jak kiedyś stało się z DevOpsem.