Cześć, dzień dobry. 

Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.

Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 20. Jak przekazać projekt IT do innego partnera.

Jednym z głównych wyzwań, jakie podejmujemy z ramienia Innovation Software jest współpraca z klientami na już istniejących projektach IT. Czyli sytuacja, w której z jakiegoś powodu klient jest zmuszony zmienić firmę programistyczną lub nagle zostaje bez swojego działu IT lub głównych osób z tego działu IT i potrzebuje kogoś, kto szybko zajmie się jego istniejącymi projektami. W tym odcinku opowiem o tym, jak podchodzimy do takich współprac i z czym w ogóle wiąże się samo przekazywanie projektu IT od jednego dostawcy do innego.

Nie przedłużając, serdecznie zapraszam do wysłuchania dzisiejszego odcinka. Cześć, dzień dobry. Dzisiaj na tapet bierzemy temat przekazywania projektów IT czy też przejmowania na swoje barki projektów IT od innych dostawców, w tym wyzwania i najlepsze praktyki związane czy to z analizą dokumentacji, kodu czy też architektury systemu, choć jak się okazuje to wszystko nie jest w tym wszystkim najważniejsze.

Podzielę się poradami jak zapewnić takie płynne przejście i kontynuację projektu czy zbioru projektów bez zakłóceń. 

‍

Dlaczego firmy zmieniają dostawcę IT?

Na początek zadałbym sobie pytanie, dlaczego firmy w ogóle zmieniają dostawcę IT? Co sprawia, że one muszą go zmienić? Jak to wygląda najczęściej w przypadku naszych klientów? Często jest tak, że pojawiają się problemy z jakością usług, czyli firma danego klienta jest niezadowolona zespół pracy, którą prowadzi, w związku z tym musi ją zmienić. Zdarza się, że zmieniają się priorytety lub też zakresy prac.

To jest taki przypadek, że u naszych klientów po prostu pojawia się sytuacja, w której obecny zespół czy obecny software house, czy innymi słowy firma programistyczna, nie mają chęci skalowania się, powiększania swojego zespołu. To dotyczy często klientów, którzy przechodzą do nas z mniejszych software house'ów, gdzie jest to stały zespół, nie wiem, 3-5 osób i taki software house nie chce zatrudniać nowych ludzi, a potrzeb klienta jest coraz więcej, coraz więcej i trudno je wszystkie ogarnąć naraz. Pojawiają się problemy komunikacyjne, pojawia się niewywiązywanie z umów, na przykład typu SLA, niewywiązywanie się z terminów, czy po prostu rozwiązanie lub reorganizacja wewnętrznego zespołu IT.

‍

Główne ryzyka przy przekazaniu projektu

Jakie ryzyka wiążą się z przekazywaniem projektu do innego dostawcy IT? Może to być oczywiście przerwanie prac, może to być niestabilność w pracy z projektem, czy po prostu niestabilność samego projektu na produkcji. Coś, o czym się często nie myśli jako pierwsza rzecz, to jest w ogóle utrata wiedzy o projekcie, czyli zarówno wiedzy technologicznej, jak i wiedzy biznesowej, która była przez na przykład ileś lat przekazywana do działu IT. I mogą to być też trudności w komunikacji z nowym dostawcą, bo jak to na początku drogi trzeba się dotrzeć, trzeba tą komunikację i zasady komunikacji wypracować.

No i to jest właśnie też jednym z ryzyk, na które bym tutaj zwrócił uwagę. 

‍

Typowe scenariusze rozstania z dostawcą

Dwie takie sytuacje, czyli jak podzielić te sytuacje, kiedy trafiają do nas klienci chcący zmienić dostawcę IT, są takie, gdzie te rozstania są powiedzmy w miarę, nazwijmy to normalne, czyli z przyczyn takich niezależnych od klienta, czyli na przykład w danej firmie właśnie zmniejsza się zespół, czy tracony jest główny programista, ale też czasami niestety pojawia się jakaś niezgoda między tymi stronami i w tym przypadku zdarza się też, że klient po prostu pozostaje na lodzie wraz ze swoim projektem lub projekt po prostu bardzo długo się ciągnie i nie jest dowożony na czas i mimo przekładania terminu dalej nie jest dowożony. No i w tego typu sytuacjach też trzeba w jakiś sposób się w tym odnaleźć i tego wyzwania się podjąć.

