IT to nie tylko pisanie kodu. O czym jeszcze warto pamiętać?

Przeglądając oferty pracy w IT, da się zauważyć, że dominują stanowiska developera, testera, specjalisty DevOps. itp. Natomiast pomiędzy tymi bardzo technicznymi kompetencjami w tak dużej organizacji jak Alior Bank, niezbędne są również inne funkcje wspierające, które np. mają za zadanie sprawdzić i zabezpieczyć jakość wdrożenia na produkcję. Wspólnym celem jest dostarczenie zamawiającemu działającego kodu, jednak jako Bank musimy również spełniać wymagania regulatorów. Wdrożenie to nie tylko instalacja, to również planowanie, zgranie całego zespołu, biorącego udział w tym procesie i działanie w trybie „emergency”, w sytuacji jak coś nie „pójdzie” zgodnie z planem.

Dzień wdrożenia

Dzień wdrożenia jest kluczowy, oddanie i sprawdzenie kilkutygodniowej pracy. Jest ekscytacja, często zmęczenie domykaniem ostatnich tematów, ale to ostatnia prosta. Zgłaszamy okienko instalacyjne i… ktoś zaczyna zadawać pytania:

Czy wszystko zostało sprawdzone?
Z jakim rezultatem?
Jeśli warunkowe wdrożenie (czyli nie wszystko działa zgodnie z założeniami), jakie będą tego skutki?
Czy główni interesariusze są poinformowani?

Podsumowanie zakończonych testów – Mamy TO! ? Teraz omówmy plan wdrożenia. 

Kolejny zestaw pytań:

Ile czasu na instalację paczki?
Czy będzie niedostępność dla użytkownika?
Ile czasu na walidację techniczną/ biznesową?
Kto wykonuje poszczególne działania/ zadania? Pod jakim telefonem będzie dostępny?
Jeśli pójdzie coś nie tak, to czy potrzebne dodatkowe osoby?
Ile czasu na bufor, na nieprzewidziane sytuacje?
Kto w tym czasie jest decyzyjny?
Jaki jest plan awaryjny?

To tylko pytania, które jednak często wywołują wiele emocji, wymagają asertywności, stawiania się w sytuacji drugiej strony. Często zaczynamy od planu optymistycznego, a kończymy na „katastroficznym”. Szukamy słabych punktów, które należy zabezpieczyć. 

Zdarzają się sytuacje, gdzie na spotkaniu dotykamy szerokiego zakresu kompetencji IT, a szczegółowe informacje nie do końca są dla wszystkich jasne. Mierząc się z tym wszystkim, musimy zachowywać pełne skupienie w trakcie spotkania oraz identyfikować punkty styku i zależności. Dlatego powinniśmy zadawać pytania w neutralny sposób, aby nie oceniać, tylko zrozumieć i w żadnym wypadku nie pozwolić uczestnikom na odbieganie w skrajności typu użalanie się, pouczanie, przechwalanie.

Poza kompetencjami „miękkimi” potrzebne jest analityczne łączenie faktów: ustalenie kto po kim i czy „spina się” to z planem. Po co tak wiele pytań, spotkań, dopytywania, potwierdzania? Na dane wdrożenie mamy zazwyczaj ograniczony czas, którego nie można rozciągnąć ze względu na konsekwencje finansowe lub wizerunkowe. Dla lepszego zrozumienia posłużę się przykładem:

Instalujemy trzy zależne od siebie zmiany. Harmonogram przygotowany co do minuty. Czas zmiany przewidziany na 7,5h (okienko 23:30 – 7:00) w tym 20% buforu, wszystkie osoby poinformowane. Zaczynamy! Instalacja, pierwszej i drugiej zmiany zgodnie z planem. Podczas instalacji trzeciej wystąpił problem ze sprzętem, potrzebne wsparcie z obszaru infrastruktury, kogoś, kto na dyżurze pomaga rozwiązać problem. Korzystamy z 30 minut buforu, bo wiedzieliśmy do kogo dzwonić.

Mając listę osób uczestniczących we wdrożeniu, wszyscy są poinformowani o „poślizgu”. Walidacja wymaga kompetencji z dziesięciu obszarów, w której uczestniczy jedenaście osób. Na 30 minut przed rozpoczęciem powinni potwierdzić mailowo, że są w gotowości.

Sprawdzamy obecność, dwóch osób nie ma. Dzwonimy pod wskazane numery telefonów. Jedna osoba odbiera „Słucham” zaspanym głosem… „Już się podłączam” druga osoba nie odbiera, pomimo kilku prób kontaktu. Mamy 30 minut na zlokalizowanie osoby. Okazało się, że brakująca osoba miała wyciszony telefon i zalogowała się w minucie rozpoczęcia walidacji, która przewidziana była na 2 godziny.

W ostatnich przypadkach testowych występuje błąd blokujący. Do zakończenia zmiany pozostała nam niecała godzina. Analiza 20 minut… konieczny restart 30 minut… weryfikacja, trochę lepiej, ale dalej nie jest tak, jak oczekiwaliśmy. Zostało 10 minut do końca dostępnego okienka. Konieczna jest decyzja czy wycofujemy wszystko, czy akceptujemy krytyczny błąd u klienta… W tym przypadku wystąpiło zbyt optymistyczne podejście do harmonogramu.

Wnioski

Na podstawie wyżej opisanego przykładu jasno wynika, że nie na wszystkie pytania zebrane były kompletne dane. Dobry kod i jego przetestowanie jest istotne, ale realizacja wdrożenia wymaga dopełnienia w zakresie organizacji. Zabezpieczyliśmy dostępność osób, ale… bufor nie zapewnił możliwości wycofania kodu i ponownego jego sprawdzenia.

Powyżej opisany przykład jest hipotetyczny, ale napisany historią wielu wdrożeń. Problemy mogą wystąpić w najmniej oczekiwanym czasie i miejscu, dlatego zawsze warto pochylić się nad rzetelnym przygotowaniem planu, który do realizacji potrzebuje ludzi umiejących działać w trybie „emergency”. W treści przytoczyłam kilka z podstawowych pytań związanych z przygotowaniem wdrożenia, ale nie można zapomnieć, że wymaga to również otwartości na pozyskane informacje i ludzi, z którymi się współpracuje. W jego trakcie szczęście też jest mile widziane ?