Cząstkowy efekt synergii

Wiele z naszych tekstów powstaje w odpowiedzi na krytykę podejścia zwinnego. Częściowy efekt synergii, to moja robocza nazwa, której od tej pory będę używał tłumacząc, dlaczego 0,2 to nieskończenie więcej niż zero. Bo ileż można słuchać, że “naszego produktu nie da się budować przyrostowo – albo wszystko, albo nic!”

 

Efekt synergii

Jednym z najbardziej nielubianych, nadużywanych i “coachingowych” sformułowań jest “efekt synergii”. Często tłumaczony jest on jako “1 + 1 > 2” lub “2 + 2 = 5”, co ma pokazać, że całość to więcej niż tylko suma części. Składając coś w jedno otrzymujemy więcej niż tylko poszczególne kawałki. Zaczynają one działać razem i tworzą coś, co nazwiemy innym wyświechtanym sformułowaniem – “wartością dodaną”.

Wspominaliśmy o tym przy okazji dumania nad idealną wielkością zespołu, gdzie pokazywaliśmy, że co prawda zespoły liczące od 1 do 3 osób są bardziej produktywne, to jednak jakościowo praca najlepiej wypada w grupach liczących 3-5 osób. Różne konfiguracje liczebności zespołów dają nam inne efekty, tak bardzo różne od pracy w pojedynkę.

Podobna rzecz ma miejsce w kontekście naszego produktu, czymkolwiek by on nie był. To nie jest tak, że “aplikacja do udostępniania zdjęć” pod tytułem Instagram byłaby tym samym, co jest, gdyby nie instagramowe stories. I trudno argumentować, że gdyby stories i Instagram to byłyby dwie oddzielne aplikacje, to wzięte razem byłyby tak samo popularne.

Ten krótki wstęp może jednak sugerować, że efekt synergii będzie argumentem przeciwko iteracyjnemu i przyrostowemu budowaniu produktów. Zwróćmy uwagę na jeden fakt – wspomniany Instagram na początku powstał jako “aplikacja do udostępniania zdjęć”. Pozostałe elementy zostały dodane później. Owszem, jako całość doskonale obrazuje on efekt synergii, ale jego historia pokazuje siłę inkrementalnego podejścia.

 

Korzyść biznesowa

Bardzo często słyszymy o systemach z kategorii “wszystko albo nic”. Product Owner zwykle argumentuje to “brakiem korzyści biznesowej z częściowego rozwiązania” bądź “koniecznością spełnienia wymagań ustawowych”. I o ile jeszcze na ten drugi powód czasami udaje nam się nabrać, tak w obu przypadkach powinniśmy instynktownie reagować niedowierzaniem i dociekaniem.

Po pierwsze, nawet aplikacja typu windowsowy Notatnik zawiera funkcje, które w metodzie MoSCoW nie byłyby określone jako “Must have”. Bo czy do naszego MVP koniecznie potrzebujemy wyboru czcionek, opcji zawijania wierszy, pomocy, opcji wstawienia godziny/daty czy drukowania dokumentu? A skoro w tak prostym programie możemy znaleźć rzeczy ważne i ważniejsze, to czy nasz “zintegrowany system do zarządzania wszechświatem” nie zawiera wymagań opcjonalnych?

Każdy system, nawet ten budowany w celu “spełnienia wymagań ustawowych” posiada funkcjonalności, które nie są niezbędne. Jasne, służą one wygodzie, ułatwiają cały proces, powodują, że nasze rozwiązanie jest lepsze od konkurencji i bardziej atrakcyjne. Ale, powtórzmy sobie jeszcze raz, nie są niezbędne.

Dzielenie produktu na mniejsze, naprawdę niezbędne kawałki, których realizacja jest możliwa w jednym Sprincie to nasza specjalność. Sprawdź nasze szkolenie “Wymagania w projektach agile” i poszerz swój product-ownerski bądź analityczny warsztat. Zapraszamy!