‍

Podejście 3-fazowe do przejęcia projektu

My takich wyzwań się podejmujemy, natomiast nie robimy tego tak bardzo w ciemno. Staramy się przejść przez takie trzy główne fazy, kiedy przy tym takim, nazwijmy to normalnym przejmowaniu projektu do innego dostawcy, w tym wypadku do nas, staramy się przejść, czyli takie trzy główne fazy i teraz o tych fazach krótko opowiem. 

‍

Faza I - Zdobycie niezbędnych informacji

Faza pierwsza to jest taka faza zdobycia niezbędnych informacji i teraz z naszej perspektywy najważniejsze jest zrozumienie powiedzmy aktualnej sytuacji klienta, aktualnej sytuacji związanej z jego projektami i też tego dlaczego pewne decyzje zostały podjęte takie, a nie inne w przeszłości.

Często jest tak, że obserwując jakąś sytuację można wyciągnąć wnioski, że przecież to jest oczywiste, że powinno być zrobione inaczej, ale kiedy prześledzimy ten ciąg taki przyczynowo-skutkowy, jakie decyzje były podejmowane i z jakiego powodu, czy jakie decyzje technologiczne podejmowane z jakiego powodu biznesowego, no okazuje się, że niejednokrotnie faktycznie to były dobre decyzje, przynajmniej na tamten czas, kiedy je faktycznie podejmowano. 

‍

Poznanie biznesu i celów klienta

I teraz aby przejść przez tą fazę zdobycia niezbędnych informacji, co jest moim zdaniem kluczowe w ogóle na samym starcie, to po pierwsze staramy się jak najdokładniej poznać biznes klienta. Staramy się dowiedzieć czym klient się zajmuje, co robi, z czego żyje, co jest jego źródłem dochodu, jakie są najważniejsze procesy zachodzące w jego firmie i w których tych procesach funkcjonuje jego oprogramowanie, które mamy docelowo przejąć.

Czyli niezależnie czy to na przykład jest e-commerce, czy jakaś firma produktowa, to mimo tego, że znamy na przykład te dwie branże bardzo dobrze, to jednak nadal patrzymy na każdy e-commerce, czy na każdą firmę produktową, na każdego Sasa, zupełnie jakby to było coś innego, no bo siłą rzeczy to jest coś innego i tam pewne procesy oczywiście będą stałe, typu działający koszyk w e-commerce, ale pewne procesy będą jednak typowo specyficzne dla danej firmy i trzeba o nich pamiętać, trzeba je przede wszystkim poznać. Następnie jak już znamy biznes klienta, czyli ten taki pierwszy ogół, to przechodzimy troszeczkę dalej do szczegółów, ale jeszcze nie w kwestie techniczne. Wchodzimy sobie w cele biznesowe klienta.

I teraz często jest tak, że firmy przejmujące oprogramowanie skupiają się typowo na oprogramowaniu, na kodzie, na repozytorium i to jest bardzo ważna sprawa od strony technicznej, żeby faktycznie o tych rzeczach pamiętać. Natomiast trzeba nadal pamiętać o tym, że te rozwiązania techniczne służą temu, żeby biznes mógł funkcjonować. Więc żeby biznes mógł dobrze funkcjonować, to jego cele muszą być realizowane, a żeby one mogły być realizowane, to muszą być znane.

