Gdy Klient nie decyduje…

„Informujemy, że podczas składania zamówienia niektóre produkty były na wyczerpaniu i nie są już dostępne. Zgodnie z regulaminem sklepu, zamówienie zostanie pomniejszone o dany produkt. Jeżeli zamówienie było opłacone z góry, środki zostaną zwrócone na konto w ciągu 7 dni roboczych.”. Taką wiadomość otrzymałem z jednego ze sklepów internetowych, prawie tydzień od złożenia zamówienia. O tym, że realizacja zamówienia będzie wydłużona wiedziałem od momentu składania zamówienia. Także później przyszła informacja o tym, że potrwa dłużej. Jednak gdy otrzymałem taką wiadomość byłem trochę zaskoczony, bo składając zamówienie nie było informacji o potencjalnych brakach produktów.

Przy wcześniejszych zamówieniach, które składałem, takie sytuacje się zdarzały, ale sposób działania sklepu był inny. Jedne sklepy oczekiwały potwierdzenia w zakresie proponowanych akcji lub anulowania zamówienia. Były też propozycje telefoniczne zastąpienia produktu innym w podobnej cenie. Pierwszy raz mi się zdarzyło, że to sklep zadziałał w określony sposób, tylko mnie informując. W sumie cieszę się, że nie czekali z realizacją zamówienia na moją decyzję, a zwrócą środki za brakujące produkty, a resztę zamówienia zrealizują.

Na poniższym diagramie w BMPN spróbowałem przedstawić opisywaną sytuację (mam nadzieję, że w poprawny sposób).

W celu zobrazowania sposobu obsługi sytuacji, gdy na magazynie jednak nie ma produktu, użyty został obiekt BPMN wskazujący na błąd wewnątrz procesu (ang. intermediate error event), a dokładnie w ramach wykonania kroku procesu. Po wystąpieniu tego zdarzenia, następuje poinformowanie Klienta (pierwszy krok po zdarzeniu) oraz zwrot środków (drugi krok po zdarzeniu). Obiekt błędu jest umieszczony na obramowaniu kroku Skompletuj zamówienie. Jest to wskazanie, że błąd nastąpił w trakcie realizacji tego kroku i został przejęty (ang. catch) i obsłużony (ang. handle) ramach wskazanych kroków.

Mogę sobie wyobrazić, że podczas tego kroku, pracownik sklepu przechodzi przez magazyn z elektroniczną listą produktów, znajduje je po kolei i umieszcza w środku transportu. Po przejściu kilkunastu pozycji zamówienia, nie odnajduje kolejnego produktu w odpowiedniej ilości. Oznacza to, kompletuje resztę. Na tej podstawie proces idzie dla zebranych produktów dalej, a dla brakujących jest obsługa sytuacji nietypowej/wyjątkowej.

Innym rozwiązaniem jest, gdy taki obiekt błędu jest umieszczany jako niezależny element w ramach przebiegu procesu (ang. sequence flow). Przykład takiego zastosowania tego obiektu można zobaczyć w innym wpisie dotyczącym wyjątków.

Reklama

Zdalne ceremonie

Panująca epidemia/pandemia oraz wprowadzone ograniczenia przez władze państwowe oraz lokalne spowodowały, że wiele podmiotów gospodarczych zaczęło się zastanawiać nad swoją przyszłością, swoim modelem działalności oraz sposobem działania. Wiele firm, co można zaobserwować na ulicy, w artykułach oraz w serwisach internetowych, wprowadziło pracę zdalną. Pracownicy przebywając w domu wykonują obowiązki związane ze swoim stanowiskiem. Muszą się przestawić na inny sposób komunikacji, interakcji oraz wykorzystywane narzędzia.

Czytałem ostatnio artykuły dotyczące pracy zdalnej. Pojawiło się wiele rad o tym jak sobie radzić, jakie zasady stosować, aby było to efektywne, jak poradzić sobie z ograniczeniami oraz jakie narzędzia wybrać. Pojawiają się rozbudowane materiały jak korzystać z określonych narzędzi komunikacji i współdzielenia pracy. Rozpatrywane są także zalety i wady każdego z nich, a także aspekt bezpieczeństwa. Dlatego postanowiłem, że nie będę skupiać się na dostępnych narzędziach – odsyłam do wielu dostępnych publikacji. Chciałbym się skupić na umiejscowieniu elementów związanych z organizacją pracy zdalnej w dwóch procesach, o których pisałem ostatnio na swoim blogu, a mianowicie planowaniu sprint oraz retrespektywie sprint.

Na poniższym diagramie są zamieszczone te dwa procesy, z usunięciem obiektów dodatkowych. Zostały wzbogacone o pewne elementy wspólne oznaczone numerami wraz z ich odpowiednim umiescowieniem w procesie (wszystkie elementy dodatkowe są zaznaczone na pomarańczowo).

Dodane elementy wskazują 3 dodatkowe kroki w procesie, które są silnie związane z przejściem zespołu agile’owego na pracę zdalną. Poniżej, krótkie przybliżenie każdego z tych kroków.

Krok oznaczony (1): Przygotuj narzędzia
Pierwszy krok, od którego warto zacząć proces planowania sprint czy retrospektywy, to wybór narzędzia, za pomocą którego będzie przeprowadzone spotkanie. Po wyborze narzędzia trzeba przygotować odpowiednie środki, zaproszenie oraz wskazać zespołowi czy potrzebuje określonych mechanizmów, instalacji czy innych elementów. Wybór narzędzia jest uzależniony od potrzeb zespołu: czy zależy zespołowi, aby tylko się słyszeć oraz móc zaprezentować swój ekran, czy też potrzebne są szersze możliwości. Może jednak potrzebne są rozwiązania w zakresie zdalnej współpracy zespołu. Może zespół chce się przez całe spotkanie widzieć (co na przykład w przypadku retrospektywy byłoby przydatne, aby widzieć reakcje). Ten krok ma miejsce przed spotkaniem, na etapie jego przygotowania.

Krok oznaczony (2): Wdróż narzędzia
W momencie rozpoczęcia spotkania, warto wykonać weryfikację czy wszyscy słyszą dobrze (w sposób akceptowalny) pozostałych uczestników i czy nie mają problemów z wybranym narzędziem. Warto też sprawdzić czy jest możliwość wyświetlenia prezentacji czy przeprowadzenia sesji współpracy przy pomocy wybranego narzędzia. Jeżeli zespół korzysta z połączeń video, to dobrze sprawdzić czy obraz spełnia oczekiwania. Dobrą praktyką jest aby na początku spotkania także ustalić zasady wykorzystania narzędzia – na przykład mutowanie się uczestników, którzy w dany momencie nie mówią lub informowanie natychmiast o problemach. Element dodany jako pierwsza część spotkania.

Krok oznaczony (3): Zweryfikuj działanie
W trakcie spotkania, warto co jakiś czas upewniać się czy nikt nie wypadł ze spotkania lub czy nadal wszyscy słyszą w sposób akceptowalny pozostałych uczestników. Uczestnicy mogą też utwierdzać się, że każdy z uczestników widzi wykonane zmiany lub cały udostępniony ekran. W sytuacjach problemowych uczestnicy przypominają o ustalonych zasadach – prosząc na przykład o wyłączenie mikrofonu, poprawę mikrofonu czy też zmianę lokalizacji w domu, bo na przykład w tle są rozpraszające dźwięki. Ten element został umieszczony na diagramie jako ścieżka równoczesna procesu, dołączona do odpowiednich miejsc w procesie – tzw. bramka równoległa (ang. parallel gateway).

 

