MENU

Zapominamy o wielu czynnikach, składających się na to, jak rozwiązanie widzi użytkownik

29 lipca 2014Architekci IT, Polecane tematy

Zbyt łatwo zapomina się o wielu czynnikach, składających się na to, jak rozwiązanie IT widzi Użytkownik Końcowy. Czy to, co zobaczy on w sytuacji naprawdę wyjątkowej będzie konsekwentne i równie przyjazne, przejrzyste jak pozostałe elementy systemu? Tu znaczenie ma nie tylko dobry projekt front-endu, ale każda warstwa rozwiązania.

architecture

Z czym się kojarzy Architektura? Ogólne diagramy, kilka perspektyw na system (lub grupę systemów) z „lotu ptaka”, rozpisane Przypadki Użycia (zakładające sterylne warunki swego przebiegu, ewentualnie podstawowe odstępstwa od przewidzianych podstawowych kroków), oraz – w razie potrzeby – przepis na integrację systemów. Infrastruktura? Zapewne ma działać i być gotowa na przyjęcie tego, co wynika z diagramów. Użytkownik widzi tylko Warstwę Prezentacji, więc reszta nie jest istotna. Prawda? Nie do końca. Niestety, gdy się ma styczność z działającymi rozwiązaniami, w życiu codziennym, można odnieść wrażenie, iż niektórzy ich Twórcy o tym zapominają, skupiając się na idealnych sytuacjach, ignorując to, że sytuacje wyjątkowe zdarzają się całkiem często.

Nieoczekiwane problemy a architektura systemów

Sytuacja wyjątkowa to nie tylko taka, gdy np. ktoś wpisze poprzez formularz WWW numer PESEL złej długości. Gdy warstwa prezentacji zaakceptuje wprowadzone wartości, mogą one wędrować pomiędzy środowiskami (niekoniecznie od tego samego Dostawcy) i czyha na nie więcej zasadzek. Zwykłe odmienne reguły walidacji, bardziej restrykcyjne niż te, w które został wyposażony GUI, mogą nam przysporzyć problemów. Także nieodpowiednie, bądź nieprzewidziane przekierowanie komunikatu międzysystemowego, wynikające z błędu na etapie projektowania procesów, czy ich implementacji jest generatorem kłopotów. Może nim być także niedostępność któregoś z elementów IT, zaangażowanych w realizację zlecenia.

Gdy się ma styczność z działającymi rozwiązaniami, w życiu codziennym, można odnieść wrażenie, iż niektórzy ich Twórcy zapominają, że Użytkownik nie tylko widzi Warstwę Prezentacji, skupiając się na idealnych sytuacjach, ignorując to, że sytuacje wyjątkowe zdarzają się całkiem często.

Przyczyn może być wiele: szeroko pojęte problemy wydajnościowe, a także pozornie niewiarygodne – jak fizycznie niestykająca wtyczka RJ45 w serwerze, czy awaria Data Center w innej lokalizacji, bądź łącze do niego prowadzące. Czy wiemy, że powiązane systemy mają zapewnione redundantne połączenie, lub są wyposażone w mechanizmy obsługi niedostępności usług? Jakie ma to znaczenie? Takie, że Użytkownik po to wszedł w interakcję z systemem, aby dane zostały przetworzone poprawnie. Nie interesuje go złożoność procesów, ani to jak wiele systemów, czy serwerów jest zaangażowanych w jego sprawę. Jeśli wystąpił jakiś problem (z jego winy, bądź szeroko rozumianej tzw. przyczyny technicznej), lepiej go o tym – prędzej czy później, ze wskazaniem na prędzej – poinformować. Najlepiej automatycznie. Tak, aby wiedział, co się stało z jego zleceniem, w jakim jest stanie, czego może się spodziewać, oraz czy są oczekiwane od niego jakiekolwiek inne akcje. Dlaczego? Gdyż nikt nie lubi pozostawać w niepewności.

To nie wstyd zaprezentować informację, że coś poszło nie tak. Wstyd (nieumyślnie) pokazać, że Użytkownik korzystając – w dobrej wierze – ze standardowego GUI, w łatwy sposób wygenerował/napotkał nieprzewidzianą sytuację, z którą sobie nasze rozwiązanie nie potrafi poradzić. Najgorszy – ze wszystkich – to taki przypadek, w którym system podaje nieprawdę, np. udaje, że wszystko poszło idealnie, a w rzeczywistości utracił zamówienie w sposób bezpowrotny, bez śladów jego istnienia.