Trochę truizm, ale tak jest, że jeżeli te cele biznesowe nie są poznane przez nową firmę programistyczną, to można też z perspektywy biznesu błędnie przyjąć, że jeżeli poprzedniemu dostawcy pewne rzeczy przekazaliśmy i pewne informacje były dla niego oczywiste i pewne informacje może już nawet były dla niego jasne bez przekazywania, to jednak ten nowy dostawca musi też otrzymać te informacje i musi otrzymywać też nowe informacje na bieżąco, dlatego u nas jest też taki etap zapoznania z celami biznesowymi. Często jest tak, że to nie jest jakiś jeden pojedynczy projekt, tylko zbiór projektów czy różnych aplikacji u klienta, czyli to nie jest tylko jakaś jedna prosta aplikacja, tylko czasem to jest też zbiór ekosystemów u danego klienta działający. No i wówczas oczywiście trzeba się zapoznać też z dokumentacją, jaka do tego projektu funkcjonuje.

‍

Dokumentacja i jej formy

I teraz tak, formy dokumentacji są różne, bo może być tak, że to jest dokumentacja taka napisana od A do Z faktycznie, czym ten system jest, dlaczego powstał i jakie ma najważniejsze funkcjonalności i też pełna dokumentacja techniczna i wtedy super. Inną formą dokumentacji mogą być na przykład zadania przekazywane firmie poprzedniej, które to zadania mogą być spisywane na jakiejś tablicy czy może były spisywane wcześniej i te zadania też są jakąś formą dokumentacji tego, co się w projekcie działo, ale czasem może być też tak, że tej dokumentacji po prostu nie będzie w żadnej formie, bo zadania były przekazywane gdzieś tam słownie albo mailowo i trudno to będzie pozbierać. W takiej sytuacji my staramy się stworzyć przynajmniej jakiś zalążek dokumentacji na start, poznając ten system czy systemę, pokrótce opisać od ogółu do szczegółu, ale na początku skupiając się szczególnie na tym ogóle właśnie, czyli na tym, żeby wiedzieć jakie systemy wchodzą, czy jakie projekty wchodzą w ten ekosystem aplikacji klienta, która z czym jest powiązana, w jaki sposób, jakie funkcjonują serwery w infrastrukturze, jaka to w ogóle jest infrastruktura.

No w dużym skrócie po prostu poznajemy ten projekt i jednocześnie go dokumentujemy, ale tak bardzo wysokopoziomowo. 

‍

Zadania rozpoczęte, ale niedokończone

Kolejne pytanie czy zbiór pytań, jakie zadajemy, to czy coś jest zrealizowane już długoterminowo, czyli czy na przykład są rozpoczęte jakieś aktualizacje systemu, jakieś naprawy, które nie zostały dokończone, jakieś zadania, które z jakiegoś powodu nie zostaną dokończone. To są rzeczy, o które warto dopytać poprzedniego zespołu, no i warto też widzieć na jakim etapie to stanęło w przypadku, kiedy takie tematy czasem też trzeba przejąć.

W idealnym świecie taki zespół, ten powiedzmy poprzedni, powinien dokończyć takie rzeczy, żebyśmy wchodzili zupełnie na zero w zadania budowane zupełnie od podstaw, ale z przyczyn różnych nie zawsze tak się da, więc jeżeli coś jest rozpoczęte, no to też trzeba to bardzo dokładnie spisać, zapoznać się z tym, no i też potem ustalić, jak to będzie faktycznie dokończone. 

‍

Znane problemy i tymczasowe rozwiązania

I coś, co też jest istotne i o co warto zapytać, a często się nie pyta poprzednich dostawców, to znane problemy związane z systemem, czyli jeżeli ten dostawca pracował poprzedni kilka lat na tym systemie, to on już pewne jego bolączki zna, pewne rozwiązania problemów też zna, zna ileś tymczasowych rozwiązań, które z tymczasowych stały się docelowymi i warto te rozwiązania, o te powiedzmy znane problemy dopytać i też o te rozwiązania już znane dopytać, no żeby nie wynajdować koła na nowo jako ten nowy zespół, no i żeby też nie powodować tego, że klient będzie miał jakieś problemy, które wcześniej nie występowały, bo zespół coś tam cyklicznie realizował po swojej stronie. Czyli tak, żeby podsumować tą fazę pierwszą, czyli zdobycie niezbędnych informacji.

