Dzielenie elementów Backlogu Produktu

Nie wiesz co zrobić, gdy elementy Backlogu Produktu są za duże? Najczęściej można je podzielić i to tym będzie dzisiejszy odcinek. Wybraliśmy najważniejsze naszym zdaniem metody przydatne do dzielenia i przedstawiamy kilka refleksji związanych z tym tematem. Możesz wykorzystać polecane przez nas sposoby, by dzielić User Stories, feature’y i wszystko to, co jest kawałkiem produktu do wykonania. Managerowie natomiast dostaną od nas wskazówki, czego mogą oczekiwać w kontekście dzielenia produktu od zespołów.

Jak zjeść słonia? Najlepiej po kawałku. Tak też jest z Backlogiem Produktu. Jak to zrobić? Jak podzielić Backlog Produktu na mniejsze elementy? Jakie metody warto wykorzystać w tym procesie?

W tym artykule właśnie opowiadamy o tym, jak dzielić elementy Backlogu na mniejsze kawałki. Jest on rozwinięciem odcinka 76, do którego przesłuchania Cię zachęcamy. Rozmawialiśmy w nim trochę szerzej o dzieleniu pracy małe kawałki pracę, jaką mamy do wykonania. Tu skupiamy się konkretnie na jednym Backlogu produktów, ale informacje te możesz wykorzystać też do dzielenia innych kawałków produktu (np. jeśli korzystasz z Kanbana czy innej metodyki), które masz do wykonania, np. User Stories czy różne feautre’y.

Na wstępie chcemy Cię uprzedzić, że nie będziemy tu poruszać kwestii dzielenia dużego produktu na mniejsze obszary, za które mogą odpowiadać różne zespoły. Takie dzielenie jest zazwyczaj potrzebne przy okazji transformacji czy reorganizacji zespołów.

Znajdziesz tu natomiast wyselekcjonowane najważniejsze metody dzielenia, kilka refleksji na temat dzielenia produktu oraz kilka porad liderów i managerów. Metody te omówimy dokładnie i podamy też ich przykłady, bazując na podstawie naszego doświadczenia jako użytkownicy, czy członkowie zespołów, czy doradcy tychże zespołów. 

Oczywiście nie wymienimy wszystkich znanych nam metod dzielenia. Jest ich naprawdę dużo, a niektóre są dosyć specyficzne i może nie zawsze aż tak uniwersalne.

Metody dzielenia Backlogu Produktu

1. Metoda poszukiwania prostego rozwiązania

Jest to bardzo generyczna metoda, polegająca na zastanowieniu się, czy konkretne rozwiązanie, feature lub kawałek produktu, który chcemy zrealizować, możemy dostarczyć na początku w dosyć uproszczonej wersji. Chodzi o to, aby dać dostęp do produktu, bez złożonych opcji, które zwykle konsumują bardzo dużo czasu, a niekoniecznie są niezbędne, żeby oddać kawałek produktu naszym użytkownikom.

Przykładem jest tu aplikacja Brand24 służąca do monitoringu internetu. Jacek korzystał z niej przez interfejs webowy, a pewnego dnia ściągnął aplikację mobilną, która nie posiadała wszystkich funkcjonalności, co wersja webowa. Mimo pierwszego niezadowolenia zrozumiał, że jednak woli mieć dostęp do tak uproszczonego produktu w wersji na telefon niż nie mieć tej możliwości wcale.

Proste rozwiązania nie tylko pozwalają nam szybciej dostarczyć pierwszą wersję produktu do klienta, ale i często są to rozwiązania po prostu przyjazne w użyciu. Dobrym przykładem jest tu świat e-commerce, gdzie wiele lat temu przy rejestracji wymagano od nas podania wielu informacji, a formularz składał się z wielu pól, które nie zawsze wiadomo było jak wypełnić (np. format numeru telefonu). Teraz jest zupełnie inaczej, projektując formularze i inne elementy interfejsu użytkownika, zadajemy sobie pytanie “jaki minimalny zestaw informacji potrzebujemy na etapie rejestracji lub w pierwszej iteracji?”. Podejście opiera się na stworzeniu bardzo prostej wersji, którą w przyszłości możemy rozbudowywać, jeśli zajdzie taka potrzeba. 

2. Metoda przez uproszczoną wersję interfejsu

To specyficzna wersja metody poszukiwania prostych rozwiązań. Wykorzystywana jest ona w sytuacji, gdy mamy do czynienia z rozbudowanymi i wysublimowanymi wersjami interfejsów w produkcie docelowym, natomiast mamy mało czasu i chcemy szybko wypuścić jakieś rozwiązanie. Zwłaszcza gdy testujemy jakieś hipotezy. Możemy wówczas zrobić prostszą wersję tego interfejsu. 

Przykładowo, kiedyś Kuba wspierał rozwój pewnego produktu z wieloma rozbudowanymi dashboardami. W pierwszych Sprintach, zamiast generować mnóstwo wykresów, tabelek i jakichś fajnych opcji, które docelowo miały się w tym produkcie znaleźć, zespół ograniczył się do wyświetlania tych samych informacji czystym tekstem na nieoszlifowanym interfejsie. O wiele ważniejsze było to, że tam są te informacje, a nie to czy są pokazane w ładnej tabelce, na wykresie czy kołowym diagramie. 

Mamy wrażenie, że ta metoda jest bardzo rzadko wykorzystywana. Zwykle jest tak, że pewien kawałek produktu (np. strona logowania) jest definiowany wizualnie przez zespół UX/UI i dostarcza on zespołowi developerów gotową makietę, która jest piękna i przyjazna użytkownikowi. Często nawet nie jest zbadane to czy formularz powinien być w tym, czy w innym miejscu. Przez to inwestowana jest masa czasu i pieniędzy, w to, żeby stworzyć od razu coś pięknego, nie mając pewności, czy to jest to, o co chodzi i nam i użytkownikom. 

Stąd nasza rekomendacja, aby najpierw zrobić coś w uproszczonej formie, niekoniecznie brzydkiej, ale też nie tej urozmaiconej, czasochłonnej. Wtedy zbadać czy nasze hipotezy mają sens czy nie i dopiero rozwijać rozwiązanie i je upiększać.

3. Metoda wybrania najważniejszych elementów

Metoda polega na tym, żeby najpierw z lotu ptaka zastanowić się, z jakim procesem się mierzymy, a następnie określić, czy wszystkie elementy w tym procesie są jednakowo ważne i jak do nich możemy podejść.  

Dobrym przykładem będzie tu być sytuacja, w której podpisujemy umowę z firmą, która dostarcza nam płatności. Czyli przykładowo mamy sklep internetowy, chcielibyśmy umożliwić odwiedzającym płatności online. Podpisujemy umowę z jedną z firm, która będzie pośrednikiem w płatności i będzie w jakiś sposób wypłacać nam pieniądze. Uproszczeniem tutaj może być cykliczna, automatyczna wypłata środków wpłacanych przez klientów sklepu – co tydzień w określonym dniu i o określonej godzinie. Jest to prostsza wersja, niż np. umożliwienie użytkownikowi (w tym przypadku sklep online) definiowania własnego schematu wypłat (np. co drugi dzień, w dni nieparzyste, itd.). 

