Paski postępu

Zawsze się śmieję, że moja praca składa się z:

  • 50% pisania maili i wklepywania treści w różne servicedeski
  • 50% myślenia w co kliknąć lub jaką komendę wydać
  • 50% oczekiwania na paski postępu

To nie pomyłka – odkąd mam 2 duże monitory mogę zerkać na te pieprzone paski w międzyczasie i wyrabiać 150% normy

Przejdźmy więc przez moją karierę i zobaczymy jak to było na przestrzeni lat 🙂

Pierwszy komputer w domu – Atari 65XE i wgrywanie gier z taśmy, to było coś… coś długiego 🙂

Atari ST i kopiowanie dyskietek programem FastCopy

Pierwsza dorywcza praca – salon gier z komputerami Amiga i kopiowanie gier dla klientów (jak odczyt z dyskietki nie szedł to kładło się coś na spacji (repeat) i czasem za setnym razem się udawało)

Pierwszy PC w domu i instalowanie Windows 95 (wiele razy bo system wyjątkowo często wymagał reinstalacji) 

Potem Windows 98 i kolejne edycje – ależ zabawa!

Potem pierwsza praca i instalowanie u użytkowników Windows NT 4.0 Workstation z CD albo lepiej z podpiętego dysku twardego… (kojarzę też 3.51 z dyskietek ale raz chyba w życiu to widziałem i wyparłem)

A pamiętacie te radosne godziny spędzone nad chkdsk jak się system rozsypał?

Jedna z częstszych przyczyn nudy przed wynalezieniem smartfonów i SCCM’a – (re)instalowanie office 97, 2000, 2003, 2010 – tego się sporo naoglądałem…

Instalki Windows 2000 i XP robiło się już Norton Ghostem – niby odmiana ale jednak pasek nadal obowiązuje a co gorsza nie bardzo jest co robić nie mając drugiego komputera… 

Albo i Clonezillą jak się nie było cebularzem i nie kradło Ghosta

Skanowanie zawirusowanych komputerów też zajęło trochę mojego życia

Był też taki okres kiedy najwięcej oglądało się tego – powinni do każdego update dodawać popcorn i colę. Swoją drogą jest z tym związany fajny prank, jeśli nie znacie to koniecznie komuś zróbcie – http://fakeupdate.net

Albo tego

Zdarzyło mi się też się niedorzecznie długie instalowanie i rozmieszczanie rozwiązań na Sharepointach – liczone w godzinach 🙂

Czy też współudział w instalacjach aktualizacji do jakichś egzotycznych softów 

Koniec końców doczekałem się pasku postępu przy robieniu kawy w pracy… 

Jak macie jakieś fajne paski postępu w pamięci dajcie znać w komentarzach.

PS. Wpis powstaje w pracy bo, zgadnijcie, czekam aż jeden soft mi się zainstaluje abym mógł kontynuować 🙂

Las Deszczowy a Photoshop

Odbieram maila. Czytam: “Proszę wydrukować załączony protokół odbioru usługi, podpisać, zeskanować i odesłać mailem, dziękuję”. Jak robot robię CTRL+P, idę do drukarki, podpisuję, skanuję a niepotrzebny papier wrzucam do niszczarki. 

Ile razy tygodniowo, miesięcznie, rocznie, robię w ten sposób? Myślę, że rocznie niszczę kilkadziesiąt świeżo wydrukowanych i podpisanych kartek. Ile mamy takich jak ja pracowników w Polsce, na świecie? Ile razem marnujemy papieru i prądu? Nie wspominając o zużyciu części w drukarkach i niszczarkach, tonerze, transporcie materiałów i urządzeń – wszystkiego co jest potrzebne abym mógł coś wydrukować i natychmiast potem zniszczyć?

Czy wdrożenie cyfrowego podpisu jest rozwiązaniem? Pewnie, że tak. Ile firm, z którymi współpracujecie honoruje taki podpis? Ma niezbędą infrastrukturę, wykupione certyfikaty, itd itp?

Czy dla osoby, która wysłała do mnie prośbę o przesłanie skanu podpisanego protokołu, byłaby różnica, gdybym nałożył mój podpis i pieczątkę w przysłowiowym Photoshopie? W 99% przypadków żadna. Ten 1% byłby załatwiony za pomocą poczty, kuriera, osobistego spotkania i podpisania czegoś obustronnie. 

