Clients are not willing to changes

13 kwietnia 2023
Jakub Rojek Jakub Rojek
Photo by Jerry'ego Zhanga from Unsplash (https://unsplash.com/photos/w5sqN_etcIQ)
Kategorie: Współpraca, Dla klientów, Wdrożenia

Tak, wiem, że tytuł artykułu jest trochę clickbaitowy. Ale tylko trochę i sami zobaczycie, gdy przeczytacie do końca. Przed nami bowiem felieton o tym, że klienci też mają swoje nawyki, którym są wierni, nawet jeśli do końca nie zdają sobie z tego sprawy. Właśnie te przyzwyczajenia są często największą przeszkodą lub ograniczeniem przy wdrażaniu oprogramowania. W tym momencie wiele osób, które kiedyś zlecało lub zleca realizację aplikacji czy systemu IT może powiedzieć "ja taki(-a) nie jestem" i rzeczywiście - nie każdy jest taki sam. Ale każdy ma swoje upodobania, które w większym lub mniejszym stopniu wpływają na pracę wykonawcy.

Jeśli zapytacie doświadczonych kierowników, analityków lub projektantów, którzy pracowali przy wdrożeniach aplikacji dla dużych klientów o najtrudniejszą rzecz podczas tego procesu, to pewnie większość odpowie, że jest to zmierzenie się z przyzwyczajeniami użytkowników. Tak - tutaj nie chodzi do końca o samych zleceniodawców, jakimi są najczęściej osoby z kierownictwa wyższego lub średniego szczebla i którzy chcą rzeczywiście poprawić proces biznesowy w swojej firmie (a przy okazji poczuć się jak wizjonerzy i kapitan wspaniałego statku, bo to zawsze przyjemne uczucie). Oni są gotowi na innowacje, a nawet "palą się" do nich, optymistycznie wierząc, że system IT rozwiąże większość trapiących ich problemów. Natomiast w rolę pesymistów wcielają się pracownicy, którzy rzeczywiście będą używać oprogramowania - to oni często stają się barierą w takich wypadkach. Najczęściej wynika to z faktu, że:

  • są przyzwyczajeni do dotychczas używanych aplikacji lub ich sposobu działania, a nowy system każe nauczyć się wszystkiego od nowa,
  • uważają, że szefowie chcą zrobić niepotrzebną rewolucję i automatycznie stawiają się w roli "buntowników",
  • nie zostali uwzględnieni przy procesie projektowania i mają o to żal,
  • aplikacja znacznie wydłuża czas wykonywania pracy (co wynika albo z niewiedzy szefów o faktycznym funkcjonowaniu firmy, albo o złej analizie IT).

Zdecydowanie najważniejszym czynnikiem jest ten pierwszy - użytkownicy mają swoje nawyki, których trudno się pozbyć. Te przyzwyczajenia pozwalają im wykonywać pewne rzeczy niejako automatycznie, bez czytania treści opcji, klikając "na pamięć" i układając w głowie cały plan dalszego działania. I nawet, jeśli nowy system IT docelowo pozwoli im wykonywać tę pracę szybciej i sprawniej, to wysiłek włożony w nauczenie się nowego interfejsu lub nawet filozofii stosowania (np. nowych terminów, powiązań pomiędzy obiektami) będzie skutecznie zniechęcał do nowego tworu, który tym samym zostaje uznawany za "wroga". Zresztą, wszyscy to przeżywamy - jeśli przez 5 lat korzystaliśmy z jednego telefonu i kupujemy nowy, to mimo iż wiemy, że ma lepsze parametry oraz większe możliwości niż poprzedni, to przez jakiś czas pomstujemy na to, że musimy szukać poszczególnych opcji i korzystanie idzie wolniej niż poprzednio.