Problem nie tylko w teorii

Słuchając wypowiedzi lekarzy, polityków, publicystów, śledząc publikacje na temat tego, co się obecnie dzieje w Polsce i na świecie w kontekście występującej pandemii, zacząłem się zastanawiać w jaki sposób można spojrzeć na podejmowane przez różne podmioty działania. Jedni wprowadzają pracę zdalną, inni wstrzymują produkcję, oferowanie usług. Jedni patrząc z wielką obawą w przyszłość, a inni są jeszcze spokojni.

Pojawiają się nowego ograniczenia, sposoby postępowania, akcje społeczne, wyrazy solidarności. Uczniowie muszą się przestawić na inny tryb nauki, osoby przyzwyczajone do bardzo aktywnego trybu życia, muszą zwolnić i zostać w domu. Osoby, które planowały różne spotkania, wyjścia na koncerty, uroczystości czy inne działania, muszą zmienić swoje plany. Ograniczają często swoje codzienne działania wymagające wyjścia z domu, do zakupów, krótkiego spaceru z dala od innych. Część osób nie może w cale wychodzić.

Każda z tych osób, podmiotów, państw walczących z epidemią/pandemią, analizuje problem, z którym się mierzy, którego doświadcza. Zbiera dostępne fakty/informacje, obserwuje zachowanie innych jednostek/podmiotów i ocenia je poprzez pryzmat swojego doświadczenia, potrzeb oraz możliwości. Przeprowadza diagnozę sytuacji w danym momencie.

W kolejnym kroku, zastanawia się na czym mu zależy, co chce osiągnąć w danej sytuacji oraz jak chce się zmierzyć z tym problemem. Czego oczekuje, że się wydarzy. Rząd może powiedzieć, że chce zmniejszyć obciążenie szpitali, zmniejszyć ryzyko masowych zachorowań czy też zoptymalizować wydatki w tym trudnym okresie. Podmiot chce zapewnić na przykład przetrwanie biznesu. A zwykły obywatel nie chce się na przykład zarazić. Jest to tzw. określenie oczekiwanego efektu działań.

W zależności od tego, kto określa problem oraz swój cel, może się pojawić różna koncepcja działań. Decydent określa jakie są możliwe działania, kroki do podjęcia, na kim możemy się wzorować, jakie są potrzebne zasoby oraz co dotychczas zrobiliśmy w celu osiągnięcia celu. Na bazie publikacji dotyczących pandemii, pojawiają się na przykład koncepcje działań, które określane są jako model europejski, chiński czy też krajów azjatyckich, patrząc globalnie na całe państwa, regiony. Każde z podejść ma jakieś skutki, prognozowany przebieg, czas dojścia do celu i ryzyka. W ramach wyboru koncepcji działania, następuje prognozowanie tego co się wydarzy.

Te ryzyka, przebieg, potencjalne efekty oczekiwane i uboczne muszą zostać wzięte pod uwagę podczas wyboru najlepszego rozwiązania do zastosowania. Ocena koncepcji działania odbywa się w gronie wybranych osób, przez jedną osobę, korzystając z wiedzy ekspertów dziedzinowych czy po prostu przez wyznaczony do tego komitet lub powołany organ decyzyjny. Na poziomie na przykład podmiotu gospodarczego może to zrobić właściciel czy zarząd. W ramach gospodarstwa domowego, może to być ocena zainteresowanej osoby czy też całej rodziny. Planowane są odpowiednie działania, kolejne kroki wynikające z podjętej decyzji. Są podejmowane odpowiednie działania przygotowawcze oraz angażowane niezbędne zasoby.

Podjęta decyzja, przygotowany plan – można zacząć działać. Rząd informuje o podjętych działaniach, wdrożonych zasadach. Podmiot gospodarczy informuje pracowników o tym, co nastąpi w najbliższym okresie i jak ma działać podmiot. Rodzina wprowadza w życie ustaloną koncepcję działania (może to być na przykład zakupy tylko rano, poprzedzone krótkim spacerem, bez odwiedzania zbyt wielu miejsc).

Po jakimś czasie, konieczna jest ocena podjętych działań. Dzięki temu wiemy czy są skuteczne, czy potrzebne są modyfikacje, czy przyniosły planowane efekty czy nie wygenerowały nowych ryzyk, a także czy nie zminiło się otoczenie i sytuacja. Obserwując różne podmioty ma się wrażenie, że po pierwszym podejściu (na przykład będziemy sprzedawać na wynos), zmieniają założenia (na przykład zamykamy lokal lub ograniczamy dotychczas podjęte działania).

W powyższym opisie, pewne elementy pogrubiłem. Są to elementy, które nawiązują z jednej strony do teorii sprawnego działania, czyli prakseologii ale także do cyklu rozwiązywania problemów. W sieci Internet można znaleźć wiele publikacji, które określają różne sposoby rozwiązywania problemów, wdrażania zmian, reagowania na nietypowe sytuacje. Wybrałem pewne uogólnienie, wzorując się na kilku publikacjach i zaprezentowałem je na powyższym diagramie.

Działanie w takich krokach ma zastosowanie na różnych poziomach życia gospodarczego, społecznego oraz prywatnego – między innymi w sytuacji, gdy pojawia się nowa sytuacja, problem, z którym trzeba się zmierzyć. Poradzenie sobie z pandemią to celowe działanie ludzkie, zmierzające do oczekiwanego efektu (ograniczenia efektów, zmniejszenie liczby zachorowań, rozłożenie zachorowań w czasie itp.).  W powyższych wyjaśnieniach pojawia się sformułowanie o wyborze najlepszego rozwiązania spośród możliwych w danym momencie i przy określonych okolicznościach. Równocześnie jest mowa o tym, że dążymy do pewnego oczekiwanego efektu. Podejmując decyzję odnośnie napotkanego problemu można spojrzeć na to jak na pewien projekt, w którym musimy spojrzeć na dwa aspekty – zarówno sprawność samego działania, jak i jego efektywność. I na koniec oceniamy czy działania były warte podjęcia i osiągnęliśmy trwały sukces, czy może porażkę. Wkrada się tutaj oczywiście niepewność, ponieważ z jednej strony nie wiemy wszystkiego o wirusie, a z drugiej nie wiemy do końca czy podjęte działania przyniosą oczekiwane efekty. Decydent narzucający/rekomendujący sposób postępowania dla innych, nie wie czy i w jakim zakresie będzie on stosowany.

Zachęcam do zapoznania się z różnymi metodami rozwiązywania problemów i przyjrzenie się temu, co się dzieje obecnie z ich perspektywy – moja próba spojrzenia jest powyżej. Czasami można wyraźnie zauważyć poszczególne etapy (zasygnalizowane przez wypowiedzi osób) lub je odczuć na własnej skórze (jak realizacja zaleceń co do braku zgromadzeń). Obecny trudny czas, gdy wszyscy mają wspólny problem do rozwiązania, jest idealnym obrazem (pozwolę sobie użyć takiego sformułowania) każdego z tych etapów.  I w sumie każdy z nas, zauważy w różnym stopniu, czy komunikowany efekt wystąpił i w jaki sposób nastąpiło przejście w kolejny cykl tego procesu. Choć mam wrażenie, że już jesteśmy w kolejnym cyklu (pewnie kolejnym z wielu).

