Sieć wyzwań dla procesu

Brak właściciela, przeładowany krokami nie wnoszącymi wartości dodanej, bez metryk, niespełniający oczekiwań odbiorcy … to tylko cztery wyzwania, które stoją przed procesami biznesowymi, spośród 11 wymienionych w artykule, na który ostatnio trafiłem – chodzi o artykuł „The 11 most common business process challenges and how to defeat them”, który polecam (skłania do refleksji). Wymieniłem te 4 wybrane, ponieważ o tych między innymi wielokrotnie pisałem na swoim blogu w różnym ujęciu:

• o właścicielu procesu i jego roli,
• o krokach istotnych dla procesu, jak i tych, które nie wnoszą wartości dla procesu (dla poszczególnych kroków można określić dla kogo są te kroki), czy można je pominąć czy może wartość, którą w noszą jest zauważalna,
• o metrykach, efektywności czy sprawności procesu,
• o niespełnionych oczekiwaniach.

Wszystkie wymienione (wyzwania, stąd (CXX) od ang. Challenge, oznaczenia wykorzystane na diagramie) we wskazanym artykule to (pozwalam sobie je przytoczyć w formie listy bo nie ja je wymyśliłem i zebrałem, zachowując oryginalne nazwy – w sprawie szczegółów odsyłam do wskazanego powyżej artykułu, gdzie każdy podpunkt jest dokładnie opisany; tłumaczenia dodane pomocniczo w nawiasach): „

• (C1) Business process not defined (proces nie jest zdefiniowany),
• (C2) Business process not owned (proces biznesowy bez właściciela),
• (C3) Purpose not understood (cel procesu nie jest zrozumiany),
• (C4) Business process not followed (nikt nie podąża za procesem),
• (C5) Customer not understood (Odbiorca/Klient nie jest poznany/nie zostały poznane jego potrzeby),
• (C6) Supplier not understood (Dostawca nie jest poznany/uczestnicy nie rozumieją jego potrzeb/nie znają go),
• (C7) Cumbersome to execute (Proces jest uciążliwy do wykonywania),
• (C8) Loaded with non-value added work (Przeładowany pracą, która nie wnosi wartości dodanej),
• (C9) Performance not measured (Proces nie jest pomierzony pod kątem wydajności),
• (C10)  Not linked to strategy (Nie połączony ze strategią),
• (C11) Don’t understand what business they are really in (Brak zrozumienia dla biznesu, w którym funkcjonuje)”.

Po zapoznaniu się z artykułem, zacząłem się zastanawiać czy nie można stworzyć między nimi diagramu powiązań, wykorzystując do tego myślenie systemowe. Moim zdaniem pewne elementy pociągają za sobą inne:

• Ciężko na przykład mówić o zmierzeniu procesu (C9), jeżeli nie wiemy gdzie są granice procesu, jakie kroki się na niego składają (C1).
• Z racji, że to właściciel powinien pilnować tego jak funkcjonuje proces, czy jest zrozumiały i jakie są zależności między dostawcą, procesem a jego odbiorcą – czyli podejście SIPOC. Gdy jego zabraknie (C2) to proces dzieje się w „swojej” formie (C7) lub nie jest wykorzystywany wcale (C4). Elementy te zostały zaznaczone na czerwono (gdy nikt nie dba o proces, nie mierzy go, nie weryfikuje, nie dostosowuje do branży, to pojawiają się kolejne problemy).

Na diagramie wskazałem więcej takich powiązań. Skutkiem „kumulacji” różnych braków (wyzwań) jest to, że proces może być uciążliwy (C7) dla uczestników lub szukają oni obejść, nie chcą stosować się do przyjętych reguł lub przestają podążać wg procesu (C4) – zaznaczone na szaro na diagramie.

Zaprezentowane zależności to przykład mający na celu zobrazowanie idei, o której myślałem i bardzo subiektywne spojrzenie z mojej strony. Zachęcam moich czytelników do komentarzy i sugestii.  

Myślenie systemowe, o którym wspominam powyżej, pozwala na zaprezentowanie wpływu pewnych elementów na siebie, oznaczając zarówno kierunek, jak i rodzaj wpływu (pozytywny/negatywny). W powyższym przykładzie mamy oznaczenie konsekwencji jednego wyzwania (choć w momencie gdy wystąpi można je nazwać zaniedbaniem/luką) na inne. Połączone potęgują wrażenie chaosu oraz powodują narastanie kosztów czy długu technologicznego.

Reklama

Czas akcji