Każda warstwa systemu jest istotna

Wszystkie warstwy, od fizycznych urządzeń, aż po wielodomenowe abstrakcyjne byty, wraz z dobrze zaprojektowaną warstwą prezentacji składają się na to, jak grupa systemów będzie odbierana. Czy używany system to sprawnie działający organizm, odporny na czynniki zewnętrzne, czy to tylko mniej lub bardziej udanie pomalowany balonik, zapadający się sam w siebie pod wpływem czasu i innych naturalnych czynników eksploatacyjnych.

Można by rzec, że przytoczone przypadki są nieistotne, skrajnie nieprawdopodobne, bądź z punktu biznesowego pomijalne – w końcu wszędzie zdarzają się błędy, a IT (zdaniem wielu osób) ma to do siebie, że działa na awarie niczym magnes i wszyscy się już do tego przyzwyczaili. Tylko – dlaczego tej statystyki nie próbować polepszyć, poprzez unikanie grzechów poprzednich projektantów? Poniżej postaram się przytoczyć niedawny przypadek z mojego życia, w którym wystąpiłem w roli Użytkownika obcego systemu, który to trafił na sytuację wyjątkową, lecz bardzo powszednią. Zabrakło jasnego zachowania systemu, a cała transakcja zakończyła się sukcesem tylko przez mój naturalny upór.

Czy wiemy, że powiązane systemy mają zapewnione redundantne połączenie, lub są wyposażone w mechanizmy obsługi niedostępności usług? Jakie ma to znaczenie? Takie, że Użytkownik po to wszedł w interakcję z systemem, aby dane zostały przetworzone poprawnie.

Otóż parę miesięcy temu miałem potrzebę dokonania rezerwacji w hotelu. Konkretnego dnia, w wybranej konkretnej lokalizacji. Ucieszyłem się, że jest to możliwe za pomocą aplikacji webowej. Tym większa ma radość była, gdy dowiedziałem się z niej, że tego dnia jest dostępny ostatni pokój, w promocyjnej, niższej cenie, dostępnej tylko online, do końca dnia. Ot marketingowe zagranie, ale działa. Niezwłocznie wypełniłem formularz. Nastąpiło przekierowanie do serwisu płatności, tam także wpisałem wymagane dane. Jeszcze jedno potwierdzenie i… zaskoczył mnie komunikat o nieudanej autoryzacji. Zdarza się. Nie ma potrzeby wnikać, czy przyczyną było odbicie się od drugiego dna limitu karty, czy coś chwilowo nie zadziałało po stronie banku / operatora kart (bądź po drodze) – ten krok, także ze względów bezpieczeństwa – dla serwisu płatności ma się kończyć niemalże zerojedynkowo – czy autoryzacja jest pozytywna, czy negatywna. Tym razem była negatywna.

Szukam, więc, możliwości ponownej zapłaty, choćby inną kartą. Niestety – brak. Zamiast tego nastąpiło przekierowanie na stronę hotelu, gdzie pojawił się komunikat o tym, że moja rezerwacja została anulowana. Myślę: trudno, spróbuję ponownie. Ponownie staram się dokonać rezerwacji – formularz „zgubił” moje dane – niech będzie, wpiszę ponownie. Najwyraźniej rozczarowania, niczym nieszczęścia, chodzą parami, gdyż po wypełnieniu strony przekonałem się o innym smutnym fakcie – upatrzony pokój w wybranym terminie został zarezerwowany. Podejrzewałem, jednak, że owa rezerwacja wynikała z mojej pierwszej, nieudanej próby. Jak się później okazało – słusznie. Tylko, co zrobić, gdy system jasno poinformował mnie, że owa rezerwacja została anulowana? Może to kwestia odczekania jakiegoś czasu, aż ona się automatycznie zdejmie? Postanowiłem zająć się innymi sprawami i sprawdzać online dostępność owego pokoju – co jakiś czas. Do wieczora się nie zwolnił. Natomiast (jak się okazało) mogłem ponownie skorzystać z serwisu płatności – ordynarnie korzystając z historii przeglądarki (URL zawierał identyfikator rezerwacji i nie dbał o sesję). Zaryzykowałem i wpisałem dane karty kredytowej. Tym razem autoryzacja przebiegła pozytywnie. Dodatkowo – natychmiast otrzymałem e-maila z informacją, że cały proces rezerwacji przebiegł pomyślnie. Wybornie!

