Projekt nie kończy się na UAT’ach

Kiedy w zasadzie kończy się projekt?

Całkiem niedawno byłem uczestnikiem prezentacji, na której jeden z PM’ów chciał opowiedzieć, na forum firmowym, o projekcie którego realizacja właśnie się rozpoczęła. Zebrała się spora grupa słuchaczy, prezentowane były założenia, cele. Jeden ze slajdów pokazywał fazy projektu ale zastanawiające dla mnie było to, że ostatnią fazą była faza UAT (User Acceptance Tests). Czekałem aż speaker zakończy swój wywód. Ku mojemu rozczarowaniu ostatnie zdanie brzmiało „Potem jest faza UAT i potem jest koniec projektu”. Nie czekając długo zadałem pytanie: „Czyli projekt nie wchodzi na produkcję?”. Wywołało to gromki śmiech i potraktowane zostało (oczywiście) z przymrużeniem oka.

Wejście na produkcję nie dzieje się „just like that”

Faktycznie moje pytanie w zamyśle miało rozbawić towarzystwo, jednak uwydatniło też poważny problem. Niestety mam wrażenie, że problem ten nadal nie jest dostrzegany przez wiele osób pracujżcych przy wytwarzaniu oprogramowania. Wdrożenia produkcyjne nie odbywają się same. Projekty nie kończą się na UAT?ach. Procedura wdrożenia produkcyjnego i przekazania projektu zespołowi utrzymania powinna być dokładnie przemyślana i zaplanowana. Wiele osób o tym zapomina, nie uwzględnia tego w harmonogramach i budżetach, nie zapewnia wystarczającego wsparcia developerskiego oraz środków pieniężnych, nie myśli o okienkach serwisowych, czasie jaki zajmie samo wdrożenie. Procedura, nawet jak powstaje, często traktowana jest po macoszemu.

Start produkcyjny

Uruchomienie produkcyjne aplikacji to dla niektórych moment, w którym otwierają szampana, zbierają gratulacje z okazji udanego końca projektu. Dla innych to dopiero początek przygody z właśnie powstałą aplikacją. W zasadzie, w zespole utrzymania, zaczyna się okres strachu i niepewności. Mimo że autorzy dumnie zapewniają, że wszystko zostało dopięte na ostatni guzik, wiemy jakie jest życie. Teraz aplikacja jest w rekach docelowego użytkownika, a jak mówi prawo Murphy’ego: „It is impossible to make anything foolproof because fools are so ingenious”.

Ciągły proces ulepszania

ITIL wprowadza pojęcia „Continual Service Improvement”.

ITIL_en

Oznacza to ciągły proces ulepszania usługi świadczonej klientowi. Proces ten zakłada cykliczne powtarzanie następujących faz:

  1. Service strategy
  2. Service design
  3. Service transition
  4. Service operation

Bezproblemowe przejście z jednej fazy w drugą jest kluczowe i zespoły projektowe muszą być tego świadome.

Jeśli Twój projekt ma być wytworzony oraz utrzymywany przez Twoją firmę musisz zawsze myśleć o nim w kontekście długoterminowym i to nie tylko przez pryzmat fazy developmentu. Proces wytworzenia aplikacji, zakończony pomyślnymi testami akceptacyjnymi, to tylko jeden z etapów i to jednej (pierwszej) iteracji procesu definiowanego przez ITIL. Traktuj powstający produkt jako usługę, która będzie świadczona klientowi przez długie lata, nieustannie ulepszaną, i miej to na uwadze już na etapie zbierania wymagań i planowania pierwszych harmonogramów. Nawet jeśli poszczególne fazy są realizowane przez inne zespoły, to zespoły te muszą wykonywać swoją pracę z myślą o tym, że kolejny zespół będzie składał się z ich koleżanek i kolegów, których praca będzie się przekładać na realne zyski tej samej firmy. Zespół, w którego rękach aktualnie znajduje się projekt, ma obowiązek zadbać o płynne przekazanie projektu kolejnemu zespołowi.

Wracając więc do pytania zadanego na samym początku. Kiedy właściwie kończy się projekt? Projekt kończy się, kiedy firma przestaje wystawiać za niego faktury.