Posiadana przeze mnie domena z kończącą się ważnością i powiadomienia od operatora domeny zainspirowały mnie do dzisiejszego wpisu. Nie było w tym nic dziwnego, ale  otrzymałem kilka różnych wiadomości dotyczących mojej domeny w temacie jej przedłużenia, które skłoniły mnie do przemyśleń. Zacząłem się im przyglądać kiedy przyszły i jakie akcje mogłem wykonać na danym etapie obowiązywania domeny. W całym okresie poprzedzającym zakończenie ważności domeny mogłem wykonać takie akcje jak: czekać, opłacić domenę z wyprzedzeniem, zrezygnować z domeny, poprawić dane, anulować zamówienie itd. Poniższy diagram prezentuje te możliwości w odpowiednich odcinkach czasu (trochę uogólniony).

Dodatkowo na diagramie dodałem informację o tym kiedy podjąłem zdecydowaną akcję – na niebiesko – zrezygnowałem z przedłużenia domeny. I z perspektywy oceniam, że komunikaty zaznaczone na czerwono są zbędne (o nadmiarowych statusach pisałem również w innym wpisie). Wskazałem w systemie, że nie chce przedłużać domeny (musiałem to potwierdzić). Cennym komunikatem – na zielono – był ten potwierdzający skuteczność rezygnacji z domeny (bo zaznaczenie braku chęci do jedno, a sam fakt wyłączenia domeny to drugie). Co ciekawe otrzymałem jeden komunikat, mówiący o upłynięciu terminu płatności za domenę po terminie jej ważności – moim zdaniem ten komunikat może spowodować pewien niepokój u Klienta, że jednak nie wszystko odbyło się zgodnie z oczekiwaniami i będą konieczne jakieś wyjaśnienia lub jednak opłacenie faktury.

Myślę, że taki proces w przybliżeniu, ma miejsce w przypadku różnych subskrypcji, usług z określoną ważnością, automatycznie lub „ręcznie” przedłużanych, płatnych jednorazowo z dany okres lub automatycznie opłacanych w odstępach czasu (te odstępy są istotne przy zgłoszeniu ewentualnej rezygnacji). Niektóre podmioty wysyłają wiadomość raz z listą możliwych akcji do wykonania, a potem z potwierdzeniem wybranej akcji. Inni komunikują każdy etap a inni z kolei pozostawiają pełną kontrolę klientowi usługi (zgodnie z zapisami regulaminów) i jedynie potwierdzają (lub nie) wykonanie określonej akcji (bo w sumie wszystko widać w systemie, który udostępnia operator, choć z tym bywa różnie – nie mam dostępu do podglądu pewnych ustawień w jednym z takich systemów, gdy nastąpiła jego migracja na inne/nowsze rozwiązanie).

Okresy między akcjami do wykonania, powiadomienia są specyficznym elementem danego systemu. Podmiot projektujący system, a dokładnie powiadomienia z procesu, ustawia co i w którym momencie wysyła. Patrząc na diagram BPMN może to być zdarzenie czasowe, np. przypadające na 1 dzień miesiąca lub określoną godzinę dnia (tak jest w przykładzie powyżej), dzień tygodnia, informujące wszystkich odbiorców, którym się kończy wykupiona usługa w następnym miesiącu lub za określony czas (np. X dni). Taki przykładowy proces został zaprezentowany na powyższym diagramie. W tym przypadku składa się z określenia listy usług, komunikatów do wysłania i ich wysyłki (komunikaty A-F).

Proces wyborczy

Tydzień temu odbyły się w Polsce wybory Prezydenta RP. Głosy zdobyte przez kandydatów rozłożyły się i żaden kandydat nie zdobył ich liczby wymaganej do wygrania w pierwszej turze (czyli powyżej 50% głosów). Za tydzień będzie więc druga tura… Od kilku tygodni, temat nie schodził z pierwszych stron serwisów, z czołówek wiadomości. Jedni informowali o tym gdzie tym razem się pojawił dany kandydat, co powiedział, co się wydarzyło w trakcie spotkania, a inni przypominali o wcześniejszym zachowaniu, decyzjach. Jedni przekonują na spotkaniach bezpośrednich, a inny wykorzystując sieć Internet. Jedni tworzą nowe hasła wyborcze, a drudzy opierają się na dotychczasowych zdaniach. Jedni zastanawiali się na kogo zagłosować, inni wiedzieli od samego początku. Teraz z kolei pojawiają się sondaże, które raz dają wygraną jednemu kandydatowi, a innym razem temu drugiemu. Kandydaci musieli jednak zacząć od zgłoszenia swojej kandydatury oraz przedstawienia odpowiedniej liczby głosów popierających. A jeszcze wcześniej musiał zostać ogłoszony termin wyborów, aby cały proces mógł ruszyć.

