Zarówno zgłoszenia błędów, jak i prośby o nowe funkcjonalności wskazują na braki w produkcie – sygnalizują, że coś faktycznie utrudnia użytkownikowi osiągnięcie sukcesu. Oba rodzaje zgłoszeń wymagają analizy, ustalenia priorytetów, implementacji oraz testowania. Ostatecznie, każdy z tych procesów wiąże się z określonym kosztem. Jak powiedziała pewna staroświecka kierowniczka projektu, z którą miałem okazję pracować około dwóch dekad temu: „Główna różnica polega na tym, kto za to płaci. Klienci płacą za nowe funkcjonalności, ale za błędy płacimy my.” Następnie dodała: „Dlatego upewnij się, że wszystko, co tylko możliwe, zostanie zakwalifikowane jako prośba o funkcjonalność.”
Nie muszę dodawać, że prowadziło to czasem do niezręcznych rozmów.
Dwie dekady później myślę, że znalazłem brakujący element tej układanki – dzięki znakomitej książce Mismatch autorstwa Kat Holmes. Rozjaśniła mi ona nie tylko kwestie związane z błędami i funkcjonalnościami, ale także pomogła lepiej zrozumieć, co sprawia, że dane rozwiązanie programowe rzeczywiście odpowiada na potrzeby użytkowników.
Holmes wprowadza koncepcję spektrum osobowości, pokazując, że osoby o różnych możliwościach mogą mieć podobne potrzeby i wpisywać się w tę samą personę użytkownika. Na przykład, jeśli weźmiemy pod uwagę zdolności wzrokowe, istnieje szeroki zakres potencjalnych ograniczeń: od całkowitej lub częściowej ślepoty, przez słaby wzrok związany z wiekiem czy schorzeniami, aż po daltonizm. Są jednak również osoby z pełną sprawnością wzroku, które mimo to mogą mieć trudności podczas korzystania z produktu – na przykład pracując w słabo oświetlonym pomieszczeniu lub w silnym świetle słonecznym na plaży. Specjalne rozwiązania projektowe, takie jak zwiększenie kontrastu wizualnego, mogą znacząco poprawić ich doświadczenie. Kluczowe jest określenie, jaką część tego spektrum chcemy wspierać, by uniknąć rozczarowań i niespełnionych oczekiwań.
I właśnie w tym tkwi brakujący element układanki – oczekiwania. Ale czyje oczekiwania? Różne osoby mają różne potrzeby i wymagania. Aby uprościć temat, skupmy się na dwóch perspektywach:
- Czy produkt spełnia oczekiwania osób, które go tworzą (interesariuszy, deweloperów, menedżerów produktu, testerów)?
- Czy spełnia oczekiwania użytkowników?
Wiem, że niektórzy mogą uznać to za zbytnie uproszczenie. W praktyce różne grupy osób zaangażowanych w rozwój produktu – interesariusze, programiści, testerzy i menedżerowie produktu – rzadko mają dokładnie takie same oczekiwania. Istnieją jednak metody i narzędzia, które pozwalają radzić sobie z tymi rozbieżnościami. Na potrzeby tej analizy skupmy się na grupie użytkowników, którzy mają podobne oczekiwania, gdzieś w ramach wspomnianego spektrum osobowości, oraz na zespole projektowym, który doszedł do względnej zgody co do wizji produktu.
Jeśli istnieją testy jednostkowe, testy akceptacyjne, testy użytkowników czy inne narzędzia do oceny przydatności, a funkcjonalność przechodzi je wszystkie, można uznać, że produkt spełnia oczekiwania obu grup. Z kolei sytuacja, w której produkt zawodzi z obu perspektyw, nie pozostawia wątpliwości – mamy do czynienia z błędem.
A co z pozostałymi dwoma ćwiartkami? To właśnie tam często można znaleźć manipulacje cenowe związane z prośbami o funkcjonalności.
Jeśli funkcjonalność działa zgodnie z oczekiwaniami twórców produktu, ale nie spełnia oczekiwań użytkowników, błędy są często opisywane jako wynik „braku odpowiednich umiejętności technicznych” użytkownika lub w mniej uprzejmy sposób – z insynuacjami dotyczącymi ich inteligencji. Inspirując się Kat Holmes, można to jednak rozumieć jako brak dopasowania między projektem a możliwościami użytkownika. Takie podejście eliminuje konieczność rozważania, czy projekt jest zbyt skomplikowany, czy użytkownik zbyt mało bystry. Mamy do czynienia z niedopasowaniem (Mismatch), które wymaga uwagi. Jeśli jedyną osobą, która potrafi zrozumieć interfejs użytkownika, jest Data z Star Treka, rynek dla takiego produktu nie będzie zbyt duży.
Z kolei jeśli funkcjonalność spełnia oczekiwania użytkownika, ale nie zgadza się z zamierzeniami twórców, może dojść do sytuacji, w której użytkownik zamawia „darmowe hamburgery” w terminalu sprzedaży i uzyskuje nieplanowane rabaty. W tej sytuacji użytkownik nie jest „zbyt głupi” – wręcz przeciwnie, okazuje się zbyt sprytny. W istocie mamy do czynienia z nadużyciem (Exploit).
Zamiast patrzeć tylko przez pryzmat tego, co jest dobre, a co złe, mamy tu cztery kategorie: błędy (Bugs), niezamierzone użycie (Exploit), funkcjonalności akceptowalne (Acceptable) i niedopasowane (Mismatch). Oczywiście, jako konsultant mogę teraz twierdzić, że stworzyłem nowy model nazwany od pierwszych liter: BEAM.
Żarty na bok, powodem, dla którego uważam, że jest to dobry sposób myślenia o problemach, jest to, że określanie wszystkiego jako błędu po prostu mówi nam, że coś zepsuliśmy. To trochę depresyjne. Ale niezamierzone użycia i niedopasowania są ukrytymi możliwościami produktu. To bardzo optymistyczne.
Odnalezienie użytkownika z niedopasowaniem zazwyczaj oznacza, że definicje naszych person użytkowników są zbyt wąskie. Rozszerzając je, możemy znacząco zwiększyć atrakcyjność naszego produktu dla szerszego grona odbiorców. Ci dodatkowi użytkownicy na spektrum mają podobne motywacje i potrzeby co pierwotna persona, a także prawdopodobnie oczekują niemal tych samych funkcjonalności produktu. Jednak niedopasowanie uniemożliwia im pełne korzystanie z naszego rozwiązania. W większości przypadków duża część pracy niezbędnej, aby zadowolić tych użytkowników, jest już wykonana. Musimy jedynie zająć się tymi niedopasowaniami.
Odnalezienie użytkownika, który niezamierzenie wykorzystuje nasz produkt, wskazuje, że ktoś czerpie z niego nieoczekiwaną wartość lub korzysta w sposób, którego nie przewidzieliśmy. Pewna część takich osób może działać w złej wierze i wymaga blokady, ale inni po prostu znaleźli sposób na użycie naszego produktu w nieprzewidziany przez nas sposób. Jeśli ktoś jest skłonny do podejmowania dodatkowych działań, by używać produktu w mniej optymalny sposób, mamy szansę lepiej zaspokoić jego rzeczywiste potrzeby.
Holmes w swojej książce zwraca uwagę, że naprawianie problemów dla pojedynczych użytkowników z niedopasowaniami nie jest ekonomicznie opłacalne. Zamiast tego sugeruje, by rozwiązywać problem jednej osoby, ale z myślą o szerszym gronie. Odkrycie niedopasowania (Mismatch) lub niezamierzonego wykorzystania (Exploit) to świetna okazja, by ulepszyć nasze produkty dla wszystkich użytkowników.
Gojko Adzic
Autor przełomowych narzędzi jak "Specification by Example" i "Impact Mapping", które zrewolucjonizowały podejście do testowania i planowania pracy. Jako uznany trener i konsultant, Gojko specjalizuje się w praktycznym zastosowaniu metod Agile i Lean, pomagając zespołom programistycznym osiągać lepsze wyniki.