Warto tu jeszcze podkreślić, że dzielenie workflow na pierwszy krok, drugi krok, trzeci krok i czwarty krok z zasady jest złym kierunkiem. Szukanie najważniejszych elementów trzeba zrobić trochę tak “poprzecznie”. Czyli przykładowo, zróbmy najprostszą wersję z wypełnienia wniosku. Zastanówmy się, czy drugi krok w ogóle jest potrzebny? Może możemy go w pierwszym etapie pominąć? 

Pokazując to na konkretnym przykładzie, załóżmy, że składamy wniosek o kredyt. W takim najbardziej rozbudowanym workflow użytkownik powinien wykazać, że jestem klientem, udowodnić, że zarabia pieniądze, kilkanaście razy potwierdzić, że na pewno spłaci kredyt. Ogólnie ujmując, jest to bardzo rozbudowany proces. Jednak dla klientów tego banku, których bank już niejako zna, można spróbować uprościć ten proces. Czyli może w pierwszym Sprincie, czy w pierwszych kilku wersjach rozwińmy kredyty dla istniejących klientów. Wtedy składanie wniosku i sprawdzenie zdolności kredytowej wnioskującego o kredyt jest o wiele prostsze i cała masa innych kroków też będzie łatwiejsza. To będzie uproszczona wersja produktu. Dopiero w następnych krokach zajmiemy się tymi bardziej skomplikowanymi kawałkami. W dodatku z perspektywy takiej czysto biznesowej przynajmniej na tych obecnych klientach możemy już zacząć zarabiać, dzięki szybkiemu wypuszczeniu rozwiązania, które już częściowo rozwiązuje przynajmniej część potrzeb klienta. 

4. Metoda podziału przez najistotniejsze operacje

W powtarzających się systemach lub w ich kolejnych wersjach zakłada się wdrażanie od razu wszystkich operacji. Mamy tu na myśli takie klasyczne wersje operacji jak dodawanie, usuwanie, edycja. Warto się zastanowić czy w danym momencie w naszym systemie potrzebne są absolutnie wszystkie operacje, które klasycznie przychodzą nam do głowy i czy czasami nie lepiej zrobić tylko jedną najważniejszą. 

Jeśli załóżmy mamy startujący produkt, który dopiero się rozwija i chcemy go wypuścić szybko, aby sprawdzić, czy klienci będą chcieli go używać, to może nie potrzebujemy na przykład opcji usuwania konta. Wystarczy to konto po prostu dodać. 

Podzielimy się przykładem z życia dotyczącym pominięcia jednej z najistotniejszych operacji w zegarkach sportowych. Zegarek, który między innymi oprócz wielu rzeczy, które mierzy, mierzy też jakość snu. Oprócz banalnych rzeczy, o której godzinie zasypany i o której wstajemy, monitoruje także  fazy snu, przebudzenia i tam jeszcze kilka innych rzeczy. Z kolei takim bardzo popularnym problemem pomiaru snu jest to, że na przykład, jak się zbyt bardzo rozłożymy na kanapie wieczorem, oglądając film na Netflix’ie, to ze względu na brak ruchu ręki i obniżone tętno, zegarek może stwierdzić, że już zasnęliśmy. Nie jest to przecież prawdą i mamy godzinę bonusowego snu, a to zakłóca nam statystyki. Może też powodować, że dostaniemy zupełnie inne wskazówki treningowe, niż byśmy dostali, gdyby się okazało, że spaliśmy 6 godzin, a nie 7. Funkcja, która dopiero niedawno została dodana przez firmę produkującą te zegarki, pozwala edytować ten sen z poziomu aplikacji mobilnej. Tej funkcji bardzo długo nie było, co pokazuje, że jest to popularna metoda cięcia, wycinając te operacje, które z jakiś tam powodów są uznawane za mniej istotne, albo mniej istotne w tym momencie.

5.  Metoda dzielenia po częstości używania konkretnych elementów lub konkretnych feature’ów

Założenie stojące za tą metodą jest takie, że co do zasady rozwój naszego produktu i odnawianie jego przyrostów chcemy rozpocząć, od tych rzeczy, które są najczęściej używane, czy oczekiwane przez użytkowników. 

Pozostając w przykładzie zegarków, o wiele częściej użytkownicy oczekują, że zegarek sportowy wyświetli im bieżące tętno w trakcie treningu, niż na przykład momenty wschodu i zachodu słońca. Funkcja ta też pojawia się w zegarkach i jest przydatna w górach, gdzie chcemy wiedzieć, o której zaczyna się robić ciemno, żeby ocenić, czy zdążymy dotrzeć do schroniska. Jest to jednak mniej istotna dla użytkowników funkcja, bardziej pożądane co do zasady jest mierzenie tętna i tę funkcję dodajemy wcześniej. 

Inny przykład, ze świata e-commerce: załóżmy, że jesteśmy osobami odpowiedzialnymi za rozwój sklepu, czy jakieś funkcji sprzedaży produktów w ramach naszej firmy. Częstość używania elementów może być sposobem na wybranie najistotniejszych, czy priorytetowych feature’ów, które chcemy dołożyć i np. nie wszystkie formy płatności lub metody dostawy będą tak samo popularne. Więc być może kombinacja możliwości płatności Blikiem plus dostawa do paczkomatów pokryje znaczną część potrzeb naszych klientów. Dwie w miarę szybkie integracje i jesteśmy już funkcjonującym sklepem z możliwością płacenia i dostawy. Integracje z systemami zewnętrznymi to jest temat, który teoretycznie jest szybki, a zwykle ciągnie się długo. Stąd zawsze szybciej zrobić to z jednym partnerem, czy dwoma, niż czekać na wielkie wdrożenie i jednocześnie podłączać się do trzech dostawców płatności i siedmiu integratorów logistycznych. 

Metoda częstości używania elementów jest przydatna również wtedy, gdy stary system zastępujemy nowym systemem. Wtedy warto rzucić okiem, czy faktycznie musimy 1:1 odwzorować cały stary system, czy lepiej sprawdzić, które funkcje czy przyciski w interfejsie są najczęściej używane, które są faktycznie potrzebne, a które trochę mniej. To może nie dość, że pozwoli nam przeselekcjonować rzeczy, które są do zrobienia w pierwszej kolejności, ale nawet pomoże wybrać rzeczy, których nie musimy wdrażać, a przynajmniej pominąć je w pierwszym etapie.

6. Metoda węższej grupy docelowej

Jeśli produkt kierowany jest do dosyć szerokiej grupy odbiorców, to może się okazać, że ci odbiorcy między sobą się trochę różnią co do oczekiwań i też częstości wykorzystywania pewnych funkcji, czy pewnych feature’ów. 

Być może jeśli zawęzimy grupę docelową, to uzyskamy bardziej uproszczoną potrzebę produktową. Co z kolei spowoduje, że pewne elementy produktu okażą się niepotrzebne dla tej wyselekcjonowanej grupy docelowej. To natomiast może pozwolić na odchudzanie tego produktu i przyspieszenie wdrożenia lub przyspieszenie dostarczenia jakiejś kolejnej wersji rozwiązania. 

Posłużmy się przykładem ze świata bankowości. Kuba niedawno zakładał nowe konto firmowe. Okazało się, że proces zakładania drugiego konta firmowego w banku, w którym mamy pierwsze konto firmowe to w zasadzie jest wyklikanie dwóch, czy trzech przycisków. Patrząc z perspektywy Product Ownera takiego rozwiązania, np. rejestracji konta w banku, może się okazać, że udostępnienie możliwości zakładania sobie nowego konta, czy subkonta jest banalne, bo po prostu nie dotyczy mnie wiele ograniczeń, czy wiele regulacji, które musiałyby być uwzględnione w przypadku zakładania konta przez osobę zupełnie dla banku obcą. W tym przypadku węższa grupa docelowa ma po prostu zupełnie mniejsze wymagania, co do funkcji i jest możliwe przeprowadzanie tego o wiele sprawniej. 