Co więcej, dawno temu pracowałem dwa lata na stanowisku, które wymagało ode mnie podpisywania codziennie kilku-kilkunastu wniosków. Przesyłanych mailem. Skany wniosku z moim podpisem robiłem właśnie w programie graficznym, nakładając pieczęć i podpis uprzednio przygotowany. Dwa lata nikt się nie zorientował. Oszczędziłem kilka ryz papieru. 

Pomyślcie o tym, zanim znowu coś zeszredujecie. 

Dla jednego sukces dla innych porażka

Historia poniższa wydarzyła się naprawdę. Za siedmioma biurami, za siedmioma przegródkami żył sobie Prezes i utyskiwał, że w jego zamku nie funkcjonuje żaden eProcurement z prawdziwego zdarzenia. Szczególnie bolało go kulejące UX dla użytkowników końcowych, którzy w znoju klepali zapotrzebowania za pomocą pradawnego ERP’a. Dostęp do ERPa okupiony był zaś takimi opłatami, cłami i daninami, że opłacało się to tak samo jak gnój na pola wozić karetą królewską zaprzężoną w 16 arabów najczystszej krwi.

Edykt zatem wydano, że śmiałek poszukiwany jest co system dla ludzi napisze, taki z wyszukiwarką a’la Allegro i koszykiem a’la… no po prostu koszykiem. No i żeby to miało takie te i żeby błyskało i migało i jeszcze – żeby nie przesadzić ze skalą zadania – na początek tylko zamówienia na materiały biurowe ogarniało. 

Śmiałek znalazł się i zebrawszy drużynę wyruszył w drogę po całym królestwie, które krain miało jedenaście. W każdej krainie poddani inne pomysły mieli na twór ów ale każdy cieszył się, że pradawny ERP zniknie i zaklęć na pamięć uczyć się nie będą musieli. Każdy już ręce zacierał bo makiety i prototypy a nawet wersje demo pokazywane przez drużynę apetyty wszystkim poddanym zaostrzyły. 

Wyzwań co niemiara pokonała dzielna drużyna bo raz, że wymagań namnożyło się niemało a dwa, że ładny interfejs koniec końców i tak trzeba było jakoś połączyć z ERP’otworem, który nie mógł przecież zostać bez pożywienia w postaci krotek, encji, zetek i innych takich.

Udało się jednak. System zafunkcjonował produkcyjnie w wersji pilotażowej a potem objął coraz to nowe obszary zakupowe i poddani cieszyli się bo w skali królestwa kilkaset osób pozbawiono przyprawiającego o szaleństwo kontaktu z pradawnym ERPotworem a oszczędności na daninach niemałe były z tego powodu. Zamiast sześćset sześdziesiąt sześć sztuk złota każdy płacił jedną miesięcznie i składać zapotrzebowania bez pośrednictwa ERPa mógł.

Każdy z wyjątkiem Prezesa i jego świty na zamku.

Urzędnicy zamkowi nie mogli bowiem przeboleć, że w jakimś tanim systemie zapotrzebowania składać będą, bez stosownej pompy, protokołu i etykiety. “Czniam taki system co to go się uczyć trzeba od nowa i ma jakieś takie nowoczesne wygibasy esy floresy, uiksy… ja sobie będę dalej używał mojego oswojonego ERPa!”

Powstał zatem przypadek nie lada, gdzie każdy, oprócz Sponsora, w nowym rozwiązaniu zapotrzebowania składa.

Komunikaty błędów w praktyce

Projektując system bardzo rzadko zwraca się uwagę na komunikaty błędów. Nasza aplikacja przecież będzie zawsze działać poprawnie, czyż nie? Niestety testy (a czasem dopiero uruchomienie produkcyjne) rewiduje to życzeniowe podejście i okazuje się, że…

  • komunikat nic nie mówi użytkownikowi, 
  • co gorzej – nie mówi też nic administratorowi czy programiście, 
  • logi nie zawierają szczegółów, które pozwoliłyby namierzyć przyczynę problemu, 

