Jest już prawie gotowe

Co to znaczy, że projekt jest gotowy? W praktyce może oznaczać to bardzo różne rzeczy…

Pewnego dnia wezwał mnie mój kierownik i powiedział: „Jest taki nowo napisany system SmerfMaruda, tam wszystko jest już gotowe i wdrożone, brakuje tylko funkcjonalności MarudzeniaSpecjalnego. Dopisz tę funkcję, nie powinno ci to zająć więcej niż dwa dni”.

Ponieważ nie znałem tego systemu, przeszedłem się do kolegów, którzy go napisali. Po kilku rozmowach okazało się, że „system jest prawie gotowy”. A to małe słowo „prawie” oznaczało następujące kwestie:

• System był zainstalowany tylko na jednym serwerze. Co więcej, w zależności od parametru konfiguracyjnego, ten serwer przełączał się między rolą serwera testowego oraz produkcyjnego. Działało? Działało. Ale nie było możliwości równoległego prowadzenia testów i pracy produkcyjnej. Istniało również poważne ryzyko, że kiedy w trakcie sesji testowej zajdzie konieczność działania produkcyjnego, to na serwerze produkcyjnym znajdą nieprzetestowane funkcjonalności.
• Kody źródłowe istniały tylko na serwerze – nie były składowane w żadnym repozytorium źródeł.
• Nie istniała żadna dokumentacja – łącznie z instrukcją kompilacji systemu. A było to o tyle ważne, że system zawierał pewien niestandardowy i unikalny komponent, który kompilowało się i uruchamiało w niestandardowy sposób.
• Serwerem, na którym zainstalowano system, był jakiś „pecet z odzysku” stojący pod biurkiem dewelopera.
• Zespół, który miał administrować systemem, nic o nim nie wiedział.

Efekt był taki, że napisanie MarudzeniaSpecjalnego faktycznie trwało dwa dni – ale wyprostowanie wszystkich innych spraw związanych z gotowością systemu do wdrożenia zajęło kolejne trzy tygodnie.

Ale tak naprawdę ważne jest co innego. Z punktu widzenia programisty – system jest gotowy, bo działa. Realizuje swoje funkcje. Z punktu widzenia gotowości do poprawnego działania produkcyjnego i do utrzymania tego systemu – system gotowy nie jest, a wdrożenie go w tym kształcie jest mocno ryzykowne.

Wynikają z tej historii dwa morały.

Pierwszy z nich jest organizacyjny. Sporo firm wprowadza procedurę „hand over” – czyli listę warunków, które muszą być spełnione, aby uznać system za gotowy do wdrożenia. Czasami warto jest taką procedurę wprowadzić. Scrum wprowadza „Definition of Done” – listę elementów czy zadań, które muszą być zakończone, aby uznać funkcjonalność za zaimplementowaną.

A drugi jest ludzki. Często wydaje nam się, że bardzo dobrze wiemy, jaki ma być efekt zadania, które zlecamy lub które wykonujemy. W tym konkretnym przypadku efektem pracy miał być „gotowy system”. Często wydaje nam się, że nasz punkt widzenia jest jasny i oczywisty dla wszystkich. Tymczasem okazuje się, że rozumienie tego efektu jest zupełnie różne dla różnych osób. Warto więc czasami sprawdzić, czy mówiąc o wykonaniu pewnego zadania mamy na myśli taki sam jego efekt końcowy jak osoba, z którą rozmawiamy.