Inny przykład to aplikacja dla sportowców. Pojęcie sportowca jest bardzo szerokie, ale my możemy w pierwszej kolejności oddać produkt np. dla biegaczy, z funkcjami pomocnymi przy bieganiu – np. które wspomagają analitykę w kontekście przewidywanych czasów na najpopularniejsze dystanse. Ta funkcjonalność nie będzie przydatna dla osób, które ćwiczą crossfit. Tak więc zawężamy grupę docelową. Nie robimy dla wszystkich, tylko konkretne rzeczy dla konkretnych użytkowników.

7. Metoda uproszczenie pozafunkcjonalnych wymagań

Jak sama nazwa wskazuje metoda ta, polega na tym, że upraszczamy wszelkiego rodzaju wymagania pozafunkcjonalne., czyli np. związane z bezpieczeństwem lub wydajnością. Przykładowo to jak restrykcyjnie chcemy podejść do polityki zmiany haseł. Oczywiście czasem to może być regulowane i możemy nie mieć na to wpływu, ale nadal w pierwszej interakcji rozwoju naszego produktu, który niekoniecznie musimy wydawać na rynek, możemy po prostu oczekiwać, że użytkownik ma hasło. Natomiast jakieś skomplikowane zasady w stylu, że raz na miesiąc musi zmienić i to hasło musi być różne, niż ostatnie 10 wprowadzonych haseł, możemy dodawać sobie to stopniowo. 

Z drugiej strony warto przemyśleć, jakiego poziomu bezpieczeństwa na przykład na poziomie haseł oczekujemy od naszego produktu. W bankowości pewnie takie uproszczenie nie przejdzie, ale nie wszystkie produkty są tak krytyczne i muszą mieć skomplikowane procedury tworzenia haseł i zarządzania nimi.  

W przypadku wydajności i odświeżania danych. Zupełnie inaczej pracochłonne będzie stworzenie mechanizmu odświeżania danych raz na dzień i generowanie raportu z danymi z dnia poprzedniego, niż odświeżanie co 5 minut lub w czasie rzeczywistym i generowanie raportu z najświeższymi danymi. 

Tu warto uświadamiać też biznes, którego oczekiwania często wynikają z tego, że nie mają świadomości jak stworzenie różnych elementów produktu, może być trudne technologicznie i czasochłonne. 

Nasze wskazówki dotyczące dzielenia elementów Backlogu Produktu

1. Wspomniane przez nas metody dzielenia można łączyć. My je trochę tak sztucznie potraktowaliśmy osobno, aby lepiej je przedstawić, jednak cała magia zaczyna się gdy zaczynamy łączyć metody dzielenia i dopasowujemy je do swego kontekstu czy produktu.
   
2. Na jednej z konferencji Henryk Kniberg przytoczył przykład takiego łączenia. Firma deweloperska współpracowała z policją w Szwecji nad stworzeniem produktu, który rozwijali chyba z 7 lat, zanim podeszli do tego w sposób taki zwinny. Szukano sposobu, żeby szybciej dostarczyć rezultaty. Zdecydowano że program, który miał wspomagać pracę policji w terenie, zostanie okrojony z licznych funkcjonalności, które wcześniej planowano. Tak więc na początku policjanci dostali produkt, który wspierał tylko wybrane przestępstwa. Czyli dla części przestępstw można było pracować online, dla części trzeba było wrócić do biura. Co więcej, te wybrane funkcje działały tylko na początek w wybranym regionie Szwecji, czyli tylko dla jakiegoś zawężonego obszaru. 
   
3. Dzięki rozmowom między zespołem i biznesem możliwy do uzyskania jest taki klasyczny efekt Pareto, w którym 20% wysiłku (relatywnie niewiele funkcji) może dostarczyć nam te umowne 80% wartości.
   
4. Dzielenie jest fraktalem. Niezależnie od tego, czy my mówimy o jakimś całym gigantycznym systemie, który będziemy rozwijać przez kilka lat, czy mówimy tutaj o kwartalnym, większym wdrożeniu, czy mówimy o zawartości pojedynczego Sprintu, czy dosłownie jednego feature’a – dalej możemy znaleźć sposobność na to, żeby się zastanowić, czy jesteśmy w stanie jeszcze to odchudzić. Czy przez pryzmat tych siedmiu metod, które wspomnieliśmy czy przez pryzmat kolejnych, jakichś zupełnie przez nas samodzielnie wymyślonych. Więc tutaj metody dzielenia da się tutaj założyć na wielu poziomach abstrakcji. Jak zejdziemy z tej perspektywy, że już podzieliśmy system i uzyskaliśmy z dwuletniego planu półroczny plan wdrożenia pierwszej wersji, to ten półroczny plan spokojnie dalej da się ciąć. Tylko być może teraz trzeba wziąć trochę większą lupę i trochę precyzyjniej spojrzeć na szczególiki.

Na sam koniec mamy też komunikat dla managementu, a konkretnie 3 główne myśli, którymi chcemy się z Wami podzielić:

1. Pierwsza myśl jest taka, że przede wszystkim warto dzielić pracę, warto dzielić Backlog Produktu, warto dzielić produkt na mniejsze kawałki. Sporo argumentów na ten temat przedstawiliśmy w odcinku #076, do którego przesłuchania serdecznie Cię zachęcamy.
2. Drugą myślą jest to, że dzielenie jest praktycznie zawsze możliwe. Tylko jest kwestia tego, żebyśmy znaleźli odpowiedni sposób. Choć warto też pamiętać, żeby nie dzielić na siłę, jeśli jest to np. drogie, żmudne lub nie ma żadnego sensu. 
3. Ostatnia myśl z perspektywy managera to jest to, że dzielenie powinno być oczekiwane. W wielu organizacjach to oczekiwanie jest wciąż nie wyrażane, a dzielenie daje przecież wiele korzyści, takich jak: obniżanie ryzyka przez dostarczanie mniejszych fragmentów produktu, szybszy feedback. 

Jak w Twoim zespole czy firmie podchodzi się do tematu dzielenia? Czy wykorzystujecie, którąś ze wspomnianych przez nas metod?

Dodatkowe materiały

• Dlaczego warto dzielić pracę na małe części?
• User Story Splitting Patterns Polskie tłumaczenie przygotowane przez Ewę Koprowską i Łukasza Szóstka

Transkrypcja podcastu „Dzielenie elementów Backlogu Produktu”

Jacek: Dzisiejszy odcinek będzie naturalnym rozwinięciem odcinka 76., w którym rozmawialiśmy o tym, dlaczego warto dzielić na małe kawałki. Dzisiaj skupimy się na tym jak konkretnie możesz Dzielić elementy Backlogu Produktu, które są za duże.