Po pierwsze poznajemy biznes klienta, po drugie jego cele biznesowe, po trzecie zapoznajemy się z dokumentacją bądź realizujemy jej zalążek, po czwarte ustalamy czy coś jest realizowane długoterminowo i po piąte pytamy o znane problemy i znane rozwiązania takich problemów. I teraz, żeby przejść przez tą fazę pierwszą, potrzeba na to około dwóch tygodni. Oczywiście w zależności od takiego powiedzmy tempa wdrożenia, od tego jak się tutaj klientowi i poprzednim mu dostawcy śpieszy, no i też od tego jak duży jest ten ekosystem.

To może być czasem trochę krócej, to może być czasem trochę dłużej, ale dwa tygodnie to jest taki etap, żeby przez tą fazę przebrnąć w miarę na spokojnie, ale też takim tempem, że no z dnia na dzień coś potwierdzamy, coś realizujemy i raczej to nie trwa, raczej to nie trwa dłużej. Możemy przejść zatem do fazy drugiej. 

‍

Faza II - Płynna praca dwóch zespołów

Faza druga to jest coś, co też się niestety pomija, a co moim zdaniem właśnie powoduje w dużej mierze to, że ten projekt może działać stabilnie i to przekazanie projektu może się odbywać płynnie.

Mianowicie jest to płynna praca nad projektem. Jeżeli się da, warto zsynchronizować pracę obu zespołów, czyli od starego dostawcy i od nowego. I teraz warto to zrobić, ponieważ w ten sposób cały proces będzie dział się płynnie, no i przekazanie projektu przejdzie praktycznie bezboleśnie, bo bardzo dużo kwestii będzie można sobie wyjaśnić w trakcie już trwania prac i realizacji po prostu zadań.

I teraz jak technicznie do tego podejść, czy organizacyjnie tak naprawdę jak do tego podejść, żeby to faktycznie dało się zrobić. 

‍

Wspólna praca na repozytorium i code review

Po pierwsze trzeba ustalić sobie wspólne zasady pracy na repozytorium kodu. Jeżeli takowego repozytorium z jakiegoś powodu twój projekt by nie miał, no to należy to na pewno nadrobić jeszcze na samym starcie.

Takie sytuacje nam się rzadko zdarzały, ale też jedną, dwie na pewno pamiętam. No i w takiej sytuacji my po prostu pierwsze co to nadrabialiśmy właśnie też to repozytorium kodu. Trochę w ramach aspektu dokumentacji, ale trochę też w ramach po prostu tego, żeby móc w sprawny sposób pracować na tym kodzie z założeniem pracy dwóch zespołów.

Po drugie dba się o to, aby proces code review przechodził przez obie strony. Co to oznacza? Oznacza to to, że jeżeli my coś jako nowy zespół, nowy dostawca zbudujemy, to stary zespół powinien sobie to sprawdzić, potwierdzić czy jest OK. Ale też jak stary zespół coś buduje, to my powinniśmy to sprawdzić i potwierdzić czy jest OK.

To powoduje, że następuje już niejako transfer wiedzy i pewne rzeczy można już na poziomie właśnie tego kodu i przeglądania kodu, czyli tego procesu code review sobie wyjaśnić. No i jednocześnie dzięki temu też przechodzi nam to prościej po obu stronach, żeby ten projekt przekazać. 

‍

Testy manualne i regresji

Następnie jeżeli chodzi o testy rozwiązań, no u nas zawsze jest tak, że do projektu jest dołączany też tester manualny, który te zadania testuje od strony funkcjonalnej i wykonuje też testy regresji przed uruchomieniem produkcyjnym i po uruchomieniu produkcyjnym.

