Trzeba też się nauczyć obu typów postrzegania świata – własnego i użytkownika. Często bowiem dochodzi do braku właściwej komunikacji wynikającej z różnego rozumienia terminów. Dla księgowych czym innym jest na przykład zamknięcie roku (wyksięgowanie przychodów i kosztów na wynik finansowy), a czym innym dla informatyka – zamknięcie okresu w programie.
Otwarte słowniki
Dla użytkownika pierwszym trudnym zadaniem jest zrozumienie, że funkcjonowanie oprogramowania w jego firmie nie zależy tylko od najnowszej wersji samego programu, ale także (a może nawet przede wszystkim) od wyartykułowania przez niego potrzeb i prób spełnienia ich poprzez poprawne wdrożenie. Niektóre z systemów zbudowane są na zasadzie otwartych słowników danych do tabel używanych w konkretnym module. Dzięki zbudowaniu właściwych składników systemu, np. kadry–płace można osiągnąć cel – zgodnie z zasadami wyrażonymi przez osobę odpowiedzialną w dziale płac. Sposób obliczania każdego składnika będzie taki, jaki wdrożeniowiec i pani z rachuby uznają za poprawny.
Przy zmianach przepisów (dość częstych w Polsce) niezbędna jest modyfikacja – czasem rozbudowa – istniejącego słownika składników kadrowo-płacowych, a przede wszystkim aktualizacja algorytmów obliczeniowych dotyczących sposobu naliczania danych na liście płac. Często dostawca oprogramowania słyszy od księgowych: „za co ja płacę; przecież mam aktualną wersję programu, a program (tego i tego) sam nie liczy” – co jest wynikiem następującego skrótu myślowego: mam program, więc wszystko powinno być w nim zaszyte.
Taki sposób postrzegania oprogramowania jest pewnie wynikiem doświadczeń z prostymi programami z minimalną możliwością konfiguracji systemu, a nie z oprogramowaniem otwartym, w którym oba elementy (program + poprawne wdrożenie) dają dopiero zadowolenie z użytkowania systemu.
Niespełnione oczekiwania
Podobny sposób rozumowania u niektórych użytkowników daje też efekt niespełnionych (ale niewyrażonych na początku) oczekiwań. Pewne założenia domyślne (mam program, więc powinien być: a) elastyczny i umożliwiać dowolne modyfikacje swojego funkcjonowania i b) jednocześnie od razu skuteczny w mechanizmach działania danej firmy). Trzeba podkreślić, że nie powinno być dwóch identycznych instalacji kadrowo-płacowych, gdyż różne są firmy, z innymi przyjętymi przez siebie regulaminami wynagradzania, z najróżniejszymi sposobami nazewnictwa składników płacowych, z innymi wcześniejszymi doświadczeniami, z najróżniejszymi sposobami rozumienia przepisów. Dla pewnych użytkowników w kwocie brutto powinno się zawierać wszystko, co podlega opodatkowaniu, dla innych w kwocie brutto nie powinny się sumować na przykład zasiłki ZUS. Takich przykładów jest mnóstwo.
W praktyce powinno się więc stosować metodę dociekania i znajdowania coraz bliższego do zadowalającego efektu sposobu funkcjonowania systemu. Polega to na stosowaniu metody kolejnych przybliżeń, aż wreszcie wszystkie możliwe przypadki i konfiguracje będą uwzględnione w algorytmach obliczeniowych. Czasem trudno jest od razu wszystko przewidzieć, więc dobrze jest sobie zostawić jakąś furtkę na modyfikację danej w awaryjnej sytuacji „z ręki”. Niemniej jednak i tu czasem może kryć się niebezpieczeństwo braku porozumienia z użytkownikiem (zobacz przykład).
PRZYKŁAD
Zdarzyło mi się niedawno usłyszeć zdanie od pani z rachuby: „proszę o dokonanie zmiany w sposobie obliczania składki zdrowotnej, aby była tylko do wysokości zaliczki na podatek”. Jak usłyszałem, tak zrobiłem. Dopiero dwa dni potem okazało się, że, owszem, ale tylko od umów o pracę, a nie od umów zlecenia. Tego pani już nie dopowiedziała, bo myślała, że sam na to wpadnę. Niestety, telepatycznych zdolności nie wykształciłem. Tak więc oprócz przełożenia życzeń użytkownika na sposób działania programu należy ustalić zasady wzajemnego komunikowania się o swoich oczekiwaniach.
Zrozumienie systemu
Często zdarza się, że do pracy w jakiejś firmie przychodzi osoba, która miała kontakt z innym oprogramowaniem. Dla takiego użytkownika największym zadaniem (trudnym) jest zrozumienie zasady działania systemu. A zasadą jest precyzyjne wyartykułowanie jakiejś funkcjonalności. Dla pewnych użytkowników niektóre funkcjonalności są „oczywistą oczywistością”, ale tylko na tej zasadzie, że w tamtym programie to było.
Wbrew obiegowym opiniom nie istnieje żaden standard. W każdej instalacji co innego jest potrzebne i konfigurowane. Po ustaleniu wspólnego języka dotyczącego detali jakiejś funkcjonalności (np. obliczanie podstawy do zasiłku chorobowego) przychodzi etap mozolnych prób. Dopiero po wyczerpaniu wszelkich możliwych przypadków (choroba osoby poniżej i powyżej 50. roku życia, część choroby na wynagrodzeniu będącym kosztem pracodawcy, część na zasiłki ZUS, cały miesiąc choroby itp.) i sprawdzeniu, że algorytmy obliczeniowe poprawnie reagują na dany przypadek. można uznać temat za rozwiązany.
W niektórych instytucjach (najczęściej w takich, które mają preliminarz kosztów) proces wdrożenia opiera się na pisemnych zleceniach, na które dopiero wdrożeniowcy reagują wizytą i jakimiś działaniami. Niestety, bardzo rzadko można spotkać klienta, który w dokładny i precyzyjny sposób wyłuszczy istotę problemu. Dlatego załatwienie sprawy, której opis jest na bardzo dużym poziomie ogólności, jest trudne. Jest trudne, bo nie są dokładnie zapisane wszelkie mechanizmy obliczania składników płacowych w powiązaniu z istniejącymi. Dla precyzyjnego opisania zasad obliczania np. dodatku stażowego w wypadku choroby należałoby napisać jakiś elaborat.
Dlatego praca oparta na zasadzie – „mam pisemne zamówienie – działam” sprawdza się jedynie przy bardzo prostych albo bardzo dokładnie opisanych poprawkach. Najlepszą metodą na dłuższą metę jest dogadywanie się z użytkownikiem – czasem dogadywanie się trwa dłużej niż sama robota. Niemniej jednak taki system pracy daje większą elastyczność przy dochodzeniu do satysfakcjonującego obie strony efektu.