Proces wyborczy o zgłoszenia komitetu/kandydata, poprzez prowadzenie kampanii aż po przeprowadzenie samych wyborów, definiuje tzw. Kodeks wyborczy. Szczegółowe wytyczne są opisane w dokumencie „Kodeks wyborczy”, dokładnie ustawie, opublikowanej na stronach rządowych dotyczących wyborów. Jest to dokument, który określa zasady dla poszczególnych wyborów. Na potrzeby tego wpisu skupiałem się na dziale V, a efekt tego spróbowałem zobrazować na poniższym diagramie.

Kilka komentarzy do tego procesu:

• W sam proces wyboru Prezydenta (wg rozdziału 1 w dziale V) są zaangażowane minimum 3 podmioty – Marszałek Sejmu, Kandydat na Prezydenta oraz Państwowa Komisja Wyborcza – co oznaczyłem elementami znanymi z UML, łącząc te obiekty z odpowiednimi krokami procesu, przez połączenia typu asocjacja.
• Działania w tym procesie wykonywane są w określonym rygorze czasowym w zakresie momentu ogłoszenia oraz przeprowadzenia poszczególnych etapów – co zaznaczyłem przez zdarzenia wskazujące na momenty czasu (ang. timer event) wykorzystywane w diagramach BPMN.
• W procesie jest krok „Zgłoś kandydaturę” oznaczony jako podproces, ze względu na to, że jest to rozbudowane działanie (opisane w rozdziale 2 działu V), realizowane także w ustalonym rygorze czasowym. Kroki tego procesu zostały zasygnalizowane w ramce „Zgłoś kandydaturę”, wraz z połączeniem ich do wskazanych wcześniej uczestników procesu.
• W procesie kluczowym elementem jest krok „Zlicz głosy” , występujący 2 razy, przy czym pierwszy z nich występuje zawsze, a drugi opcjonalnie, w zależności od wyników 1 tury głosowania, co zostało oznaczone za pomocą bramki opartej o dane (ang. Exclusive data-based gataway)

Podróżne dylematy

Przed długim weekendem czerwcowym wiele rodzin/osób zastanawiało się jak spędzić ten czas. Czy spędzić go w domu czy wyjechać? Spędzić go w jednym miejscu czy w kilku? Przedłużyć weekend czy skorzystać tylko z 4 dni? Odwiedzić rodzinę? Kogo i kiedy? Gdzie nocować? Którędy jechać? Co zabrać? Wziąć urlop czy nie? Co załatwić? Co zrobić? Z czego zrezygnować? Gdzie będą korki na drodze? Gdzie są utrudnienia w ruchu? Jaki jest koszt przejazdu? I wiele innych pytań.

Jednym z elementów jest kwestia przemieszczania się, czyli jakie miejscowości oraz w jakiej kolejności odwiedzić. Załóżmy, że mamy do odwiedzenia kilka miejsc (lokalizację, z której startujemy oraz 4 inne lokalizacje, tak jak na poniższym diagramie) i chcemy każde z nich odwiedzić tylko raz i wrócić do domu. Przejazd między miastami jest związany z kosztem przejazdu, odległością oraz czasem potrzebnym na przejazd (przykładowe elementy zostały wskazane na dostępnych połączeniach na diagramie).

Jest to związane z tzw. problemem komiwojażera (ang. travelling salesman problem). Chodzi o wybór najszybszej, najkrótszej lub najtańszej ścieżki (w zależności od zastosowanych wag na przejściach) przejścia po takim diagramie (dokładnie grafie), w ramach której wyruszamy z danego punktu początkowego, odwiedzamy wszystkie lokalizacje i wracamy do punktu początkowego, odwiedzając każdą lokalizację (poza początkową) tylko raz.

Myślę, że z takim problemem spotkało się wiele osób mających w planach odwiedzenie kilku lokalizacji (nie wnikam z jakiego powodu) – nie istotne czy są to punkty na obszarze danego kraju, kilku krajów, kontynentów czy danego regionu lub miasta. Można wykorzystać różne środki komunikacji lub skorzystać z własnego. Można poruszać się też pieszo. Mogą wystąpić roboty drogowe, objazdy, zwiększone natężenie ruchu czy może konieczne jest wykorzystanie przeprawy promowej. Elementy te wpływają na koszty i czas przejazdu. Z kolei ukształtowanie terenu może spowodować, że trasa blisko położonych lokalizacji w linii prostej, może się znacznie wydłużyć. Niektórzy oferują także przewóz dodatkowych osób, zmniejszając koszt przejazdu po swojej stronie. Atrybuty na połączeniach powinny uwzględniać wszystkie te elementy w zakresie czasu, kosztu przejazdu czy też fizycznej odległości.