—

Za inspirację do poruszenia tego tematu, a dokładnie tematu prakseologii, dziękuję jednemu z obserwatorów mojego bloga, który odniósł się w komentarzu na LinkedIn do mojego wpisu o metodzie start-stop-continue z 2 marca 2020.

„Ciche” zdarzenie w procesie

Miałem pomysł na wpis zainspirowany tym, co się dzieje obecnie w Polsce i na świecie. Zrezygnowałem jednak z niego, choć tematyka tego wpisu będzie jakoś związana z tematyką zdrowia i medycyny. Jakiś czas temu, wysłałem w usługach medycznych zlecenie.. Po wybraniu właściwej opcji, potwierdzeniu oświadczeń zlecenie zostało wysłane. Mijają kolejne dni, a powiadomienia o realizacji/podjęciu zlecenia nie przychodzi. Po sprawdzeniu w systemie okazało się, że zlecenie wisi. Postanowiłem ustalić co się dzieje poprzez wykorzystanie infolinii zamiast udawać się do punktu, czekać w kolejce i odejść „z niczym” – co się ostatecznie okazało. Okazało się, że lekarz właściwy do podjęcia zlecenia jest nieobecny przez określony czas. Trudno, trzeba poczekać.

Wracając jednak do infolinii, z której nie korzystałem od dawna, spotkałem się z nową dla mnie sytuacją. Generalnie bardzo rzadko mam okazję korzystać z infolinii. Ostatnie moje doświadczenia były inne, bardziej standardowe, opierające się na wybieraniu określonych numerów z klawiatury, a potem kończyło się rozmową z konsultantem. Tym razem było inaczej…

Po przywitaniu, przedstawieniu formuły o ochronie danych osobowych, identyfikacji poprzez podanie numeru klienta, padło sformułowanie: „Proszę powiedzieć czego potrzebujesz…”. I w tym momencie nastała cisza – ja nic nie mówiłem i w słuchawce była cisza. Czekałem na standardową formułkę: „Wybierz 1, aby…., wybierz 2, aby…”. Po kilkunastu sekundach usłyszałem: „Powiedz, co potrzebujesz, na przykład [i pojawia się fraza] chcę się umówić na wizytę”. I w tym momencie stało się jasne, że zmienił się model obsługi na infolinii. Podałem potrzebę i „obsługa” poszła dalej już w mniej zaskakujący sposób. Było to ciekawe doświadczenie, które próbowałem zobrazować na poniższym diagramie w BPMN, z pewnym zastrzeżeniem. Zastosowałem na nim uproszczenie dla zadania „Kontynuuj proces” (zaznaczonego linią przerywaną). Nie wskazałem konkretnych kroków, które dalej mogłyby wystąpić – można to potraktować jako podproces lub pominięcie kroków procesu podczas jego wizualizacji.

Po rozłączeniu zacząłem się zastanawiać:

• (1) na ile sekund ciszy był ustawiony system (oznaczenie zdarzenia czasowego (ang. intermediate timer event) na diagramie),
• (2) co w sytuacji, gdybym użył jakiegoś sformułowania, np. komentując do osoby obok: „chyba nie działa”,
• (3) co w sytuacji, gdybym użył słowa, na które system nie jest przygotowany,
• (4) co w sytuacji, gdybym powiedział coś za cicho/niewyraźnie lub w sposób niekompletny (np. ze względu na posiadane objawy)

System w różnych sytuacjach może mieć przygotowaną odpowiednią reakcję – prosić o powtórzenie, powiedzenie głośniej, użycie innych słów, „dopyta” lub skieruje bezpośrednio do konsultanta z odpowiednim oznaczeniem sprawy. Sytuacje (2)–(4) są wynikiem działań oznaczonych na diagramie poprzez grupę, w której znajduje się „Przeanalizuj przekaz”. Jest to pewne uproszczenie, na które sobie pozwoliłem i wykorzystałem do tego element bramki opartej o dane (ang. data based gateway). Danymi tutaj jest „treść” przekazu przełożona na odpowiednie części składowe oraz odpowiednio przeanalizowana (zainteresowanych odsyłam do publikacji na ten temat).

Przypuszczam, że takie rozwiązania nie są rzadkością. Wynikać to może z różnorodności potrzeb użytkowników. Zdarzyło mi się kilka razy, że zastanawiałem się, którą opcję wybrać spośród wskazanych i przeważnie wtedy wolałem nawiązać połączenie z konsultantem. Myślę, że pewne kwestie mogą zostać obsłużone bez udziału konsultanta – na przykład mógłbym sobie wyobrazić, że przesunięcie wizyty na pierwszy możliwy termin. W powyższym przypadku to system za użytkownika wybiera odpowiednią ścieżkę obsługi a może nawet skierować do odpowiedniego konsultanta, bazując na ustalonych regułach czy słowach kluczowych.

Gdy chodzi o pieniądze

Wczoraj słuchając wypowiedzi podczas konferencji prasowej, mającej miejsce późnym wieczorem, dotyczącej przekazania określonej kwoty ma media publiczne, zacząłem się zastanawiać jakie pytania/kryteria można postawić podejmując taką decyzję. Spokojnie, nie będę się zastanawiał nad pytaniami, które można postawić dokładnie we wspomnianej sytuacji. Nie będę się także wypowiadał na temat przedmiotu decyzji czy też wyrażał swojej opinii odnośnie podjętej decyzji. Nie będę też zastanawiał się nad konsekwencjami tej decyzji. Nie będę też nawiązywał do działań, które miały miejsce, przed podjęciem tej decyzji.

Spróbuję uogólnić taką sytuację skupiając się na samym procesie podejmowania decyzji. W sytuacji podejmowana decyzji o finansowaniu, decydent zbiera informacje, ocenia kwestie formalne oraz merytoryczne, identyfikuje cel finansowania i jego warunki a potem wskazuje jaka jest decyzja. Poniższy diagram przedstawia w formie drzewka decyzyjnego jakie kwestie mogłyby być brane pod uwagę podczas podejmowania decyzji o udzieleniu finansowania (z perspektywy komitetu bądź pojedynczej osoby).

Na diagramie zaznaczono takie elementy jak:

• przykład kwestii odnoszącej się do weryfikacji kwestii formalnych (kompletność wniosku – np. czy posiada wszystkie wymagane dane, załączniki, zgody);
• weryfikacja merytoryczna w zakresie elementów biznesowych wniosku takich jak relacja wnioskowanej kwoty do planowanych efektów, korzyści biznesowych, uwzględnienia otoczenia biznesowego, sytuacji rynkowej;
• weryfikacja prośby/wniosku w kontekście obowiązujących reguł czy zasad; np. w organizacji może funkcjonować przepis, że na dany rodzaj inicjatywy przeznaczamy tylko określoną kwotę budżetu lub odgórne postanowienie, że nie podejmujemy zobowiązań finansowych w kontekście określonych podmiotów/dostawców (bo na przykład ryzyko jest za duże);
• decyzja odnośnie tego czy przekazanie środków powinno być obarczone dodatkowymi warunkami (np. Zestawienia wykorzystania, udostępnienie w transzach) czy wnioskujący otrzymując środki nie musi nic więcej robić.

