Trzy miasta – trzy procesy zakupu biletu

Dawno nie pisałem na moim blogu dotyczącym modelowania procesów. Trzeba to zmienić, więc dzisiaj będzie wpis zainspirowany moim ostatnim wypadem do Warszawy, przy okazji odbywającej się tam konferencji dot. m.in. sztucznej inteligencji, mechanizmów LLM oraz powiązanych tematów.  Tematyką wpisu będzie sposób kupowania biletu na przejazd komunikacją miejską w aplikacji mobilnej oraz krótka zabawa mechanizmem generowania odpowiedzi (za pomocą AI) dostępnej w edytorze tekstów, która zapoczątkuje nową kategorię tekstów na moim blogu.

W Poznaniu często korzystam z komunikacji miejskiej i czasami kupuję bilet za pomocą aplikacji. Sprawa jest prosta, przechodzę do aplikacji, wybieram rodzaj biletu (z listy ulubionych), potwierdzam i go opłacam. W sumie tylko kilka kliknięć. Niezależnie od tego, czy jest tłok, czy jadę blisko, czy daleko, sposób zakupu wymaga skorzystania tylko ze swojego telefonu. Pomijam kwestię aktywnego dostępu do Internetu i środków na koncie.

W Warszawie, także postanowiłem skorzystać z takiej samej opcji, na początku wszystko wyglądało tak samo, a potem pojawiło się zaskoczenie. Bilet trzeba skasować, podchodząc do odpowiedniego miejsca a pojeździe (na przykład tramwaju) i zeskanować kod z kodem, tak zakładam, pojazdu. Czyli pojawił się jeszcze jeden krok. Zastanawiam się, co wtedy, gdy jest tłok w pojeździe. Trochę to przypomina próbę dostania się do kasownika.

Wtedy przypomniałem sobie, że w którymś z miast, które odwiedzałem ostatnio, także korzystałem z aplikacji mobilnej do zakupu biletu na przejazd. Było to dokładnie w Gdańsku. Tam proces wygląda jeszcze inaczej. Po wyborze biletu trzeba wpisać numer linii, którą się jedzie. Sprawa prosta, bo w sumie wsiadając do pojazdu, przeważnie wiemy w jakim pojeździe jesteśmy. Mogę sobie wyobrazić, że ktoś jedzie z przystanku, z którego jest kilka linii w jednym kierunku i wsiada się do pierwszego, który przyjedzie – można wtedy nie zwrócić uwagi.

Te 3 przykłady pokazują różne rozwiązania dla jednego procesu. Jadąc do innego miasta można się zdziwić albo z przyzwyczajenia nie wykonać czynności (skasowanie biletu w Warszawie). Z drugiej strony, w Warszawie można kupić bilet przed wejściem do pojazdu, a potem go skasować, gdy w Poznaniu czas przejazdu wskazany na bilecie „startuje” w momencie zakończenia transakcji (co może być uzależnione od różnych czynników niezależnych lub zależnych od kupującego). Takie rozwiązania są także umotywowane doświadczeniami organizatorów transportu miejskiego w danym mieście, wcześniejszych doświadczeń, problemów, czy też polityki oraz wariantów dostępności biletu. Z mojej perspektywy, gdy potrzebowałem najprostszy bilet, aby przemieścić się na trasie zajmującej 10 minut, były to pewne zauważalne różnice, które mnie zainteresowały.

Powyższy diagram prezentuje przebieg tych procesów od najprostszego do najbardziej skomplikowanego z mojej perspektywy.

Na koniec obiecana we wstępie ciekawostka, korzystając z narzędzi AI dostępnych w jednym z edytorów tekstów zadałem następujące pytania o różnice w powyższych procesach:

Pytanie 1: Why is it necessary to validate the ticket in Warsaw after buying it in mobile application? (tłum. „Dlaczego trzeba kasować bilet w Warszawie po zakupie w aplikacji mobilnej?”)

