Wdrożenie != koniec pracy

Krótko o tym, dlaczego powinniśmy wyraźnie rozróżniać moment wdrożenia od zakończenia pracy i jakie korzyści nam to przynosi.

Czy wdrożenie to koniec pracy?

W wielu firmach spotkałem się z takim modelem pracy, już po samym developmencie:

• User Story / fragment rozwiązania jest już na głównej gałęzi, przeszedł wszystkie testy i code review.

• Jedyne czego brakuje to przestawienie wajchy i wdrożenie paczki na główne środowisko.

• Po wdrożeniu praca zostaje przez nas uznana za zakończoną.

Można to zwizualizować jako fragment typowej tablicy zespołu:

Zespół świętuje sukces dokładnie w momencie, gdy dana funkcja pojawia się na środowisku produkcyjnym. Czy jednak jest tak idealnie?

Takie myślenie niesie ze sobą 2 zasadnicze problemy:

• Zamyka pracę po wdrożeniu – spojrzenie na koniec procesu

• Ogranicza częste wdrażanie – spojrzenie na początek procesu.

Omówimy je po kolei.

Zamykanie pracy po wdrożeniu

Rzadko kiedy dzieje się tak, że po wdrożeniu możemy natychmiast odtrąbić sukces. W prawdziwej pracy produktowej wdrożenie na produkcję to dopiero początek problemów.

W zależności od specyfiki możemy mieć do zrobienia:

• Monitorowanie – sprawdzanie czy aplikacja się odpowiednio zachowuje.

• Metryki – wysyłanie szczegółowych informacji procesowych do narzędzi analitycznych.

• Dokonfigurowanie – włączenie specyficznej konfiguracji dla danej funkcji.

• Sprzątanie po sobie – usunięcie nadmiarowego kodu lub dodatkowa refaktoryzacja.

• Dokumentacja – spisanie nowych praktyk, czy podejść do zbioru wiedzy

• Dodatkowe translacje – dodanie nowych tłumaczeń, poza standardowym zbiorem do wdrożenia.

Jeśli po wdrożeniu przesuwamy zadanie na DONE, to kto się tym ma zająć?

W mojej ocenie jest to jeden z powodów, dla których zespoły nie pamiętają o analizie dokumentacji. Pojawia się poczucie, że moja praca została zakończona. Skoro projekt jest DONE to co niby mamy jeszcze tam robić?

I niestety w taki sposób kluczowe elementy pracy uciekają bokiem. Część tematów jest porzucanych (np. dokumentacja), część robi się na ad-hoc zwiększając koszt kognitywny zespołu (np. translacje). Ostatecznie cierpi i zespół, i jakość produktu.

Dużo więcej pisałem o tym w poprzednim odcinku newsletteru Jaka jest rola Tech Lead w Delivery.

Jednak, istnieje druga strona tego medalu. Problem ograniczenia częstych wdrożeń. I to on jest w mojej ocenie o wiele poważniejszy.

Ograniczenie częstych wdrożeń

Powyższa tabela pracy może powodować złudne wrażenie powiązania wdrożenia z rozwiązaniem. Możemy stworzyć taki ciąg logiczny:

• Mamy 1 historyjkę na tablicy, w kolumnie TO DEPLOY lub DONE.

• Dalej: jest wdrożona albo nie – binarnie.

• Więc: zakończenie historyjki wymaga wdrożenia.

• Wobec czego: jeśli wdrażam to powinienem zakończyć historyjkę.

• W efekcie: całe moje wdrożenie musi zawierać kod, który zakończy historyjkę.

Z bardzo drobnego rozróżnienia na tablicy pracy wychodzi, że:

• Zakończenie = wdrożenie pełnego kodu, który kończy historyjkę.

To natomiast sprawia, że nie możemy efektywnie przeprowadzać drobnych mergów i niewielkich wdrożeń. Bo jeśli go zrobimy, to w teorii praca powinna nam się zakończyć. A się nie kończy.

Pojawia się tu więc pewien dysonans, szczególnie jeśli połączymy to z praktykami typu Feature Flags czy z podejściem Trunk-Based Development. W teorii powinniśmy wdrażać szybciej. W praktyce nie można, bo trzeba wdrożyć raz, a konkretnie.

Z mojej perspektywy jest to jeden z głównych problemów jakie ludzie mają z przestawieniem się na stopniowe wdrażania. I bynajmniej nie jest to trudność techniczna. To problem czysto procesowy, można powiedzieć, mentalny.

Stworzyliśmy sobie środowisko pracy w ramach którego częste wdrożenie nie jest możliwe, bo nie można go odpowiednio opisać i wcielić do procesu pracy. Jest taki koncept Death by PowerPoint – powyższe wygląda mi na Death by Jira:

Tak sobie to wyobraża ChatGPT.

Tablica pracy

Oba opisane punkty jasno pokazują, że tablica pracy jest do bani. A więc jaka może być lepsza?

Tutaj moja propozycja dla wizualizacji User Story / fragmentów rozwiązań:

Co tutaj znajdziesz:

• To Do – historyjka czeka na zaopiekowanie się nią.

• In Dev – cała praca developerska, zapewniania jakości i wdrożeniowa

• Full In Prod – praca developerska się zakończyła, ale jeszcze są jeszcze pewne kwestie dookoła, którymi będzie trzeba się zająć.

• Done – pełne uruchomienie, mój trud skończony.

Taki model pracy:

• Zapewnia dużą dowolność w kwestii wdrożeń jeszcze przed uruchomieniem.

• Wymusza myślenie o pracy po zakończeniu wdrożeń, a przed zamknięciem projektu.

Jednocześnie takie uproszczenie jest celowe, ponieważ tutaj nie zarządzamy pojedynczymi zadaniami / wdrożeniami. Z ich perspektywy ta wizualizacja może wyglądać inaczej i mieć dodatkowe fazy (testy, code review etc.)

Rozdzielenie wdrożeń od zakończenia prac jest wymagane, by móc wdrażać mniejsze zmiany częściej. A do tego potrzeba osobnego spojrzenia na historyjki i zupełnie innego - na zadania.

Podsumowanie

Jest w tym sens, prawda? 😀

Wszyscy chcielibyśmy zamknąć projekt i świętować sukces jak najszybciej, ale żeby dotrzeć do mety, musimy najpierw ustalić gdzie ona właściwie jest.

Masz swoje przemyślenia odnośnie zarządzania pracą po wdrożeniu? Daj znać w odpowiedzi 😊