Projekty i produkty
W świecie IT systemy informatyczne dzielimy na dwie kategorie: projekty i produkty. Te pierwsze to dedykowane rozwiązania dla konkretnego klienta, dostosowane w stu procentach do jego potrzeb i wymagań oraz w pełni przez niego finansowo utrzymywane. Z kolei z produktów na ogół korzysta wielu nabywców – jest to opcja tańsza, gdyż koszty maintenance’u aplikacji nie spoczywają na barkach tylko jednego podmiotu, ale partycypują w nich wszyscy użytkownicy. Mankamentem produktów jest nieznacznie mniejsze dopasowanie do indywidualnych potrzeb każdego z odbiorców. Z punktu widzenia klienta jest to kompromis między użytecznością a kosztem.
Warto zauważyć, że my – analitycy, architekci czy programiści – nie projektujemy oprogramowania dla siebie ani nie powinna to być sztuka dla sztuki. Z systemu ma ktoś korzystać, używać go, więc musi być on dostosowany do potrzeb odbiorców, musi spełniać wymagania, usprawniać pracę lub zapewniać rozrywkę. Musi spełniać swoje zadanie. Mija się z celem rozwijanie czegoś, czego nikt nie używa. To trochę jak z pisaniem wierszy do szuflady, tylko byłoby to hobby trochę droższe. A nie możemy dobrze rozwijać systemu, jeśli nie sprawdzimy go na rynku, bo dopiero rynek zweryfikuje naszą koncepcję, zastosowane rozwiązania, przydatność, opłacalność… Dopiero po wypuszczeniu aplikacji w świat dowiemy się tak naprawdę, czy ktoś w ogóle będzie chciał z tego naszego rozwiązania korzystać, czy będzie skłonny za nie zapłacić. Będziemy mogli zweryfikować nasze założenia w praktyce.
System rusza w świat
Oddanie systemu w ręce użytkowników wiąże się z tym, że możemy poznać ich opinię o naszym oprogramowaniu. Informacje zwrotne możemy podzielić na dwie kategorie: zgłoszenia problemów z działaniem aplikacji i pomysły na usprawnienie i rozwój systemu. Te pierwsze musimy usunąć i to jak najszybciej. Z drugimi może być większy problem…
Jeżeli klient korzysta z rozwiązania dedykowanego, nie ma powodów, żeby nie rozwijać go zgodnie z nawet ułańską fantazją tego, kto za to płaci. W przypadku produktów już tak łatwo nie jest – każda nowa funkcjonalność, najdrobniejsza zmiana musi być wprowadzana z myślą o wszystkich użytkownikach systemu. Za każdym razem musimy zważyć, czy nie zaszkodzi ona produktowi, co inni użytkownicy na to powiedzą, czy nie spowoduje odpływu klientów, jaki będziemy mieli z tego zysk, jakiemu procentowi naszych odbiorców się to przyda, czy jest zmiana jest spójna z wizją rozwoju rozwiązania itd.
Niejednokrotnie bowiem zdarza się, że z nowych opcji korzysta tylko część użytkowników, a pozostali uznają je np. za zbędny, a nawet przeszkadzający. Jak odnaleźć się w tym wszystkim, projektując rozwiązanie? Jak wpleść tutaj jedną z cenniejszych rzeczy, jakie możemy otrzymać od klienta, czyli jego feedback? Jak sprawić, żeby nowe ficzery nie były uciążliwe dla tych, którzy nie będą z nich korzystali? Przed takimi problemami stajemy za każdym razem, kiedy rozwijamy nasze systemy.
Coś poszło nie tak…
Ludzie często nie lubią zmian, bo naruszają ich poczucie bezpieczeństwa – również ma to zastosowanie w obcowaniu z technologią. Nawet drobna modyfikacja aplikacji może wywołać falę krytyki. Zapoznając się z opiniami użytkowników, nie możemy jednak zapominać o tym, że produkt musi ewoluować w czasie, czasem przejść (nie tylko wizualną) metamorfozę – tak jak zmienia się rzeczywistość wokół nas. Musi podążać za zmianami prawnymi, za nowymi trendami w layoutach, w UX itd. Musi reagować na zmieniające się potrzeby grupy docelowej – pewnie funkcje mogą przestać być potrzebne, inne z trzeciorzędnych awansują na najważniejsze.
Informacja zwrotna od odbiorców nie zawsze musi być pozytywna – i nie tylko dlatego, że zdarzają się błędy w działaniu oprogramowania. Czasami negatywny feedback wynika z niewiedzy użytkownika, z nieumiejętności posługiwania się systemem. Należy wówczas zadać sobie pytanie, co zrobić, żeby zmienić tę sytuację i jak uniknąć podobnych incydentów w przyszłości. Może nasza aplikacja jest za mało intuicyjna, może niezrozumiała, może brakuje podpowiedzi, tutoriali, instrukcji? Może przydałoby się demo, wprowadzenie? Może trzeba dodać sekcję z FAQ (najczęściej zadawane pytania), a może zorganizować szkolenie dla użytkowników lub udostępnić im możliwość zadawania pytań przez czat? A może mamy za wysoki próg wejścia i należy coś z tym zrobić?
Feedback od użytkowników produktów IT jest niezwykle ważny dla firm zajmujących się ich tworzeniem, dlatego trzeba umiejętnie na niego reagować i nim zarządzać. W pierwszej kolejności pozwala on na szybsze wykrywanie ewentualnych problemów z produktem. Informacja zwrotna pomaga nam również lepiej zrozumieć potrzeby i oczekiwania klientów i możliwie najlepiej dostosować produkt do realnych potrzeb rynku. Feedback od odbiorców rozwiązania może też być źródłem inspiracji do dalszego innowacyjnego rozwoju produktu, co może się przyczynić do zwiększenia jego konkurencyjności na rynku. Dlatego niezwykle ważne jest, aby umieć wypracować kompromis między rozwojem produktu a oczekiwaniami klientów.
Agnieszka Kukuła
Przygodę z analizą biznesową rozpoczęła ponad 10 lat temu, wspierając organizacje w procesie optymalizacji i wdrażania systemów informatycznych. Po kilku latach przeszła na drugą stronę mocy, by zasilić szeregi dostawców rozwiązań. Uczestniczyła w projektach dla podmiotów m.in. publicznych, z otoczenia biznesu, z branż FMCG, odlewniczej, smart city. Obecnie, w pełni pochłonięta tematyką ubezpieczeń, wspiera klientów VSoft.
Miłośniczka poprawnej polszczyzny. Ostatnio żywo zainteresowana tzw. prostym językiem (plain language).