Punktem wejścia do podejmowania decyzji jest weryfikacja dostępności budżetu. Jeżeli środki się skończyły lub dostępny budżet został zarezerwowany na inne kwestie, to wtedy wniosek jest odrzucany bez dalszej analizy. W przypadku, gdy środki są dostępne, możliwe są różne warianty sytuacji, począwszy od odrzucenia wniosku z powodów formalnych, przez odrzucenie ze wskazaniem elementów do wyjaśnienia, potem akceptacje warunkowe czy na koniec akceptacja bezwarunkowa. Wszystko zależy od rodzaju wniosku, osób podejmujących decyzję oraz przyjętych zasad, a także innych kwestii specyficznych dla danej organizacji czy podmiotu gospodarczego.

Akceptacja środków może być także wielostopniowa – w zależności od kwoty czy przedmiotu, który będzie podlegał finansowaniu. Można sobie wyobrazić, że na diagramie dojdzie element, który wskaże, że wniosek zostanie przekazany do wyższej instancji lub innego komitetu. Często w statusach spółek (czego odzwierciedlenie można znaleźć w KRS), są informacje kto może podejmować zobowiązania, w jakim zakresie i do jakich kwot. Takie przesunięcie decyzyjności może się pojawić w momencie analizy wniosku, pozyskania dodatkowych informacji czy też dostępności lub nie w danym momencie osób uprawnionych, a także aktualności pełnomocnictw czy występującego otoczenia biznesowego. Podczas analizy mogą wyjść kwestie, które należy skonsultować z jednostką prawną, podatkową czy też działem księgowości.

Warto tutaj dodać, że może też także występować możliwość odwołania się od decyzji. Zgodnie z przyjętymi zasadami w organizacji czy podmiocie gospodarczym, osoba zainteresowana musi wykonać odpowiednie kroki, aby ponownie rozpatrzono jego wniosek o finansowanie. Efektem może być ponowne przejście powyższej ścieżki lub podtrzymanie decyzji bez analizy.

Przypuszczam, że wielu moich czytelników czekało kiedyś na taką decyzję, starało się o podjęcie decyzji uczestnicząc w wyjaśnieniach. Może niektórzy nawet brali udział w podejmowaniu takiej decyzji – jestem ciekawa czy jeszcze jakąś kwestię można wskazać jako element takie procesu.

Start-stop-continue

Praca w grupie/zespole, działanie osoby pełniącej określoną rolę, realizowany proces, organizacja uroczystości/spotkania/warsztatów… – to tylko niektóre działania mające miejsce czy to w życiu prywatnym, czy to w życiu zawodowym. Sposób działania w każdym z tych obszarów może zostać przeanalizowany przy użyciu metody wskazanej w tytule wpisu – start-stop-continue. Metoda ta zakłada znalezienie odpowiedzi na pytania:

• [start] co powinniśmy lub powinna zacząć robić osoba, aby osiągnąć lepszy efekt, lepiej zostać ocenionym czy też, aby uniknąć napotkanych problemów?
• [stop] co powinniśmy lub powinna przestać robić osoba, ponieważ np. zauważamy, że nie przynosi to oczekiwanego efektu, wprowadza zamieszanie lub jest nieefektywne?
• [continue] co powinniśmy lub powinna nadal robić osoba, ponieważ to przynosi właściwe efekty, jest dobrze oceniane i pomaga w realizacji zadań?

Metoda ta jest także często stosowana, obok innych dostępnych metod, podczas tzw. retrospektywy sprintu. Retrospektywa sprintu jest to spotkanie zespołu scrumowego. Jej celem jest analiza sposobu działania zespołu scrumowego, bazując na obserwacjach i odczuciach członków tego zespołu. Jest okazją, aby omówić co działa, co nie działa a czego nam brakuje podczas realizacji pracy zespołu. Mogą to być takie elementy jak komunikacja, podejście do problemów, dostępność product ownera czy inne elementy. Efektem powinna być propozycja zmian, działań, które można wdrożyć już od kolejnego sprintu.

Osoba, która moderuje takie spotkanie, powinna zadbać o zachowanie pewnego porządku spotkania, tak, aby każdy z uczestników miał świadomość jakie są oczekiwania, czego może się spodziewać oraz jaki rodzaj zaangażowania będzie oczekiwany. Pozwoli to także zapewnić, aby każdy z członków zespołu miał możliwość, aby się wypowiedzieć i przekazać swoje uwagi, przemyślenia czy zastrzeżenia. Inną kwestią jest czy każdy uczestnik będzie chciał z takiej możliwości skorzystać. Dlatego ważny jest odpowiedni dobór metod zbierania propozycji lub/i aktywizacji uczestników.

Uczestniczyłem w różnych spotkaniach retrospektywy i moim zdaniem każda jest inna. Miałem okazję kilkakrotnie poprowadzić takie spotkanie i to z kolei dało mi zupełnie inną perspektywę. Myśląc o tym, zacząłem się zastanawiać nad strukturą takiego spotkania. Próbą zobrazowania jest poniższy diagram procesu retrospektywy.

Poszczególne kroki procesu są następujące:

Zbierz zespół/zaproś uczestników.
Pierwszym etapem jest zebranie uczestników spotkania w (najlepiej, choć nie zawsze jest to możliwe) jednym miejscu i czasie. Dokładny termin i miejsce spotkania to często element umowy wewnątrz zespołu. Jednakże dobrze jest, aby ktoś przypomniał lub zachęcił zespół do udania się na takie spotkanie lub przygotowanie się do niego. Pozwoli to także uniknąć niepotrzebnych opóźnień w jego rozpoczęciu lub wymówek odnoszących się do braku wiedzy o spotkaniu lub konieczności przygotowania się.

Przedstaw planowany przebieg spotkania
Osoba prowadząca spotkanie powinna wskazać w jaki sposób będziemy pracować, jakie elementy wykorzystamy oraz jakiego typu zaangażowanie będzie potrzebne. Dobrze także jak przypomni jaki jest cel ceremonii oraz na jakie zasady umówił się zespół dla tej ceremonii.

Przeprowadź działania
Osoba prowadząca moderuje spotkanie, pilnuje czasu, zgodnie z przyjętymi i zaproponowanymi do wykorzystania metodami. Może także podsumowywać poszczególne etapy oraz dotychczas zebrane wnioski. Może zachęcać do udziału milczących uczestników spotkania. Na spotkaniu mogą wystąpić takie aktywności jak: ocena działań ustalonych na poprzednim spotkaniu, zebranie tematów na bieżące spotkanie, ocena zadowolenia zespołu, przegląd kontraktu, wyjaśnienie zauważonych problemów czy inne. Po każdym działaniu, osoba prowadząca powinna ustalić z zespołem czy przechodzimy do kolejnej części spotkania czy jeszcze poświęcamy czas na dokończenie rozpoczętego tematu.

Podsumuj spotkanie/Zbierz wnioski
Osoba prowadząca zbiera wnioski lub prosi zespół o ich podsumowanie. Zachęca zespół do wybrania tych działań, które podejmie w kolejnym sprint. Działania mogą dotyczyć szeregu elementów składających się na pracę zespołu. Mogą np. dotyczyć ograniczenia marnotrawstwa w działaniach zespołu, komunikacji, reakcji na ocenę pracy zespołu czy innych.