Otrzymana/Wygenerowana odpowiedź: „It is necessary to validate the ticket in Warsaw after buying it in mobile application to ensure that the ticket is legitimate and to prevent fraud. By validating the ticket, transportation officials can ensure that the correct fare was paid and that the rider is authorized to use public transportation. This helps to maintain the integrity of the transportation system and ensures that all riders pay their fair share. Additionally, ticket validation helps to prevent overcrowding on public transportation by tracking the number of passengers on board.”,

po przetłumaczeniu (za pomocą Google Translator):

„Konieczne jest skasowanie biletu w Warszawie po jego zakupie w aplikacji mobilnej, aby mieć pewność, że bilet jest legalny i zapobiec oszustwom. Stwierdzając ważność biletu, urzędnicy ds. transportu mogą upewnić się, że zapłacono właściwą opłatę za przejazd i że podróżny jest upoważniony do korzystania z transportu publicznego. Pomaga to zachować integralność systemu transportu i gwarantuje, że wszyscy pasażerowie płacą sprawiedliwie. Ponadto sprawdzanie biletu pomaga zapobiegać przeludnieniu w transporcie publicznym poprzez śledzenie liczby pasażerów na pokładzie”.

Pytanie 2: Why is it necessary to indicate the line number in Gdańsk during process of buying the ticket in mobile application? (tłum. „Dlaczego podczas zakupu biletu w aplikacji mobilnej konieczne jest podanie numeru linii w Gdańsku?”).

Otrzymana/Wygenerowana odpowiedź: „It is necessary to indicate the line number in Gdańsk during the process of buying the ticket in the mobile application in order to ensure that passengers are boarding the correct bus or tram. By specifying the line number, the application can generate the appropriate ticket and provide passengers with the correct information regarding their route. This helps to prevent confusion and ensure that passengers reach their intended destination efficiently and safely.”,

po przetłumaczeniu (za pomocą Google Translator):

„Konieczne jest podanie numeru linii w Gdańsku podczas zakupu biletu w aplikacji mobilnej, aby mieć pewność, że pasażerowie wejdą do odpowiedniego autobusu lub tramwaju. Podając numer linii, aplikacja może wygenerować odpowiedni bilet i przekazać pasażerom prawidłowe informacje dotyczące ich trasy. Pomaga to uniknąć nieporozumień i gwarantuje, że pasażerowie dotrą do celu sprawnie i bezpiecznie.”.

Można powiedzieć, że kwestia kasowania biletu łatwiej byłoby mi uzasadnić. W drugim przypadku najbardziej do mnie przemawia kwestia uniknięcia nieporozumień, w szczególności podczas kontroli.

Spróbowałem też wygenerować cały wpis za pomocą powyższego mechanizmu, wskazując różną treść zapytania, ale nie udało mi się uzyskać w treści wskazania różnic, o których pisałem powyżej. Teksty skupiały się bardziej na początkowych etapach procesu, czyli rejestracji, sposobu wybierania biletu czy możliwego sposobu opłacenia tego przejazdu. Pewnie wynika to z kwestii zapytania. Czasami jednak trzeba zajrzeć do regulaminu lub na stronę przewoźnika, aby taką różnicę zauważyć wcześniej i potem nie być zaskoczonym.

Gdy pojawia się problem z produktem

„Houston, mamy problem” (ang. Houston we have a problem) to chyba jedno ze sformułowań, które zna każdy. Słyszał je, używał, oglądał film, gdzie ono padło czy nawet zna historię tego sformułowania (choć w rzeczywistości brzmiało trochę inaczej). A może ktoś czytał książkę o takim tytule? Ale nie, spokojnie dzisiaj nie będzie o filmie, książce czy podboju kosmosu, będzie o problemach. Słowo to pada w różnych określeniach… „mam problem”, „chyba mamy problem”, „problem do rozwiązania”, „problematyczne”, „zarządzanie problemami”, „rozwiązywanie problemów” itd.

Czasami mówi się, że lepiej powiedzieć zamiast problemu, że istnieje wyzwanie (podobno lepiej brzmi). Fakt jest taki, że zadziało się coś, czego się nie spodziewaliśmy, co powoduje nieprawidłowe działanie, niedostępność usługi/procesu/produktu, powołanie komitetu sterującego czy konieczność podejmowania szybkich decyzji. Mamy tutaj więc dwie strony „medalu” – identyfikację problemu oraz reakcję na problem.

