Spis treści
Dodawanie nowej funkcjonalności - przypadek 1
Dostałem ciekawe pytanie na temat dodawanie nowej funkcjonalności przy przy okazji postów z serii "Przepisujemy moduł w systemie". Zacząłem odpowiadać, a odpowiedź robiła się coraz dłuższa. Ostatecznie wydaje mi się, że zarówno pytanie jak i odpowiedź, mogą mieć dla Ciebie wartość. Na tym skupię się w tym wpisie.
Oto i ono:
Dla porządku (pamiętasz, że w metodach warsztatowych lubimy porządek?:) ) podzielę mail na dwa pytania:
- Czy Event Storming jest dobrą metodą, na dodawanie nowej funkcjonalności w istniejącym już systemie?
- Czy gdy bierzemy się za dodawanie nowej funkcjonalności do istniejącego systemu, to warto robić Event Storming dla całości zagadnienia?
Dodawanie nowej funkcjonalności - przypadek 1
Pytanie brzmi: Czy Event Storming jest dobrą metodą, na dodawanie nowej funkcjonalności w istniejącym już systemie?
Gdy pytamy, czy Event Storing będzie dobry przy okazji "nowej fukcjonalności", to posługujemy się pewnym skrótem myślowym. Otóż, jeśli funkcjonalność jest już wymyślona, to żadnego stormingu tam nie potrzeba. Zatem to pytanie należy rozumiec tak, że mamy jakiś problem biznesowy, który planujemy rozwiązać poprzez dostarczenie nowej funkcjonalności. Chcemy najpierw zrozumieć, co się dzieje w biznesie, a potem zaproponować rozwiązanie.
Przy powyższych założeniach, moim zdaniem jak najbardziej tak. Mam bardzo dużo takich przypadków. Najczęściej pracuję z systemami enterprise: bankowość, ubezpieczenia.
Najważniejszą sprawą jest, aby na warsztat zaprosić właściwe osoby. Ja zapraszam:
- product ownera i proszę go/ją, aby zaprosił również co najmniej jedną osobę z biznesu, która bardzo dobrze rozumie domenę
- zespół deweloperski (cały)
W powyższym opisię przyjąłem, że zespół pracuje w Scrum, czyli jest tam product owner biznesowiec, a zespół liczy nie więcej niż dziewięć osób.
Na takim warsztacie skupiamy się wyłącznie na jednym wąskim zagadnieniu i dość szybko przechodzimy do tak zwanego design level w Event Stormingu, czyli szczegółowego rozkminiania, co z czym współpracuje i jakie są tego konsekwencje.
Dodawanie nowej funkcjonalności - przypadek 2
Pytanie brzmi: Czy gdy bierzemy się za dodawanie nowej funkcjonalności do istniejącego systemu, to warto robić Event Storming dla całości zagadnienia?
To zależy :), lecz jako szanujący się konsultant, poniżej wyjaśniam od czego.
Klient wewnętrzny
Jeśli pracujesz dla klienta wewnętrznego, czyli masz product ownera oraz biznes w swojej firmie i robicie swój własny soft, to nie. Sugeruję zrobić Event Storming tylko dla fragmentu, nad którym właśnie pracujecie. To podejście będzie działać, gdyż wszyscy jesteście zanurzeni w tym samym kontekście Waszej pracy. Macie ten sam majndset - mówiąc po kołczowemu.
Klient zewnętrzny
Jeśli pracujesz dla klienta zewnętrznego, czyli Ty lub Twoja firma dostaliście zlecenie dodania ficzera do systemu Waszego klienta, to tak. Sugeruję zrobić Event Storming dla całości biznesu. Opracowanie razem z klientem etapu big picture Event Stormingu, pozwoli Ci zrozumieć Ci cały kontekst problemu oraz zaproponować dobre rozwiązanie. Mniej więcej ten przypadek opisuję w serii postów o wspólnym tytule "Przepisujemy moduł w systemie".
To podejście kosztowo się opłaca, gdy system nie jest "aż tak duży". "Aż tak duży", to rozmyte pojęcie, ale dam Ci pewne przybliżenie. https://booksy.com, http://nofluffjobs.com, http://wakacje.pl. Te serwisy, nigdy nie były moimi klientami, ale z palca strzelam, że mieszczą się w pojęciu "nie aż tak duży". Biorę pod uwagę, że wymienione serwisy, to tylko wizualna końcówka tych biznesów i dużo mięcha jest ukrytego pod spodem, w tzw. backoffice.
Jeśli soft jest większy np. korporacja ubezpieczeniowa, bank, to mapowanie wszystkiego wykłada się o pieniądze, gdyż jest to dużo godzin pracy wielu ludzi. Firma musiałaby mieć naprawdę bardzo poważny problem, żeby na coś takiego się zdecydować. "Naprawdę poważny problem" to np.:
- technologia/komponent, na której oparliśmy większość naszego biznesu, przestaje być rozwijana i wspierana przez producenta,
- mamy taki dług techniczny, że całkowicie utraciliśmy przewidywalność, nie mamy pewności czy potrafimy regresyjnie testować nasze oprogramowanie.
Pozostałe przypadki
Pozostałe przypadki, gdy warto przeprowadzić Event Storming dla całości biznesu, gdy już istnieje system, który go wspiera, to:
- przepisywanie systemu z jednej technologii do drugiej,
- optymalizacja procesów biznesowych,
Jak mam przekonać klienta?
Pewnie kołacze Ci teraz w głowie pytanie: jak przekonać klienta do przeprowadzenia warsztatu Event Storming w opisanych wyżej przypadkach. Odpowiedź może Cię rozczarować, ale myślę, że jest ważna z perspektywy tego, co analizujemy w postach nt. przepisywania modułu w systemie.
Przekonanie klienta nie jest (teraz) Twoim problemem. Zakładam, że pracujesz jako: PO, PM, developer/tester, analityk. Problem przekonania klienta do Event Stormingu jest problem sprzedażowym, nie analitycznym. Wskazówki, jak zmierzyć się z problemem sprzedażowym znajdziesz we wpisie pt. Pytania, które zadaję klientom na wstępie.