Zakończ spotkanie
Osoba prowadząca podczas tego kroku dziękuje za wykonaną pracę, określa gdzie będą dostępne zebrane wnioski, podsumowanie oraz materiały. W ramach tego kroku może także poprosić o ocenę spotkania  pod kątem jego efektywności, zadowolenia zespołu. Taka ocena może być przydatna dla osoby prowadzącej – może pomóc w lepszym przeprowadzeniu kolejnego spotkania lub może być podstawą do wybrania w przyszłości innych metod zbierania informacji lub/i aktywizacji uczestników.

Ceremonia ta jest bardzo ważna. Tak jak planowanie sprint o którym pisałem miesiąc temu, wskazuje kierunek tego CO i JAK robimy w zakresie rozwoju produktu w poszczególnych sprint, tak retrospektywa wskazuje kierunek rozwoju zespołu oraz pozwala na zmianę sposobu jego działania. Ceremonia ta pozwala na to, aby tak, jak to określa wskazana na wstępie metoda: [start] zacząć robić, coś czego nie robiliśmy, czego wg zespołu zabrakło; [stop] przestać robić to, co nam utrudnia efektywną pracę oraz [continue] kontynuować to, co zespół ocenił jako cenne i czego warto się trzymać. Jest to zgodne z duchem scruma, zakładającym ciągłą inspekcję prac (zastanawiamy się nad tym co robimy oraz jak działamy), przejrzystość działań (pokazujemy jak pracujemy, jakie są efekty oraz mówimy otwarcie co nie działa i co powinniśmy zmienić) oraz adaptację (wprowadzamy zmiany i dostosowujemy działania do zebranych oczekiwań).

 

Ewolucja czy rewolucja?

15 lutego – to dzień, w którym Ministerstwo Finansów udostępniło dla podatników, w dedykowanej usłudze „Twój e-PIT”, automatycznie wypełnione deklaracje PIT za 2019 rok. Zainteresowani mogą się zalogować do usługi, wykorzystując określone dane dostępowe lub profil zaufany, zweryfikować i uzupełnić deklarację (np. o to jak przekażą 1% podatku lub wskazując ulgi), połączyć deklarację ze współmałżonkiem, a następnie wysłać wypełnioną deklarację, a następnie pobrać UPO (potwierdzenie złożonej deklaracji). Wszystko dzieje się w udostępnionej usługi. Wystarczy postępować zgodnie z instrukcjami. Można też nic nie robić i deklaracja zostanie złożona automatycznie w odpowiednim terminie . Wszystko dzieje się przez Internet – takich deklaracji złożonych przez Internet w zeszłym roku było ok. 16 mln, w 2016 – ok. 10 mln, a w 2012 – ok. 2mln (dane znalezione w Internecie).

Cofnijmy się teraz w czasie, zanim przyszedł rok 2008, gdy po raz pierwszy można było złożyć deklarację przez Internet (co zrobiło wtedy ok. 300 osób), deklaracje były wypełniane ręcznie (tzw. proces ręczny) na dedykowanych drukach lub przygotowanych do tego aplikacjach, które pozwalały na wydruk wypełnionej deklaracji i jej dostarczenie do właściwego urzędu skarbowego lub na bezpośrednie wysłanie deklaracji przez Internet.

Proces rozliczania deklaracji PIT, który można było wykorzystać na różnym etapie rozwoju tej usługi, jest zobrazowany na poniższym diagramie w BPMN, prezentujący 3 warianty składania deklaracji (od najstarszego papierowego, przez pośredni, do najnowszego):

Zastanówmy się teraz czy z perspektywy podatników proces przejścia z PIT papierowego do w pełni elektronicznej wersji (nastąpiła tutaj tzw. elektronizacja procesu) był ewolucją (ang. evolution) czy rewolucją (ang. revolution). Zanim to zrobimy przytoczmy czym charakteryzują się takie zmiany.  Zbierając informacje zróżnych publikacji dostępnych w sieci Internet można powiedzieć, że:

Ewolucja	Rewolucja
(E1) Zmiana następuje stopniowo, przyrostowo	(R1) Następuje zastąpienie czegoś istniejącego, czymś całkowicie nowym
(E2) Zmiana w danym momencie dotyka określonego obszaru	(R2) Zmiana dotyka wszystkich powiązanych obszarów za jednym razem
(E3) Ludzie mają więcej czasu, aby się przystosować do zmiany. Więcej osób identyfikuje się ze zmianą	(R3) Ludzie nie mają czasu na dostosowanie się. Zmiana może być dla nich bardzo gwałtowna, a nawet bolesna.
(E4) Zmiany są komunikowane stopniowo i wraz z nimi są przeprowadzane odpowiednie działania edukacyjne	(R4) Działania komunikacyjne i edukacja mogą być niewystarczające
(E5) Istnieje możliwość wycofania się z wprowadzonej w danym etapie zmiany i dostosowania jej założeń i zakresu	(R5) Nie ma możliwości często wycofania się z wprowdzonej zmiany
Moim zdaniem proces przypomina działania zgodne z PDCA czy benchmarkingiem	Moim zdaniem proces przypomina działania zgodne z reengineeringiem
Podsumowanie: zmiana przeprowadzana może mieć duży wpływ a być wykonywana rzadko (rewolucja) a może także być wykonywana często, ale posiadać mały wpływ (ewolucja). Jeżeli zmiany są częste i ogromnym wpływie może powstać chaos, a w momenie, gdy nie robimy zmian lub są one bardzo rzadko i mają mały wpływ, to wtedy mamy stagnację.

Patrząc na powyżej wskazane cechy i zachowanie podatników myślę, że można powiedzieć, że zmiana była ewolucyjna. Możliwość rozliczania deklaracji przez Internet została wprowadzona już w 2008 i co roku rosła liczba decydujących się na takie rozwiązanie. Mogli oni stopniowo pozyskiwać informacje o tym jak to wygląda, czy jest bezpieczne, co jest potrzebne, jakie są ograniczenia, problemy, słuchając zarówno specjalistów w tej dziedzinie, czytając artykuły, czy też zbierając informacje ze swojego otoczenia (połączenie cech E3 i E4 z tabeli powyżej). Teoretycznie nadal pozostaje możliwość rozliczenia deklaracji papierowo, więc cały czas pozostaje pewna furtka dla wprowadzających takie rozwiązanie (jakby zastosowanie punktu E5).

Samo przejście z deklaracji wypełnianej całkowicie po stronie podatnika do w dużym stopniu zautomatyzowania procesu i udostępnienia go w dedykowanej usłudze, jest rewolucyjne (samo ministerstwo określiło to w zeszłym roku jako „nową jakość”). Jest to wprowadzenie czegoś całkowicie nowego (cecha R1), co powoduje zmianę zachowań u podatników – mogą to zrobić jeszcze szybciej, wygodniej, z mniejszym ryzykiem popełnienia błędu. Ciężko tu mówić o tym, że jest to bolesne czy gwałtowne (cecha R3). Jednak jest to zmiana dotykająca wszystkich obszarów za jednym razem – zbierania informacji, przygotowania rozliczenia oraz składania deklaracji (R2). Wcześniejsze zmiany procesu dotykały części obszarów (cecha E2) – np. wypełniania deklaracji czy składania deklaracji (ręcznej po jej wydruku czy korzystając mechanizmów automatycznych). Zmiany między poszczególnymi wariantami (od najstarszego do najnowszego) są oznaczone kolorami na diagramie wraz z odpowiednimi komentarzami. Zaznaczone są także miejsca, gdzie określone kroki już nie występują w późniejszej wersji.