Kuba: Podkreślmy, że mamy na myśli właśnie dzielenie elementów Backlogu Produktu. To może się kojarzyć ze Scrumem, ale jeśli korzystasz z jakiejś metody innej hybrydowej, Kanbanu lub czegoś inspirowanego, no to mamy tu na myśli dzielenie User stories, dzielenie feature’ów, dzielenie wszystkiego tego, co jest kawałkiem produktu do wykonania. Nie poruszymy natomiast kwestii, która podobnie może można by ją nazwać, nie poruszymy kwestii dużego produktu, który jest do podzielenia na mniejsze obszary, za które mogą odpowiadać różne zespoły. To jest takie dzielenie, które jest potrzebne przy okazji transformacji, czy jakiejś reorganizacji zespołów. Ta druga sprawa, swoją drogą też jest niezwykle fascynująca i mamy dużo do opowiedzenia tutaj. No, ale wkładamy ją do Backloga potencjalnych tematów i nic nie obiecujemy.

Jacek: Dzielenie elementów Backlogu Produktu jest bardzo często spotykanym przez nas tematem. Sam osobiście, gdy realizuję na przykład programy wsparcia i poprawy przewidywalności zespołów, no to właściwie jest to absolutny pewniak, temat, który trzeba dotknąć, jeżeli chcemy popracować nad przewidywalnością. 

 Kuba: Ten odcinek będzie zawierać wyselekcjonowane najważniejsze metody dzielenia. Będzie też kilka refleksji na temat dzielenia produktu i takie porady dla poziomu liderskiego czy managerskiego. Czego oczekiwać od zespołów, gdy przychodzi temat dzielenia elementów Backlogu Produktu. Coś, co musimy koniecznie podkreślić to to, że nie wymienimy wszystkich znanych nam metod dzielenia. Jest ich cała masa, niektóre są dosyć specyficzne i może nie zawsze aż tak, powiedzmy na miejscu, dla każdego, czy na tyle uniwersalne. Więc tu naprawdę wyselekcjonujemy tylko kilka z tych metod, ale za to chcemy poruszyć je głęboko i przede wszystkim bardzo bogato w przykłady. Czy to z naszego życia jako użytkownicy, czy z naszego życia jako tutaj członkowie zespołów, czy doradcy tychże zespołów? To przejdźmy do rzeczy. Jakie metody dzielenia polecamy?

Jacek: Pierwsza metoda, to metoda poszukiwania prostego rozwiązania. Jest to taka metoda bardzo generyczna, dlatego od tej metody chcieliśmy zacząć i polega na tym, żeby zastanowić się, czy konkretne rozwiązanie, czy konkretne feature, czy konkretny kawałek produktu, który chcemy zrealizować, czy można go dostarczyć na początku w jakieś takiej dosyć mocno uproszczonej wersji. Po to, żeby te wszelkie rzeczy, które są złożone i które zazwyczaj konsumują bardzo dużo czasu, a niekoniecznie zawsze są konieczne, żeby oddać kawałek produktu naszym użytkownikom, realizować. Takim przykładem z mojego doświadczenia to jest aplikacja Brand24. Aplikacja do monitorowania social mediów, z której korzystałem po prostu przez interfejs webowy i pewnego dnia ściągnąłem aplikację mobilną. Moje takie początkowe wrażenie było takie, że coś tutaj zostało obcięte. Nie mam podstawowych funkcji. Natomiast kiedy chwilę się tą aplikacją pobawiłem, zrozumiałem, że wolę mieć dostęp do tak uproszczonego produktu, ale jednak mieć go na telefonie, niż nie mieć go w ogóle. 

Kuba: No i tutaj ta metoda szukania prostych rozwiązań jest też o tym, żeby te proste rozwiązania być może pozwoliły nam szybciej dostarczyć to pierwsze rozwiązanie, tak jak w Jacka przykładzie. Ale też proste rozwiązania, to często są po prostu rozwiązania przyjazne dla klienta czy dla użytkownika. I tutaj przykład, który mi chodzi mocno po głowie, to to jak obserwuję świat e-commerce’u, z racji swoich bardzo starych doświadczeń pracy w czasach Allegro. Lata temu rejestracja w internecie zawierała mnóstwo pól, była bardzo rozbudowana, często nie do końca znane reguły walidacji. Jak wpisać numer telefonu, albo czy przyjmie kod pocztowy. Zwłaszcza jeśli są jakieś strony, które mają użytkowników w wielu krajach. Natomiast metoda dzielenia przez proste rozwiązania idzie też w kierunku tego, żeby sobie zadać pytanie, jaki minimalny zestaw informacji potrzebujemy od klienta, czy użytkownika, na przykład na etapie rejestracji i w pierwszej wersji, w pierwszej iteracji. W pierwszym kroku, czy w pierwszym Sprincie. Zróbmy taką wersję super prostej rejestracji. Ewentualnie będziemy ją rozbudowywać, jeśli będzie na to potrzeba. Być może poprosimy też klienta, żeby uzupełnił jakieś dane w późniejszych etapach korzystania z naszego produktu. Tutaj to jest taki fajny moment, w którym proste rozwiązanie będzie łatwe do implementacji. Szybciej dostarczamy rozwiązania na rynek, a jak jeszcze zrobimy to mądrze, to przy okazji to będzie po prostu bardzo przyjazne dla klienta. 

Kuba: Druga metoda dzielenia, taka jest swego rodzaju specyficzna wersja tych prostych rozwiązań, o których powiedzieliśmy w pierwszym przykładzie, to metoda przez uproszczoną wersję interfejsu. Mamy tu na myśli taką sytuację, czy takie przypadki produktów, które mają jakiś rodzaj interfejsu użytkownika i te interfejsy w wielu produktach mogą być bardzo wysublimowane, bardzo rozbudowane, też takie bym powiedział super dopuszczone. Natomiast, zwłaszcza gdy jest mało czasu, zwłaszcza gdy chcemy szybko wypuścić jakieś rozwiązanie. Zwłaszcza gdy tylko testujemy pewne hipotezy, nazwijmy to MVP. To możemy po prostu zrobić wersję trochę prostszego rozwiązania, trochę też prostszego interfejsu. Ja pamiętam już lata temu, gdy wraz z pewnym zespołem, który wspierałem, rozwijaliśmy dosyć w zamierzeniu, czy w wizji, bardzo dużą wersję produktu, pełną bardzo rozbudowanych dash boardów. No ale w pierwszych Sprintach ten zespół, zamiast generować mnóstwo wykresów, mnóstwo tabelek, mnóstwo jakichś takich fajnych opcji, które docelowo miały się w tym produkcie znaleźć. W pierwszych Sprintach te same informacje były wyświetlane dosłownie w plain tekście, czystym, nieoszlifowanym, nieostylowanym interfejsem. Bo o wiele ważniejsze było to, że tam są te informacje, te konkretne dane, a nie to czy tabelka, czy jakiś wykres, czy jeszcze jakaś kołowy diagram coś tam super prezentuje. 

Jacek: Ja mam wrażenie, że w ogóle bardzo często, albo odwrotnie, bardzo rzadko ta metoda dzielenia jest wykorzystywana. Taki bardzo popularny wzorzec, który obserwuję to to, że pewien kawałek produktu jest definiowany wizualnie poza zespołem. Czyli czy taki zespół designu, czy zespół UX przygotowuje finalną makietę, na przykład stronę logowania, o której wspomniałeś czy jakiegoś innego elementu procesu. No i właściwie zadaniem zespołu, jest po prostu oddanie 1 do 1 tego interfejsu tak, jak on jest zrobiony. No, a jest zrobiony w takiej wersji już ładnej. Czyli te formularze są wymuskane, ładnie tam cienie padają, zaokrąglenia, to wygląda super i jest przyjazne dla Użytkownika. Natomiast często to idzie w parze, z tym że ta hipoteza, że w ogóle ten formularz tutaj i ten feature, w ogóle nie jest zbadana. Tak więc inwestujemy masę czasu, ergo pieniędzy w to, żeby to było piękne, a tak naprawdę nie mamy pewności, czy to jest w ogóle to. Więc pomysł tego, żeby najpierw zrobić – może nie brzydko – ale w uproszczony sposób i zbadać, czy to ma sens. No zdecydowanie jest metodą, którą rekomendujemy. 

