Jak doprowadzić do korzystania z produktu przez użytkownika końcowego?

Czy można w ogóle myśleć o tym, że użytkownik, dla którego wykonujemy system - na jego zlecenie i zgodnie z jego wymaganiami - nie będzie chciał uruchomić gotowego produktu? Jeśli sytuacja taka ma miejsce w przypadku niewielkiego produktu, wówczas jej przyczyn można upatrywać w niezgodności oczekiwań użytkownika z dostarczonym produktem. Problemem jest produkt i jego jakość. Jeśli zaś sytuacja dotyczy dużego systemu informatycznego, wówczas jej przyczyny leżą najczęściej w źle zorganizowanym i niewłaściwie przeprowadzonym procesie jego wdrożenia.

Czy można w ogóle myśleć o tym, że użytkownik, dla którego wykonujemy system - na jego zlecenie i zgodnie z jego wymaganiami - nie będzie chciał uruchomić gotowego produktu? Jeśli sytuacja taka ma miejsce w przypadku niewielkiego produktu, wówczas jej przyczyn można upatrywać w niezgodności oczekiwań użytkownika z dostarczonym produktem. Problemem jest produkt i jego jakość. Jeśli zaś sytuacja dotyczy dużego systemu informatycznego, wówczas jej przyczyny leżą najczęściej w źle zorganizowanym i niewłaściwie przeprowadzonym procesie jego wdrożenia.

Gorszy, lepszy - co to znaczy?

Również i w drugim przypadku jakość oprogramowania może mieć znaczenie, na przykład gdy nowy produkt jest gorszy od używanego. Co to znaczy gorszy? Dla użytkownika końcowego "gorszy" może oznaczać taki, który ma gorzej zaprojektowane ekrany albo opracowane raporty. Z punktu widzenia firmy cechy te mogą być jednak drugorzędne wobec takich jak przetwarzanie w trybie on-line, centralna baza danych, automatyczne, konfigurowalne przetwarzanie dzienne, czy też funkcje dostępne dla komórek organizacyjnych, które nie miały wsparcia systemu informatycznego. Jeśli uruchamiany system swoim zasięgiem ogranicza się do wydzielonej komórki organizacyjnej, ocena jego przydatności jest stosunkowo łatwa i to ona zazwyczaj decyduje o sukcesie wdrożenia. Jeśli jednak obejmuje on funkcjonowanie całej instytucji, wówczas ocena jego przydatności to wypadkowa wielu cząstkowych ocen. Ocena końcowa nie jest w tym przypadku sumą ocen cząstkowych. To bardziej złożony proces budowania wizerunku nowego produktu, kształtowania się obiegowych opinii o systemie i jego wykonawcach - to pewnego rodzaju gra zaufania i wiary w osiągnięcie sukcesu.

Gra interesów

Uruchomienie systemu to moment, w którym zazwyczaj zachodzą planowane zmiany w organizacji uruchamiającej system. Dopóki o systemie jedynie się mówi i tylko go planuje lub projektuje, dopóty gra interesów nie jest jeszcze jasna. Ale gdy rozpoczyna się uruchamianie systemu, staje się zrozumiałe, że to, co dla kogoś było zagrożeniem, może w każdej chwili stać się realnym problemem. Ci, którzy upatrywali swojej szansy w uruchomieniu systemu, czują, że nadchodzi ich chwila.

Pierwsze objawy kryzysu można obserwować jeszcze przed uruchomieniem systemu. Kiedy kolejne oddawane elementy oprogramowania zaczynają tworzyć zamkniętą, spójną i w pełni użyteczną całość, zaczyna się krytyka rozwiązania. Gwałtownie narasta lista zgłaszanych uwag, uzupełnień, błędów. Ci, którzy nie chcą systemu, wykazują jego braki. Ci, którzy chcieliby jego uruchomienia, boją się, że system, za którym się opowiadali, będzie po prostu zły. Nagle okazuje się, że wcześniejsze ustalenia, spisane wymagania, zdefiniowana procedura zgłaszania i poprawiania błędów "biorą w łeb". I jedni, i drudzy (zwolennicy i przeciwnicy) zasypują twórców oprogramowania żądaniami zmian, bez których uruchomienie systemu jest - ich zdaniem - niemożliwe. Próby racjonalnego usystematyzowania uwag zawodzą - górę biorą emocje. Z pozoru błahy i nieistotny błąd może nagle okazać się dowodem na to, że produkt nie jest nic wart i przyczynkiem do twierdzenia, iż pieniądze wydane przez zamawiającego to czysta strata (to głos przeciwników). Nagle zupełnie drugorzędne funkcje, których implementację planowano na długo po uruchomieniu jądra systemu, stają się natychmiast wymagalne. Zwolennicy systemu, szukając kolejnych sojuszników i poparcia dla uruchamianego systemu, muszą przekonywać kolejne osoby do rozwiązań oferowanych przez nowy system. Dla nich to właśnie wiele nieistotnych "bajerów" jest argumentem potwierdzającym poparcie dla systemu. I tak oto nagle okazuje się, że w dwa razy krótszym czasie trzeba wykonać dwa razy więcej funkcji. Emocje sięgają zenitu, a doba nie chce się wydłużyć poza 24 godziny.

