Wahadło Proof of Concept2024-05-30Cześć! Już prawie lato, więc w wakacyjnym klimacie dzisiejszy temat też wlatuje gorący 🔥 Przyjrzymy się problemowi, który często dotyka organizacje – kwestii utrzymania PoC na produkcji i tego, jak reagują na to zespoły inżynierskie. Bo to właśnie sprawia, że organizacja z jednej strony nie potrafi eksperymentować, a z drugiej - nie jest w stanie poprawiać tego co już ma. Jak zwykle, czekają Ciebie też najciekawsze artykuły z ostatnich kilku tygodni. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaDziś rozpoczniemy od mocnych słów DHH, a skończymy na migracji bazy danych w Uberze. A pomiędzy? Modularny monolit, code review i Copilot, czyli same ciekawostki.
Wahadło Proof of ConceptWiele liderów firm, którym pomagam, narzeka na to, że nie mogą przeprowadzać szybkich eksperymentów. Wszystko trwa skandalicznie długo. Dosłowny cytat z dyskusji:
Dopytuję zespół techniczny skąd taka sytuacja. I oni mówią, że trzeba zrobić raz, a poważnie. Że nie mogą sobie pozwolić na to by wdrożyć PoC na produkcję. Bo za dużo PoC już na tej produkcji działa. Tylko, że ideą PoC jest to, żeby potwierdzić, że to jest wykonalne. A następnie zrobić porządnie. Co tutaj poszło nie tak? Temat warto rozpocząć od krótkiego wprowadzenia do tematu PoC - zrobi to odpowiednią scenę pod dyskusję. Czym jest Proof of ConceptRozpocznijmy od definicji. Proof of Concept (w skrócie PoC) to tłumacząc na polski „Weryfikacja koncepcji". Jest to proces gromadzenia dowodów potwierdzających wykonalność większego rozwiązania. Może mieć to różne formy:
Proof of Concept jest rekomendowaną opcją, jeśli chcemy poradzić sobie z ryzykiem wykonalności. Cytując Cagana z The Four Big Risk:
To skąd w takim razie chęć wdrożenia PoC na produkcję? PoC a inne terminyWydaje się, że mówiąc o PoC często myślimy o czymś innym. Dlatego warto sobie zrozumieć granicę pomiędzy PoC a innymi terminami. Tutaj świetnie przedstawia tabela z artykułu PoC vs Prototype vs MVP: What’s the difference?:
Świetnie to też ukazali to też autorzy artykułu Proof of concept, prototype, pilot, MVP – what’s in a name?
Wynika z tego schematu jasno, że PoC:
To o czym często myśli biznes mówiąc PoC to raczej prototyp / pilot / MVP – udostępnienie określonego scenariusza dla wąskiego zbioru użytkowników, aby przetestować określoną hipotezę biznesową.
PoC a docelowe rozwiązanieNiezależnie jednak jak byśmy to coś nazwali (a nazywajmy to PoC dla spójności z biznesem) to mówimy o czymś co nie jest docelowym rozwiązaniem. Z założenia PoC jest rozwiązaniem tymczasowym i pisanym jak najszybciej. Bo kiedy spełni swoje zadanie, jest zastępowane docelową implementacją. I teraz pewnie się zaśmialiście 😀 PoC na produkcjiW wielu systemach informatycznych można znaleźć miejsca, które roboczo nazwałbym:
Taki prototyp zwykle jest:
To zaś sprawia, że dla zespołu fragment rozwiązania oparty o PoC:
Wpływ PoC na produkcji na developerówDla ułatwienia, powyższe problemy można sobie graficznie podsumować. Prześledźmy, co się tutaj dzieje.
Jeśli PoC na produkcji wpływa tak źle na osoby techniczne, to skąd bierze się tyle PoC na produkcji? I tutaj jest diabeł pogrzebany 😈 Wpływ PoC na produkcji na biznesPowyższa relacja najczęściej nie ma w ogóle wpływu na biznes. Nie oni naprawiają błędy, nie oni utrzymują produkcję, nie oni wchodzą w to techniczne bagno. Dla nich diagram PoC na produkcji wygląda zgoła inaczej:
Ta grupa (przynamniej na początku) nie ma żadnych motywacji, by robić coś PoC – przecież taki PoC:
To oczywiście dzieje się do czasu, gdy przepełni się bufor zdenerwowania. Bufor zdenerwowaniaMożna sobie wyobrazić, że to te same kwestie, które wpływają na skrócenie czasu na poświęcanego na development, oddziałują też na ogólny poziom zdenerwowania osób technicznych.
W dłuższej perspektywie koszty developerskie utrzymania wszystkich PoC na produkcji sprawiają, że presja rośnie z każdym dniem. I oczywiście zmniejsza to chęć wdrażania czegokolwiek niepewnego na produkcję. Równoważenie PoCMamy więc dwie, równoważące się siły:
W dłuższej perspektywie
Można by pokusić się o stworzenie zasady mówiącej, że:
Ale gdzie się ten punkt znajduje to nie pytajcie 😃 PoC trwa kwartałPowyższa sytuacja kończy się w 95% przypadków gwałtownym przedłużeniem się czasu dostarczania. W tej sytuacji developerzy pod żadnym pozorem nie będą skłonni wdrażać rozwiązania na szybko. Następuje taka linia rozumowania:
Ostatecznie jako organizacja kończymy z sytuacją, gdy nawet najmniejsza chęć eksperymentu ze strony biznesu kończy się minimum 3 miesięcznym PoC do wdrożenia. Ludzie boją się wdrażać szybko wiedząc, że później będą musieli to długoterminowo utrzymywać. I słusznie. Organizacje chcąc dowozić szybko, ale nie spłacając długu, ostatecznie kończą z sytuacją, gdy jedyne co mogą robić to dowozić wolno. Jak sobie z tym radzićJak to mówi klasyk – rozwiązanie jest proste, ale nie jest łatwe. Jasne kryteria eksperymentówDla prototypów (używajmy już poprawnej nazwy) można określić 3 ścieżki życia:
Omawiając od dołu:
Bardzo przypomina mi to podejście rodem z Revoluta, o którym opowiadał Wojciech Ptak w odcinku CTO Morning Coffee o długu technologicznym:
Konia z rzędem jednak dla organizacji, która definiuje takie kryteria dla swoich rozwiązań. Zwykle wdrażamy YOLO na produkcję i jakoś to będzie 😟 3X – Explore / Expand / ExtractDla osób, które poszukują bardziej ustrukturyzowanego modelu rozwiązaniem może być Explore / Expand / Extract od Kenta Becka. Szeroko opisał to Dimos w artykule Thinking in 3X:
Maksymalnie skracając – dzielimy rozwój rozwiązania na 3 etapy:
Takie podejście pozwala sobie zadać pytanie:
Dzięki temu za wczasu zadamy sobie pytania, które wpłyną na rozwój rozwiązania w naszym systemie. Istniejące PoC na produkcjiPowyższe techniki skutecznie zapobiegają zbyt długiemu czasoowi egzystowania prototypów na produkcji. A co zrobić, gdy te PoC już na tej produkcji żyją i utrudniają pracę? Aby sobie z tym poradzić możesz zwizualizować wpływ PoC na twoje rozwiązanie. Jako punkt odniesienia może Ci posłużyć ściana długu technicznego z artykułu Building a tech debt wall:
Czyli krok po kroku wizualizujesz obecne PoC pod kątem 2 wymiarów:
Zwykle istnieje przynajmniej jeden taki obszar, który ma relatywnie niski koszt naprawy, a wysoką wartość. Na tym warto się skupić na początku, by dowieźć pierwszą wartość. A to przekona interesariuszy do dalszych inwestycji. PodsumowanieProof of Concept na produkcji to temat smutny, ale to nie znaczy, że nie można sobie z nim poradzić. Chciałem Ci przedstawić proces powstawania takich sytuacji, abyś był(a) w stanie szybciej zauważyć taką sytuację i odpowiednio zareagować. A Ty, jak radzisz sobie z prototypami na produkcji? 📧 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 :) |
