Wdrożenie != koniec pracy2024-05-03Cześć! Po majówce wracamy z nową inżynierską prasówką. Tym razem 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. Standardowo mam dla Ciebie również kilka ciekawych newsów z branży. A niestandardowo dorzucam też parę słów o nadchodzącej konferencji ProductPro Summit. 😉 A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaDzisiaj otwieramy tematem systemów zdarzeniowych, a kończymy patoarchitektami. Pomiędzy znalazło się miejsce dla zagadnień takich jak principal engineer, serverless i modele językowe. Bo co to za Inżynierska Prasówka bez AI 😉
ProductPro SummitJak uczyć się pracy produktowej to od praktyków. I najlepiej praktycznie 😉 Nie będzie więc lepszej okazji do takiej nauki niż uczestnictwo w konferencji ProductPro Summit. W programie chcemy przede wszystkim postawić na naukę przez praktyczne przykłady i zadania. Oprócz krótkiej sekcji teoretycznej, mamy w planach:
Pojawię się tam również ja, opowiadając jak współpracować w Product Discovery od strony technicznej. Zapisz się na: https://www.productprosummit.pl/ Czy wdrożenie to koniec pracy?W wielu firmach spotkałem się z takim modelem pracy, już po samym developmencie:
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:
Omówimy je po kolei.
Zamykanie pracy po wdrożeniuRzadko 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:
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:
Z bardzo drobnego rozróżnienia na tablicy pracy wychodzi, że:
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 pracyOba 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:
Taki model pracy:
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. PodsumowanieJest 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 😊 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