Czyje błędy?

Jakże często zdarza się twórcom systemu być w sytuacji, w której klient twierdził, że dana funkcja systemu nie działa, a inna owszem, ale tylko czasami, a za to jeszcze inna działa, ale niezgodnie z oczekiwaniami, choć twórcy systemu są przekonani, iż wszystkie działają poprawnie i zgodnie z postawionymi wymaganiami. A wszystko to dzieje się tylko dlatego że klient sam zaczął się "bawić" systemem i bez odpowiedniej jego znajomości nie mógł ustawić właściwych parametrów. Nie skonfigurował systemu pod kątem swoich potrzeb i wyciągnął błędne wnioski. Kiedy ów klient wygłosi krzywdzące sądy o systemie, jest już za późno - rysa na wizerunku produktu pozostanie. Mało który potrafi się przyznać, że tak naprawdę to był jego błąd, jego niewiedza, po prostu jego wina. Będzie szedł w zaparte. Będzie twierdził, że dokumentacja systemu jest zła (bo gdyby była dobra, to przecież by sobie przeczytał o tym, jak się konfiguruje system), system pomocy interaktywnej w programie jest bezużyteczny (bo gdyby był pomocny, to poprowadziłby go za rękę w najtrudniejszych momentach), szkolenia zostały źle przeprowadzone (bo gdyby były dobrze przygotowane, to wiedziałby wszystko, co było mu potrzebne), że... będzie jeszcze wiele innych, drugorzędnych argumentów, których jedynym skutkiem będzie zła atmosfera i pogarszający się wizerunek systemu. To, że w pięć minut po wygłoszeniu przez niego krzywdzącej opinii wszystkie funkcje zadziałały w pełni poprawnie i zgodnie z jego oczekiwaniami (oczywiście po uruchomieniu przez specjalistów), pozostanie niezauważone.

Strategia obecności

Jak przeciwdziałać takim negatywnym zjawiskom? Jest chyba tylko jedna rada - być na miejscu, u klienta, stać obok użytkownika końcowego. Wiele nieporozumień bierze się stąd, że podczas rozmów przeciwników i zwolenników systemu nieobecni są jego autorzy, którzy w sposób jasny i autorytatywny zaświadczyliby o określonych cechach systemu lub o jego brakach. Rozmowy osób, które oprogramowania nie znają, doprowadzają do powstawania mitów o tym, czego system nie potrafi albo co miał oferować. Przy rozstrzyganiu takich sporów nieco inna jest sytuacja, gdy jest uruchamiany gotowy produkt, a inna, gdy produkt jest tworzony na zamówienie.

W tym pierwszym przypadku można powoływać się na zakres udzielonej licencji, ofertę, istniejącą gdzie indziej praktykę. W przypadku tworzenia systemu na zamówienie jest znacznie gorzej. Tutaj stosunkowo łatwo obarczyć producenta winą za niewłaściwe zrozumienie postawionych wymagań lub pominięcie istotnych wymagań w wyniku źle przeprowadzonej analizy. Uruchamiając system, dostawca musi na stałe skierować sporą grupę osób do klienta. Ich pobyt tam to tylko z pozoru strata czasu. Efektywność wykorzystania specjalistów od systemu może być niska, patrząc na to z punktu widzenia wymiernych efektów pracy. Oceniając jednak ich pobyt, trzeba to rozpatrywać również, a niekiedy przede wszystkim, w kategoriach zapobiegania nieszczęściu. Trzeba postawić pytanie, ile może potencjalnie kosztować zła opinia o systemie i negatywna ocena procesu wdrożenia. Wraz z dostępnością pracowników u klienta musi iść dostępność projektantów i programistów wprowadzających oczekiwane zmiany w systemie - zwłaszcza w końcowej fazie uruchamiania systemu. Nie warto ryzykować przesunięcia od dawna zapowiadanego i przez wszystkich oczekiwanego terminu uruchomienia systemu, tylko dlatego że zespół wytwarzający oprogramowanie nie był gotowy do wprowadzenia niezbędnych zmian lub zauważonych błędów krytycznych.

Różnica między płotką a wielorybem

Można powiedzieć, że zamiast inwestować w czas pracy naszych specjalistów na miejscu u klienta lepiej zainwestować w szkolenia użytkowników. Nie od dziś wiadomo że głodnemu bardziej potrzebna od ryby jest wędka i umiejętność łowienia ryb samemu. Problem jednak polega na tym, że uruchamianie systemów bardziej przypomina polowanie na wieloryby niż łowienie płotek. Chwila nieuwagi i potężny ogon pływającego olbrzyma może nas po prostu roztrzaskać na kawałki. Tutaj zwykłe szkolenie nie wystarcza - potrzebna jest rutyna i doświadczenie będące pod ręką na zawołanie. Użytkownik musi z pewnością być przeszkolony. Nie ma też sensu, aby personel dostawcy wykonywał za niego rutynowe czynności. Konieczne jest jednak prowadzone na bieżąco doradztwo, zwłaszcza w zakresie złożonych i skomplikowanych czynności, takich jak administrowanie systemem. Strojenie systemu w pierwszym okresie jego funkcjonowania skutecznie może wykonywać jedynie personel wykonawcy systemu. Tylko on może z dużą wyrozumiałością znosić błędy i niedoróbki "łat", wykonywanych w systemie na ostatnią chwilę. Zamawiający nie zrozumie, dlaczego zgłoszona przez niego poprawka na dzień przed uruchomieniem systemu może być wykonana gorzej niż "wygrzewana" od lat pozostała część systemu.

