Lokalizacja projektu – historia pewnej przeprowadzki

Lokalizacja projektu ma wpływ na sam projekt. Określa czynniki środowiskowe organizacji, w której projekt funkcjonuje, takie jak warunki rynkowe, wpływy i problemy społeczne i kulturowe, ograniczenia prawne, względy finansowe (kursy walut, stopy inflacji itp.). Projekty IT realizowane są w różnych lokalizacjach w zależności od potrzeb. Z mojego doświadczenia wynika, że głównym kryterium wyboru lokalizacji jest budżet. Jeśli projekt wykonuje podwykonawca, często lokalizacja projektu jest w innym państwie. Jest również wiele innych powodów tego stanu rzeczy. Poza kosztami wytworzenia oprogramowania, które są różne w różnych lokalizacjach, istotna może być również dostępność ludzi o określonym profilu i łatwość ich zatrudnienia. Niemniej jednak nic nie jest na stałe i na zawsze, więc gdy w grę wchodzą pieniądze, podejmowane są często decyzje o zmianie.

Z tego co zaobserwowałem, lokalizacja projektu zmienia się zaskakująco często i nie jest to coś, a temat przenosin projektów w IT jest ogólnie przemilczany, tak jakby to była zawsze sytuacja wyjątkowa. Tymczasem w mojej karierze spotkałem się nawet z sytuacją, gdy projekt był przenoszony wielokrotnie, dlatego wpadłem na pomysł, aby podzielić się własnymi spostrzeżeniami.

Zacznę od historii, z którą dane mi było się osobiście zetknąć. Pod koniec artykułu podzielę się również swoimi przemyśleniami oraz dobrymi praktykami i generalnie sugestiami w postaci “checklisty” na co powinno się zwrócić uwagę. Zanim jednak opiszę historię pewnej przeprowadzki, usystematyzujmy niektóre rzeczy.

Pociąg ruszył…

Pomijając powód dla którego podejmowana jest decyzja o przenosinach projektu (a te naprawdę mogą być wielorakie), projekt o nazwie “przenosiny projektu” cechują dwa główne atrybuty, które rzutują na cały proces:

• jeśli projekt jest realizowany przez zewnętrznego dostawcę, od kogo wychodzi inicjatywa przeniesienia projektu: czy decyzję podjął klient, czy projekt chce przenieść dostawca;
• czy projekt jest przenoszony wraz z ludźmi do nowej lokalizacji, czy też ludzie nie są przenoszeni, a jednym z naszych zadań będzie zadbanie o transfer wiedzy, a może gdzieś po środku – przenosimy tylko część ludzi albo dokładamy do projektu kolejną lokalizację.

Lokalizacja projektu, z którym się zetknąłem, realizowanego dla klienta zewnętrznego, była w jednym z krajów Wspólnoty Niepodległych Państw. Łatwo było znaleźć kompetentnych ludzi do projektu, wyszkolonych w technologii jaka była wymagana. Ludzie też nie byli jakoś bardzo drodzy. Byli wręcz nawet dosyć tani i to był jeden z głównych powodów, dla którego projekt dla amerykańskiego klienta realizowany był się właśnie tam. Pewnego dnia jednak klient podjął decyzję, że nie do końca podoba mu się sytuacja polityczna w tym regionie i zakomunikował, że chce projekt przenieść do Polski, a konkretnie do Krakowa. Ponieważ jest zadowolony ze współpracy z ludźmi, chciałby przenieść projekt wraz z całym zespołem do nowej lokalizacji. Po krótkich negocjacjach dotyczących wyższych stawek dla nowej lokalizacji projekt “przenosiny projektu” wystartował początkiem 2018 roku. 

Zarządzanie zmianą

Rzeczą, za którą zabrano się w pierwszej kolejności, było przekonywanie ludzi do przeprowadzki. Jeśli się ma rodzinę (dzieci), drugi współmałżonek ma jakąś pracę, jest się zakorzenionym w danym środowisku, nie jest to łatwa decyzja. Do negocjacji zabrano się do tego fachowo. Stworzono tymczasową rolę ambasadora projektu, człowieka który pracuje w nowej lokalizacji, ale natywnie posługuje się językiem zespołu projektowego. Odbył podróż do zespołu i przekonywał, że jest OK. Wstępnie złożone propozycje finansowe ludzie jednak odrzucili. Trzeba było dołożyć trochę więcej, niektórym obiecano szybką ścieżkę kariery (od seniora do project managera w rok) albo zaproponowano pracę dla współmałżonka. Motywowano również tym, że praca w Schengen ma pewne plusy polegające na tym, że można bez przeszkód podróżować po całej Europie, opowiadano o zdrowym krakowskim powietrzu (?) i bliskości gór, oraz zapewniono wsparcie w przenosinach w postaci dodatkowego budżetu na start, zorganizowaniu wymaganych zezwoleń na pracę itd.