Na diagramie wskazałem przykładowe odległości, ceny i czas przejazdu między 5 lokalizacjami, zakładając, że jedna z nich jest traktowana jako startowa. Atrybuty te na pierwszy rzut oka mogą się wydawać nielogiczne, ale starałem się uwzględnić, nie wskazując tego wprost, niektóre z powyższych elementów. Bez problemu można znaleźć na nim ścieżkę, która odwiedza wszystkie wierzchołki (lokalizacje) i wraca do początkowego punktu. Przykładem jest ścieżka START->4->2->1->3->START lub START->1->2->3->4->START. Oznacza to, że powyższe połączenia między lokalizacjami tworzą tzw. cykl Hamiltona. Znalezienie takiej ścieżki o najmniejszej wartości atrybutu branego pod uwagę jest rozwiązaniem problemu komiwojażera.

Dla podanego grafu (połączenia między lokalizacjami go tworzą) mamy takie cykle (wydaje mi się, że to wszystkie i że się nie pomyliłem podczas zliczania):

Przykładowy cykl	Odległość (km)	Koszt (zł)	Czas (h)	Śr.  prędkość km/h	Liczba  km/zł
START>4>2>1>3>START i odwrotnie	470	41	6	78,33	11,46
START>1>2>3>4>START  i odwrotnie	660	33	11	60,00	20,00
START>3>4>2>1>START  i odwrotnie	430	36	8	53,75	11,94
START>1>3>2>4>START  i odwrotnie	670	48	9,5	70,53	13,96

Wśród wskazanych powyżej cykli widać, że pierwszy ma najmniejszy czas przejazdu, drugi najniższą cenę a trzeci najkrótszą odległość. Osobiście wybrałbym pierwszą ścieżkę.

Przy większej liczbie lokalizacji i połączeń, proces wyszukiwania „najlepszego” rozwiązania komplikuje się obliczeniowo. Można jednak powiedzieć, że wyznaczenie optymalnej trasy jest częścią większego procesu składającego się z określenia lokalizacji do odwiedzenia, oszacowania kosztów, czasu oraz odległości wymaganych do pokonania, czyli atrybutów połączeń, zaplanowania sposobu postępowania (wybór całej ścieżki lub pierwszych kroków, a potem dostosowywanie), realizacji planu, a na koniec oceny planu (np. wybrana droga nie nadaje się do użytkowania) i dostosowanie na przyszłość. Na diagramie został wskazany taki proces – kolorem zostały zaznaczone kroki odnoszące się do diagramu połączeń.

Atrybuty na powyższym diagramie można zmieniać podczas następnego podejścia lub na przykład likwidować określone krawędzie/połączenia jako nieakceptowalne z perspektywy kolejnej realizacji takiej „podróży”. Można także dodawać i odejmować lokalizacje i połączenia. Istotne jest to, że przy każdej takiej zmianie może nastąpić zmiana optymalnego rozwiązania, a także może zmienić się liczba cykli.

Weryfikacja i potwierdzenie

1 czerwca 2020, to nie tylko Dzień dziecka, który z jednej strony powoduje radość u wielu dzieci, ponieważ dostały prezenty lub mają zaplanowane inne aktywności niż zwykle, a z drugiej strony „wymusza” na rodzicach/opiekunach inną organizację pracy w tym dniu. To także początek tygodnia, miesiąca oraz okresu, w którym pracownicy różnych firm biorą swoje pierwsze wakacyjne urlopy. To także dzień będący początkiem sprintu dla wielu zespołów, zarówno tych sprintów trwających miesiąc, jak i dwa tygodnie. Osoby, które planują pracę w tych zespołach, biorą pod uwagę różne elementy, wpływających na capacity zespołu (czyli tzw. dostępność zespołu lub pojemność zespołu).

Podczas planowania sprint, capacity zespołu, co wskazałem jako element wejściowy do kroku „Wybierz elementy z backlog” na diagramie w poprzednim wpisie (oraz poniżej), determinuje to ile pracy można zaplanować na najbliższy sprint. Osoba przygotowująca planowanie, czyli przeważnie product owner, podczas weryfikacji capacity zepsołu, bierze pod uwagę takie elementy jak (są to przykłady, mogące wystąpić w różnych zestawach):

• planowane nieobecności (urlopy, szkolenia, konferencje itp.),
• nieplanowane wcześniej nieobecności (choroby/zwolnienia, opieka nad dzieckiem),
• długie weekendy/dni wolne od pracy,
• wydarzenia firmowe, wymagające obecności członków zespołu,
• odejścia pracowników na koniec poprzedniego miesiąca lub zaplanowane na najbliższy sprint (czas potrzebny na przejęcie wiedzy a nie na prace związane z rozwojem produktu),
• informacje z retrospektywy sprint,
• uzgodnienia wewnątrz organizacji dotyczące na przykład ograniczonego udziału niektórych członków zespołu w pracach danego zespołu,