Czyli testy funkcjonalne to oznacza sprawdzenie, czy dane zadanie faktycznie jest OK, czy spełnia swoje cele biznesowe, czy jest funkcjonalnie OK i czy ma spełnione kryteria odbioru. Testy regresji, czyli sprawdzenie czy po naszych zmianach, czy po zmianach też starego jeszcze dostawcy, nie nastąpiły te tak zwane regresje, czyli po prostu błędy, których być nie powinno, a które zostały spowodowane na skutek jakichś zmian w kodzie. I teraz ten proces testów też staramy się wdrażać tak, żeby to już było realizowane po naszej stronie, jako u nowego dostawcy.

Ale jeżeli np. w projekcie klienta, jakby w dokumentacji projektu klienta były zapisane też jakieś scenariusze testowe, jakieś ustalenia co do tego, jak projekt powinien być testowany, to na tym etapie też bierzemy to pod uwagę, żeby faktycznie to się działo. 

‍

Proces uruchomień produkcyjnych

Jeżeli później chodzi o uruchomienie produkcyjne tych zmian, czy to naszych, czy starego dostawcy, to my staramy się jak najszybciej włączać się w ten proces i ten proces już przejmować na swoje barki, tak żeby osoba po naszej stronie była odpowiedzialna za wszelkie wdrożenia produkcyjne.

Natomiast to też się różnie praktykuje. Czasem jest też tak, że działamy jako dwa niezależne zespoły, ale po prostu na jednym kodzie mniej więcej w jednym czasie. Mam na myśli, że w danym, nie wiem, właśnie dwóch, trzech tygodniach, kiedy projekt jest przekazywany.

No i wówczas każdy odpowiada za swoje uruchomienia produkcyjne i każdy realizuje procesy np. testowe osobno. Ale to wszystko zależy od tego tak naprawdę jak się to ustali.

W idealnym świecie podchodzimy do tego w ten sposób, że to uruchomienie produkcyjne jak najszybciej przejmujemy na swoje barki. 

‍

Wspólna tablica projektowa i komunikacja

To co jest istotne jeszcze w pracy takich dwóch zespołów to to, że należy zapewnić taki stały dostęp do komunikacji. Mam tutaj na myśli zarówno komunikację na linii my-klient, jak i na linii my i stary dostawca.

Bo jeżeli te komunikacji sobie nie zorganizujemy, no to wówczas jeżeli klient w tym wypadku jest zobowiązany do tego, żeby łączyć nasze działania komunikacyjne, to raz, że nie chcemy mu tutaj dokładać dodatkowej pracy i dodatkowego czasu zabierać, a dwa, że możemy pewne rzeczy od strony technicznej po prostu wyjaśnić bezpośrednio z poprzednikami i tak też jest najlepiej. Jeżeli się da to fajnie jest współpracować na wspólnej tablicy projektowej. Czyli żeby zadania obu zespołów były w jednym miejscu.

Ale to też nie zawsze jest must have. To w zależności od tego jak się to ustali, jak się do tego podejdzie. Plusem tego, że pracujemy na jednej tablicy jest to, że faktycznie te zadania widać łatwo, jakie są uruchamiane na produkcji, co się dzieje.

Jeżeli są dwie różne tablice, to ten proces uruchomienia produkcyjnego trzeba troszkę bardziej unormować. To znaczy zorganizować po prostu inaczej informacje o tym, że to uruchomienie jest realizowane. No i tutaj tak naprawdę jeżeli chodzi o fazę drugą, no to od strony technicznej i organizacyjnej Wam to opowiedziałem.

Czyli jest to faza, na której wspólnie pracujemy nad projektem jako dwa zespoły. Ustala się pracę co do tego jak ma wyglądać działanie na repozytorium kodu. Dba się o proces code review, aby obie strony go realizowały wzajemnie.

Dba się o testy i o to, żeby uruchomienie produkcyjne z reguły już było realizowane po naszej stronie. Natomiast ważne jest, żeby po prostu było. No i zapewnia się dostęp do komunikacji, tak żeby obie strony też mogły się komunikować.

Obie strony, czyli stary dostawca i nowy dostawca. 

‍