Problemem okazał się dosyć skomplikowany nasz system podatkowy, dlatego złożono obietnicę, że osoby będą miały niższy podatek ze względu na prawa autorskie. Ludzi przekonano i przenosiny ruszyły. Ale jeszcze zanim ruszyły okazało się, że jest problem, żeby zaakceptować ich (mocno ponad widełki) ostateczne stawki. Jeden z wyższych managerów nawet mocno się zdenerwował pensją zaproponowaną dla jednego z liderów. Jak już się uspokoił i udało się go przekonać, powrócił do swojego managerskiego pokoju tylko po to, żeby się zorientować, że ta stawka nie była dla lidera, tylko zaledwie mocnego-regulara-prawie-prawie-seniora. No ale jak już to się udało przeskoczyć tę drobną niedogodność przenosiny finalnie ruszyły.

Poszło bardzo sprawnie. W piątek zespół pracował jeszcze w starej lokalizacji, w poniedziałek już w nowej. Czyżby pełen sukces? No też nie do końca. Pierwszą niespodziankę zrobił urząd skarbowy, który z początkiem 2018 roku spowodował zatrzymanie programu praw autorskich. I nie była to zmiana prawa, ale tylko i wyłącznie zmiana interpretacji prawa istniejącego. Było obiecane, a nie ma. Zespół ostro podniósł temat, że został oszukany. Kolejną niespodziankę sprawili nowi pracownicy, którzy zostali zatrudnieni do projektu już w nowej lokalizacji. Okazało się, że coś co “stary” zespół nazywa Scrumem, nie ma nawet cienia podobieństwa to tego framework’u. Planowanie? Retrospektywa? Po co to komu? Jakiś backlog? Przecież robimy to, co każe klient. Dla większości relokowanych pracowników był to ich pierwszy projekt. Wydawało im się, że Scrum właśnie tak wygląda. Niestety szybko zrodziło to konflikty z nowymi osobami, którym zdarzyło się wcześniej pracować w czymś, co bardziej Scrum przypominało.

Co gorsze, okazało się, że wśród relokowanych osób tylko garstka jako tako posługuje się angielskim, reszta zna ten język bardzo słabo. “Stary” zespół jest hermetyczny i nie rozmawia z nowymi pracownikami, nie chce też im pomóc, bo nowi chcą robić pewne rzeczy inaczej niż oni robili do tej pory. Zwalił się jeszcze do tego klient z pretensjami, że zatrudnianie ludzi w nowej lokalizacji nawet w połowie nie idzie tak, jak to łatwo szło w starej. Dodatkowo, z powodu konfliktów, nowi zatrudnieni pracownicy dosyć szybko z projektu zaczęli uciekać, co również nie umknęło uwadze klienta.

Lessons learned z przeprowadzki

Odbyłem dosyć pogłębioną retrospektywę jak to wszystko poszło. Z zespołem projektowym, zarówno z pracownikami relokowanymi, jak i tymi przyjętymi do projektu już w nowej lokalizacji. Rozmawiałem z klientem. Wiele rzeczy wyjaśniliśmy sobie post factum. Coś zostało jeszcze naprawione. Projekt istnieje do dziś, z tarciem, ale jakoś idzie do przodu. Co mógłbym poradzić tym, którzy stają przed projektem “przeprowadzenia” projektu? Na początek rzeczy, które wydaje się, że i tak powinny być robione.

Więc zanim zabierzesz się do przeprowadzki:

