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

 

Reklama

Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

dane_logowania_430px

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

  • (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
  • (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

  • Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
  • Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.


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.

Równoczesne ścieżki procesu

Uruchamiam w pewien weekend swój komputer i po kilku sekundach widzę komunikat o braku możliwości odczytu dysku. Dobra restartuję go i zastanawiam się co się mogło stać. Próbuję ustalić przyczynę problemu i znaleźć możliwe rozwiązania, zgodnie z metodologią 8D, o której pisałem ponad rok temu. Próbuję komend na poziomie linii poleceń, sprawdzania dysku, uruchomienia trybu awaryjnego, załadowania poprzedniej wersji. Wszystkie działania wykonywałem sekwencyjnie. Ostatecznie skończyło się na instalacji systemu od początku. Mówi się trudno.process_rownoczesny_450

Wrzuciłem płytkę, zmieniłem tymczasowo kolejność źródeł uruchomienia systemu. Wreszcie pojawił się ekran – uruchom system z dysku lub zainstaluj system. Wybrałem to drugie i po kilku ekranach zaczyna się kopiowanie plików. A tu nagle zaskoczenie, mogłem równocześnie konfigurować przyszły system. Ooo…, coś nowego. Zwykle działo się to sekwencyjnie – najpierw kopiowanie potem parametry lub na odwrót. A tu taka oszczędność czasu.

Powyższy przykład można zobrazować diagramem w BPMN przy wykorzystaniu elementów pozwalających na rozdzielenie procesu na dwie równoczesne ścieżki (tzw. parallel gateway). Element początkowy rozdziela ścieżkę a element końcowy łączy. Przejście do dalszej części procesu możliwe jest dopiero po zakończeniu obydwu ścieżek. Gdyby czynności były sekwencyjnie ułożone nie byłoby tego elementu. Przed rozdzieleniem były pewne zadania istotne dla obydwu ścieżek, a potem były zadania będące efektem wszystkich wcześniej zakończonych kroków – uruchomienie systemu po raz pierwszy w wybranej wersji językowej i dla danego użytkownika.