Jacek: Kolejną, trzecią metodą, o której chcemy dzisiaj powiedzieć, to metoda wybrania najważniejszych elementów, pewnych kroków, które znajdują się w naszym procesie czy w naszym workflow. Zadanie polega na tym, żeby najpierw z lotu ptaka zastanowić się, z jakim procesem się mierzymy, a następnie zastanowić się, czy wszystkie elementy w tym procesie są jednakowo ważne. I też kwestia, jak do tych elementów w tym procesie możemy podejść.  Myślę, że tutaj dobry może być przykład sytuacji, w której podpisujemy umowę z firmą, która dostarcza nam płatności. Czyli przykładowo mamy sklep internetowy, chcielibyśmy umożliwić odwiedzającym nasz sklep płatności online. Podpisujemy umowę z jedną z firm. No i w jakiś sposób ta firma będzie nam wypłacać pieniądze. Taka jest potrzeba moja jako klienta, który podpisuje taką umowę. Przykładowo pewnym takim uproszczeniem może być to, że wypłaty pieniędzy wpłacanych przez klientów sklepu są robione automatycznie. W pewien sposób taki cykliczny od dostawcy płatności. No i jest to prostsza wersja, niż umożliwianie użytkownikowi definiowania sobie jakiegoś własnego schematu wypłat – co drugi poniedziałek, w dni nieparzyste. Można wymyślić masę różnych warunków ludziom, które mogą przyjść do głowy. Natomiast tutaj po prostu upraszczamy, że idzie automat. On wypłaca na przykład co dwa tygodnie, niezależnie od tego, ile tej kwoty jest do wypłaty. Albo w jedną stronę nie wypłacamy mniej niż 1000 zł. I też automat jak się uzbiera tysiąc, to wypłaca. 

Kuba: Workflow to jest bardzo wdzięczny temat, a jednocześnie czasami dla niektórych przerażający. Ja sam sporo swoich doświadczeń, sporo lat spędziłem w instytucjach finansowych i tutaj te workflow to często są jakieś procesy biznesowe, ale dotyczące również interakcji z klientem. Więc to na przykład będzie jakiś rodzaj wniosku, albo zakładanie czegoś, albo procesowanie pewnego oczekiwania, czy żądania klienta.  Klasycznym sposobem na realizację workflow jest robienie go krok po kroku. Mamy pewne wyobrażenie kompletnego procesu i budujemy sobie kroczek po kroczku, zaczynając od tego pierwszego etapu. W większości tych etapów w instytucjach finansowych to jest – klient czegoś chce i zgłasza się do banku, czy do ubezpieczeniowej firmy i zaczynamy zabawę. I to co teraz mówię z lekkim przekąsem, to jest swego rodzaju przekleństwo dla ekip wykonawczych tego typu procesy. Ale to też jest często dramat dla klienta, który musi się przekonać przez tonę ekranów, dziesiątki pól, które są do wypełnienia, załączniki, które trzeba wysłać. I tutaj jeśli wracamy do dzielenia, to znowu może być tak, że przy okazji wymyślimy sporo uproszczeń, ale wyjdę już z tej przyjazności dla klienta i wrócę do koncepcji szybkiego dostarczenia rozwiązania mniejszymi kawałkami. Dzielenie workflow na pierwszy krok, drugi krok, trzeci krok i czwarty krok. Z zasady powiem, że to jest zły kierunek i szukanie najważniejszych elementów trzeba zrobić tak poprzecznie. Czyli na przykład, zróbmy najprostszą wersję z wypełnienia wniosku. Zastanówmy się, czy drugi krok w ogóle jest potrzebny? Może możemy go w pierwszym etapie pominąć? I żeby przejść na bardzo konkretny przykład, no to załóżmy, że składamy wniosek o kredyt. W takim najbardziej rozbudowanym workflow to by trzeba w ogóle się wykazać, że jestem klientem, udowodnić, że zarabiam pieniądze. Siedemnaście razy potwierdzić, że na pewno to spłacę. To jest bardzo rozbudowany proces. Ale dla klientów banku, w którym już mam konto, czy mojego własnego klienta z perspektywy banku już mi znanego, może da się to bardzo uprościć. Czyli może w pierwszym Sprincie, czy w pierwszych kilku wersjach rozwińmy kredyty dla istniejących klientów. Wtedy to składanie wniosku jest o wiele prostsze, sprawdzenie jego zdolności kredytowej też jest prostsze i cała masa innych kroków też będzie o wiele bardziej banalna. To będzie uproszczona wersja produktu. Zajmiemy się tymi bardziej skomplikowanymi kawałkami w następnych krokach, a być może nawet już w tej perspektywy takiej czysto biznesowej, przynajmniej na tych klientach obecnych może już możemy zacząć zarabiać, dzięki szybkiemu wypuszczeniu rozwiązania, które już częściowo rozwiązuje przynajmniej część potrzeb klienta. 

Kuba: Czwartą metodą dzielenia produktu, którą chcemy tutaj wymienić, to jest podział przez najistotniejsze operacje. Często jest takie naturalne skojarzenie, że pewne elementy, zwłaszcza w takich bym powiedział powtarzających się systemach, czy kolejnych wersjach systemów, że pewne operacje muszą być od razu zrealizowane wszystkie. Mamy tu na myśli takie klasyczne wersje operacji, czyli dodanie, usunięcie edycja. Warto się zastanowić czy naprawdę w danym kroku, czy naprawdę w danym momencie w naszym systemie potrzebne są absolutnie wszystkie operacje, które klasycznie przychodzą nam do głowy i czy czasami po tych przecinkach, w moim zdaniu, nie warto podzielić i na przykład zrobić tylko, albo dodawanie, albo pominąć któryś z tych takich mniej oczywistych elementów. Co mam na myśli? Może jeśli mamy na przykład startujący produkt, który dopiero się rozwija, chcemy go wypuścić szybko, chcemy w ogóle sprawdzić, czy klienci będą chcieli go używać, to może nie potrzebujemy na przykład opcji usuwania konta. Wystarczy to konto dodać. Być może zmienić login, a może nawet na początku zmieniania loginu też nie trzeba uwzględnić.