Faza III - Pełne przejęcie projektu

I przechodzimy wówczas do fazy trzeciej, czyli do pełnego przejęcia projektu. I ona wychodzi dość naturalnie jakby z fazy drugiej przechodzi się do fazy trzeciej poprzez właśnie to, że jakby zadania są przekazywane na początku.

Mniej zadań idzie do nas, więcej do starego zespołu, no bo my musimy się tutaj też rozpędzić i sobie po prostu te zadania zacząć realizować. Natomiast z czasem, czyli z perspektywy kilku tygodni zaczynamy coraz więcej tych zadań przejmować na swoje barki. Poprzedni dostawca dostaje tych zadań coraz mniej.

No i finalnie dochodzimy do etapu, że faktycznie jesteśmy w stanie w stu procentach realizować pracę i tak to działa. I dzięki takiej trzyfazowej i dzięki takiemu trójfazowemu czy dzięki takim trzem fazom przejmowania projektu jesteśmy w stanie rzeczywiście ten projekt zorganizować i faktycznie go przejąć tak, żeby on bezpiecznie i stabilnie był dowożony. I teraz to podejście działa i ono faktycznie funkcjonuje tylko wtedy jeżeli zakładamy i ona faktycznie jest dobra wola i współpraca czy chęć współpracy wszystkich stron, czyli starego dostawcy, klienta oraz nowego dostawcy.

‍

Co jeśli brakuje dokumentacji i dobrej woli?

No ale co jeśli tej dobrej woli nie ma albo ktoś już zakończył współpracę i po prostu przychodzi do nas z projektem, ale właśnie na przykład bez dokumentacji i z koniecznością odtwarzania pewnych ustaleń ad hoc bez komunikacji z poprzednimi poprzednim zespołem, poprzednim dostawcą to też da się zrobić i my też takie rzeczy robimy, czyli w takiej sytuacji na pewno trzeba dużo ostrożniej podchodzić do pewnych kwestii. Trzeba dbać o komunikację między nami a klientem i wszystkie zmiany zawsze trzeba dokładnie testować, ale w tym wypadku testować trzeba je jeszcze dokładniej. Szczególnie w takich przypadkach warto jest podejść do tego w ten sposób, że po pierwsze zbudować mapę procesów, które dzieją się w danej aplikacji.

Po drugie jeżeli pojawiają się jakieś sytuacje awaryjne to reagować na nie mimo wszystko na spokojnie i mimo wszystko wiadomo, że jak jest awaria trzeba zareagować od ręki trzeba ją szybko rozwiązać, ale jeżeli chodzi o to rozwiązywanie awarii, jakieś rozwiązania tymczasowe no to trzeba tutaj na pewno też do tego podchodzić bardzo ostrożnie i z perspektywy klienta też warto tutaj jednak być troszkę bardziej dostępnym do komunikacji, żeby pewne rzeczy logiczne potwierdzić, czy one faktycznie w danej sytuacji tak się powinny zadziać. I trzecia rzecz, która często w takich sytuacjach wychodzi to to, że warto jakby pracować dwutorowo, czyli z jednej strony gasić rzeczy, czy gasić pożary, które występują bo one z reguły występują w tego typu projektach i trzeba o nie po prostu zadbać i tutaj innej opcji nie ma i do tego gaszenia pożarów potrzeba dobrej komunikacji. Natomiast jeżeli chodzi o drugi tor no to są ustalenia długoterminowe i plan długoterminowy, który faktycznie spowoduje, że będziemy realizować te prace pomyślnie.

‍

Case study 1: Przejęcie platformy B2B od jednego programisty

W ramach tego odcinka chciałbym jeszcze opowiedzieć o dwóch sytuacjach. To były właśnie dwa takie, nazwijmy to przejęcia. Jedno to takie robione kroczek po kroczku, zgodnie ze sztuką na spokojnie, a drugie robione w warunkach bardziej nazwijmy to hardkorowych, ale w których też trzeba było się odnaleźć i które też spowodowały, że nie boimy się podejmować takich wyzwań.

