Spis treści
Wybieraj metodę właściwą do kontekstu
Metoda 1: Poszatkuj użytkownika
Zacznę od przykładu. Pracowałem kiedyś dla firmy ubezpieczeniowej, w której czas dostarczenia nowej funkcjonalności dostępnej dla klienta wahał się w granicach 18-24 miesiące. Osoby, które nad tym pracowały mówiły o następujących powodach tak długiego lead time:
- żeby funkcjonalność była użyteczna dla klienta, trzeba wdrożyć ją w całości tak, jak została zaprojektowana,
- potrzeba wielu konsultacji z prawnikami,
- potrzeba spełnić wiele wymagań regulacyjnych,
- potrzebny jest również dewelopment w systemie core (system, który realizuje transakcje ubezpieczeniowe), a za system core odpowiedzialna jest osobna spółka.
Trzeba sobie dobrze uświadomić, że wielkie cele biznesowe generują jeszcze większą złożoność techniczną. Często przedstawia się ten fakt jako piramidę. Wierzchołek piramidy to wymaganie biznesowe, a jej podstawa to wymagania techniczne. Niepodzielony na części cel biznesowy po dojściu do szczegółów technicznych, wygeneruje ogromną ilość specyfikacji, zawiłych diagramów i konieczności synchronizacji. Z doświadczenia wiem, że bardzo trudno prowadzi się w takich przypadkach warsztaty, gdyż po prostu jest zbyt dużo rzeczy do przeanalizowania.
Wybieraj metodę właściwą do kontekstu
Gdy spec IT słyszy, że trzeba podzielić dużą funkcjonalność na kawałki, to przeważnie pierwszą metodą, która przychodzi mu lub jej wtedy do głowy jest warsztat User Story Mapping (USM). USM jest właściwą metodą, gdy analizujemy proces pracy potencjalnych użytkowników, a potem szukamy funkcjonalności, które im w tym najbardziej pomogą. USM dobrze sprawdza się podczas wymyślania funkcjonalności, gdy użytkownicy są dobrze zdefiniowani i mamy na warsztacie przynajmniej kogoś, kto ich reprezentuje.
Rzeczywistość jest jednak taka, że często wkraczasz w już istniejące prace, gdy warsztaty z użytkownikami zostały już dawno przeprowadzone, gdy funkcjonalności zostały już zaprojektowane, a makiety ekranów zaakceptowane. Co wtedy?
Krok wstępny
Trzymajmy się przykładu firmy ubezpieczeniowej i załóżmy, że chodzi o nową funkcjonalność sprzedaży polisy OC samochodu. W pierwszym kroku możliwie jak najdokładniej sporządź listę wszystkich spraw, które sprawiają, że dostarczanie nowej funkcjonalności "musi" trwać tak długo.
Wcześniej podałem, że moi rozmówcy wskazali następujące powody:
- żeby funkcjonalność była użyteczna dla klienta trzeba wdrożyć ją w całości tak, jak została zaprojektowana,
- potrzeba wielu konsultacji z prawnikami,
- potrzeba spełnić wiele wymagań regulacyjnych,
- potrzebny jest również dewelopment w systemie core, a za system core odpowiedzialna jest osobna spółka.
Sporządź tak długą i tak precyzyjną listę, jak tylko się da. Im dłuższa, tym większa będzie przyjemność z wykreślania kolejnych punktów.
Metoda 1: Poszatkuj użytkownika
Zadaj następujące pytanie: Jakich cech użytkownika tej funkcjonalności musimy się pozbyć, aby wyeliminować któryś z powodów wydłużających prace?
Popatrz na poniższy rysunek w kontekście funkcjonalności do sprzedaży polis OC.
W tym przypadku okazało się, że określony zestaw cech związanych z potencjalnym kupującym np. wiek, marka samochodu, znacząco wpływają na ocenę jego szkodowości. To z kolei upraszcza modele ryzyka, eliminuje część pracy po stronie prawników oraz dewelopment po stronie systemu core.
Początkowe skoncentrowanie się na jednym konkretnym typie klienta/użytkownika pomaga wyeliminować część zadań wydłużających pracę. Gratulacje, właśnie nieco okroiliśmy nasze MVP.
Jako ciekawostkę dodam, że w trakcie wspomnianej współpracy z firmą ubezpieczeniową dowiedziałem się, że czerwone samochody mają najniższą szkodowość... Nie mam pojęcia dlaczego, ot taka zależność 😃
Metoda 2: Pomiń warianty procesu
W każdej funkcjonalności wyróżniamy conajmniej 3 rodzaje scenariuszy, czyli tego co się może wydarzyć w trakcie korzystania z niej:
- scenariusze podstawowe - opisują najbardziej pożądany sposób korzystania z funkcjonalności, maksymalizują efekt, który stara się osiągnąć właściciel produktu np. konwersja, sprzedaż, zaangażowanie.
- scenariusze alternatywne - opisują mniej pożądane, ale wciąż legitne sposoby na korzystanie z funkcjonalności np. co się stanie po błędnym podaniu hasła, co się stanie w przypadku, gdy użytkownik rozpocznie korzystanie, ale przez dłuższy czas będzie nieaktywny.
- scenariusze wyjątkowe - opisują to, co powinno się wydarzyć, gdy wcześniej wydarzy się coś, co zdecydowanie nie powinno się wydarzyć.
To, co chcę Cię zaproponować nie jest żadnym z powyższych scenariuszy 😃. Zerknij na rysunek:
Na górze zapisałem z grubsza kroki potrzebne do złożenia wniosku o polisę OC. Natomiast pod spodem znajdą się warianty, czyli sposoby w jakie przejść poszczególne kroki. "Obcięcie" funkcjonalności polega na zrezygnowaniu (przynajmniej na dany moment), z niektórych wariantów. Można to zrobić na dwa sposoby:
- strzałka zielona na rysunku - rezygnujemy z najbardziej czasochłonnych do zaimplementowania wariantów i zostawiamy zestaw minimalny tak, jak na rysunku; przypuszczanie ten wybór najbardziej skróci czas pracy;
- strzałka niebieska na rysunku - zostawiamy wariant podstawowy, czyli najbardziej pożądany przez biznes i rezygnujemy z reszty; to nie jest wariant najszybszy, lecz najbardziej konwertujący; jednocześnie nie będzie on tak czasochłonny, jak robienie wszystkiego od razu.
Jeśli spodziewasz się, że wgryzając się w nowe przedsięwzięcie, na dzień dobry dostaniesz mapę wariantów, jak na rysunku i tylko zaznaczysz sobie zielone i niebieskie strzałki, to ochłoń 😃. To raczej się nie wydarzy. Taka mapę musisz sam/a poskładać sobie z fragmentów dokumentacji, makiet ekranów i rozmów z interesariuszami.
Metoda 3: Zdekomponuj outcome
Pamiętasz maila nr 1 pt. "Rozmowa o bulgulatorze". Jeśli nie, zachęcam do odświeżenia sobie. Opisałem tam różnicę między:
- outputs - to, co produkujemy,
- outcomes - to, za co płacą klienci.
Każde wdrożenie ma (powinno mieć) sprecyzowane oczekiwania biznesowe, czyli outcome. Różnie z tym bywa, bo czasem jedynym celem pracy jest jej dokończenie. Przypuśćmy jednak, że w Twoim przypadku istnieje zdefiniowany outcome
Wspólnie z osobami odpowiedzialnymi za biznes zastanów się, w jaki sposób podzielić outcome na mniejsze części. Ponownie zerknij na rysunek.
Gdy zadam sobie pytanie Za co chcą zapłacić klienci?, to w naszym ubezpieczeniowym przykładzie chodzi o polisę OC. Jednak - jak obrazku powyżej - możesz podzielić biznesowe oczekiwania na mniejsze części i skupić się na dostarczaniu kolejnych małych outcomes.
Metoda 4: Ściśnij czas
Zadaj pytanie: Jaką część tej funkcjonalności możemy udostępnić użytkownikowi w kwartał?
Czasem działa, lecz przeważnie musisz pomóc swoim rozmówcom obcinać zakres prac z wykorzystaniem metod 1, 2 i 3.