Zastanówmy się przez chwilę, jaki jest powód takiego nastawienia potencjalnych użytkowników, a także źródło innych problemów - jest nim często oczywiście nieufność wobec nieznanego, ale też szok. Zauważmy, że wdrażanie systemu do organizacji zwykle faktycznie oznacza rewolucję - firma nie będzie zamawiała oprogramowania, które tylko trochę poprawi pracę, bo szkoda na to pieniędzy. Dlatego nowa aplikacja zmienia bardzo dużo i siłą rzeczy reorganizuje również pewne elementy procesu, gdyż trudno uzyskać postęp stosując te same techniki co poprzednio (choć - oczywiście - wszystko zależy od sytuacji). Tego nie da się w pełni uniknąć i o ile w niektórych kwestiach powrót do "starej metody" może mieć sens, o tyle niektóre nowe funkcje zazwyczaj są kluczowe dla rozwoju, a to one są "odpowiedzialne za zamieszanie".

Natomiast to, co można bez wątpienia zrobić, to włączenie pracowników w projektowanie nowego rozwiązania i tutaj wrócę do pojęcia szoku. Wyobraźcie sobie, że żyjecie sobie w niewiedzy, korzystacie z Excela od kilku lat i nagle przychodzi szef, zaprasza Was na spotkanie, na którym dowiadujecie się, że niedługo zaczniecie korzystać z zupełnie nowej aplikacji, o której coś tam słyszeliście, ale nigdy nie traktowaliście tego na poważnie, ponieważ mówiło się o niej w kuluarach. Oczywiście, że w większości przypadków Waszą naturalną reakcją będzie obrona i szukanie dziur, zwłaszcza, że macie świadomość, że Wasz pracodawca da krótki czas na przyzwyczajenie się, ale praca i tak musi zostać wykonana. I tutaj można bardzo ładnie tym zarządzić i to na dwa sposoby.

Pierwszym z nich jest tworzenie projektu w oparciu o zwinność, ale to nie wystarczy - podział na etapy musi zakładać, że "rewolucji" stopniowo ulegają osobne, pomniejsze części całego procesu, które mogą być wprowadzane niezależnie. Przykładowo, jeśli firma posiada dział handlowy, projektowy, produkcyjny, kontroli jakości oraz kadrowy, a system ma obejmować całą działalność firmy, to może warto tak zaplanować prace, aby np. wdrożyć system tylko dla jednego działu i to nawet nie dla wszystkich jego zadań. W ten sposób firma będzie miała więcej czasu nie przyzwyczajenie się do nowego rozwiązania, informacja o powstającym oprogramowaniu będzie dystrybuowana wewnątrz metodą nieformalną (można zażartować, że to taki "marketing szeptany"), łatwiej też nad tym zapanować oraz dowiedzieć się, czy rzeczywiście aplikacja zmierza w dobrym kierunku. Być może na podstawie jednego działu okaże się, że pewne koncepcje są błędne dla całej organizacji i trzeba przeprojektować ten fragment. A zdecydowanie lepiej to robić na mniejszym systemie niż całym projekcie - jest to filozofia bliska podejściu MVP.

Drugim sposobem (który jak najbardziej może i powinien być łączony z pierwszym) jest włączenie pracowników w proces analizy i projektowania. Oczywiście, nie wszystkich naraz, gdyż nie może to zaburzać codziennej pracy organizacji. Natomiast z doświadczenia wiemy, że jeśli w rozmowach o powstających funkcjach uczestniczy ktoś, kto rzeczywiście potem będzie z tych funkcji korzystał, to odbiór wynikowego produktu będzie dużo lepszy (oczywiście, zakładając, że software house zrobi wszystko jak należy). Po pierwsze, kierownicy operują na trochę innym poziomie i nie zawsze są blisko małych, ale istotnych kwestii, które są obecne w codziennej pracy (a pracownicy nawet nie zdają sobie sprawy z tego, że to coś, o czym warto rozmawiać). Nierzadko widywaliśmy na spotkaniach, że po wypowiedzi pracowników szefowie przy nas wręcz dopytywali ich o pewne detale, będąc autentycznie zdziwieni. Po drugie, działa tutaj czynnik psychologiczny - pracownik uczestniczący w rozmowach zaczyna łagodniejszym okiem patrzeć na wykonawcę IT i sam projekt. Czuje się potrzebny, doceniony i może odpłacić do zaufaniem do nowego systemu IT. Co więcej, przy bardzo dobrych układach w organizacji może być kimś w rodzaju "ewangelisty" oprogramowania wśród innych pracowników. A to bardzo cenna waluta, która przyda się w procesie wdrażania. Warto też wspomnieć, że osoba uczestnicząca w ustaleniach, nawet jeśli tylko doradza, a nie decyduje, czuje się trochę odpowiedzialna za obrany kierunek.

