Zacznijmy od tego, czym jest wartość. Na stronach Encyklopedii Zarządzania możemy znaleźć zapis mówiący, że wartość „to jedna z podstawowych kategorii aksjologii (nauki o wartościach), która określa wszystko, co jest pożądane, godne i cenne dla jednostki; to co stanowi cel dążeń ludzkich”. Jak tę definicję przełożyć na biznes? O ile nie prowadzimy działalności non profit, wartością biznesową będzie coś, co finalnie można przełożyć na pieniądze (przychody i koszty). Czyli co konkretnie? Dla jednych będzie to wysoka jakość oferowanego produktu, zaspokojenie potrzeb użytkowników końcowych, wysoki poziom user experience, a dla drugich np. unikalność świadczonych usług lub oferowanych produktów, ich innowacyjność czy nieskazitelna reputacja firmy. Inni za wartość biznesową uznają jedynie obniżenie kosztów i odpowiednio wysoki, liczony w złotówkach, zwrot z inwestycji.
Skąd mamy zatem wiedzieć, co jest wartością dla naszych klientów? (Dla uproszczenia klientem będziemy nazywać użytkownika końcowego rozwiązania, bez rozróżniania, czy jest to klient wewnętrzny czy zewnętrzny). Odpowiedź jest prosta: musimy z nimi rozmawiać! Wiemy, do kogo nasz produkt jest kierowany, kto jest jego odbiorcą. Na ogół staramy się również wiedzieć, co jest dla klienta ważne i użyteczne. Wartość biznesowa powinna nam wskazywać, po co nasz produkt istnieje, dlaczego jest używany.
Kiedy powstaje wartość?
Nie, nie w chwili zakończenia implementacji. Co z tego, że powiemy klientowi, że funkcjonalność X czy Y jest już gotowa? Z jego punktu widzenia nadal nic się nie zmieniło. Ale kiedy nastąpi wydanie produktu, klient dostanie do dyspozycji nową wersję oprogramowania, uzupełnioną o dodatkowe funkcje – to wtedy mamy do czynienia ze zgoła odmienną sytuacją. Od tego momentu klient już może używać wspomnianych X czy Y, może czerpać z tego korzyści.
Warto w tym miejscu zaznaczyć, że wydanie produktu nie musi nieść ze sobą jedynie wartości dodanej – może również wytworzyć negatywną. W jaki sposób? Na przykład pod postacią wprowadzonych do oprogramowania błędów lub spadku wydajności, które utrudniają klientowi wykonywanie codziennych zadań lub ograniczają jego zaufanie do narzędzia (np. błędy w algorytmach wyliczeniowych). Wartość negatywna dużo silniej oddziałuje na ludzi, w niektórych przypadkach może prowadzić wręcz do bardzo szybkiej utraty klienta. Dlatego tak ważne jest dokładne weryfikowanie produktu, zanim zostanie przekazany w ręce docelowego odbiorcy.
Innym ważnym punktem jest tzw. moment aha! Czyli jest to chwila, w której użytkownik poczuł, że produkt coś mu dał, że dzięki niemu udało mu się rozwiązać jakiś problem, zrealizować zadanie. Dał mu wartość. Myślę, że moment aha! możemy odnosić nie tylko do rozwiązania jako całości, ale – w przypadku produktów złożonych – również do pojedynczych funkcjonalności.
Pętla feedbacku
Trzeba bardzo uważać, aby rozwijając produkt nie wpaść we – wspomnianą w tytule – pułapkę ficzerów. Trzeba nieustannie mieć w tyle głowy, że nie wszystko, co wymyślimy, nie wszystkie funkcjonalności mogą mieć dla klienta jakąkolwiek wartość. Musimy więc każdy nasz pomysł rozbudowy produktu konsultować z jego odbiorcami, musimy weryfikować, czy wprowadzane zmiany są dobrze przyjmowane. Czasami może się okazać, że dla klienta ważniejsze (a co za tym idzie – dużo bardziej wartościowe) niż nowa, ogromna, innowacyjna funkcjonalność będzie usunięcie jednego kliknięcia w procesie, który jest codziennie wykonywany w systemie przez wielu pracowników, albo wprowadzenie autouzupełniania wartością domyślną jakiegoś pola. Tak więc niejednokrotnie drobna rzecz może być dla klienta ważniejsza niż wielka i „wypasiona” funkcjonalność.
Rozwój produktu to stałe zbieranie danych, korzystanie z eksperymentów i hipotez, które powinny być jak najszybciej weryfikowane na rynku. Informacje zwrotne gromadzimy przez cały okres życia produktu, a w zależności od etapu, na którym się on znajduje – z użyciem różnych metod, narzędzi czy grup docelowych. Cele prowadzenia badań również zmieniają się w czasie. Tzw. pętla feedbacku składa się z definiowania celów, zbierania feedbacku, porządkowania informacji, podejmowania działań – i tak w kółko.
EBM
Warto mierzyć produkt. Na różne sposoby, w różnych ujęciach. Ostatnimi czasy coraz większą popularność zyskuje Evidence Based Management (EBM), czyli zarządzanie oparte na dowodach, na faktach. Jak możemy przeczytać na scrum.org – EBM ma pomóc organizacjom „mierzyć, zarządzać i zwiększać wartość, jaką czerpią z dostarczania produktów. EBM koncentruje się na poprawie wyników, zmniejszeniu ryzyka i optymalizacji inwestycji”. Chodzi o to, żeby ustalenia opierać na bazie jak najlepszej jakości obiektywnych danych, a nie „widzimisię” kadry zarządzającej. Zbieranie danych, śledzenie metryk i uwzględnianie ich przy podejmowaniu decyzji pomaga również w maksymalizowaniu wartości biznesowej, poprawia zdolność jej dostarczania. Pokazuje, w którym miejscu się znajdujemy i dokąd chcemy dojść. Metryki mogą pomóc weryfikować poprawność stawianych hipotez biznesowych.
Co można mierzyć? Niemal wszystko. Przychód per pracownik, satysfakcję pracownika, satysfakcję klienta, częstotliwość wydawania wersji, czas obsługi zgłoszeń, czas dostarczenia nowych funkcjonalności, współczynnik innowacji, poziom długu technicznego, koszt utraconych korzyści w czasie – i wiele innych rzeczy. EBM grupuje te metryki w cztery kluczowe obszary: wartość obecna, czas dostarczenia produktu na rynek, zdolność do innowacji, wartość niezrealizowana. Drugi klucz podziału to wskaźniki wiodące i opóźnione. Możemy sterować tymi pierwszymi, aby zobaczyć efekt na tych drugich.
Przy określaniu, co chcemy mierzyć, ważne jest, aby wystrzegać się tzw. metryk próżności. Zaliczamy do nich np. liczbę odsłon strony (nie każdy, kto wyświetlił stronę sklepu – coś kupił) czy pobrań aplikacji (nie każdy, kto pobrał – korzysta).
Model Kano
Kiedy dobrze rozpoznaliśmy potrzeby i oczekiwania odbiorców naszego produktu, przy projektowaniu nowych rozwiązań możemy posłużyć się modelem satysfakcji klienta, opracowanym w latach 80. XX wieku przez Japończyka, prof. Noriakiego Kano. Jest to podział wymagań ze względu na zadowolenie użytkowników produktu. Na wykresie mamy podane dwa wymiary: satysfakcję klienta (oś y) i jego potrzeby (oś x) oraz trzy krzywe, obrazujące grupy wymagań i potrzeb interesariuszy:
- podstawowe – są to funkcjonalności, bez których produkt nie ma dla odbiorcy racji bytu, to jest „absolutny must have” aplikacji, czyli coś, czego obecność jest konieczna i oczywista, nie powoduje u klienta dodatkowych pozytywnych emocji, ale czego brak jest dotkliwie odczuwany i powoduje niezadowolenie;
- wydajnościowe – są to funkcje, co do których klienci nie mają pewności, czy system może je posiadać; ich obecność w oferowanym rozwiązaniu wzbudza zadowolenie użytkowników, podnosi liniowo ich satysfakcję, ale brak funkcjonalności z tej kategorii nie powoduje, że produkt staje się bezużyteczny;
- ekscytujące – są to to elementy produktu, które wzbudzają zachwyt, przyciągają uwagę, powodują efekt wow! – można je śmiało nazwać czynnikami przewagi konkurencyjnej, bo pozwalają wyróżnić się na rynku; często klienci nawet nie wiedzą, że mogą taką funkcjonalność otrzymać, więc ich poziom zadowolenia mocno rośnie.
Istnieją również takie elementy produktu, które są dla klientów całkowicie obojętne – ich obecność nie zwiększa poczucia satysfakcji, a ich brak nie zostałby nawet zauważony. Zdecydowanie nie warto ich rozwijać, bo stanowią jedynie koszt.
Trzeba pamiętać, że wartość funkcjonalności w czasie ulega deprecjacji – to, co kiedyś było „wow” z czasem staje się funkcją wydajności, by po kolejnym okresie uplasować się na linii wymagań podstawowych. Na przykład ok. dwadzieścia lat temu oferowane przez sieci komórkowe naliczanie sekundowe w rozmowach telefonicznych było ewenementem na rynku, a dziś nikt się nawet nad tym nie zastanawia, jest to oczywistość. Innym przykładem może być podłączanie nowej drukarki do komputera – kiedyś płyty ze sterownikami i żmudna instalacja, dziś wystarczy dostęp Internetu i magia dzieje się sama. Jak szybko następują tego typu zmiany w wymaganiach? To zależy przede wszystkim od branży, tempa jej rozwoju i innowacyjności oraz długości życia produktów. W IT zmiany te są bardzo łatwo zauważalne.
Na koniec
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).
