Jeśli przeczytasz uważnie artykuły: Odróżniaj wartościowe od użytecznego, Cięcie zakresu na wczesnych etapach, Dlaczego drobne zmiany trwają wieczność, Rozwiązuj problemy, odhaczaj zadania - to zgodzisz się z tym, że:
- gdy skupiamy się na stopniowym wzroście wartości oprogramowania, to niekoniecznie idzie za tym pełna użyteczność dla klienta - to jest OK.
- mamy co najmniej trzy metody wyłuskiwania tego, na czym w pierwszej kolejności powinien skupić się dewelopment:
- poszatkowanie użytkownika tak, aby wyodrębnić takie oczekiwania, które można dowieźć,
- pominięcie części wariantów procesu biznesowego,
- zdekomponowanie outcome,
- ściśnięcie czasu :).
- istotną przyczyną obsesyjnego dorzucania pracy do IT jest zbyt duża bezwładność procesu deweloperskiego.
- lepiej definiować zakres prac z perspektyw outcome zamiast output.
Zacznijmy od przykładu.
Planujemy zakres
Zbierzmy w całość poszczególne elementy układanki, które opisuję w tej serii. Oto, koncept tego, co planujemy dostarczyć:
Dla kogo robimy?
Dla właścicieli japońskich samochodów, starszych niż 25 lat, którzy rejestrują kolejny samochód do 3,5t, maksymalnie 3-letni.
Za co najbardziej chcą zapłacić klienci?
Za polisę OC wystawioną szybko i bez formalności.
Jakie jest nasze rozwiązanie?
Apka sprawnie zbiera podstawowe dane. Konsultant rejestruje umowę w systemie corowym. Po potwierdzeniu zawarcia umowy, konsultant za pomocą apki odsyła klientowi umowę bądź odmowę.
Kluczowe funkcjonalności
- Podanie danych osobowych,
- Podanie danych pojazdu,
- Podanie sposobu użytkowania pojazdu,
- Akceptacja zgód prawnych,
- Autoryzacja kodem SMS.
Poza zakresem
Skanowanie dowodu, integracja z mObywatel, dodatkowi właściciele, doubezpieczenie, rozróżnienie między wnioskodawcą o polisę a właścicielem samochodu.
Planujemy sprinty
W rygorze powyższych założeń rozkminiamy, jakie konkretne małe ficzerki są potrzebne, aby umożliwić klientowi korzystanie z tych kluczowych funkcjonalności (wypunktowane wcześniej). Mnie wyszło tak:
Definiujemy cele sprintów
Jak możesz zauważyć cały zakres pracy upakowałem w krótkie interwały, które znawcy nazywają iteracjami bądź sprintami. Ważne jest to, że każda z tych iteracji ma konkretny cel do osiągnięcia. W naszej nowomowie powiemy, że po zakończeniu prac w ramach iteracji, zespół powinien dostarczyć wzrost wartości tworzonego produktu w postaci konkretnego outcome ;)
Fajnie to brzmi, co? :) Trochę jak "wybrane aspekty pewnych problemów". W gruncie rzeczy chodzi to, że na koniec prac w iteracji, trzeba mieć podstawę do wystawienia faktury. I to podstawę lepszą niż: "zaraportowaliśmy X dni pracy". Innymi słowy trzeba mieć odpowiedź na pytanie: ile dla sponsora warta jest praca, którą wykonaliśmy? W przedstawionym przykładzie mamy następujące cele sprintów:
- Przepchnięta rura.
- Sprawdzony wcześniej klient może kupić OC.
- Minimalizujemy wysiłek klienta.
- Apka gotowa na każdego klienta.
Zacznijmy wyjaśnienia od "przepchniętej rury" :). To ważne, aby na zakończenie każdej iteracji, a idealnie w każdym momencie, tworzone oprogramowanie można było uruchomić. Uważaj, nie piszę, że trzeba je od razu sprzedawać - piszę, że trzeba je uruchomić.
To zasada Shitf Left mówi, że aktywności, w których jest możliwość wystąpienia błędu, należy przesuwać na jak najwcześniejsze etapy procesu. Możliwość uruchomienia oprogramowania w dowolnym momencie, sprawia, że od razu wychodzą na wierzch wszystkie techniczne niedociągnięcia, kłopoty z integracją, nieaktualne certyfikaty, błędy w trasowaniach itd. Żeby oprogramowanie uruchomiło się i działało, trzeba te wszystkie problemy rozwiązać, czyli przepchąć rurę ;). W literaturze mówią na to Walking Skeleton.
Celem sprintu nr. 2 jest podstawowy flow dla "sprawdzonego klienta". Kim jest sprawdzony klient? To taka grupa testowa, co do której jesteśmy pewni, że nie wyskoczy nam jakaś niespodzianka formalno-prawna, tacy co widząc lukę w oprogramowaniu dadzą dobry feedback, tacy co współpracują z nami bliżej nad rozwojem naszych produktów. Często w tej grupie są pracownicy danej organizacji i stąd bywa nazywana Family & Friends.
W celu trzecim skupiamy się na polerowaniu doświadczenia klienta. Chcemy, żeby zawarł umowę OC szybko i sprawnie. Natomiast w celu czwartym rychtujemy apkę dla dowolnego klienta - jak mówią - z ulicy.
Co wykorzystałem w artykule?
Wprawne oko zauważyło, że w tym artykule, do dekompozycji funkcjonalności na mniejsze kawałki i upakowania ich w sprinty, posłużyłem się fragmentem warsztatu User Story Mapping. Ten warsztat jest fragmentem kursu online Warsztatowe metody analizy. Ten kurs to mega combo metod usprawniających współpracę z klientami! Zerknij na stronkę i zobacz, czego możesz się nauczyć.