Po drugie, bardzo często Product Owner wypowiada się za klienta, bo chce go zadowolić na siłę. To nie jest ta prostota, o której tyle mówimy. Nie wymyślajmy, nie kombinujmy, zróbmy minimum, z którego nasz klient będzie zadowolony. Słowo-klucz – “zadowolony”. A to znaczy, że jeśli musimy klientowi udowadniać, że spełniliśmy jego potrzeby, to na sto procent ich nie spełniliśmy.

Wykorzystajmy empiryzm. Zbudujmy rozwiązanie wystarczająco dobre i oddajmy je do użytku. To nasz klient nam powie, czy wystarcza mu do osiągnięcia sukcesu i czy jest już z niego zadowolony. Ze swojej strony możemy zagwarantować, że każdy klient preferuje kawałek użytecznego rozwiązania zamiast oczekiwania na kompletny i finalny produkt.

Bo nie musimy nikomu udowadniać, że 0,2 jest większe niż zero.

 

Cząstkowy efekt synergii

Postawmy więc tezę: każda realna wartość dostarczona klientowi jest lepsza, niż jego oczekiwanie na pełne rozwiązanie. Co do tego nikt nie powinien mieć wątpliwości. Oczywiście stworzenie czegoś, co będzie dla odbiorcy biznesowo przydatne jest wyzwaniem, ale to przecież my jesteśmy ekspertami i to nas klient zatrudnia, żebyśmy mu w tym pomogli.

Pójdźmy o krok dalej – kilka funkcjonalności zrobionych na przysłowiowe 20% (patrz: Zasada Pareto) często będzie o wiele bardziej przydatne dla naszego odbiorcy niż jedna zrobiona na 100%. Bo przecież w wielu przypadkach podstawowa ścieżka obsługuje 95% przypadków. Z kolei obsługa tych pozostałych 5% zajmie nam kilka razy więcej czasu niż dostarczenie “happy path”. Po co odbiorca ma na to czekać?

Pamiętajmy, że te 20% to wcale nie musi być “happy path”. To mogą być procesy wspomagające pracę manualną, dostarczone zanim ją zautomatyzujemy. To może być pilotaż, wdrożenie w małym zakresie czy wreszcie skrajnie uproszczona funkcjonalność, stworzona w celu przetestowania pomysłu na rynku, a nie na serwerach testowych.

Cząstkowy efekt synergii: 0,2 + 0,2 + 0,2 > 1

Propagowana przez Scotta Adamsa idea “talent stacku”, czyli szerokich i przenikających się kompetencji mówi o tym samym. Możemy być ekspertem w jakiejś dziedzinie i radzić sobie świetnie. Nasze perspektywy są wtedy bardzo dobre, ale ryzyko też jest spore (albo wszystko, albo nic). Jeżeli zaś jesteśmy dobrzy bądź bardzo dobrzy (ale nie najlepsi) w wielu różnych dziedzinach, mamy nie tylko więcej szans, ale i unikalne możliwości.

Specjalista w kilku dziedzinach bywa o wiele bardziej wartościowy, niż ekspert w jednej dziedzinie. Jasne, eksperci są cenieni, ale jest ich względnie dużo. Osoba, która posiada kilka mniej lub bardziej powiązanych ze sobą umiejętności jest rzadsza. A co za tym idzie, gdy trafi na kogoś, kto potrzebuje tych wszystkich kwalifikacji, będzie o wiele cenniejsza.

 

Efekt synergii fragmentów produktu

W podobny sposób myślmy o naszych produktach. Nie czekajmy z wdrożeniem czy dostarczeniem naszego rozwiązania do spełnienia stu procent wymagań. Nie silmy się też na spełnienie “wszystkich kryteriów akceptacji danego epica“. I przede wszystkim – nie próbujmy nikogo zadowolić na siłę, często wbrew jego woli.

Klient prawdopodobnie nie potrzebuje kompletnego rozwiązania, aby osiągnąć wartość. A już na pewno będzie bardziej zadowolony z częściowego rozwiązania niż z bezczynnego oczekiwania na koniec projektu.

I zawsze pamiętajmy, że 0,2 jest zdecydowanie większe niż zero.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: