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.

Reklama

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

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.