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

nieocenione2_360px

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

zamowienie_error_500px

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

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

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

Zdalne ceremonie

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

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

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

zdalne_ceremonie_520px

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

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

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

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