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

Reklama

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.

„Ciche” zdarzenie w procesie

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

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

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

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

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

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

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

Ewolucja czy rewolucja?

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

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

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

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

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

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

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

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

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

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

Niespełnione oczekiwania jako początek zmian

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

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

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

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

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

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

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

Proces planowania sprintu

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

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

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

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

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

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

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

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

—

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

Gdy brak zdarzenia…

Ostatnio idąc do pracy, zauważyłem jak zmienia się cykl na skrzyżowaniu, które muszę pokonać. Samochody zaczęły zwalniać i w momencie jak dotarłem na skrzyżowanie zapaliło się im czerwone a ja nacisnąłem przycisk dla pieszych, aby wywołać zielone. Niestety zgodnie z cyklem zapaliło się światło zielone najpierw na jednej podporządkowanej, potem na drugiej. W tym momencie powinno zapalić się światło zielone dla pieszych, ale to nie nastąpiło. Przypuszczam, że za późno nacisnąłem przycisk, aby algorytm zmiany świateł to wyłapał. Może przycisk nie działał, choć to raczej nie możliwe, bo często z tego przejścia korzystam. Mogę przypuszczać, że cykl jest ustawiony jak na poniższym diagramie.

Na powyższym diagramie w BPMN wykorzystane zostały elementy:

• Zdarzenie oparte o czas (nadejście określonego momentu czy minięcie określonego czasu), co jest oznaczone przez obiekt timer event. Na diagramie są 2 takie zdarzenia: początkowe dla procesu (start timer event), oznaczone jako (A) na diagramie oraz pośrednie, występujące wewnątrz procesu (intermediate timer event), oznaczone kolejnymi literami (B, C, D, E).
• Zdarzenie informujące o otrzymaniu sygnału/komunikatu od zewnętrznego aktora (message event), tym razem zastosowane wewnątrz procesu (intermediate message event). Takim komunikatem/sygnałem jest żądanie od pieszego, który oczekuje zmiany światła z czerwonego na zielone dla przejścia dla pieszych. Ostatnio wskazywałem, że to zdarzenie może rozpocząć proces. W tym wypadku to zdarzenie wpływa na przebieg procesu, który wykonałby się i tak bez tego zdarzenia – nastąpiłaby zmiana świateł, tak, aby samochody z dróg podporządkowanych mogły przejechać przez skrzyżowanie. Różnica między obiektami jest widoczna na diagramach – jedno z nich ma pojedynczą linię (początkowe), a drugie podwójną (wewnątrz procesu).
• Bramka oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze napotkane zdarzenie inicjuje uruchomienie ścieżki/przebiegu procesu, występującego po tym zdarzeniu. Na końcu rozdzielenia też jest bramka i w zależności od jej rodzaju – wszystkie ścieżki muszą dojść do tego miejsca lub wystarczy jedna, aby proces przeszedł dalej. W powyższym przykładzie zastosowano również bramkę, która oznacza, że wystarczy tylko jedno z „wejść”, aby przejść dalej w procesie (tzw. exclusive gateway). Taka bramka znajduje się także poniżej, w celu wyboru jednej ze ścieżek, w zależności od tego, czy światło dla pieszych jest zielone czy nie. Decyzja oparta jest o zebrane dane/statusy (exclusive data-based event) a nie zdarzenia. Wcześniejsze zdarzenie (żądanie pieszego) spowodowało zmianę światła lub nie – jest to w sumie zero-jedynkowe. Takie oznaczenie można zaliczyć do danych sterujących procesem. Gdy brak takiego zdarzenia, zadania dotyczące światła dla pieszych w przebiegu procesu zostaną pominięte.
• Zadania (ang. tasks) wykonywane w procesie – zmiany świateł na czerwone, a potem na zielone dla odpowiednich sygnalizatorów oznaczonych numerami (1)-(4).
• tzw. artefakty, czyli dodatkowe elementy rozszerzające interpretację diagramu. Dodałem komentarze dotyczące przebiegu procesu, aby lepiej oznaczyć miejsca, które opisuje w punkcie dotyczącym bramek. Są to informacje dodatkowe, które nie sterują przebiegiem procesu, a pozwalają lepiej zrozumieć przedstawiony diagram.

Za pomocą wskazanych obiektów można sterować przebiegiem procesu oraz sekwencją wykonywanych zadań. W zależności od obsłużonych zdarzeń lub ich kolejności wystąpienia, proces pójdzie ścieżką „domyślną”, obsłuży wyjątek lub zastosuje zadania wynikają z alternatywnego przebiegu procesu. Powyższy proces mógłby przebiegać tak, że zawsze następuje przełączenie światła dla pieszego – z czerwonego na zielone, niezależnie od jego żądania.