Uwzględniając to, że tych elementów wpływających na capacity zespołu jest wiele a sama czynność weryfikacji ma ogromne znaczenie dla możliwości wytwórczych zespołu, postanowiłem wydzielić na diagramie procesu planowania sprint, który przygotowałem w ramach wcześniejszego wpisu (uwzględniając kroki 1*,2*,3* z wpisu o zdalnych ceremoniach), dwa dodatkowe kroki (oznaczone czarnym tłem) . Na diagramie oznaczyłem, że te dwa zadania są „pochodną” danych wejściowych do wskazanego powyżej kroku procesu („Wybierz elementy backlog„).

Pierwszy: Zweryfikuj capacity
Krok ten ma miejsce przed samą ceremonią, w ramach przygotowania. Jest wykonywany na bazie dostępnych na dany moment informacji o capacity zespołu. Atualność powinna zostać zweryfikowana wspólnie z zespołem deweloperskim podczas samego planowania. Product owner bierze pod uwagę wskazane powyżej elementy i dostosowuje swoją propozycję prac na najbliższy sprint.

Patrząc dodatkowo na dotychczasową prędkość zespołu, napotkane problemy, zakończone i niezakończone zadania, może zadecydować o przesunięciach zadań między planowanymi sprintami, rezygnacji z pewnych zadań lub przygotowaniu innego podejścia do określonych zadań. Może także wytypować zadania, które wymagają ponownego refinementu. Jest to propozycja kolejności – można ustawić kroki wskazane na diagramie w ramach przygotowania ceremonii w innej kolejności. Propozycja przygotowania przed ceremonią jest efektem różnych zasygnalizowanych działań, pamiętając o tym, że ostateczny zakres sprint backlog zostanie ustalony dopiero podczas właściwej ceremonii.

Drugi: Potwierdź capacity
Podczas samej ceremonii następuje potwierdzenie planowanych nieobecności, przyjętych założeń oraz ewentualna aktualizacja o informacje przekazane w ramach zespołu. Zespół wymienia się wewnętrznie informacjami o nieobecnościach i określa swoją dostępność. Działanie to zaproponowałem na diagramie po przedstawieniu propozycji planu sprint. Uzasadniam to tym, że zespół może lepiej osadzić to, co wie o dostępności członków zespołu i na przykład odnieść się do określonych zadań, że ich nie ruszymy bez udziału określonej osoby lub bez rozwiązania problemu, którym ta osoba się zajmowała.

Teoretycznie takie informacje powinny zostać przekazane na koniec poprzedniego sprint – jednak w momencie planowania może to okazać się bardziej lub mniej kluczowe, bazując na wizji zespołu odnośnie realizacji proponowanych zadań. Jest to propozycja – kolejność można zamienić. Istotne jednak jest następny krok, w którym bazując na tych ustaleniach, następuje aktualizacja elementów a następnie potwierdzenie ich kompletności.

Dla kogo ten krok?

„W drodze”, „Zdezynfekowana”, „Czekam w punkcie” oraz „Odebrana” – takie cztery wiadomości (uogólnione na potrzeby wpisu) otrzymałem ostatnio od podmiotu pośredniczącego w dostawie produktu zamówionego w sklepie internetowym. Pierwszy komunikat pojawił się, gdy podmiot odebrał paczkę, drugi pojawił się, gdy paczka trafiła do sortowni (można to było sprawdzić śledząc paczkę), kolejny, gdy dotarła do wybranego punktu odbioru a ostatni oznaczał, że została odebrana. Dotychczas korzystałem kilkakrotnie z tego pośrednika i dopiero w okresie pandemii, pojawił się ten dodatkowy krok, związany z dezynfekcją (dokładnie ozonowaniem) przesyłki. Jest to krok, który wprowadziło wiele podmiotów. Jeden z nich (znalazłem taką informację w sieci Internet) uzasadnia tę zmianę, tym, że daje ona „możliwość zagwarantowania nadawcom i odbiorcom”, tego podmiotu, „maksymalnego poziomu bezpieczeństwa obsługiwanych przesyłek”.

Gdy czytałem takie informacje dotyczące różnych podmiotów zacząłem się zastanawiać w jaki sposób można scharakteryzować taki krok (ozonowanie/dezynfekcja przesyłki) w procesie dystrybucji paczki. Podnosi, zgodnie z powyższym cytatem, przede wszystkim bezpieczeństwo obsługi paczki – czym zainteresowany jest:

• odbiorca (klient) przesyłki, ponieważ może ją odebrać bez ryzyka kontaktu z wirusami (związanych z pandemią),
• osoby uczestniczące w procesie (pracownicy/personel), mogą spokojnie zająć się przesyłką na różnych etapach procesu, przekazać ją dalej,
• właściciel i interesariusze firmy (akcjonariusze) – jeżeli pracownicy są bezpieczni, nie generuje to potencjalnego kosztu przestoju, szukania dodatkowych osób, generowania opóźnień w dystrybucji czy też akcji dodatkowej dezynfekcji większych powierzchni; jest to także pewnie wynik optymalizacji kosztowej – gdzie pewnie ryzyko związane z obsługą zainfekowanej przesyłki i szacowany koszt likwidacji skutków był porównany z kosztem wprowadzenia takiego kroku i jego stosowania w procesie.

Element ten to także budowa wizerunku i jasny komunikat dla społeczeństwa, że realizujemy dodatkowe kroki, aby nasi Klienci oraz pracownicy czuli się bezpieczni. To także reagowanie na zmieniające się otoczenie, wymogi sytuacji oraz możliwość zapewnienia ciągłości działania.

Można powiedzieć, że taki dodatkowy krok w procesie tworzy „wartość„. W szczególności, że nie wiąże się z dodatkowymi kosztami, a potencjalne (teoretyczne) opóźnienie z tego tytułu wydaje się akceptowalne z perspektywy odbiorcy. Dla mnie osobiście tak.

Na diagramie graficznie oznaczyłem dla kogo wynika wartość z tytułu poszczególnych etapów procesu oraz pojawienia się tego nowego elementu w procesie. Zgodnie z wyjaśnieniem powyżej – krok jest „współdzielony” przez różne zainteresowane strony. Dodatkowo został dodany stan dot. przeprowadzenia komunikacji na „rynku” dla potencjalnych/zainteresowanych osób o wprowadzonej zmianie. Diagram przedstawiony został w postaci diagramu stanów (ang. state diagram), opierając się na stanach zakomunikowanych odbiorcy bezpośrednio – pominięte zostały stany wskazane w mechanizmie śledzenia przesyłki. Są to stany kluczowe  dla przebiegu procesu, określające jego ramy zarówno z perspektywy dostawcy przesyłki, odbierającego ją od sklepu internetowego (sprzedający), jak i dla końcowego Klienta (kupujący), ponieważ szybko może się zorientować, na jakim etapie jest jego przesyłka i czy może udać się do punktu odbioru.

Dobrze jest zwrócić uwagę na takie inforamcje dotyczące podmiotów, z których korzystamy w okresie pandemii, ze szczególnym uwzględnieniem tego, czy podmiot wykonuje to bezpłatnie oraz na jakich warunkach i przy jakich ograniczeniach. Pozwoli nam to uniknąć na przykład sytuacji, gdy zostaniemy naciągnięci przez oszustów wykorzystujących taką sytuacją na rynku.

Przesłanki postępu w sprint

Codziennie, o tej samej porze, na 15 minut, przed tablicą papierową, suchościeralną lub elektroniczną, w ustalonym miejscu lub za pomocą ustalonego środka komunikacji (gdy ceremonie odbywają się zdalnie,  lub zespół nie znajduje się w jednym miejscu), cały zespół scrumowy, bez wyjątków, opóźnień spotyka się tzw. daily (dokładnie daily scrum). Jest to spotkanie, które ma umożliwić wymianę zespołowi informacji o tym, czy przybliżamy się do celu sprintu, czy pojawiły się jakieś problemy, czy są zagrożenia. To także okazja do synchronizacji, podjęcia szybkich decyzji oraz ustalenia zasad pomocy czy współpracy. W czasie takiego spotkania każdy z obecnych uczestników powinien zabrać głos i zostać wysłuchanym. To moment oderwania od realizowanych prac i skupienia się w danym momencie na tym spotkaniu – w celu inspekcji prac i odpowiedniego dostosowania (adaptacji) działań. Spotkanie to odbywa się przez cały sprint od momentu jego rozpoczęcia na planowaniu sprint, aż do jego zakończenia. Samo spotkanie może być też jednym z tematów poruszanych na spotkaniu retrospektywy.

Miałem okazję uczestniczyć w spotkaniach daily, które były zróżnicowane pod względem sprawności przebiegu, liczby podejmowanych decyzji czy też zaangażowania członków zespołu. Obserwowałem także spotkania w innych zespołach, których nie byłem członkiem. Co ciekawe można podczas takiego spotkania usłyszeć różne sformułowania i wypowiedzi. Jedni się rozwodzili, inni przechodzili do sedna i w żołnierskich słowach mówili, to, co uważali za stosowne. Uczestniczyłem też w spotkaniu, w którym podczas daily, następowało przejście po blokach tematycznych, przy których każda z osób mogła się wypowiedzieć. W innych spotkaniach, każda z osób wypowiadała się po kolei, jedna po drugiej, czy to alfabetycznie czy też w ustalonej na bieżąco kolejności.

