Dużo nie zawsze znaczy dobrze

Z A R Z Ą D Z A N I E F U N KC J O N A L N O Ś Ć R O Z W I Ą Z A Ń
Dużo nie zawsze
znaczy dobrze
Największym błędem projektantów jest myślenie,
że najlepszy i najbardziej dochodowy jest projekt
mający najwięcej funkcjonalności.
akie czynniki warunkują osiągnięcie sukcesu podczas tworzenia
portali internetowych i aplikacji?
Ważne są treści proponowane
użytkownikom czy ciekawa
grafika. Zasadniczą rolę odgrywają
funkcjonalności i wygoda użytkowania.
Funkcjonalności dopasowane do wymagań
użytkowników sprawiają, że chętnie korzystają z serwisu, wracają na naszą stronę
i pozostawiają dane. Na ten temat wydano
niezliczone ilości poradników i książek,
ale twórcy projektów IT wciąż nietrafnie
odgadują potrzeby odbiorców i proponują
rozwiązania, które często są dla nich odpychające. Powszechnym zjawiskiem podczas
realizacji projektów IT są ciągłe zmiany, dodawanie coraz to innych funkcjonalności.
Bez względu na to, czego dotyczy projekt,
obserwujemy tak absurdalne rozwiązania,
że trudno jest zrozumieć, co autor chciał
przez to powiedzieć.
Panuje moda na tworzenie własnych
katalogów firm i produktów. Wiele startupów jest wzorowanych na królach rynku,
tj. Allegro, Oferteo, Panoramie Firm czy na
Google. Właściciele tych projektów często
myślą, że jeśli połączą kilka intratnych
rozwiązań istniejących na rynku i dodadzą
multum nowych funkcjonalności, uda im
się odnieść sukces. Niestety, gdyby to było
tak proste, każdy z nas byłby milionerem.
Weźmy serwis, który poza katalogiem
firm i produktów oferuje także funkcjonalności „niezbędne” każdemu menedżerowi:
dodanie wizytówki własnej firmy, wyszukiwarkę kontaktów, możliwość zaproszenia
znajomych do swojego profilu, stworzenie
grupy dyskusyjnej, możliwość dodania
wydarzenia, kalendarz i wyszukiwarka
tychże wydarzeń, lista ogłoszeń i możliwość dodawania własnych, przeglądanie
blogów, założenie swojego. Możemy także
śledzić aktywność użytkowników, dyskusje, wydarzenia, oferty i blogi. Wszystko po
to, abyśmy mogli budować dobre otoczenie biznesowe i relacje z potencjalnymi
kontrahentami.
J
18
COMPUTERWORLD 6 września 2011
Dezorientacja i koszty
KAMILA
VESTERGAARD
Czy to wszystko jest przydatne dla użytkownika? Czy szukalibyśmy produktów,
np. artykułów biurowych, poprzez wyszukanie firm z danej branży, a następnie
sprawdzanie, czy mają w ofercie potrzebne
nam wyroby? A może wykorzystalibyśmy
inny sposób proponowany przez twórców
strony: wyszukalibyśmy wszystkie firmy
z naszej miejscowości i sprawdzali, która
sprzedaje artykuły biurowe? Użytkownik
szuka produktu, nie firmy! W tym przykładzie mamy funkcjonalności niezgodne
z wymaganiami odbiorców końcowych.
Widać, że wydawcy strony przyjęli za
motto zasadę: „Najlepszy, to znaczy mający
najwięcej funkcjonalności”. Nie oni jedni.
W tę pułapkę wpada wiele firm tworzących
portale internetowe. Skutki takiego działania mogą okazać się tragiczne.
Po pierwsze, zbyt duża liczba funkcjonalności dezorientuje użytkowników.
Mogą oni zniechęcić się do aplikacji i nie
będą z niej korzystać. Jeszcze gorzej, gdy
są one całkowicie oderwane od ogólnej
konwencji projektu, strony, aplikacji lub
– w najgorszym przypadku – gdy specjalnie
dla nowych funkcjonalności zmieniana
jest konwencja całego produktu. Jest to tak
zwany niekontrolowany cykl życia produk- Rys. 1:
Wykres Kano
tu, który ciągnie za sobą ogromne koszty.
Po drugie, wdrożenie każdej funkcjonalności trwa, a to powoduje koszty. Każda
funkcjonalność to dodatkowy koszt. Nie
mogąc oprzeć się chęci dodania nowej
opcji dla użytkowników, skazujemy się
na przekroczenie założonego terminu lub
budżetu. W przypadku start-upów może to
zakończyć działalność z powodu wyczerpania środków finansowych.
Analizą funkcjonalności powinni zajmować się specjaliści. Zwykle w firmach robią
to programiści, graficy, project managerowie – osoby, których sposób myślenia nie
jest zorientowany na potrzeby użytkowników. Bez przeprowadzenia badań pracownik opiera się na swojej opinii lub zgaduje,
jakie funkcjonalności powinny być wdrożone, a jakie można pominąć. Spotykam się
z sytuacjami, gdy w dużych firmach pracują specjaliści ds. funkcjonalności, a ich rola
ogranicza się do sporządzenia propozycji
funkcjonalności. Decyzje na temat wdrożeń
podejmuje osoba niekompetentna.
Zbyt duża liczba funkcjonalności dezorientuje użytkowników.
Również testowaniem nie mogą zajmować się członkowie zespołu odpowiedzialnego za projektowanie i wdrożenie.
Jest to najgorsze wyjście z sytuacji! Tacy
pracownicy dokładnie wiedzą, jak działają
poszczególne funkcjonalności i nigdy nie
będą w stanie wcielić się w użytkownika,
który pierwszy raz ma styczność z produktem – mamy całkowitą pewność, że
aplikacja będzie nieintuicyjna. Najlepszym
rozwiązaniem jest przeprowadzenie testów
z prawdziwymi odbiorcami produktu,
polegające na losowym wybraniu osób
reprezentujących grupę docelową.
Użyteczne metody
Jak wybrać funkcjonalności zgodne z potrzebami użytkowników i kluczowe dla
projektu? Jak rozwiązać problem zbędnych
funkcjonalności? Które funkcjonalności
wdrożyć najpierw? Możemy skorzystać
z kilku sprawdzonych metod priorytetyzowania funkcjonalności.
Metoda MPM
Metoda MPM (Multi-stage Picking-out Method) pozwala ograniczyć ilość funkcjonalności do liczby, którą można kontrolować.
Pracowników powinno podzielić się na
sześcioosobowe grupy, co ułatwia prowadzenie badań i wyciąganie wniosków.
Każda wypowiedź powinna być zanotowana na oddzielnej kartce. Nie powinno
się zezwalać na samodzielne spisanie
wymagań przez klienta, ponieważ grozi to
niekompletnymi danymi.