Z nazwaniem czy identyfikacją problemu, stwierdzeniem faktu jego istnienia przez osobę, która ma z nim do czynienia, nie ma jakiejś wielkiej trudności. Wyzwanie (świadomie używam tego słowa) pojawia się z drugiej strony – w reakcji na znaleziony problem. W zależności od przyczyny problemu czy zależności od tego, co wcześniej wykonała dana osoba, z komunikowaniem problemu szerszemu gronu może być trudniej, a czasami może to powodować strach/przerażenie czy też inną reakcję, może ucieczkę.

Mając w pamięci różne sytuacje, zarówno te, w których byłem odbiorcą komunikatu, czy biernym obserwatorem czy też osobą identyfikującą problem, mogę pokusić się o identyfikację (czyt. nazwanie) kilku podejść do takiej sytuacji (podane nazwy to pierwsze skojarzenia z zachowaniem, moje bardzo subiektywne określenia):

• śpioch – nie robi nic, niech problem sam się rozwiąże, może ktoś inny go też znajdzie i podejmie kroki; nie musi się martwić i tłumaczyć, sprawdzać itd. W tej sytuacji nie czuje się odpowiedzialny za problem a także jego/jej działania nie przyczyniły się do niego;
• konspirator – również nie robi nic, a wręcz ukrywa problem. Może ktoś przy okazji znajdzie go w innej sytuacji i powie o nim. Wtedy może udać zdziwienie lub podejść do tego inaczej. Reakcja wynika często z tego, że po pierwsze nie chce podjąć działań, boi się reakcji, oceny ale z drugiej nie chce wziąć odpowiedzialności za swoje działania lub brak działań, które przyczyniły się do pojawienia problemu;
• ofiara – mówi, że jest problem. Żali się jak do niego mogło dojść, że to przeoczył/a. Niech każdy pomoże, on/a sobie nie poradzi. On/a nic nie potrafi, jak robi takie błędy. Plus jest taki, że problem wychodzi na jaw, ale równocześnie trzeba sobie poradzić z osobą zgłaszającą, która tworzy niezbyt przyjemną atmosferę;
• współpracownik – mówi, że jest problem, ale stara się do niego podejść racjonalnie. Znaleźć przyczynę, porozmawiać o skutkach, przyznać się do błędu, ale nie robić wokół siebie zamieszania jak w przypadku „ofiary„. Wtedy skupiamy się na faktach i działamy. Nie szuka winnego. Współpracujące zachowanie może się pojawić także wtedy, gdy ktoś nie ma wpływu (jak w przypadku „znalazcy” poniżej), ale chce pomóc bardziej (na przykład sprawdzić po rozwiązaniu, uczestniczyć w testach, dostarczyć szczegółowe dane dotyczące problemu lub nawet zaangażować się w zespół wraz z propozycją rozwiązań). Postawa ta może być także w przypadku powiązania z problemem;
• bohater – stwierdza, że jest problem i już znalazł jego rozwiązanie. Wskazuje wokół co trzeba zrobić, kogo poinformować, jak działać. Bierze na siebie odpowiedzialność równocześnie stając się liderem tematu od „a” do „z”, nawet przygotowując lessons learned, aby taka sytuacja nie powtórzyła się w przyszłości. Nie szuka winnego;
• sędzia – wskazuje, że jest problem, równocześnie wskazując co jest przyczyną, najlepiej ze wskazaniem osoby/procesu/tematu, który się do tego przyczynił. Jeżeli problem jest spowodowany przez kogoś innego, to bez skrupułów następuje ocena sytuacji. Jeżeli problem jest spowodowany przez działania danej osoby, wskazywana jest słabość systemu lub procesu, który nie zabezpieczył przed problemem;
• znalazca – mówi, że jest problem, ale nie ma możliwości zajęcia się nim, nie ma wpływu na system, proces, jednostkę itd. W szczególności ma to miejsce, gdy jest Klientem, użytkownikiem, odbiorcą.

Wyobraźmy sobie, że przez kilka sprintów zespół deweloperski pracował nad produktem, zgodnie z kierunkiem wskazanym przez product ownera. Wszystkie ceremonie przeszły bez problemów. Na planowaniu była pełna gotowość do realizacji zmian, na review prezentowany był pięknie działający produkt z kolejnym przyrostem. Na daily czy retrospektywnie nikt nie zgłaszał problemów czy trudności. Zadecydowano o wdrożeniu, mijają dwa dni i następuje wielkie bum… w jednym z kluczowych procesów produktu, następuje błąd. Trafia zgłoszenie do zespołu w kolejnym sprint, wszystkie prace są wstrzymane w celu jego rozwiązania. Jest problem z produktem. Wiadomo gdzie, w którym miejscu i… Ktoś zgłosił problem, więc zachował się jako „znalazca” a nie „śpioch”. W zespole (oznaczonym jako osoby na kole przerywanym na diagramie powyżej). zaczyna się szukanie przyczyny problemu i w zależności od przyczyny problemu mogą pojawić się różne z wymienionych zachowań – na przykład:

• „sędzia” może powiedzieć, że to przez brak odpowiednich testów, które powinny być wykonane przez osobę X, zespół XYZ (przykład oznaczony na diagramie powyżej na szaro jako osoba poza zespołem);
• „ofiara” może powiedzieć, że to moja część pracy, zacząć płakać na spotkaniu, że przez nią Klienci mogą nas oczernić na forach. Że ja sobie nie poradzę z tą sytuacją (przykład na czerwono oznaczony na diagramie powyżej).
• „bohater” może powiedzieć, że wie jak obejść problem. Na przykład może wskazać, że problem znika, gdy na danym ekranie, użytkownik zapisze dany stan, zrestartuje aplikację i ponownie wejdzie (przykład na zielono oznaczony na diagramie powyżej).
• „konspirator” może powiedzieć, że to nie nasz problem, u nas wszystko działało, mamy potwierdzenia z testów i kto inny powinien się zająć problemem (przykład oznaczony na fioletowo na diagramie powyżej).

Spotkałem się z różnymi reakcjami w takich sytuacjach i moim zdaniem najłatwiej jest, gdy wszyscy są albo „współpracownikami” (przykład na pomarańczowo zaznaczony na diagramie powyżej) albo „bohaterami” bo wtedy najszybciej można rozwiązać problem, nie ma szukania winnych. Jeżeli osoba, która zawiniła przyzna się do błędu i pomoże w identyfikacji miejsca, ułatwi to wszystkim pracę. Gdy ze względu na duch współpracy, zaangażuje się, też to ułatwi wszystkim zadanie.   

Powyższe określenia są moją subiektywną próbą zobrazowania zachowań, które obserwowałem w różnych sytuacjach biznesowych i prywatnych. Pewnie nie pokrywają pełni możliwości, ale moim zdaniem wskazują te, które dość często można zaobserwować. Te, które są bardzo wyraziste.

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.

„Skutki” ochrony danych

Jeden z sobotnich poranków, sprawdzam prywatną pocztę i wśród wiadomości znajduję zatytułowaną w następujący sposób: „Komunikat ws. naruszenia ochrony danych osobowych” (więcej o takich komunikatach można znaleźć w sieci Internet) . W pierwszym momencie zrobiło mi się gorąco, bo tego się nie spodziewałem i może to być problem, w zależności od tego, który podmiot wysłał taką wiadomość (w domyśle jakimi danymi dysponował). Spojrzałem na nadawcę i trochę się uspokoiłem. Pierwsze pytanie, które sobie zadałem: „Kiedy korzystałem z tego serwisu?”. Na pewno dawno (po sprawdzeniu okazało się, że kilka lat temu), więc czytam już spokojnie całą wiadomość. Wiadomość można streścić w 5 punktach (więcej o takim zawiadomieniu można znaleźć na stronie UODO):

1. co się stało? czyli opis sytuacji;
2. co to może oznaczać? czyli konsekwencje. Przy tym punkcie postanowiłem, że sprawdzę jakie moje dane mają, zmienię hasło dostępu oraz wyślę prośbę o usunięcie konta.
3. co zrobili i co planują zrobić? To, co przeczytałem wzbudziło mój niepokój ale mnie nie zaskoczyło, bo te elementy znam już z artykułów związanych z RODO (o kilku kwestiach pisałem też na blogu).
4. co mogę zrobić po swojej stornie? Informacje odnosiły się bardziej do sugerowanych reakcji, gdy jednostka/osoba, która weszła w posiadanie moich danych, zaczęła je wykorzystywać. Utwierdziłem się w przekonaniu co do akcji, które chciałem podjąć. Dodatkowo zdecydowałem się na zarejestrowanie się w BIK, co wskazywał jeden z punktów.
5. dodatkowe informacje. Można powiedzieć, że przyjąłem do wiadomości.

Wykonałem akcje:

• [grupa A na diagramie:] sprawdziłem jakie dane podałem – na szczęście nie podałem PESEL, serii dowodu osobistego oraz innych specyficznych danych. Dane były bardzo ograniczone (uff!) i błędnie sformatowane ze względu na wprowadzone zmiany w systemie.
• [grupa A na diagramie:] zmieniłem hasło. Nigdy nie zaszkodzi.
• [grupa A na diagramie:] wysłałem prośbę o usunięcie konta w serwisie ze wszystkimi danymi powiązanymi (bo takiej opcji nie ma w samym serwisie) – nie jest mi potrzebny dostęp do tego serwisu i nie mam żadnych aktywnych usług/transakcji/opcji. Konto zostało usunięte.
• [grupa B na diagramie:] zapoznałem się z informacjami na stronie BIK, a następnie zarejestrowałem się w serwisie.

Powyższy diagram prezentuje wykonane ścieżki postępowania. Rozpoczyna się od zdarzenia inicjującego opartego o komunikat (message event). Następnie przybliża ścieżkę weryfikacji danych, zmiany hasła, prośby o usunięcie konta, a następnie rejestracji w BIK.    

Wskazany proces rejestracji w BIK (link znalazłem po przygotowaniu powyższego diagramu) jak widać ma dużo elementów mających na uwadze bezpieczeństwo danych oraz jednoznaczne potwierdzenie tożsamości. Samo potwierdzenie rejestracji jest wieloetapowe – trzeba zrobić przelew weryfikacyjny (na przykład korzystając z płatności online), dane przelewu muszą się zgadzać z wprowadzonymi danymi, trzeba wykonać kroki z wiadomości wysłanej na wskazany e-mail, po drodze dostajesz specjalny kod na wskazany numer telefonu i go podajesz podczas ustalania hasła, a potem trzeba zalogować się dodatkowo podając PESEL w formie maskowanej. Czułem, że podmiotowi zależy na ochronie moich danych przy równoczesnym zabezpieczeniu się przed nieuprawnionym dostępem do nich.

Po otrzymaniu takiej wiadomości, mamy jakieś opcje, aby upewnić się czy nasze dane nie zostały wykorzystane lub jak poznać, że zostały wykorzystane lub też co możemy zrobić, aby się ustrzec przed takim ryzykiem w przyszłości (wiadomość wskazywała takie opcje, można też znaleźć takie informacje w dedykowanych artykułach). Wiele zależy od rodzaju danych, które wpadły w niepowołane ręce. Im ich więcej lub/i bardziej detaliczne, to można powiedzieć, że ryzyko jakiś niechcianych zdarzeń, z perspektywy ich właściciela, rośnie.

Dobrze zawsze się zastanowić czy udostępniane dane (wprowadzane podczas rejestracji lub przy innej okazji) pasują do działań/operacji możliwych do wykonania w serwisie lub w danej funkcjonalności/procesie. Jeżeli na przykład w serwisie będzie tylko korzystać z publikacji wewnątrz serwisu, podawanie numeru PESEL czy dowodu osobistego nie wydaje się uzasadnione. Z kolei, gdy zamierzamy podejmować zobowiązania wymagające jednoznacznego potwierdzenia tożsamości, brak podania takich danych może uniemożliwić skorzystanie z takich usług online czy nawet stacjonarnie. O przykładzie nadmiarowych danych podczas zgłoszenia reklamacji pisałem w innym wpisie.

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.