Jacek: Przykład takiej najistotniejszej operacji, a właściwie pominięcia jednej z nich mam na swoim prywatnym podwórku – mianowicie zegarków sportowych. Zegarek, który mam między innymi oprócz wielu rzeczy, które mierzy, to mierzy też jakość snu. Czyli oprócz banalnych rzeczy, o której godzinie zasypany i o której stajemy, no to jeszcze fazy snu, przebudzenia i tam jeszcze parę innych rzeczy. I bardzo takim popularnym problemem pomiaru snu jest to, że na przykład, jak się zbyt bardzo rozłożymy na kanapie wieczorem, oglądając jakiegoś Netflix’a, no to ze względu na brak ruchu ręki i obniżone tętno, zegarek może stwierdzić, że usnęliśmy. Co jest nieprawdą i mamy godzinę bonusowego snu, co zakłóca nam statystyki. Może też powodować, że dostaniemy zupełnie inne wskazówki treningowe, niż byśmy dostali, gdyby się okazało, że spaliśmy 6 godzin, a nie 7. Funkcja, która dopiero niedawno została dodana przez firmę Polar, to jest funkcja, która pozwala przyciąć ten sen. Na takiej zasadzie, że jeżeli nieprawdą jest, że zasnąłem wcześniej, no to z poziomu aplikacji mobilnej, to w sumie też jest ciekawe, bo tylko z poziomu aplikacji mobilnej, a z poziomu interfejsu dobowego już nie. Co jest też w sumie oddzielną w ogóle warstwą cięcia. Mogę sobie powiedzieć – dobra, nie usnąłem o dwudziestej trzeciej, tylko tak naprawdę o północy. Tej funkcji bardzo długo nie było, co pokazuje, że jest to popularna metoda cięcia, wycinając te operacje, które z jakiś tam powodów są uznawane za mniej istotne, albo mniej istotne w tym momencie.

Jacek: Następny sposób dzielenia Backlogu Produktu na mniejsze kawałki to jest sposób po częstości używania konkretnych elementów, czy konkretnych feature’ów. Założenie stojące za tą metodą jest takie, że co do zasady chcemy rozpocząć rozwój naszego produktu i odnawianie jego przyrostów, od tych rzeczy, które są najczęściej używane, czy oczekiwane przez użytkowników. Przykład, pozostając w tych zegarkach, o wiele częściej użytkownicy oczekują, że zegarek sportowy wyświetli im bieżące tętno w trakcie treningu, niż na przykład coś, co też się pojawia, ale jest o wiele rzadziej używane – momenty wschodu i zachodu słońca. Czyli przykładowo jesteśmy w górach, chcemy wiedzieć, o której zaczyna się robić ciemno, kiedy jest ciemno, kiedy właściwie ostatnie światełko widzimy. No, żeby na przykład ocenić, czy zdążymy dotrzeć do schroniska. Natomiast jest to bardziej taka już funkcja, nazwijmy to outdoorowa, a ludzie co do zasady chcą mierzyć tętno. Więc wiedząc to, że jednak najbardziej pożądaną funkcją, jest jednak jasność co do tego, jak często bije moje serce, no to dodajemy tę konkretną funkcję wcześniej.

Kuba: A ja wrócę do przykładu ze świata e-commerce. Załóżmy, że jesteśmy osobami odpowiedzialnymi za rozwój sklepu, czy jakieś funkcji sprzedaży naszych produktów, czy w ramach naszej firmy. Częstość używania elementów może powodować, może być sposobem na wybranie najistotniejszych, czy priorytetowych feature’ów, które chcemy dołożyć i na przykład nie wszystkie formy płatności będą tak samo popularne. Czy tak samo nie wszystkie formy dostawy będą tak samo często używane i tak samo oczekiwane przez klienta? Więc na przykład kombinacja możliwości płatności Blikiem plus dostawa paczkomatami, być może pokryje znaczną, znaczną część potrzeb naszych klientów i dwie szybkie integracje – trochę żartuję z tą szybkością integracji – ale dwie szybkie integracje i jesteśmy już funkcjonującym sklepem z możliwością płacenia i dostawy. Jeśli ironizuję z integracjami i niektórych z was lekko zakłuł temat, że podłączenie się do różnych dostawców, partnerów, to jest zawsze męka. To zawsze szybciej, lepiej zrobić to z jednym partnerem, czy dwoma, niż czekać na wielkie wdrożenie i jednocześnie podłączać się do trzech dostawców płatności i siedmiu integratorów logistycznych. To zawsze będzie jeszcze więcej ryzyka i jeszcze bardziej nas odsuwa od faktycznie funkcjonujących opcji w naszym produkcie. I może już nie użyję szczegółowego przykładu, ale z tą częstością używania elementów, to też jest dobry trop, gdy mamy do czynienia z systemem, który jest zastępowany, gdzie zastępuje stary system nowym systemem. Też wtedy warto rzucić okiem, czy faktycznie musimy 1:1 nadzorować cały stary system, czy czasami, jeśli nie zrobimy takiego trochę rankingu, co jest najczęściej używaną funkcją, jakie kroki w procesie, jakie dosłownie przyciski na interfejsie, jakie są potrzebne, a jakie są trochę mniej potrzebne. To może nie dość, że pozwolić nam przeselekcjonować rzeczy, które są do zrobienia w pierwszej kolejności, ale nawet wybrać rzeczy, które może w ogóle ich nie musimy robić i możemy je pominąć, albo przynajmniej na pierwszym etapie zobaczyć, czy w ogóle ktoś będzie o nie zabiegał.

Kuba:  Szóstą metodą, którą wymienię, co do dzielenia produktów, trochę podobną do częstości używania dla mnie, to jest węższa grupa docelowa. Jeśli produkt jest kierowany do dosyć szerokiej grupy odbiorców, to może się okazać, że ci odbiorcy między sobą się trochę różnią co do oczekiwań i też częstości wykorzystywania pewnych funkcji, czy pewnych feature’ów. I to jest oczywiście zawsze ciężka decyzja produktowa, a najlepiej żeby bazowała na jakichś bardzo konkretnych faktach, na konkretnych też założeniach biznesowych, ale może się okazać, że jeśli zawęzimy grupę docelową, to uzyskamy pewną  uproszczoną potrzebę produktową. Czyli pewne elementy produktu mogą się okazać niepotrzebne dla wyselekcjonowanej i grupy docelowej, co może pozwolić też na trochę odchudzanie tego produktu i przyspieszenie, na przykład wdrożenia, czy przyspieszenie dostarczenia jakiejś kolejnej wersji rozwiązania. I znowu wrzucę przykład ze świata bankowości, bardzo osobisty przykład. Całkiem niedawno zakładałem nowe konto firmowe. No i się okazało, że proces zakładania drugiego konta firmowego w banku, w którym mamy pierwsze konto firmowe to w zasadzie jest praktycznie wyklikanie dwóch, trzech przycisków i już je mam. W ogóle byłem w szoku, że już mam to konto. No bo tak zakulisowo, to wiem, że tak może funkcjonować. Czyli też patrząc z perspektywy Product Ownera takiego rozwiązania, powiedzmy rejestracji konta w banku, może się okazać, że udostępnienie możliwości zakładania sobie nowego konta, czy subkonta jest banalne, bo po prostu nie dotyczy mnie wiele ograniczeń, czy wiele regulacji, które musiałyby być uwzględnione w przypadku zakładania konta przez osoby zupełnie dla banku obcą. I to nie wiem, czy znajdę biznes case’a na takie przypadki, ale to jest dla mnie taki bardzo wyrazisty przypadek, że większa grupa docelowa po prostu ma zupełnie prostsze wymagania, co do funkcji i jest możliwe przeprowadzanie tego o wiele sprawniej. 