Gdyby nie determinacja i nastawienie na ten konkretnie hotel – w normalnej sytuacji – skorzystałbym z innego tylko, dlatego że ktoś w hotelowym systemie IT założył, iż płatność kartą kredytową, poprzez system zewnętrzny, zawsze kończy się pozytywnie i innych sytuacji nie należy obsługiwać. Wyłączam z rozważań opcję, gdy opisane zachowanie systemów było wynikiem wspierania przez nie modelu biznesowego, w którym problemy z promocją online są pożądane i zmuszają przyszłego gościa do skorzystania z droższej oferty tradycyjnej.

To nie wstyd zaprezentować informację, że coś poszło nie tak. Wstyd pokazać, że Użytkownik korzystając – w dobrej wierze – ze standardowego GUI, w łatwy sposób wygenerował/napotkał nieprzewidzianą sytuację, z którą sobie nasze rozwiązanie nie potrafi poradzić.

Testujmy wystąpienia sytuacji niestandardowych

Naprawdę warto poświęcać więcej uwagi sytuacjom niestandardowym, takim jak przypadek powyższy (moim zdaniem stanowiący dość elementarne niedopatrzenie) jak i bardziej złośliwym wyjątkom. Zgodnie z prawami Murphy’ego Użytkownicy, prędzej czy później, trafią na każdy z nich, w najmniej dogodnym dla wszystkich momencie. Ich obsługa nie musi być realizowana indywidualnie, może to być ścieżka generyczna, lecz wykonywana w sposób przejrzysty dla Użytkownika. Wiąże się to z większymi nakładami pracy na analizę i, oczywiście, nie należy też przesadzać w drugą stronę, gdyż zanim światło dzienne ujrzy prototyp produktu, sponsorzy projektu mogą już dawno stracić zainteresowanie tematem. Jednakże, zwykle lepiej ująć wyższy koszt rzetelnej analizy i implementacji, niż tracić później niemałe pieniądze na manualnym „dokręcaniu” zleceń, czy pośrednio – złej opinii Użytkowników aplikacji.

Krzysztof Wilniewczyc jest Solution Architektem w Asseco Poland.

Na co zwrócić uwagę projektując system IT

1. Dla użytkownika ważna jest nie tylko warstwa prezentacji, ale i to, co się za nią kryje.
2. Bierzmy pod uwagę sytuacje wyjątkowe, także pozornie niewiarygodne – jak fizycznie niestykająca wtyczka RJ45 w serwerze, czy awaria Data Center w innej lokalizacji.
3. Wszystkie warstwy, od fizycznych urządzeń, aż po wielodomenowe abstrakcyjne byty, wraz z dobrze zaprojektowaną warstwą prezentacji składają się na to, jak grupa systemów będzie odbierana.
4. Lepiej ująć wyższy koszt rzetelnej analizy i implementacji, niż tracić później niemałe pieniądze na manualnym „dokręcaniu” zleceń, czy pośrednio – złej opinii Użytkowników aplikacji.

Tekst pochodzi z magazynu ITwiz 1/2014.

Podobne tematy:

One Response to Zapominamy o wielu czynnikach, składających się na to, jak rozwiązanie widzi użytkownik

  1. Piotr Kowalski napisał(a):

    Brak zapewnienia spójności transakcyjnej to kardynalny błąd w architekturze systemu. Wiem, że nie jest to trywialne w heterogenicznych systemach rozproszonych, ale z pewnością możliwe do zrealizowania (sam nie tak dawno temu wykonywałem projekt, gdzie trzeba było zapewnić spójność trzech systemów – każdy w innej technologii). Więc prawdopodobnie w opisywanym przypadku wykonawcy oprogramowania zawiedli, gdyż nie sądzę, aby poprawna realizacja tego projektu miała mieć znaczący wpływ na budżet. Tak na marginesie – budżetowanie powinno z założenia opiewać na produkt pozbawiony wad podstawowych, ale wiadomo jaka jest rzeczywistość.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

« »