Nie ukrywajmy też jednej rzeczy - kierownicy organizacji również muszą uspokoić swoich podwładnych i pomóc im przejść przez ten proces. Szczególnie dotyczy to szkoleń z obsługi nowego systemu, w którym uczestniczy pewna grupa pracowników (lub cała firma) i oczywiste jest, że ta będzie miała pytania, a nawet wątpliwości. Osoba szkoląca musi się z tym liczyć i przygotować. Natomiast problemem staje się sytuacja, w której użytkownicy zgodnie zaczynają pomstować na system, nie próbując nawet nabywać nowej wiedzy. Słyszałem o takich przypadkach np. podczas wprowadzania dzienników elektronicznych w szkołach. W tym momencie dużą rolę powinien odegrać szef pracowników, któremu powinno zależeć na uspokojeniu sytuacji i doprowadzeniu do prawidłowego przeszkolenia ludzi. Sam na szkoleniach, które przeprowadzałem dla firm, wspominałem o tym, że pytania są jak najbardziej mile widziane, ale wszelkie sugestie dotyczące działania systemu należy zostawić na koniec spotkania. Zwłaszcza, że pewne początkowo niezrozumiałe aspekty czasami naturalnie wyjaśniają się w trakcie dalszej prezentacji.

Podsumowując, wdrażanie nowych systemów IT do organizacji jest trudne i to nie tylko ze względów technicznych. Rzadko zdarza się, że wszyscy ochoczo przystępują do korzystania z nowego oprogramowania, szczególnie jeśli wcześniej korzystali z innego - częściej przypomina to podchodzenie do nowinki jak do jeża. Dlatego istotne jest odpowiednie kierowanie tym procesem już od początku, także na etapie analizy, aby powoli przyzwyczajać ludzi do nowej wizji i nie tworzyć dodatkowych podziałów na linii kierownicy-pracownicy. Można wręcz powiedzieć, że mamy tutaj do czynienia z oswajaniem przyszłych użytkowników. W tym procesie dużą rolę odgrywa także właśnie szefostwo, które nie powinno izolować swoich podwładnych od tego tematu, jeśli nie jest to absolutnie konieczne.

Pozdrawiam i dziękuję - Jakub Rojek.

Lubimy pisać, nawet bardzo, ale na co dzień tworzymy aplikacje webowe i mobilne. Sprawdź niektóre z wykonanych przez programów.

Komentarze

Wczytywanie komentarzy...

O autorze

Jakub Rojek

Główny programista i współwłaściciel Wilda Software, z wieloletnim doświadczeniem w tworzeniu i rozwoju oprogramowania, ale także w pisaniu tekstów na różnorakich blogach. Zaprawiony w boju analityk i architekt systemów IT. Jednocześnie absolwent Politechniki Poznańskiej i okazjonalny prowadzący zajęcia na tej uczelni. W wolnych chwilach oddaje się graniu w gry wideo (głównie w karcianki), czytaniu książek, oglądaniu futbolu amerykańskiego i e-sportu, odkrywaniu cięższej muzyki oraz wytykaniu innym błędów językowych.

Jakub Rojek