Podzielę się z Wami paroma pomysłami na lepsze komunikaty błędów w aplikacjach biznesowych.

Nie strasz

Skonstruuj komunikat tak, aby był zrozumiały dla użytkownika i aby nie miał on poczucia winy. Warto użyć kilku słów pocieszenia i wziąć winę na siebie. To my, projektanci i administratorzy aplikacji czy infrastruktury, doprowadziliśmy do sytuacji, kiedy coś poszło nie tak. Jeśli aplikacja pozwala wykonać powtarzalny zbiór czynności prowadzący do błędu to coś jest z nią nie tak. 

Informuj

Komunika “Internal server error 500” nikomu niewiele mówi. Dla najczęstszych przypadków (których wystąpienia nie da się wyeliminować) przygotuj komunikat opisujący dokładnie co się stało i co należy dalej zrobić oraz czy istnieje jakieś obejście problemu. Często pozwoli to zmniejszyć ilość zgłoszeń jakie trafiają do firmowego centrum wsparcia.

w jednym z systemów częstą sytuacją było klikanie w link do już obsłużonego zadania, które trafiło do grupy osób. Pierwsza osoba wykonywała zadanie a reszta grupy dostawała błąd i zgłaszała usterkę na helpdesk. Po zmianie suchego komunikatu na szczegółowe objaśnienie co użytkownik ma zrobić (sprawdzić na liście zadań, czy takowe na pewno tam figuruje) ilość zgłoszeń tej kategorii spadła o ponad 90%. 

Nie zdradzaj za wiele

Użytkownika nie interesuje stack trace z Twojej aplikacji. Osobę mającą złe intencje już tak. Nie dodawaj “dla własnej wygody” żadnych informacji jakie zwraca serwer, kod, aplikacja. Przekieruj to do logów aplikacji.

Jeśli jesteś paranoikiem dodaj losowe opóźnienie przed wyświetleniem komunikatu błędu. Utrudni to życie złoczyńcom generującym specjalnie różnego rodzaju błędy i mierzącym czas odpowiedzi aplikacji – czasem można w ten sposób wywnioskować conieco o architekturze rozwiązania lub o istnieniu bądź nie istnieniu jakiegoś wpisu w bazie danych.

Klasycznym przykładem jest próbkowanie formularza resetu hasła adresami email i badanie czy dla (nie)istniejących adresów aplikacja odpowiada wolniej bądź szybciej. 

ułatwiaj sobie (i innym) życie

Jeśli błędy w Twojej aplikacji często trafiają do późniejszej obsługi, np. w ramach firmowego helpdesku albo na twoją skrzynkę mailową, możesz zastosować sztuczkę, która zaoszczędzi Tobie przeszukiwania logów, do których trafiają szczegółowe dane o błędzie. 

Dodaj do strony z komunikatem błędu przycisk “Zgłoś błąd do administratora”. Pod przyciskiem zabuduj wysyłkę maila na zdefiniowany w konfiguracji aplikacji adres, zawierającą np.:

  • adres, na jakim wystąpił błąd
  • dokładną datę i godzinę, 
  • login zalogowanego użytkownika a także, jeśli masz takie dane (możesz zintegrować się z jakąś usługą katalogową) jego Imię, Nazwisko, mail i telefon, 
  • dokładną treść błędu,
  • cały ciąg wywołań, stack trace, teksty jakie trafiły do logów,

Scentralizuj i zabezpiecz dane o błędach

Oczywiście dane występujące w komunikatach błędów są po części wrażliwe a po części to cenna wiedza. Warto się zastanowić, czy chcesz je zawsze w całości wysyłać na zdefiniowany mail (np. firmowy servicedesk).

Jeśli chcesz mieć nad tym większą kontrolę możesz zbudować sobie prostą aplikację, która wystawi serwisy przyjmujące dane o błędach z Twoich systemów. Po wystąpieniu problemu – oprócz pokazania strony użytkownikowi – wszelkie szczegóły będą wysyłane do centralnej bazy danych.

Po kliknięciu przycisku “Zgłoś błąd do administratora” zostanie wysłany tylko link do podglądu zdarzenia. Link ten nie będzie zawierał żadnych danych wrażliwych a otworzyć go będzie mogła jedynie osoba mająca stosowne uprawnienia.