Pewnie dla pewnej grupy podatników, wypełnienie deklaracji w tradycyjnej formie, będzie najbardziej wygodne i będzie to jedyny akceptowalny sposób. Mają do tego jak najbardziej prawo, ale muszą się trzymać pewnych zasad. Mogą tak postępować, bo nie mają innego wyjścia, boją się lub nie akceptują innych dostępnych rozwiązań. Tacy podatnicy mogą wymagać przekazania większej liczby informacji lub dedykowanej edukacji, jeżeli wprowadzana zmiana zakładałaby ograniczenie stopniowe takiej możliwości (cecha E4) lub w pewnym momencie nastąpiłoby nagłe odcięcie takiej możliwości (cecha R4). Ciekawe czy taki punkt odcięcia nastąpi.

Mimo wszystko wydaje mi się, że patrząc całościowo, ta zmiana ma charakter ewolucyjny. Do określenia jej jako w pełni rewolucyjnej brakuje mi tego elementu odcięcia  – zastąpienia dotychczasowej usługi. Jeżeli podatnik ma prawo wyboru, to nadal „stara” wersja procesu będzie funkcjonować.  Myślę, że jest to dobry kierunek, zgodny z obowiązującymi trendami do ograniczania procesów opartych o papier (nie tylko ze względu na ekologię, ale także koszty obsługi takiego procesu) oraz zmniejszania pracochłonności wykonania czynności, które są obowiązkowe.

A co myślą czytelnicy mojego bloga? Czy moja interpretacja jest słuszna?

Niespełnione oczekiwania jako początek zmian

Ostatnio poszedłem do biura podróży, z którego jakiś czas temu korzystałem, aby dowiedzieć się jakie oferty wycieczek wpasowałyby się w moje oczekiwania oraz warunki graniczne, które określę podczas wyboru. Po przedstawieniu oczekiwań, zapoznaniu się z przedstawionymi ofertami, wyszedłem z biura. I nie czułem się zadowolony. Sposób obsługi, pytania oraz sposób przedstawienia oferty nie był taki jak oczekiwałem. Przedstawicielka biura nie zachęciła mnie do skorzystania z ich oferty, a wręcz zniechęciła. Poszedłem więc do kolejnego biura z myślą, że będzie inaczej. I było. Zdecydowanie. Wyszedłem z biura z bardzo pozytywnymi odczuciami oraz nawet z typami ofert, z których byłbym chętny skorzystać. Dwie rozmowy i dwa jak różne efekty i odczucia. Proces obsługi (z perspektywy biura podróży), którego doświadczyłem, wraz z próbą identyfikacji różnic, przedstawiłem na poniższym diagramie używającym elementów notacji BPMN z dodatkowymi artefaktami i oznaczeniami (które wyjaśnię w dalszej części wpisu).

Proces oznaczony niebieskimi strzałkami to ten, który spełnił oczekiwania, a ten z czerwonymi strzałkami całkowicie odstawał od moich oczekiwań. Jak się okazuje do biura poszedłem z pewnymi oczekiwaniami – oznaczmy je jak M(oje)O(czekiwania) na potrzeby wpisu i powyższego diagramu. Sposób realizacji obsługi dla procesu czerwonego oznaczmy jako R(ealizacja)U(usługi)D(la)C(zerwonego) [odpowiedni obiekt na diagramie]. I odpowiednio dla niebieskiego – R(ealizacja)U(sługi)D(la)N(iebieskiego) [odpowiedni obiekt na diagramie]. Różnica między wartościami odpowiednio RUDC lub RUDN a wartością MO to jest tzw. luka 5 w modelu jakości usług (GAP 5 w ramach Service Quality Model). Jest to luka między otrzymaną a oczekiwaną usługą. W przypadku procesu niebieskiego ta luka, bazując na moich indywidualnych odczuciach, prawie nie występowała a w przypadku czerwonego była bardzo duża.

Wyobraźmy sobie, że właściciele sieci przeprowadzają/zlecają badanie jakości obsługi w swoich punktach sprzedaży lub takie badanie wykonuje niezależna instytucja. I, idąc dalej, to czerwone biuro podróży ma bardzo słabe wyniki w porównaniu do sieci niebieskiej. W takiej sytuacji, aby nie tracić klientów oraz udziału w rynku, właściciel decyduje się, tak załóżmy, na przeprowadzenie benchmarkingu procesów (pisałem o tym 9 lat temu na moim blogu), wzorując się na liderze rynku lub choćby na sieci niebieskiej, po względem budowy wartości dla klienta oraz realizacji procesu obsługi. Tym sposobem został zrealizowany pierwszy krok procesu benchmarkingu – identyfikacja obszaru/procesu.

W drugim kroku, jakim jest analiza, sieć czerwona może zebrać informacje o różnicach w sposobie funkcjonowania i realizacji działań na styku klienta i pracownika sieci, gdzie zauważona została luka oczekiwań i efektów realizacji. Mogę sobie wyobrazić, że wyznaczony pracownik sieci czerwonej lub zatrudniona do tego osoba udaje się do sieci niebieskiej, aby na własnej skórze poczuć jak wygląda proces, oraz znając instrukcje oraz wyniki badania, określić gdzie tkwią różnice w sposobie obsługi (na diagramie miejsca z różnicami są zaznaczone obszarami w kolorze szarym). W podanym przykładzie w dwóch miejscach różnica polega na wykonaniu określonego kroku lub nie, a w trzecim miejscu są wykonywane różne kroki. Taka osoba obserwująca proces, może właśnie zauważyć, co robi pracownik, aby przyciągnąć, zachęcić i utworzyć dłużej trwającą relację z klientem. Może też wskazać, że dany krok powoduje znaczną różnicę w budowaniu relacji lub wpływa silnie, bazując na swoim doświadczeniu, na poziom satysfakcji.

Po zebraniu obserwacji, można przejść do dalszych kroków procesu benchmarkingu. Dostosowując proces do obserwacji i doświadczeń można poprawić jakość obsługi klienta. Nie mówię tu o kopiowaniu rozwiązań, a bardziej o wyciąganiu wniosków z doświadczeń i próby spojrzenia na proces w inny sposób. To jak wygląda proces jest uzależnione od wewnętrznej polityki, dostępnych szkoleń i przyjętych założeń obsługi, doświadczeń z przeszłości. Może też być wynikiem istnienia lub próby zaadresowania pozostałych luk w jakości obsługi (czyli luk 1-4)). Wdrażanie na siłę rozwiązań niespójnych z resztą procesów i działań podejmowanych przez organizację, może bardziej zaszkodzić niż pomóc. Taka zmiana może następować stopniowo obserwując na przykład innych graczy na rynku, a nie tylko lidera rynkowego. Ta ciągła zmiana poprzedzona obserwacją konkurentów lub liderów rynkowych, analizie różnic i wdrażania odpowiednich zmian jest sednem procesu benchmarkingu.

W kontekście zmian widocznych dla klienta i zapewniania spójności z wewnętrznymi procesami organizacji, dobrze się zastanowić nad takimi elementami jak:

• komunikacja zmian i założeń,
• interesariusze procesu poza klientem,
• mierzenie efektów wprowadzanych zmian,
• ograniczenia budżetowe i dostępny czas,
• strategia i ewentualna potrzeba jej zmiany.

Czy RODO wpływa na BPR?

Dwanaście lat temu, dokładnie 9 lutego 2008, we wpisie na moim blogu, wymieniłem kroki składające się na proces reengineeringu (tj. reinżynierii procesów biznesowych, w skrócie BPR). W powiązanych wpisach opisałem, wykorzystując również dostępne publikacje w tym temacie, z czego składają się wybrane kroki tego działania. Natomiast część kroków pozostawiłem bez rozbudowanych wyjaśnień. Wspomniany proces reengineeringu ma na celu przebudowę/zmianę procesu, która odbywa się w oderwaniu od obecnego przebiegu procesu. Takie podejście ma na celu stworzenie procesu, który spełnia oczekiwania jego odbiorców, realizuje potrzeby podmiotu oraz adresuje w odpowiedni sposób kwestie, które dotychczas nie zostały wzięte pod uwagę. Przypomnijmy jakie kroki zawiera to działanie – przedstawione w postaci procesu na diagramie poniżej.

Podczas przygotowania odpowiedzi na pytanie postawione w tytule, trafiłem na ciekawy artykuł, który idealnie podsumowuje kroki, które należy wykonać, aby przejść przez proces dostosowania organizacji do RODO. W artykule jest informacja że „te wymagania dotyczące zgodności [mój dopisek: chodzi o RODO] mogą stymulować inicjatywy związane z przeprojektowaniem procesów biznesowych”, czyli wspomnianym reengineeringiem.
Autor artykułu wymienia 6 kroków, które powinny podjąć organizacje, podmioty czy przedsiębiorstwa w momencie, gdy dostosowują się do wymogów RODO (GDPR).

Autor artykułu zwraca uwagę zarówno na aspekt budowy świadomości, zmiany kultury, zarządzania, jak i na kwestie samego procesu dostosowania. Sam proces dostosowania jest rozbity, trochę to upraszczając, na identyfikację danych, identyfikację przepływów oraz na zmianę kluczowych polityk i procesów. Właśnie tym 3 krokom składającym się na proces dostosowania chciałbym się bliżej przyjrzeć w kontekście reengineeringu. Dlaczego? Ponieważ efekty identyfikacji danych i przepływów mogą wpłynąć na decyzję o tym, jaki proces wybierzemy do reengineeringu a potem na dalsze kroki realizowane w ramach tego działania. Przyjrzę się teraz bliżej tym 3 krokom wskazanym w artykule i spróbuję (mam nadzieję, że w poprawny sposób) je odnieść do kroków reengineeringu – podsumowanie takiego odniesienia (w poniższych wyjaśnieniach takie elementy są podkreślone) znajduje się również na diagramie:

• Identyfikacja danych/Zestawienie danych w przedsiębiorstwie (odpowiednik „Catalogue data across the enterprise z artykułu”) – sprowadzając to do kroków reengineeringu, możemy podczas wyboru procesu zdecydować się na ten, w którym przetwarza się najwięcej danych osobowych lub/i który został oceniony jako (najbardziej) problematyczny pod względem zgodności z RODO (co się wpasowuje moim zdaniem w punkt „dotyczący skali problemów powodowanych przez proces” wymieniony w książce, o której piszę w jednym z wcześniejszych wpisów). Podczas analizy procesu możemy zwrócić uwagę na to jakie rodzaje danych występują lub nawet mogą być nadmiarowe w określonych krokach lub czy same czynności przetwarzania nie są zbyt rozbudowane a może dane są za długo przechowywane. Warto też przyjrzeć się uczestnikom procesu i ich potrzebom w zakresie danych. Odnosząc się do regulacji RODO, można jeszcze postawić wiele innych pytań. Myślę jednak, że już te wskazane pytania dają podstawy do głębszej analizy procesu. Celem działania jest określenie potrzeb i oczekiwań odnośnie docelowego procesu.
• Identyfikacja przepływów/Zweryfikuj przepływy danych w ramach przedsiębiorstwa (odpowiednik „Audit data flow across the enterprise” z artykułu) – podczas analizy procesu możemy spojrzeć na proces z perspektywy danych, które przepływają między jednostkami przedsiębiorstwa. Wyobraźmy sobie, że proces jest oparty o system i uczestniczą w nim co najmniej 2 jednostki biznesowe. Wykonują one różne zadania, ale mają dostęp do tych samych danych. Wg RODO w danym momencie użytkownik powinien mieć dostęp do danych, które są mu rzeczywiście potrzebne. W zależności od sytuacji, trzeba pogłębić temat lub odnotować ten fakt w wynikach analizy/rekomendacjach. Angażując różne jednostki kontrolne, regulacyjne, wspierając się specjalistami ochrony danych (na przykład włączając ich do zespołu), przedsiębiorstwo może wybrać określoną strategię postępowania w samym procesie i określić jakie dodatkowe działania należy podjąć, aby uniknąć problemów w przyszłości. Opiekun czy właściciel procesu może tutaj odegrać ważną rolę, ponieważ z założenia zna oczekiwania odnośnie procesu i jego dotychczasowy przebieg, a także związane z nim regulacje.
• Utwórz lub popraw kluczowe polityki i procesy (odpowiednik „Create or improve key policies and processes” z artykułu) – w ramach reengineeringu budujemy nowy proces. Jest to szansa aby spojrzeć na dane wykorzystywane w tym procesie z nowej perspektywy i zmienić sposób ich wykorzystywania. Podczas uwzględniania aspektu RODO może się okazać, że dla procesu trzeba dobudować lub podłączyć (istniejące lub nie) dodatkowe podprocesy lub procesy powiązane, które będą adresować specyficzne sytuacje. Może się także okazać, że w nowym procesie dane można ograniczyć do minimum i uprosić proces także z perspektywy jego odbiorcy. Budując nową wersję procesu konieczne jest także spojrzenie na obowiązujące regulacje oraz polityki postępowania związane z procesem. One także muszą zostać odpowiednio przebudowane, z zachowaniem zgodności z wprowadzonymi przez organizację procesami ochrony danych osobowych czy dedykowanymi politykami w tym zakresie.

Mam nadzieję, że udało mi się trochę przybliżyć ten wpływ RODO na BPR.  Sama odpowiedź na pytanie postawione w tytule jest jak najbardziej twierdząca. Tak jak wskazuje wspomniany artykuły może wręcz się przyczynić do rozpoczęcia takich działań lub nawet ich przyspieszenia.

—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Proces planowania sprintu

Na początku stycznia na LinkedIn jeden z jego użytkowników udostępnił wpis ze strony agileinstitute.pl o tytule „Czy cel sprintu w Scrumie jest opcjonalny?”. Autorem artykułu jest Aleksander Kóska i pod jego udostępnieniem rozwinęła się ciekawa dyskusja. W trakcie dyskusji wyraziłem swoje zdanie, że moim zdaniem dobrze jest, gdy ten cel sprintu jest zdefiniowany, bo wiemy wtedy do czego zespół dąży i łatwiej podejmować decyzje, gdy pojawią się wątpliwości. O tym więcej za chwilę… Swoją drogą warto zapoznać się ze wskazanym artykułem oraz z powiązanymi treściami.

Po zapoznaniu się z tą dyskusją, zacząłem się zastanawiać jak w „rzeczywistości” wygląda proces planowania sprintu oraz jak on jest powiązany z określonym celem sprintu. Specjalnie jedno ze słów w powyższym zdaniu umieściłem w cudzysłowie, ponieważ będzie to pewne spojrzenie na ten proces. A proces ten, czego mam świadomość, może wyglądać różnie w zależności od specyfiki produktu, składu zespołu, jego dojrzałości agile’owej, a także zebranego doświadczenia w trakcie dotychczas zakończonych sprintów. Zaznaczam, że jest to spojrzenie z perspektywy product ownera. Gdyby zapytać różne zespoły lub product ownerów, pewnie można byłoby zidentyfikować różnice, ale myślę, że pewne ramy pozostałyby wspólne.

Zacznę od próby zobrazowania tego procesu na diagramie. Następnie spróbuję go przybliżyć. Do zobrazowania procesu użyłem notacji BPMN (pokolorowanej w specjalny sposób), której staram się używać, gdy próbuję graficznie przedstawić diagramy i koncepcje omawiane we wpisach na tym blogu.

Na diagramie zostały umieszczone następujące kroki:
1) Określ cel sprintu
Choćby wstępnie, product owner powinien określić czy w kolejnym sprint zespół ma się skupić na dalszym rozwoju funkcjonalności, dodaniu nowej funkcjonalności, likwidacji długu technologicznego, poprawie błędów, dokończeniu zadań z bieżącego sprintu lub zmianie funkcjonalności po zebranych uwagach np. z pilotażu. Możliwości jest wiele, zależy to od produktu, etapu jego rozwoju oraz ustalonego wcześniej planu działań. Product owner określając cel sprintu kieruje się wizją produktu, do której dąży. Przygotowanie sprintu oraz sama ceremonia planowania odbywa się w odpowiednim momencie czasu (dlatego zastosowałem na starcie procesu zdarzenie start event – timer).
2) Wybierz elementy z backlog
Product owner może wybrać wstępną listę elementów, którymi powinien się zespół zająć w następnym sprint. Elementy wynikają z przyjętego celu sprintu oraz priorytetów w ramach backlogu (wejście do kroku procesu oznaczone za pomocą asocjacji na diagramie). Zadania powinny być już wycenione na refinement (polecam wpis na blogu agile247.pl na temat tej ceremonii). Podczas ich wyboru uwzględnia prędkość (ang. velocity – odsyłam do szczegółowej informacji na scrum.org) oraz możliwości (ang. capacity – odsyłam do szczegółowej informacji na scrum,org) zespołu (kolejne wejścia do tego kroku, które oznaczyłem na diagramie – są to elementy wykorzystywane podczas realizacji kroku). Efektem jest wstępna wersja sprint backlog (wyjście z kroku procesu).
3) Omów elementy z zespołem
Na ceremonii planowania, wstępny sprint backlog omawiany jest z zespołem, wyjaśniane są wątpliwości (jeśli się pojawią). Często pojawia się dyskusja o tym, czy zadania są możliwe do wykonania, czy jednak nie powinny być wykonane inne zadania – bazując na doświadczeniach wcześniejszych sprintów i tym, co się wydarzyło od momentu wyceny i omówienia danego zadania podczas refinement). Product owner powinien także omówić jak dane zadanie, które wybrał w poprzednim kroku, przyczynia się do realizacji celu sprintu, który także powinien przedstawić. Zespół z kolei patrząc na proponowany cel sprintu może zaproponować inne zadania, które jego zdaniem przyczynią się do realizacji celu.
4) Zaktualizuj elementy
Jeżeli to jest konieczne elementy sprint backlog są aktualizowane i wyceniane ponownie. Podczas tego kroku mogą się pojawić dodatkowe zadania, nowe lub wzięte z backlog lub mogą zostać jakieś zadania „zrzucone” do backlog. W tym kroku może także nastąpić wstępne przypisanie opiekunów elementów (wyjście z kroku) – na przykład zespół może określić, którymi zadaniami zajmie się w pierwszej kolejności i kto z zespołu podejmuje jakie kroki. Poszczególni członkowie zespołu sami wskazują, które zadania zamierzają zrealizować. Efektem jest zaktualizowany sprint backlog.
5) Potwierdź kompletność elementów
Krok, którego celem jest ostateczne potwierdzenie czy cały zespół wie i rozumie co jest do zrobienia, do czego dąży zespół (wskazane poprzez cel sprintu), jaki jest wstępny plan na realizację zadań oraz tego, że wszystkie konieczne zmiany w sprint backlog zostały wykonane.
6) Uruchom sprint
W tym momencie powstaje pewien rodzaj umowy między zespołem a product ownerem. Pozwala ona zespołowi skupić się na wykonywaniu zaplanowanych prac. Formalne uruchomienie sprintu następuje przeważnie w narzędziu wspierającym pracę zespołu, monitorowanie postępów, dokumentowanie działań. Takie narzędzie może także wspierać liczenie prędkości zespołu.

Powyższy proces jest ważnym elementem pracy w zespole agile’owym. Planowanie to ceremonia, która decyduje w dużym stopniu o tym jak dużymi krokami rozwija się produkt. Jeżeli capacity zespołu lub jego prędkość spada, zespół w porozumieniu z product ownerem podejmie na kolejny sprint mniejsze zobowiązanie. Efektem może być późniejsze dostarczenie oczekiwanej funkcjonalności dla klienta. Może także wystąpić sytuacja, gdy konieczne będzie ograniczenie wymagań odnośnie produktu.

Jak widać cel sprintu przewija się na każdym kroku tego procesu planowania. Pomaga decydować o tym, co powinno zostać podjęte w danej iteracji a co porzucone. Bez niego będzie o wiele trudniej. Planowanie jako czynność biznesowa, zgodnie z jej definicją, zakłada silną korelację między celem oraz sposobem dojścia do niego.

W definicji zawartej w business dictionary mamy zapis: „Podstawowa funkcja zarządzania obejmująca jeden lub wiele planów do osiągnięcia optymalnego połączenia potrzeb [czyli wymagań zapisanych w backlog i planie rozwoju produktu] z dostępnymi zasobami [capacity zespołu, jego umiejętności]. Proces planowania obejmuje: (1) identyfikację celów do osiągnięcia; (2) definiuje strategię do ich osiągnięcia; (3) tworzy lub organizuje niezbędne środki [omawiane podczas planowania] (4) wdraża, prowadzi i monitoruje kroki z zachowaniem odpowiedniej sekwencji [codzienne daily pozwala na weryfikację postępu prac, identyfikację problemów]”. W nawiasach kwadratowych umieściłem komentarze odwołujące się do treści poruszonych powyżej podczas opisu procesu planowania w agile.

Myślę, że zdefiniowanie celu dla sprintu tworzy całość z ceremonią oraz jest spójne z rozumieniem procesu planowania.

—

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.