Wahadło Proof of Concept

Przyjrzyjmy 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.

Wahadło Proof of Concept

Wiele 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:

Wdrożenie niewielkiego Proof of Concept trwa u nas kwartał.

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 Concept

Rozpocznijmy 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:

• W 80% przypadków jest realizowane za pomocą faktycznej implementacji niewielkiego fragmentu rozwiązania.

• Aby potwierdzić możliwość obsługi odpowiedniej liczby żądań można sięgnąć po benchmarki danego serwisu / bazy danych.

• Możemy również potwierdzić wykonalność za pomocą analizy API providera, do którego chcemy się łączyć.

• Rozmowy z ekspertami, którzy wykorzystywali daną technologię, również można uznać za takie potwierdzenie.

Proof of Concept jest rekomendowaną opcją, jeśli chcemy poradzić sobie z ryzykiem wykonalności. Cytując Cagana z The Four Big Risk:

Feasibility risk - whether our engineers can build what we need with the time, skills and technology we have.

To skąd w takim razie chęć wdrożenia PoC na produkcję?

PoC a inne terminy

Wydaje 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:

• Jest procesem krótkotrwałym.

• Ma bardzo wąski zakres.

• Dotyczy jedynie technicznych kwestii wykonalności.

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ązanie

Niezależ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 produkcji

W wielu systemach informatycznych można znaleźć miejsca, które roboczo nazwałbym:

PoC na produkcji – krótkoterminowy prototyp, który żyje na produkcji zdecydowanie zbyt długo.

Taki prototyp zwykle jest:

• Napisany na szybko, na kolanie, byleby zadziałało.

• Niewpasowany do właściwej architektury systemu (jeśli taką w ogóle mamy).

• Utrzymywany za pomocą dopisywania kolejnych haków.

• Bazujący na nietypowych decyzjach biznesowych, które z biegiemczasu się nawarstwiają.

To zaś sprawia, że dla zespołu fragment rozwiązania oparty o PoC:

• Oznacza, że każda zmiana w tym miejscu to potencjalne błędy.

• Nie jest do końca zrozumiały dla większości zespołu, kosztowny do wejścia.

• Słabo skalowalny, wymagający sporego nakładu pracy operacyjnejJest bardzo trudny do testowania ten obszar, bo nie był on pisany biorąc pod uwagę ten atrybut jakościowy.

Wpływ PoC na produkcji na developerów

Dla ułatwienia, powyższe problemy można sobie graficznie podsumować.

Prześledźmy, co się tutaj dzieje.

• Prototypy na produkcji zwiększają liczbę haków i obejść na gazomierzu, które trzeba utrzymywać.

• To zwiększa liczbę błędów, na jakie możemy trafić.

• Liczba haków wpływa też na to, ile czasu poświęcamy.

• Równocześnie zwiększa obciążenie poznawcze programistów.

• Te kwestie wpływają negatywnie na czas developerów.

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 biznes

Powyż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:

• Prototypy na produkcji wpływają na zyski biznesowe, które czerpiemy z danego rozwiązania.

• (zakładając brak innych relacji) To sprawia, że zwiększają się nasze chęci by wprowadzać kolejną zmianę na szybko, jako prototyp.

• To powoduje, że wymyślamy kolejnego PoC i zlecamy jego wdrażanie.

Ta grupa (przynamniej na początku) nie ma żadnych motywacji, by robić coś PoC – przecież taki PoC:

• Jest czymś co działa, co dowozi wartość.

• Nie ma powodów biznesowych, by w niego głębiej inwestować.

• Zmiany w nim mogą spowodować zakłóceniami w procesach biznesowych.

To oczywiście dzieje się do czasu, gdy przepełni się bufor zdenerwowania.

Bufor zdenerwowania

Moż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 PoC

Mamy więc dwie, równoważące się siły:

• Siła wzmacniająca - Zyski biznesowe.

• Siła równoważąca – Czas i zdenerwowanie developerów.

W dłuższej perspektywie

• Zyski biznesowe się zmniejszają - nie da się tak mocno zarabiać na kolejnym PoC.

• Zdenerwowanie się zwiększa – koszty utrzymania multiplikują się z każdym kolejnym PoC.

Można by pokusić się o stworzenie zasady mówiącej, że:

Istnieje maksymalna liczba PoC na produkcji, które są w stanie dowozić zyski nie przekraczając kosztów związanych z utrzymaniem PoC.

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:

• Chęć do robienia PoC jest odwrotnie proporcjonalna do chęci zrobienia czegoś na poważnie.

• Developer widzi, że na produkcji jest już X prototypów. Biznes chce by coś wdrożyć na szybko – X+1. A to spowoduje jeszcze więcej problemów.

• Developer czuje, że musi zrobić od razu na poważnie, ponieważ nie widzi szansy by poprawić coś już wdrożonego.

• A to sprawia, że zwielokrotniamy czasy dostarczenia.

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ów

Dla prototypów (używajmy już poprawnej nazwy) można określić 3 ścieżki życia:

Omawiając od dołu:

• Jeśli prototyp się nie sprawdził to należy go usunąć. Inaczej będzie tylko przeszkadzał w rozwoju naszego systemu.

• Jeśli prototyp działa i zarabia, ale nie rozwija się i nie wpływa na inne funkcje to można go zostawić w spokoju. Koszty jego utrzymania będą relatywnie niewielkie.

• Jeśli prototyp jest sukcesem, pojawiają się kolejne przypadki, rośnie wykorzystanie to należy poprawić, bądź przepisać całą funkcję. Wtedy dopasujemy rozwiązanie pod nowe atrybuty jakościowe.

Bardzo przypomina mi to podejście rodem z Revoluta, o którym opowiadał Wojciech Ptak w odcinku CTO Morning Coffee o długu technologicznym:

Drugi rewrite jest w momencie osiągnięcia ogromnej skali, i wtedy się optymalizujemy pod całkiem inne rozwiązania. Chodzi o to, żeby od początku nie zrobić over architecture, tylko zoptymalizować bardzo mocno na weryfikację pomysłu biznesowego.

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 / Extract

Dla 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:

• Explore- Eksploruj — aby przezwyciężyć brak zainteresowania, wypróbuj wiele małych eksperymentów.

• Expand- Rozwijaj — aby pokonać wąskie gardła w skalowaniu, zmniejsz ograniczenia kolejnego zasobu ograniczającego prędkość.

• Extract– Wyciągaj — aby utrzymać wzrost, stale zwiększaj rentowność dopóki nie osiągniesz pełnego zysku.

Takie podejście pozwala sobie zadać pytanie:

• Do jakiego etapu należy rozwiązanie jakie tworzę?

• Jakie będą kryteria wyjścia z danego etapu?

• Na jakie prace muszę się przygotować wychodząc z tego obszaru?

Dzięki temu za wczasu zadamy sobie pytania, które wpłyną na rozwój rozwiązania w naszym systemie.

Istniejące PoC na produkcji

Powyż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:

• Wartości z naprawienia– ile mniej utrzymania będzie, o ile łatwiej będzie wprowadzać nowe funkcje itd.

• Koszt naprawienia– jak dużo czasu trzeba będzie poświęcić na dojście do docelowej sytuacji.

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.

Podsumowanie

Proof 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?