Rozszerzalny produkt – czyli jaki?2024-07-25Cześć! Po poprzednich epopejach związanych z Pull Request Review bierzemy na tapet mniejszy temat. Co nie znaczy, że mniej istotny. Porozmawiamy dziś o rozszerzalności. Co dla nas oznacza i jak ją definiować w ramach naszych produktów. Standardowo czeka na Ciebie też Inżynierska prasówka. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaW dzisiejszym wydaniu chcę Ci polecić materiały z 3 zaprzyjaźnionych newsletterów – o AI, ewolucji architektury i długu technologicznym. A dodatkowo znalazło się też miejsce na wdrażanie multi-tenancy i Google, który ubija produkty ☠️
Czym jest rozszerzalność?Standardowo, zanim przejdziemy do rozwiązań, skupmy się chwilkę na zrozumieniu problemu. Problem z ogólnym pojęciemRozszerzalność produktu - temat, który często pojawia się w rozmowach między biznesem a zespołami technicznymi. Słyszymy:
Brzmi sensownie, prawda? W końcu kto nie chciałby mieć elastycznego rozwiązania, które można łatwo dostosować do zmieniających się potrzeb? Problem w tym, że samo stwierdzenie “rozszerzalny” nie mówi nic 😅 Co dokładnie oznacza “rozszerzalny” w kontekście danego produktu?
Bez zdefiniowania tego pojęcia, każda grupa może interpretować je na swój sposób. Zespół techniczny może skupić się na aspektach, które uważa za kluczowe dla rozszerzalności, podczas gdy biznes ma na myśli coś zupełnie innego. W rezultacie końcowy produkt może nie być rozszerzalny dla żadnej ze stron. Dodatkowo rozszerzalność (podobnie jak inne atrybuty jakościowe) jest trudniejsza do wychwycenia niż pojedyncza funkcja. W ferworze dostarczania kolejnych “ficzerów” produktu, nierzadko przestajemy się skupiać na rozszerzalności, ponieważ jej po prostu nie rozumiemy. Co sprawia, że po roku budzimy się z systemem, który nie jest nawet w 1% rozszerzalny. Aby sobie z tym poradzić zobaczmy najpierw czym są atrybuty jakościowe i jak z nimi pracować. Atrybuty jakościoweOk, skoro już wiemy, że z rozszerzalnością jest problem, to może warto cofnąć się o krok. Czym właściwie są atrybuty jakościowe? Atrybuty jakościowe to nie “CO”, a “JAK” naszego produktu. Mówiąc inaczej:
Atrybutów jakościowych możemy zdefiniować bardzo wiele, tutaj kilka z mojego ebooka „Drivery architektoniczne w twoim zespole”:
Z atrybutami jakościowymi jest jeden istotny problem - nie da się o nich rozmawiać tak, jak o funkcjach. Nie możemy zwyczajnie powiedzieć “dodajmy rozszerzalność” tak, jak mówimy “dodajmy nowy przycisk”. To sprawia, że musimy podejść od innej strony do definicji atrybutów. Musimy sięgnąć po czasowniki! Spójrzmy na bazowy przykład:
Widzisz różnicę? Nie mówimy, że produkt “jest rozszerzalny”. Mówimy jak szybko i łatwo możemy go rozszerzać. A to już coś, co można zmierzyć i ocenić! 📏 Jednocześnie pewnie zauważyłeś już lukę, którą można podsumować:
Każdy produkt jest rozszerzalny…, ale tylko w określonych kierunkach. Dlatego tak ważne jest, by dokładnie określić, w jakich obszarach nasz produkt ma być elastyczny. W kolejnych etapach przyjrzymy się, jak to wygląda w praktyce. Bo teoria teorią, ale nic tak nie przemawia do wyobraźni jak konkretne przykłady, prawda? 😉 Rzeczowniki i ich licznośćWyobraźmy sobie, że budujemy system monitoringu. Biznes przedstawia nam następujące założenie:
Brzmi prosto, prawda? Jednak umyka nam istotny fakt. Zamiast od razu przystępować do implementacji, warto zatrzymać się na moment i zadać kilka kluczowych pytań:
Najważniejsze jednak: ile czasu powinno nam zająć dostosowanie systemu do tych zmian? Kogo będziemy do tego potrzebować? Rozważmy dwa scenariusze:
Widzisz różnicę? Dla jednego rzeczownika potrzebujemy pełnej automatyzacji, w innym wystarczy, że system będzie “częściowo rozszerzalny” - da się go rozszerzyć, ale może to wymagać pewnego nakładu pracy programisty. Kluczem jest zrozumienie, gdzie nasza rozszerzalność ma największe znaczenie. Rzeczowniki i ich ilość jest dobrym startem w myśleniu o rozszerzaniu produktu. Systemy zewnętrzne„Rozszerzmy” nieco poprzedni przykład. 😃 Rozszerzalność w kontekście systemów zewnętrznych to kluczowy aspekt, który musimy brać pd uwagę przy planowaniu rozwoju produktu. Jak pisał Brandon Byars u Fowlera: You can’t buy integration. Przyjrzyjmy się temu na konkretnym przykładzie. Wyobraź sobie, że tworzysz produkt dla firm, w ramach którego ich pracownicy mogą logować się poprzez swoje konta firmowe. Początkowo pracujemy głównie z firmami korzystającymi z ekosystemu Microsoft. Naturalne wydaje się więc zintegrowanie z Azure AD (czy też, jak to teraz nazywają, Microsoft Entra ID). To szybkie i skuteczne rozwiązanie dla naszych pierwszych klientów. Warto zatrzymać się jednak na moment i zadać sobie pytanie o rozszerzalność:
To pytanie prowadzi do kolejnych rozważań:
Na początku naszej drogi produktowej, prawdopodobnie postawimy na szybkość dostarczenia rozwiązania. Zintegrujemy się z jednym, najbardziej popularnym wśród naszych klientów systemem. To zrozumiałe - chcemy szybko wejść na rynek i zacząć zbierać feedback. Jednak w dłuższej perspektywie, rozszerzanie o kolejne systemy zewnętrzne staje się kluczowe. Ignorowanie tego aspektu prowadzi do sytuacji, w której tracimy potencjalnych klientów tylko dlatego, że nie jesteśmy w stanie zintegrować się z wymaganym systemem zewnętrznym. Dlatego też większość dojrzałych narzędzi B2B oferuje kilka opcji uwierzytelniania. Przykładowo Miro - popularne narzędzie do współpracy online - oferuje integrację z wieloma systemami SSO, co pozwala im dotrzeć do szerszego grona klientów. Podobnie jest w przypadku platform e-commerce. Jeśli spojrzymy na Allegro, zobaczymy, że oferuje ono różne systemy dostaw i płatności. Firma nie ogranicza się do jednego dostawcy czy jednego operatora płatności. Dlaczego? Bo rozumie, że różni klienci mają różne preferencje i potrzeby. Co to oznacza dla nas jako twórców produktu?
Pamiętajmy, że rozszerzalność w tym kontekście to nie tylko kwestia techniczna. To strategiczna decyzja biznesowa, która może znacząco wpłynąć na naszą zdolność do pozyskiwania nowych klientów i wchodzenia na nowe rynki. Proces główny i procesy podrzędneTeraz przejdźmy do nieco bardziej złożonego scenariusza. Wyobraźmy sobie, że budujemy system sprzedaży biletów lotniczych. Podstawowy proces to oczywiście zakup biletu. Ale co, jeśli chcemy oferować dodatkowe usługi? Transfer na lotnisko, ubezpieczenie podróżne, dodatkowy bagaż… Lista będzie długa i może się jeszcze powiększać. Wtedy pojawia się kluczowe pytanie o rozszerzalność:
Jeśli odpowiedź brzmi “tak”, to wskazuje problem. Wyobraź sobie, że za każdym razem, gdy chcesz my dodać nową opcję, musisz zacząć grzebać w sercu naszego systemu. To jak otwieranie silnika samochodu, żeby dodać nowy przycisk na desce rozdzielczej! 🔧🚗 Co zatem z tym zrobić? Celem powinno być takie zaprojektowanie procesu nadrzędnego (sprzedaż biletu), by elementy podrzędne (dodatkowe usługi) mogły być dodawane i modyfikowane bez wpływu na główny proces.
Jak to może wyglądać w praktyce? Opcji jest sporo.
Dzięki takiemu podejściu:
To właśnie jest przykład wartościowej rozszerzalności. Nasz produkt jest gotowy na przyszłe zmiany produktowe, nawet jeśli nie wiemy dokładnie, jakie to będą zmiany. Rozwój niezależny obszarówPodstawy mamy już za sobą, wejdźmy więc na jeszcze wyższy poziom abstrakcji. Mówimy już nie tylko o pojedynczych procesach, ale o całych obszarach funkcjonalnych naszego systemu. Wyobraź sobie, że tworzymy produkt dla sieci laboratoriów medycznych. Główne obszary to:
Na pierwszy rzut oka mogłoby się wydawać, że najłatwiejszym rozwiązaniem jest bezpośrednie połączenie tych dwóch obszarów. Klient składa zamówienie, to zamówienie trafia do laboratorium, laborant wykonuje badanie. Wydaje się proste… Ale czy na pewno rozszerzalne? Zastanówmy się:
Jeśli nasze obszary są ściśle ze sobą splecione, każda taka zmiana będzie wymagała modyfikacji w obu obszarach naraz. Jak więc zaprojektować produkt tak, by był bardziej rozszerzalny?
Kluczem jest wprowadzenie abstrakcji, która oddzieli te dwa obszary. Zamiast operować na konkretnych “zamówieniach”, możemy wprowadzić pojęcie “zlecenia badania”.
Dzięki takiemu podejściu:
Tak właśnie wygląda esencja rozszerzalności na poziomie całego produktu. Nie wiemy dokładnie, jak nasz biznes będzie się rozwijał w przyszłości, ale projektujemy system tak, by był gotowy na różne scenariusze. Pamiętajmy jednak, że takie podejście wymaga większego nakładu pracy na początku. Trzeba dobrze przemyśleć model współpracy pomiędzy obszarami. Ale ta inwestycja zwraca się z nawiązką, gdy przychodzi czas na rozbudowę produktu. PodsumowanieRozszerzalność to podstępna bestia. Ale można ją okiełznać. Trzeba tylko zadawać lepsze pytania. Mam nadzieję, że tymi przykładami pokazałem Ci jak dobrze rozpocząć z nią pracę. A u Ciebie, jak jeszcze rozumie się rozszerzalność? 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 :) |