No i pierwsze to było takie, gdzie mieliśmy taką hurtownię, która miała napisane świeże oprogramowanie. To oprogramowanie, taka platforma B2B ona została uruchomiona produkcyjnie całkiem niedawno. No i okazało się, że programista, który tą platformę budował z jakiegoś powodu będzie musiał odejść z firmy, która go zatrudniała, która była podwykonawcą tego naszego klienta.

No i pojawiła się taka sytuacja, że klient zmuszony był szukać innej firmy, bo właśnie poprzednicy nie chcieli zrekrutować kogoś nowego na miejsce tego głównego programisty. No i tak naprawdę tutaj właśnie podeszliśmy do tego zupełnie modelowo, czyli poznaliśmy biznes klienta, poznaliśmy jego najbliższe cele biznesowe, zapoznaliśmy się ze stanem platformy, zapoznaliśmy się z jej dokumentacją, zapoznaliśmy się z tym, jak ten poprzedni programista realizował pracę. Ten programista opowiedział nam o tym, w jaki sposób realizował proces deploymentu, w jaki sposób przebiegały do tej pory testy, w jaki sposób odbierał zadania od klienta i je realizował i w jaki sposób zwracał je do klienta.

Czyli poznaliśmy tak naprawdę cały proces, poznaliśmy to, jak ta współpraca przebiegała. Tutaj też programista był bardzo chętny do komunikacji, do wszelkich ustaleń, do przekazywania nam informacji. No była taka w stu procentach dobra wola.

No i to było o tyle dobre, że rzeczywiście tutaj mieliśmy też dobrą komunikację z klientem, więc wszystko przechodziło sprawnie i cały proces zamknął się w około 3-4 tygodnie, jeżeli dobrze pamiętam. No i tak naprawdę tutaj właśnie dokładnie tak robiliśmy, że jak się już zapoznaliśmy z tymi wszystkimi informacjami, dokumentacją, procesem, jak to wszystko przebiegało, rozpoczęliśmy wspólną pracę nad projektem, czyli właśnie fazę numer dwa. W ramach tej fazy zaczęliśmy realizować pierwsze zadania, które też sprawdzał ten poprzedni programista, oceniał czy jakość kodu jest OK, czy wszystko się zgadza w tym, co realizujemy, czy od strony takiej też technicznej to się zgadza, ale też od strony biznesowej, czy niczego nie pominęliśmy.

To też dawało trochę większe poczucie bezpieczeństwa klientowi, no bo jednak klient wiedział, że to tamten programista zbudował platformę, my byliśmy totalnymi świeżakami, jeżeli chodzi o jej znajomość, no bo siłą rzeczy wchodziliśmy tam zupełnie na świeżo, zupełnie od podstaw. Natomiast to finalnie faktycznie sprowadziło się do tego, że nasz proces delikatnie dostosowaliśmy do tego, do czego klient był przyzwyczajony, dzięki czemu też klient nie musiał się wdrażać zupełnie od nowa w jakieś takie procesy wytwarzania, oprogramowania. Z drugiej strony dołożyliśmy kilka takich jeszcze procesów z naszej strony, typu właśnie te rozszerzone testy, czy też jakby sposób samego uruchomienia produkcyjnego delikatnie zmieniliśmy, no co spowodowało, że finalnie ten projekt przejęliśmy i po dziś dzień się nim opiekujemy, a to już minęły chyba za trzy lata, albo i dłużej.

‍

Case study 2: Przejęcie projektu z awariami

