O napisaniu tego tekstu…

Categories Programowanie

O napisaniu tego tekstu myślałem dość długo, ale dopiero sytuacja z Cyber Punkiem 2077 mnie zmotywowała.

Miejsce akcji: Wrocław, duża firma telekomunikacyjna
Czas akcji: Połowa drugiej dekady XXI wieku

Prolog:
Scena 1. Mamy duży kawałek softu rozwijany przez dział X. Oprogramowanie to odpowiedzialne za wiele różnych rzeczy, między innymi start urządzenia, software upgrade, konfigurację urządzeń zewnętrznych, zgłaszanie alarmów i wiele więcej. Soft był rozwijany przez wiele lat przez wielu różnych programistów z użyciem różnych narzędzi (na przykład IBM Rhapsody – generowanie kodu na podstawie diagramów). Programiści narzekają na duży dług techniczny, implementacja nowych funkcjonalności jest coraz trudniejsza.
Scena 2. Mądrzy ludzie zwołują workshop. Potem następny. Starszyzna rozmyśla jak rozwiązać problem.
Scena 3. W końcu zapada decyzja. Przepisujemy wszystko od nowa! W nowym releasie wszystko zrobimy od nowa! Dodatkowo zaimplementujemy nowe ficzury! A co tam, co może pójść nie tak?

Akt I
Scena 1. Dział X przepisuje.
Scena 2. Dział X nadal przepisujemy.
Scena 3. Dział X przepisuje, ale końca nie widać
Scena 4. Data releasu się zbliżą, a wszystko jeszcze nie gotowe.

Akt II
Scena 1. Testerzy chcą zacząć testować, ale jeszcze nie ma co.
Scena 2. Management zaczyna naciskać, pojawiają się pierwsze pytania czy uda się wypuścić soft w planowanym terminie.
Scena 3. Testowanie się opóźnia, bo jeszcze nie gotowe.

Akt III
Scena 1. Testerzy grają 8 godzin w piłkarzyki, bo nie ma czego testować.
Scena 2. Manager testerów zaczyna się denerwować. Na jednym ze spotkań zaczyna krzyczeć na wszystkich, bo dobrze wie, że terminów nie da się dotrzymać i jego ludzie będą musieli pracować po godzinach, żeby nadrobić zaległości.
Scena 3. Managerowanie działów Y i Z przyłączają się do managera testów. Wiedzą, że ich ludzie również będą musieli pracować po godzinach z nie swojej winy.
Scena 4. Testerzy powoli zaczynają organizować się w gangi, żeby walczyć o dostęp do piłkarzyków.

Akt IV
Scena 1. Gotowe!
Scena 2. Ale nie bardzo, nic nie działa. Urządzenie nawet nie startuje.
Scena 3. Okazuje się, że programiści działu X nie są tacy doskonali, jak wszyscy myśleli. W nowej wersji jest pełno bugów!
Scena 4. Poza tym, brakuje również mnóstwo innych funkcjonalności, które były w starej wersji – workaroundów na problemy sprzętowe, specjalnych rzeczy, które były zaimplementowane na prośbę klienta, etc.
Scena 5. Wszystko jeszcze bardziej się opóźnia. Data releasu już dawno minęła, zaczyna się walka o jak najmniejsze opóźnienie.

Akt V
Scena 1. Programiści działu X pracują dzień i noc, żeby naprawić wszystkie błędy.
Scena 2. Zaczyna krążyć legenda, że programiści działu X muszą brać urlop, jeśli chcą mieć wolny weekend.
Scena 3. Programiści działów Y i Z również nie mają lekko – też pracują po godzinach, bo testowanie ich ficzurów było opóźnione o prawie pół roku.
Scena 4. Najgorzej ze wszystkich mają testerzy. Praktycznie nie mają czasu na sen. A jeśli już uda im się zdrzemnąć chwilę w firmowej toalecie, to śnią o wymarzonych piłkarzykach.
Scena 5. Release! W końcu! Nie ważne, że grubo po terminie. Nie ważne, że dużo rzeczy nadal nie działa.

Epilog:
Okazało się, że ktoś zapomniał przetestować jedną ważną konfigurację. Ponad 5 tysięcy urządzeń w Korei Południowej zostało uszkodzonych przez błąd w sofcie. Firma musi pokryć koszty ich wymiany.

Oczywiście, odrobinę całą sytuację odrobinę uprościłem, ale to wszystko się wydarzyło naprawdę.

#programowanie