Może być też tak, że w zależności od liczby żądań, czy jedno czy z dwóch stron jezdni, zmiana świateł dla samochodów następuje szybciej lub czas oznaczający, że konieczne jest przestawienie świateł się wydłuża. Pewnie istnieje też system, który dostosowuje długość cykli do ruchu lub natężenia ruchu pieszych. W niektórych miastach były testowane (a nawet chyba są wdrożone) takie mechanizmy, które badają natężenie ruchu lub mają zmienny system sygnalizacji w zależności od pory dnia.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Dzięki niej będę mógł tworzyć treści bardziej dostosowane do Waszych oczekiwań. Jeżeli pojawią się jakieś uwagi do samej ankiety lub problemy z jej wypełnieniem prośba o sygnał w komentarzu lub na adres e-mail podany po prawej stronie.

Przez telefon czy na stronie?

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Automatyczne reguły oparte o wzorce

„Automatyczna odpowiedź: Potwierdzenie otrzymania wiadomości. Państwa wiadomość została przekazana do właściwego pracownika […] ”, a dalej podpis i informacja „Wiadomość została wygenerowana automatycznie, prosimy na nią nie odpowiadać.”. Takiego maila otrzymałem w odpowiedzi na wiadomość skierowaną do podmiotu gospodarczego, wskazując w tytule numer sprawy. Nie otrzymałem jeszcze odpowiedzi na to zgłoszenie. Jednak mogę sobie wyobrazić co się stało na poziomie skrzynki odbiorczej. Mechanizm obsługujący, pobrał tytuł wiadomości, sprawdził do kogo powinna trafić sprawa, a potem wysłał maila z powyższą odpowiedzią. Poniższy diagram w BPMN prezentuje przebieg takiego procesu automatycznego.

Na diagramie znajduje się tym zadania „reguła biznesowa” (ang. business rule task), o której pisałem już kilkakrotnie, obrazując ją różnymi przykładami oraz zastosowaniami. W ramach tego kroku następuje próba odnalezienia osoby przyporządkowanej do określonych sformułowań lub numerów użytych w tytule. Mogą to być poszukiwania dokładnego odpowiednika lub zakresów wartości (wzorca). z uwzględnieniem ewentualnych określeń poprzedzających lub następujących po poszukiwanym fragmencie. Reguła może też przewidywać, że inne przypadki są przesyłane do ręcznego przyporządkowania. Reguły mogłyby także zakładać priorytety sprawdzania.

Fragment tytułu (wzorzec) – przykłady	Przyporządkowanie
[NR SPRAWY] 2018/06/1*	Osoba X
[NR SPRAWY] 2018/06/0*	Osoba Y
[NR SPRAWY] 2017/*	Skrzynka ogólna
….
*PRODUKT A*	Zespół A
*PRODUKT B*	Zespół B
…
*PRODUKT N*	Zespół N
RE/ODP:*	Pierwotny nadawca (lub osoba zastępująca)
brak przyporządkowania	Skrzynka ogólna

Notacja uniwersalna dla procesu

Wiele symboli, grafik, mechanizmów, które nas otacza każdego dnia jest zrozumiała niezależnie od posiadanego wykształcenia, narodowości czy wcześniejszych doświadczeń. Gdy widzimy “+” w wyrażeniu, to wiemy, że coś dodajemy do czegoś. Gdy widzimy czerwone światło na ulicy, to oznacza brak możliwości ruchu. Gdy widzimy pięciolinię to myślimy o muzyce. Podobnie jest z wieloma innymi symbolami. Symbole są mniej lub bardziej upowszechnione. Korzystanie z nich ułatwia komunikację, wymianę pomysłów oraz idei między różnymi odbiorcami. Opisane przykłady wskazują na stosowanie tzw. notacji uniwersalnej, z ang. universal notation.

W przypadku procesów biznesowych, także istnieje taka notacja, która pozwala na zaprezentowanie przebiegu procesu w sposób zrozumiały dla większości odbiorców. Jest to tzw. Universal Process Notation, po przetłumaczeniu Uniweralna Notacja dla Procesów. W tej notacji, jak widać na powyższym diagramie są stosowane obiekty (ramki), zawierające informację o nazwie czynności oraz jej wykonawcy oraz połączenia opisujące wejścia i wyjścia poszczególnych czynności. W odróżnieniu od notacji BPMN, którą się często posługuję w ramach diagramów na blogu, zapis jest zdecydowanie uproszczony.

Na powyższym diagramie zapisałem przykładowy proces dot. kolejkowania, gdzie występowały dwie różne role – użytkownik oraz system. Produkty poszczególnych kroków były różne i można je jednoznacznie określić: Otrzymane żadanie klienta, Wypełniony formularz, Zapisane zgłoszenie, Parametry listy ustalone, Sprawa dodana do kolejki. Strzałki informują o kolejności kroków oraz kierunku przekazywania wejść. Dodatkowo mamy ponumerowane kroki, aby łatwiej było się do nich odnosić. Pozwalają też zidentyfikować pierwszy krok (proste zastosowanie uniwersalnej notacji związanej z liczbami).