Jeżeli chodzi o drugi taki projekt, drugą sytuację, tutaj było zupełnie inaczej, to znaczy to był właśnie moment kiedy klient do nas trafił i powiedział, że aktualnie jego programiści niestety z jakiegoś powodu są już niedostępni i potrzebuję wsparcia na CIT-a, bo nie dość, że jest projekt do zaopiekowania, no to ten projekt ma jeszcze błędy i pojawiają się jakieś awarie, które trzeba rozwiązać. No i teraz tutaj to, co my w takiej sytuacji zrobiliśmy, to przede wszystkim dobrze wybadaliśmy, mimo tych awarii, które były, które trzeba było oczywiście zaopiekować. To z jednej strony już zaczynaliśmy się zapoznawać z tymi awariami od strony technicznej, jak tam możemy pomóc, jak możemy tym awariom sprostać, żeby je przynajmniej krótkoterminowo wygasić, żeby ten pożar został wygaszony.

Natomiast z drugiej strony też staraliśmy się, czyli tym zajmował się programista, z drugiej strony project manager zajmował się tym, żeby zdobyć od klienta jak najwięcej informacji o tym, z czego te awarie mogą wynikać, czy one już wcześniej się pojawiały, jakie tu jest podłoże biznesowe. I skupiliśmy się najpierw na tym, żeby krótkoterminowo wygasić to, co faktycznie wymagało wygaszenia, czy ugaszenia w zasadzie, czyli te właśnie awarie i błędy. Natomiast jak ugasiliśmy te najważniejsze dla klienta, jego biznes oparty o tą daną aplikację mógł już dalej działać.

No to tutaj na spokojnie podeszliśmy już do tematu na tyle, na ile się dało od początku, czyli faktycznie nadrabiając dokumentację, nadrabiając repozytorium kodu, nadrabiając takie podstawowe praktyki, z których korzystamy, no i sprowadzając ten projekt na taki poziom organizacji, jaki byśmy chcieli mieć, tak żeby faktycznie działał on długoterminowo stabilnie. I tutaj też co ciekawe, potem okazało się, że była jeszcze jedna aplikacja u klienta w ekosystemie i od początku tego nie wiedzieliśmy. Natomiast na etapie awarii, tej pierwszych, które klient zgłaszał, nie musieliśmy tego wiedzieć.

No i tutaj też wyszedł taki trochę mechanizm, że z jednej strony klient dzięki temu, że szybko zareagowaliśmy, no to mógł dalej działać z biznesem i mógł też wyciągnąć pewne wnioski z tego, co się zadziało. Czyli z tego, że no jednak potrzeba takiej stałej opieki i tego, żeby ktoś reagował, nawet jeżeli ma zespół wewnętrzny, no w tym wypadku już nie miał. Natomiast summa summarum dotarliśmy do tego, że faktycznie plan długoterminowy to podstawa.

Mieliśmy już nauczkę z przeszłości tutaj, no właśnie na tej sytuacji, że trzeba to zrobić. No i od tego mogliśmy zacząć dalsze działania, dalsze prace, tak żeby zachować już tutaj trochę więcej prewencji, a nie tylko reakcji ad hoc. 

‍

Zapowiedź kolejnego odcinka i zakończenie

Dzięki bardzo za odsłuchanie dzisiejszego odcinka.

Zachęcam do zostawienia łapki w górę i przede wszystkim do zasubskrybowania mojego podcastu, aby nie przegapić kolejnego odcinka. A będzie to odcinek pod tytułem Prewencja czy reakcja? Dlaczego warto inwestować w stałą opiekę IT zanim pojawią się problemy? Czyli jest to odcinek, który opowie trochę dokładniej o tej ostatniej sytuacji, o której Wam opowiedziałem, czyli o tej, w której przemawialiśmy projekt, gdzie on był w takim dość dużym pożarze i bez znajomości tego projektu rozwiązaliśmy problemy klienta, ale w sposób taki ustandaryzowany i jednak spójny. I myślę, że ten temat tego czy prewencja czy reakcja to się może wydawać oczywiste dla wielu z Was, ale oprócz tej odpowiedzi na pytanie dlaczego warto zainwestować w stałą opiekę, opowiem trochę więcej o tym jak owa opieka IT powinna z mojej perspektywy wyglądać.

Dzięki raz jeszcze za odsłuchanie 20 odcinka mojego podcastu i do usłyszenia za tydzień. Cześć!

‍