Załóżmy, że mamy 7 osobowy zespół i w ramach danego sprint, trzy wybrane spotkania daily, wyglądały jak na poniższym diagramie pod kątem użytych sformułowań i przekazanych informacji.

Można zauważyć, że część sformułowań (jak nie większość) odpowiada na pytania, które „określają” formułę daily – Scrum Guide proponuje następujące pytania:

• Co zrobiłem wczoraj, co pomogło Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone na diagramie zielonym tłem)
• Co zrobię dzisiaj, co pomoże Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone pomarańczowym tłem)
• Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu? (oznaczone tłem czerwonym)

Każda z osób formułując swoją wypowiedzieć zadecydowała o czym chce powiedzieć i co powinna powiedzieć – w zależności od wykonanej pracy, postępów, tego, co się wydarzyło poprzedniego dnia lub planu na kolejny dzień czy nawet dni. Można powiedzieć, że przeprowadza pewien proces decyzyjny – próba jego zobrazowania znajduje się na poniższym diagramie

Na diagramie dodałem dodatkowe wyjaśnienia, które z jednej strony uzasadniają umiejscowienie danego pytania w drzewku decyzyjnym (ang. decision tree) a z drugiej – tak myślę – wyjaśniają przyjęte założenia. Na diagramie analogicznymi kolorami zaznaczono elementy odpowiadające powyższym pytaniom ze Scrum Guida. Pierwszym pytaniem jest to o zakończenie swoich zadań, ponieważ najbardziej przybliża do realizacji celu sprintu. Kolejne pytania wskazują na postęp w realizacji przyjętych zobowiązań na sprint. Na końcu każdej ścieżki jest pytanie o urlop, które mógłbym pominąć, jednakże nieobecności, w szczególności te niezaplanowane, mogą znacznie wpłynąć na realizację zobowiązań – dlatego to zasygnalizowałem.

Analizując wskazane komentarze członków zespołu, można powiedzieć, że odpowiedzi na niektóre pytania można się domyślić . Może być tak, że zespół umówił się na to, że mówi – nie mam problemów lub nie widzę zagrożeń dla realizacji zadań, gdy to jest faktem. Z tego co zaobserwowałem bardziej jest to odpowiedź w domyśle przy założeniu, że jak jest problem, to osoba, która go znalazła, go poruszy. Zespół mógł się także dowiedzieć wcześniej o problemie lub efekcie dotychczasowych prac. Uczestniczyłem też w daily, gdzie padało na koniec pytanie – czy są jakieś problemy lub zagrożenia dla realizacji prac. Przeważnie członkowie zespołu skupiają się na dwóch aspektach – co zrobili i planują robić w kolejnym dniu.

Odpowiadając sobie samemu na te pytania, co w sumie obrazuje diagram, skupiamy się na tym, co jest istotne z perspektywy celu sprintu oraz pozwala się zespołowi zmieścić w ograniczonym czasie dla tego spotkania. W szczególności, gdy informujemy o zakończeniu zadań, które się podjęło, dajemy sygnał zespołowi, że jest przestrzeń na pomoc, dodatkowe zadania lub uzgodnione działania.

Na diagramie umieściłem 2 rozdzielone pytania: o problem i o zagrożenie. Mógłbym to połączyć w jedno pytanie lub zamienić kolejność. Przyjąłem założenie, że najpierw rozwiązujemy problem, który może mieć skutek w braku realizacji danego zadania lub powiązanych. Podobnie jest z zagrożeniem, ale jest to ocena wykonującego zadania, które może się zmienić w przeciągu najbliższego dnia lub po dopytaniu przez członków zespołu, może być ograniczona przez odpowiednią pomoc, dodatkowe wyjaśnienia lub może być istotnym problemem, którym należy się pilnie zająć.

Na diagramie zaprezentowałem tylko trzy dni (opierając się na przykładowych wypowiedziach, które są zebrane z różnych dni), a biorąc pod uwagę, że sprint trwa dwa tygodnie lub dłużej, tych możliwych komentarzy i ich wariantów może wystąpić znacznie więcej i mogą wskazywać na różnorodne podejście poszczególnych członków zespołu. Jednakże idea jest wpólna – są one wynikiem refleksji nad poprzednim dniem oraz tym, co planuje się zrobić kolejnego dnia.

Ocena zamówienia – moment i konstrukcja

Udało się! Dotarło bez części zamówionych produktów, ale wreszcie odebrałem zamówienie, o którym pisałem w poprzednim wpisie. Przyszło w całości, nieuszkodzone, bezpiecznie zapakowane. Choć spodziewałem go się trochę wcześniej. Patrząc na zrealizowany proces mogę dla niego wskazać następujące komentarze:

1. (+) sklep posiadał produkty, których szukałem,
2. (+) ceny produktów były akceptowalne,
3. (+) dostępne sposoby płatności i dostawy pozwoliły wybrać to, co mi pasuje,
4. (+) nie odwołali/nie wstrzymali zamówienia w przypadku problemów,
5. (+) produkty przyszły w całości,
6. (-) zamówienie przyszło z opóźnieniem,
7. (-) informacje o dostępności produktów nie są do końca prawdziwe, przez co nie dostałem kompletu zamówienia.

Podsumowując:  jestem zadowolony z realizacji tego zamówienia – biorąc pod uwagę liczbę (+) i (-). Co ciekawe sklep ma specyficzny sposób zachęcania do wypełnienia ankiety o zrealizowanym zamówieniu. Pierwszy raz dostałem prośbę, jeszcze przed wysyłką zamówienia – zachęcała do tego wiadomość: „Wystaw opinię o naszym sklepie w zamian za…..” – sprawdziłem, że przyszła po statusie „gotowy do wysłania”. Dzień po odebraniu przesyłki przyszła kolejna wiadomość: „Twoja opinia jest dla nas ważna”, która także odwoływała się w treści do możliwości nagrodzenia za wydanie opinii.

Na poniższym diagramie stanów w UML (ang. state diagram) umiejscowiłem tę prośbę o ocenę (stan „Brak oceny”) w całym procesie zamówienia, patrząc z perspektywy statusów, które otrzymałem w postaci wiadomości e-mail lub określiłem sobie samodzielnie (oznaczone na szaro).

Po otrzymaniu pierwszej wiadomości, zadałem pytanie: co tak szybko? Przecież zamówienie nawet do mnie nie zostało wysłane. Po drugiej wiadomości, zacząłem zastanawiać się czy chcę wypełniać tę ankietę i w jaki sposób ten fakt wpłynie na moją ocenę, uwzględniając również to, co opisałem w poprzednim wpisie. Ostatecznie uruchomiłem proces oceny, chcąc sprawdzić, czy będzie okazja do wypowiedzenia się w tej kwestii. Wyglądało to następująco:

• Pytania dotyczyły zakupionego produktu – czyli pytania dotyczące komentarzy (1) i (5) powyżej.
• Pytania dotyczyły procesu w samym sklepie – dla (2), (3) i (7) powyżej.
• Pytania dotyczyły czasu dostawy – dla (4), (6) i (7),
• Prośba o dodatkowe komentarze – tutaj mógłbym wskazać te elementy, o które nie było pytania bezpośrednio. Mógłbym pochwalić za pewną elastyczność związaną z brakiem produktów równocześnie wskazując, że można byłoby to poprawić. Mógłbym wskazać zastrzeżenia co do ankiety itd.

Zabrakło mi w czasie czy nawet przed wypełnieniem ankiety informacji, czy ankieta jest anonimowa, czy zostanie opublikowana na stronie czy tylko przesłana. Dopiero na ostatnim kroku, jest informacja o akceptacji regulaminu, który odpowiada na te pytania. Wydaje się, że taką informację w skrócie można byłoby zawrzeć na 1 ekranie lub w innej formie.  Można też powiedzieć, że wystarczyłaby wysyłka ankiety w tym drugim kroku, na przykład 2 dni po nadaniu przesyłki, zakładając standardowy czas realizacji dostawy dla wybranej formy dostawy.  Plusem jest to, że ankieta jest prostsza od tej, którą kiedyś opisywałem. Ma też element niestandardowy jakim jest możliwość zamieszczenia zdjęcia lub dodatkowe informacji związanej z zamówionym produktem (np. zachęcają do pokazania jak go odbiorca wykorzystuje).

Umiejscowienie prośby o ocenę dla zamówień , które ostatnio składałem, było różne. Konstrukcja ankiety również.   Przeważnie przychodziły w momencie powiadomienia o wysłaniu zamówienia. W jednym przypadku przyszła informacja z pewnym opóźnieniem. Ten czas opóźnienia dla ankiety jest dość istotny – z jednej strony wpływa na to ile pamiętamy z realizowanego procesu, a z drugiej może wpłynąć na samą chęć wypełnienia ankiety. Zależy to od tego jak sprawnie przeszło zamówienie, jakie spowodowało reakcje, a także od podejścia odbiorcy – jedni nie wystawiają ocen wcale a inni to robią zawsze i wszędzie. Reszta z odbiorców jest gdzieś pośrodku i pewnie na pytanie o to, czy wystawią ocenę, odpowiedzą krótko „to zależy”.  Podobnie jest z konstrukcją ankiety – długa i szczegółowa może zniechęcić do jej wystawienia. Prosta i krótka może zachęcić do jej częstego wypełnienia.

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.

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).