Aplikacja taka zapewnia

  • większą kontrolę nad dostępem do błędów z poszczególnych aplikacji – możesz zdefiniować grupy administratorów i zarządzać ich składem, 
  • możliwość wyszukiwania, raportowania i korelowania błędów z wielu aplikacji, np. pod kątem częstotliwości lub rodzajów problemów

Unikaj… jeśli się to opłaca

Rób tak aby nie było błędów – to oczywista rada. Idealny świat to systemy bezusterkowe, samonaprawialne. Życie pokazuje że nie zawsze mamy wpływ na wszystkie komponenty które są częścią rozwiązania oraz te, z którymi ono współpracuje. Czasem jest też tak, że błąd zdarza się raz na miesiąc czy raz na rok i zwyczajnie nie opłaca się ich naprawiać. Taniej jest po prostu obsłużyć błąd ręcznie. To żadna ujma na honorze a zwyczajna kalkulacja zysków i strat.

Jak wybrać największe zło

Startując nowy projekt w firmie często stajemy przed wyborem:

a) kupmy gotowe narzędzie i dostosujmy nasze procesy do tego co ono oferuje; może będzie trzeba nagiąć nasze procedury ale system wystartuje błyskawicznie – dzięki temu znacznie szybciej zaczniemy korzystać z jego benefitów (znam kilka takich przypadków). 

b) wynajmijmy programistów i zbudujmy aplikację szytą na miarę, zróbmy testy z użytkownikami, iterujmy kolejne coraz lepsze wersje; nasza firma ma już wypracowane procesy, wzorce i trzeba się idealnie w nie wpasować. Będzie drożej w implementacji ale po wdrożeniu systemu proces będzie szedł szybciej, wygodniej, taniej a użytkownicy będą zadowoleni (co na każdym etapie potwierdzimy badaniami UX – takich znam mniej ale jednak były). 

Skoro z grubsza mamy takie dwie czarno-białe opcje (i jakąś gamę szarości pomiędzy nimi) to czemu idziemy zazwyczaj w… 

c) wybierzmy darmowe albo kupmy najtańsze gotowe rozwiązanie, brnijmy w jego naginanie do naszych potrzeb ale jednocześnie naginajmy nasze procesy do ułomności tego podejścia (bo nie wszystko da się – dysponując takim a nie innym budżetem – zmienić/poprawić) łamiąc karki użytkownikom końcowym; wydajmy masę kasy, przekroczmy wszystkie terminy i cieszmy się słąbym, niedopasowanym, ułomnym rozwiązaniem, które bardziej przeszkadza niż pomaga

DLACZEGO?

Ekspercka porada

kręcąc się przy laptopach usłyszałem co następuje

  • Pani z działu laptopy: Jaki to moa być laptop?
  • Klientka: no taki do internetu, filmów, gier
  • Pani z działu laptopy: a jeśli do gier to musi być, wie pani, taki z lepszym, szybszym znaczy, procesorem no i musi mieć, tę, kartę graficzną osobną, tak zwaną Nvidia albo Dżifors, no jedną z tych dwóch

interfejs webowy

zabawne jak kolejne fale przedstawicieli różnych produktów odkrywają technologię cienkiego (webowego) klienta.

Ja rozumiem, że jeśli przez 15 lat sprzedawaliśmy produkt oparty o grubego klienta, instalowanego na stacji u użytkownika, przejście na web może wywołać szok. Jednak opowiadanie potencjalnemu klientowi, że to jest nowość, rewolucja, przewaga konkurencyjna? Trąci sporym oderwaniem od rzeczywistości.

Prosty trick do zastosowania w budowaniu workflow na platformie Sharepoint

Ostatnio miałem poprawić coś w starym rozwiązaniu, które budowałem na Sharepoint 2010. Odkryłem przy tym ciekawy trick, na który wpadłem pewnie natchniony jakimś tutorialem na Youtube.

Trick przydaje się, jeśli chcemy zmieniać adresatów i treść maili systemowych (wysyłanych przez workflow do użytkowników) ale nie chce nam się w tym celu modyfikować samego workflow.

Czytaj dalej Prosty trick do zastosowania w budowaniu workflow na platformie Sharepoint