• rozmawiaj z ludźmi, tak często jak to możliwe – przygotowuj ich do zmiany,
• zrób listę ryzyk – taką wg PMBOK Guide, zarządzaj nimi,
• zrób listę osób zaangażowanych w proces zmiany lokalizacji i następnie zdefiniuj ich odpowiedzialność wg RACI,
• bądź transparentny na ile się da z klientem, poinformuj go o spodziewanej prędkości zatrudniania w nowej lokalizacji, daj znać też jakiego może spodziewać się poziomu rotacji,
• sprawdź istniejącą dokumentację projektu (okaże się przydatna podczas transferu wiedzy – jeśli istnieje) i upewnij się, że dobrze wiesz jak wygląda proces dostarczania,
• upewnij się, że wiesz w jaki sposób jest zapewniona jakość w projekcie,
• mierz velocity jeśli stosujesz Scrum, lead time, jeśli masz Kanban, cokolwiek, co powie Ci jak pracuje zespół przed, w trakcie i po relokacji,
• powiedz klientowi, żeby spodziewał się, wahnięć w prędkości pracy zespołu – jest to normalne,
• upewnij się, że mierzysz satysfakcję klienta przed, w trakcie i po relokacji,
• upewnij się, że nowa lokalizacja projektu nie stwarza przeszkód prawnych, np. projekty wymagające dostępu do specyficznych danych mogą być prowadzone tylko w określonych lokalizacjach ze względu na ochronę tychże danych,
• rozmawiaj z ludźmi. To już było? Nie szkodzi, warto przypomnieć.

Teraz przypadki bardziej szczególne.

• Jeśli to Ty jako podwykonawca wyszedłeś do klienta z inicjatywą przeprowadzki:
  • upewnij się, że masz mocne argumenty, używaj języka korzyści i zysków dla klienta,
  • bądź gotów nawet na to, że w pierwszej kolejności klient będzie chciał zmienić wykonawcę, czyli Ciebie.
• Jeśli przeprowadzasz projekt z ludźmi:
  • upewnij się, że wiesz z jakimi ludźmi masz do czynienia, jeśli chodzi o ich kulturę, mentalność czy zdolności komunikacyjne,
  • zbierz argumenty, żeby ich przekonać do przeprowadzki,
  • przygotuj się na to, że będziesz być może potrzebował czasu na wyrobienie stosownych pozwoleń,
  • przeprowadzkę rób raczej nie w stylu “wszyscy na raz”, ale w mniejszych grupach – zmniejszasz wówczas ryzyko, że coś pójdzie nie tak, np. z nowej lokacji nie da się pracować z uwagi na nie w pełni dostosowaną infrastrukturę,
  • po przeprowadzce nie spocznij na laurach, tylko intensywnie rozmawiaj z ludźmi, bo wtedy wychodzi najwięcej problemów.

• Jeśli przeprowadzasz sam projekt, bez ludzi:
  • najpierw postaraj się sprawdzić jakie są relacje klienta z ludźmi z projektu,
  • rozważając nową lokalizację, sprawdź jak szybko da się tam zatrudniać ludzi,
  • dowiedz się coś o historii projektu oraz o architekturze i zastosowanych rozwiązaniach – pomoże Ci to zaplanować transfer wiedzy,
  • zaplanuj transfer wiedzy (technologie, proces, dokumentacja, dostępy, środowiska, terminy, architektura, wiedza tajemna) – najlepiej sprawdza się praca w parach, postaraj się, aby nowy zespół tak szybko, jak tylko się da, wypuścił nową wersję produktu,
  • zastanów się kiedy i jak powiesz ludziom ze obecnego zespołu, że ich praca w projekcie dobiega końca,
  • zaplanuj stosowny budżet, przez jakiś czas będziesz musiał utrzymywać, być może niekompletne, ale dwa równoległe zespoły projektowe,
  • jeszcze taka bardzo praktyczna rada – zorientuj się jakie jest zapotrzebowanie na ludzi w nowej lokalizacji do innych projektów o takim profilu jaki potrzebujesz. Może się okazać, że co prawda zatrudniać w nowej lokalizacji się da, ale nie jesteś jedynym w kolejce rekrutacyjnej albo, że Twój priorytet nie jest najwyższy.

Rozmawiaj z ludźmi

Osoba, która będzie odpowiedzialna za przeniesienie projektu moim zdaniem powinna być z lokalizacji docelowej. Głównie chodzi tutaj o współpracę z zespołem rekrutującym oraz znajomość lokalnego rynku pracy. 

Jeśli kiedyś staniesz przed zadaniem przeniesienia projektu do nowej lokalizacji (co wcale nie jest mało prawdopodobne), pozostaje mi życzyć Ci powodzenia. To też jest projekt, tylko specyficzny o tyle, że zwykle znacznie krótszy od typowych projektów IT, ale nadal najeżony ryzykami.

I pamiętaj, ROZMAWIAJ Z LUDŹMI. Jeśli miałbyś tylko jedną rzecz z tego artykułu wynieść dla siebie, to niech to będzie właśnie to.