Jacek: Ja z kolei pozostanę w przykładzie sportowym. Jest masa programów do analizy tego jak trenujemy. Nie wchodząc w szczegóły, cała masa statystyk, które mogą nam pomóc. No i sportowiec to też jest szerokie pojęcie. Tak więc możemy w pierwszej kolejności na przykład oddać produkt dla biegaczy. W sensie jakieś funkcje konkretne dla biegaczy – na przykład, które wspomagają analitykę w kontekście przewidywanych czasów na najpopularniejsze dystanse. Czyli te 5, 10, 21 i na odległość maratońską. Z czego na przykład nie ucieszą się osoby, które przykładowo trenują cross fit, bo akurat dla nich te funkcje mogą być nieistotne. Tak więc zawężamy grupę docelową. Nie robimy dla wszystkich, tylko konkretne rzeczy dla konkretnych użytkowników. 

Jacek: I ostatnia metoda. Celowo umieściliśmy ją na koniec, bo też jest trochę taka genetyczna. To metoda polegająca na tym, że upraszczamy wszelkiego rodzaju wymagania pozafunkcjonalne. I tych wymagań pozafunkcjonalnych może być całkiem sporo. Takie dwie najbardziej popularne, to na przykład bezpieczeństwo, albo wydajność. I tutaj generalnie, no jest przez to, że tych niefunkcjonalnych opcji jest cała masa, no to otwiera się nam też spory wachlarz tego, czym możemy sobie sterować. Jednym z wymiarów może być bezpieczeństwo systemu. Czyli na przykład to jak restrykcyjnie chcemy podejść do polityki zmiany haseł. Oczywiście czasem to może być regulowane i możemy nie mieć na to wpływu. Ale nadal w pierwszej interakcji rozwoju naszego produktu, który niekoniecznie musimy wydawać na rynek, możemy po prostu oczekiwać, że użytkownik ma hasło. Natomiast jakieś skomplikowane zasady w stylu, że raz na miesiąc musi zmienić i to hasło musi być różne, niż ostatnie 10 czy X wprowadzonych haseł. Możemy dodawać sobie to stopniowo. Z drugiej strony też bym się zastanowił, jakiego poziomu bezpieczeństwa na przykład na poziomie haseł oczekujemy od naszego produktu. Kuba masę przykładów podałeś bankowych. No to wyobrażam sobie, że tam być może jest mniejsza przestrzeń na jakieś kompromisy. No, ale nie wszystkie produkty są tak krytyczne, więc może wymuszanie co dwa tygodnie, żeby się hasło zmieniło, no to nie jest najlepszy pomysł dla naszego produktu. 

Kuba: I z tymi pozafunkcjonalnymi wymaganiami jest trochę tak, że zwłaszcza jeśli nie mówimy o nich wprost, jakby nie nazywamy ich po imieniu, to możemy wpaść w taką pułapkę założeń. Czyli na przykład grupa wykonawców w danym przedsięwzięciu może na przykład zakładać, że oczekiwania są o wiele bardziej wysublimowane. Ta poprzeczka położona jest o wiele wyżej. A na przykład strona biznesowa nawet może sobie nie zdawać sprawy, jak dużą różnicę robią różne stopnie tych wymagań pozafunkcjonalnych. No bo też po prostu nie znają szczegółów możliwych rozwiązań, różnic i takich konsekwencji na przykład architektonicznych, czy konsekwencji też takich inżynierskich, między tym lub tamtym rozwiązaniem. No i tutaj prosta dla mnie, taka pokorna nauka z przeszłości również, to kwestia wydajności. Coś, co może oznaczać na przykład odświeżenie danych raz na dzień, czyli dostaniesz raport z danymi z wczoraj. Zajmie być może X, a wiele rzędów więcej pracy będzie do zrobienia, jeśli ja będę miał oczekiwanie, że ten raport będzie mi dawał informacje zawsze świeże, co 5 minut, albo wręcz dosłownie, co sekundę odświeżane. Zazwyczaj to jest oczywiście kwestia pewnie technologiczna, ale zazwyczaj będzie spory przeskok między tym, jak łatwo, jak pracochłonne będzie wykonanie. W zasadzie wszystkich innych funkcji identycznych, tylko różniących się dokładnie tym parametrem. Więc tutaj warto sobie te rzeczy przede wszystkim głośno nazywać, a to trochę poza nawiasem tego odcinka, a oprócz tego sobie jasno powiedzieć, że być może w pierwszej wersji nasze dane będą odświeżone relatywnie rzadko, ale już wniosą jakąś wartość. A jeśli się okaże, że musimy to dorobić, to może w drugim, trzecim kroku, w kolejnej wersji dorobimy ten sam feature, czy tę samą funkcję, ale trochę bardziej wydajną, albo trochę częściej odświeżającą się, albo mogącą obsłużyć większą ilość klientów jednocześnie. Trochę to tak start-up’owo zabrzmi, więc przełamie to tutaj może korporacyjność banków. Może na początek miejmy w ogóle klientów i w drugim kroku będziemy się martwić, czy jak będziemy ich mieli milion, czy jesteśmy w stanie ich obsłużyć. Bo może się okazać, że będziemy mieli super wydajną architekturę, która będzie tylko używana przez nas i naszych znajomych.

Kuba: I wychodząc już z tych przykładów i konkretnych metod, które chcemy zaproponować. Kilka takich refleksji na koniec będących swego rodzaju spięciem tych wszystkich rzeczy, które mam nadzieję, że już przychodzą Ci do głowy, gdy nas słuchasz, gdy opowiadamy o tym jak dzielić. Przede wszystkim te metody dzielenia można łączyć. Czyli to, że my je trochę tak sztucznie potraktowaliśmy osobno i też staraliśmy się, żeby te przykłady też na siebie wzajemnie nie nachodziły, to tak naprawdę magia się zaczyna, gdy zaczynamy łączyć metody dzielenia, gdy bierzemy je do swego kontekstu czy do naszego produktu. No i szeregiem rozmów między zespołem, między stroną jakichś interesariuszy refleksji po tej stronie produktowej, jest do uzyskania taki klasyczny efekt Pareto. Czyli 20% wysiłku, relatywnie niewiele funkcji. Jest szansa, że dostarczy bardzo dużą część wartości. Może te właśnie umowne 80% wartości. 

Jacek: Przykład takiego łączenia, który oboje z Kubą kojarzymy z konferencji, to jest przykład przytoczony przez Henryka Kniberga, który opowiadał o tym, jak firma deweloperska współpracowała z policją w Szwecji nad rozwojem produktu, który, zanim podeszli do tego w sposób taki zwinny, no to rozwijali – zdaje się siedem lat. Nie było tam sukcesów, no więc pomysł był taki, żeby w jakiś sposób szybciej dostarczyć rezultaty. No i to, na co między innymi się zgodzili, to to, że program, który miał wspomagać pracę policji w polu, w sensie, kiedy są poza biurem, miał całą masę możliwości, więc zaczęli się zastanawiać, jak można go dociąć. Tak więc na początku policjanci dostali produkt, który wspierał tylko wybrane przestępstwa. Czyli dla części przestępstw można było pracować online, dla części trzeba było wrócić do biura. Co więcej, te wybrane funkcje działały tylko na początek w wybranym regionie Szwecji, czyli nie dla wszystkich tylko dla jakiegoś zawężonego obszaru. Link do tego case’a dołączymy do materiałów, gdyby ktoś miał ochotę sobie go przeczytać i pogłębić. 