Jeśli więc dopuszczamy w naszym postępowaniu szybkie, pozaproceduralne - z punktu widzenia procesu wytwórczego - ścieżki wprowadzania zmian w oprogramowaniu, to nie pozostaje nam nic innego, jak zrekompensować utraconą jakość produktu poprzez zwiększoną liczbę personelu wspomagającego jego uruchamianie bezpośrednio u klienta.

Fobie i sympatie użytkowników

Przy uruchamianiu systemu niezwykle istotne jest nastawienie do niego jego przyszłych użytkowników. Jeśli przed pierwszym użyciem produktu użytkownik usłyszy o nim niepochlebne opinie, że jest zły, słaby, niedostosowany do jego potrzeb, to zapewne przy pierwszych napotkanych trudnościach w użytkowaniu dostarczonych programów przyjmie obiegową opinię za swoją. Własne niepowodzenia wytłumaczy w ten właśnie sposób i dołączy do grona wątpiących. Jeśli jednak przed zetknięciem się z systemem usłyszy o nim pozytywne opinie, wówczas pierwsze niepowodzenia raczej sceduje na barki swoich nieumiejętności i krótkiej pracy z systemem. Będzie zainteresowany doszkoleniem się, gdyż skoro system jest dobry, to jego obecne kłopoty wynikają raczej z braku odpowiedniej wiedzy i doświadczeń niż ze słabości produktu. Te proste zachowania występują w różnych odmianach przy każdym wdrożeniu.

Warto sobie uzmysłowić, że wdrażanie i uruchamianie produktu to proces jego sprzedaży, a także proces zabiegania o przychylność i względy klienta. Każdy chce uczestniczyć w projektach, które kończą się sukcesem, a ten przecież przychodzi dopiero z chwilą, kiedy postanowienia zawartego kontraktu zostaną wypełnione. Podpisanie umowy to tak naprawdę początek drogi. Jeśli więc mamy wątpliwość, czy wysyłać pracownika na drugi koniec Polski, tylko dlatego że pewien rozhisteryzowany użytkownik twierdzi, iż nasz system i usługi są do niczego, to zaciśnijmy zęby i przypomnijmy sobie zasadę, że nasz klient to nasz pan.

Praca non stop

Specyficzną grupą wdrożeń są uruchomienia produktów, które startują w trybie "wszystko albo nic". Uruchomienie wszystkich funkcji systemu od razu to cecha przede wszystkim systemów pracujących w trybie on-line oraz produktów, których termin uruchomienia jest nieprzekraczalny. Z sytuacją taką mamy najczęściej do czynienia, gdy w życie wchodzą nowe przepisy prawa (wprowadzenie podatku od towarów i usług, denominacja, czy choćby ostatnie wymogi rozliczania się ze składek na ubezpieczenia społeczne). Uruchamianie tego typu produktów to niejednokrotnie praca 24 godziny na dobę. Zespół wdrożeniowy to sztab antykryzysowy. Sytuację znacznie lepiej oddają pojęcia zaczerpnięte ze sztabów dowodzenia armii niż z inżynierii oprogramowania. Zarządzanie zamienia się w dowodzenie. Praca nad produktem staje się walką z czasem. Normowany czas pracy jest zastąpiony powszechną mobilizacją. Technika i wiedza znaczą niejednokrotnie mniej niż spryt i intuicja. W decydującym momencie logistyka i wsparcie przestają odgrywać rolę - trzeba liczyć wyłącznie na siebie. Szkolenie i rozwój zawodowy ustępują miejsca bezwzględnej eksploatacji zdobytych wcześniej umiejętności i posiadanej wiedzy. Bezpowrotnie zniweczone zasoby to nie strata, a jedynie koszt zwycięstwa. Nieuchronność nadciągającego terminu niesamowicie wyostrzają kryteria oceny oraz wyprowadzają na pierwszy plan zarządzanie poprzez analizę ryzyka. Priorytet zyskują działania zmierzające do zapobiegania nadciągającej katastrofie. Od razu widać, co jest ważne, a co pozostaje tylko nic nie znaczącym tłem. W naturalny sposób przebiega selekcja czyichś "widzi mi się"od rzeczowych i użytecznych pomysłów.

Pozostaje tylko zastanowić się, dlaczego tak rzadko i sporadycznie wprowadzamy do zwykłych projektów tak skuteczne i niezwykle rozsądne zarządzanie poprzez analizę ryzyka.

<hr>

Włodzimierz Serwiński jest pracownikiem Prokom Software SA, kierownikiem projektu Oprogramowanie KSI ZUS.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200