Kuba: Kolejna refleksja, którą chcę się podzielić, to jest taka myśl, która Jacka zawsze śmieszy. Czyli myśl, że dzielenie jest fraktalem. Na początku zastrzegałem, że nie mówimy tu o dzieleniu produktu jako całości, powiedzmy całej platformy Allegro, albo wszystkich funkcji w banku, jakie są. Natomiast myślę, że tutaj jest do uzyskania taki trochę efekt, że niezależnie od tego, czy my mówimy o jakimś całym gigantycznym systemie, który kilka lat będziemy rozwijać, czy mówimy tutaj o kwartalnym, większym wdrożeniu, czy mówimy tutaj o zawartości pojedynczego Sprintu, czy dosłownie jednego feature’a takiego już naprawdę chudziutkiego – dalej myślę, że jest miejsce na to, żeby się zastanowić, czy jesteśmy w stanie jeszcze to odchudzić. Czy przez pryzmat tych siedmiu metod, które wspomnieliśmy czy przez pryzmat kolejnych, jakichś zupełnie przez nas samodzielnie wymyślonych? Więc tutaj metody dzielenia da się tutaj założyć na wielu poziomach abstrakcji. Jak zejdziemy z tej perspektywy, że już podzieliśmy system i uzyskaliśmy z dwuletniego planu półroczny plan wdrożenia pierwszej wersji. To ten półroczny plan spokojnie dalej da się ciąć. Tylko być może teraz trzeba wziąć trochę większą lupę i trochę bardziej precyzyjniej spojrzeć na szczególiki.

Jacek: À propos tych fraktali. To tylko taki komentarz, dlaczego mnie bawią w takim sensie, że ja sobie przypomniałem, kiedy zderzyłem się z fraktalami po raz pierwszy. To było na studiach informatycznych. One się pojawiały jako przykład napisania jakiegoś programu. Uczyliśmy się języka i to już było – wtedy Turbo Pascala – jako taka podstawa takiego nauczenia się programowania. No więc nie dość, że język był nowy, no to żeby było wesoło, to narysujmy fraktal. W sensie może – Hello world – najpierw wyświetlimy, a dopiero później fraktale. Więc jak słyszę fraktal, to od razu mi się przypominają studia. No, a to wiadomo był fajny okres. Natomiast obiecaliśmy też na początku, że będziemy też mieć komunikat do managementu. Czyli jeżeli jesteś w roli managerskiej i słuchasz nas, to mamy takie trzy główne myśli, którymi chcielibyśmy się podzielić. Pierwsza myśl jest taka, że przede wszystkim warto dzielić pracę, warto dzielić Backlog Produtu, warto dzielić produkt na mniejsze kawałki. Sporo argumentów na ten temat przedstawiliśmy w odcinku #076. Więc jeżeli nie słuchałeś lub nie słuchałaś tego odcinka, to zachęcamy do odsłuchania. Z mojej perspektywy jest to o tyle istotne, że osobiście w swojej pracy zawodowej, kiedy pracuję z klientami, nadal spotykam się z kwestionowaniem sensu dzielenia. Tak więc na pewno warto sobie tę wiedzę uporządkować, zdobyć, utrwalić. Co ważne, dalej ją propagować.

Kuba: Druga myśl jest taka, że dzielenie jest możliwe. Brzmi to może banalnie, ale ten odcinek mocno o tym wspomina. Ja na bazie swoich dzisiejszych doświadczeń w kwestii dzielenia zajmuję zawsze takie dosyć ostre stanowisko. Przyjmuję założenie, że na pewno da się podzielić. Tylko jest kwestia tego, żebyśmy znaleźli sposób. Wiele osób właśnie, gdy pracuję z konkretnym zespołem, na początku trochę ma ochotę podjąć wyzwanie, albo inaczej, rzucić je mi. No ale na szczęście dosyć szybko udaje nam znaleźć się jakiś sposób dzielenia lub odkryć wszystkie założenia, które zakładamy, czy przyjmujemy, że nie dzielimy, bo jest to dla nas, w naszych głowach jakieś. Drogie, trudne, żmudne i parę tego typu rzeczy. Natomiast z perspektywy managerskiej warto przyjąć założenie, że dzielenie jest możliwe. Nie ma powodów, żeby tego dzielenia nie robić.

Jacek: I ostatnia myśl z perspektywy managera. Być może najtrudniejsze, to jest to, że dzielenie powinno być oczekiwane. W sytuacji, w której management nie buduje tego oczekiwania, że jest wartość z tego, żeby dzielić, jest wartość z tego, żeby obniżać ryzyko przez to, że dostajemy mniejsze kawałki produktu i coś możemy z tym zrobić. Między innymi możemy pokazać to interesariuszom. Możemy pokazać wybranej grupie, klientom. Cokolwiek. Możemy dostać po prostu feedback wcześniej. Pomimo tego nadal spotykam się z organizacjami, gdzie jakby to oczekiwanie nie jest w żaden sposób jakby wyrażone. Tak więc zachęcamy Cię do tego, żeby wprost mówić o tym. Może być tak, że osoby, które masz w zespole jako manager, one być może wcześniej nie pracowały w ten sposób. Więc albo nie wiedzą, dlaczego warto dzielić, albo nie wiedzą, że coś można podzielić. Na pewno warto  o tym rozmawiać i zahaczać z zespołami temat dzielenia rzeczy na mniejsze kawałki.

Kuba: Podsumowując całość. Jakie metody dzielenia polecamy?

Jacek: Proste rozwiązanie, uproszczona wersja interfejsu, najważniejsze elementy z kroków procesu, najistotniejsze operacje.

Kuba: Częstość używania elementów, węższa grupa docelowa, uproszczenie pozafunkcjonalnych wymagań.

Kuba: Notatki do tego odcinka, artykuł, transkrypcję naszej rozmowy, wspomniane przez Jacka materiały oraz materiał, który zaraz dopowiem, zapis wideo naszej rozmowy, znajdziesz na stronie porzadnyagile.pl/81. A wspomniany dodatkowy materiał, to polskie tłumaczenie User Story Splitting Pattern, które wspomnieliśmy przy okazji 76. odcinka. Polskie tłumaczenie jest przygotowane przez Ewę Koprowską i Łukasza Szóstka, których przy okazji bardzo gorąco pozdrawiamy. Ten materiał jest co do treści identyczny, jak wersja angielska, ale wiemy, że dla niektórych może być przyjaźniej i łatwiej przyswoić taką wersję dobrze przetłumaczoną na nasz język. Polecam zajrzenie do materiałów na stronie. Niestety głosno nie przeczytam linka, bo jest on kompletnie nieprzyjazny i nie ma sposobu, żeby go tutaj go przekazać. Po prostu musisz zajrzeć na stronę porzadnyagile.pl/81.

Jacek: Na koniec tego odcinka zapraszamy Cię na nasze świeże miejsce na mapie Social Mediów, czyli na nasz Instagram. Będą się tam pojawiać treści wideo i graficzne, podsumowujące najistotniejsze i wartościowe kawałki z naszych rozmów. Sporo treści, które publikujemy, znajdziesz też na naszych pozostałych profilach społecznościowych. Tak więc zapraszamy Cię do polubienia, odwiedzenia, zasubskrybowania Instagrama czy LinkedIn’a, czy Facebook’a, czy Twitter’a. We wszystkich tych Social Mediach jesteśmy i czekamy na Twoją obecność i komentarze.

Kuba: W tym odcinku to by było na tyle. Dzięki Jacek.

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia wkrótce.