Dziś na warsztat bierzemy wodotryski i spróbujemy znaleźć przyczyny, dla których w tworzonych przez nas rozwiązaniach czasami pojawiają się rzeczy zupełnie zbędne.
Czym są wodotryski?
Wpisuję dane na formularzu, klikam przycisk „Zapisz”. Zamiast napisu „Zapisz” pojawia się animowane kółko, a sam przycisk zmienia kolor. Cały formularz staje się przyciemniony. Rozbłyska na chwilę w momencie, gdy dane zostają zapisane, a na ekran wyjeżdża półprzezroczysty komunikat „Zapisano dane”, który po kilku sekundach znika. Wraca napis „Zapisz” na przycisku, który z kolei staje się nieaktywny do czasu wprowadzenia jakichkolwiek zmian w formularzu.
„Wodotryski – żargonowe określenie zbytecznych cech programu komputerowego, dodawanych jedynie dla zaspokojenia ambicji autora, ale w zasadzie mało użytecznych z punktu widzenia podstawowych zadań programu.” – Wikipedia
Czy jest jakakolwiek korzyść dla użytkownika z takiego dopieszczenia zwykłego formularza? Warunkiem koniecznym zadowolenia odbiorcy jest uczynienie jego pracy prostszą i łatwiejszą. Jeśli nie udaje nam się osiągnąć tego celu, żadne wodotryski nie pomogą w pozytywnym odbiorze naszego rozwiązania. Gdy zaś wspiera ono czyjąś pracę w znacznym stopniu, atrakcyjność wizualna schodzi na drugi plan.
Co nie znaczy, że powinniśmy tworzyć rozwiązania brzydkie albo nieatrakcyjne. Pamiętajmy jednak, że zwykle nie dostajemy od nikogo punktów za rzeczy nieistotne. Tu też warto dodać, że „efekt wow” w aplikacjach kierowanych do masowego odbiorcy jest jak najbardziej istotny. Intuicyjność aplikacji na komórki czy wizualna atrakcyjność gier komputerowych to nie wodotrysk, ale „podstawowe zadanie programu”.
Skąd biorą się wodotryski?
Każdy pasjonat, zajmując się czymś, co go fascynuje, będzie chciał to zrobić dobrze. I nie ma w tym nic złego, jeśli daną rzecz robi dla siebie. Jeżeli jednak robimy coś dla kogoś, to musimy przyjąć punkt widzenia odbiorcy. Być może wymiana akumulatora w motocyklu na żelowy jest ogólnie świetnym pomysłem, ale nie w sytuacji, w której celem jest po prostu przegląd gwarancyjny.
Pół biedy, jeżeli wodotryski, które otrzymujemy są dla nas przezroczyste czasowo lub kosztowo. Jeśli architektura rozwiązania jest rozsądna, być może oprogramowanie opisanego we wstępie formularza zamknęłoby się w kilku słowach dodanych do parametrów paru funkcji.
Są jednak takie sytuacje, w których zbędne cechy forsowanego przez nas rozwiązania powodują dodatkowe koszty lub problemy. Wodotryski nieuchronnie też będą wyceniane przez nas o wiele wyżej niż gdyby ich wartość miał oszacować klient.
Wspominaliśmy o pokrewnym fenomenie przy okazji naszego pierwszego filmu o błędach poznawczych, czyli Ikea Effect. W skrócie: jeżeli włożyliśmy w jakąś rzecz naszą pracę, jakakolwiek by ona nie była, to będziemy uważali, że jest ona więcej warta niż ktoś, kto nie przyłożył do niej ręki. I trudno się temu dziwić.
Podobnie oczywiste jest, że największe niezrozumienie zawsze będą powodowały wodotryski techniczne. Fakt zoptymalizowania struktur w bazie danych i wielokrotnego przyspieszenia działania naszej aplikacji lub perfekcyjne zabezpieczenie backendu przed spływającymi do niego błędnymi danymi nikogo nie zachwyci. Nawet, jeśli dla twórcy jest to coś, z czego jest dumny.
Z czego więc się cieszyć?
Nie możemy oczekiwać, że ktoś podziękuje nam za pracę, o której nie wie albo za efekty, których nie dostrzegł. Chociaż nie wiadomo jak byśmy się napracowali nad naszymi algorytmami, optymalizacją, sprytnym wykorzystaniem bibliotek, to dla statystycznego odbiorcy naszej aplikacji w ogóle nie będzie to miało znaczenia.
Wodotryski wizualne, ciekawe wykorzystanie komponentów czy atrakcyjność oprawy naszej aplikacji zwykle nie zasłuży w oczach naszego klienta na więcej niż „fajnie to wygląda, ale…”
Oprawa to czynnik higieny – jeżeli nasze rozwiązanie jest paskudne, to każdy będzie na to narzekał. Jeżeli jednak przekroczymy poziom, w którym już nie można powiedzieć, że jest brzydkie, to dalsze jego upiększanie nie spowoduje dodatkowych pochwał. Skoro klienta nie rozprasza już grafika, to skupi się na funkcjonalnościach.
Celem dla użytkownika nigdy nie będzie to, co jest atrakcyjne dla programisty. Musimy być świadomi tego, że klient będzie cieszył się z intuicyjnego, działającego oprogramowania, pozwalającego mu na realizowanie jego potrzeb biznesowych. Programista budując setny interfejs metodą kopiuj-wklej ani nie będzie czuł, że się rozwija, ani nie będzie mu to sprawiało satysfakcji. Nawet jeśli to jest dokładnie to, co „zmaksymalizuje wartość biznesową„.
Trudno oczekiwać, żebyśmy byli w stanie całkowicie wejść w skórę drugiej osoby. Użytkownik nie zrozumie programisty, bo widzi tylko efekt końcowy. Programista więcej czasu spędza dewelopując, niż używając stworzonej przez siebie funkcjonalności. Ani jeden, ani drugi nie czuje, które aspekty są upierdliwe dla „obcego” procesu.
I tak, użytkownicy chcą „nudnych”, znajomych, ale działających funkcjonalności, a programiści chcą „wydziwiać” w imię własnego rozwoju i dążenia do doskonałości. Mało który deweloper będzie zadowolony widząc, że jego dzieło jest „tylko” użyteczne. Potrzeba tu czegoś więcej, niż mechanicznego „klepania kodu”.
Jak pogodzić wodotryski i funkcjonalności?
Pomiędzy twórcami i odbiorcami często tworzone są sztuczne bariery. Czasami jest to „warstwa” analityków, która odsuwa użytkowników jeszcze dalej od programistów. Zdarza się też, że Product Owner staje po którejś ze stron i zabija kreatywność zespołu dając szczegółowe wytyczne bądź faworyzuje pewne rozwiązania techniczne kosztem użyteczności.
Agile manifesto wyraźnie mówi: „Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.” Pamiętajmy też, że oddawanie do testów nie wystarczy i miejmy na uwadze cel zwinności, czyli zadowolenie klienta.
Zbierając to wszystko razem mamy nadzieję zbudować zespół, który będzie w stanie zadbać o oczekiwania klienta i nie zagubić się w tworzeniu wodotrysków. Nikt nie mówi, że w pracy mamy się nie rozwijać. Ale nie powinno się to odbywać kosztem naszych klientów.
Aby sobie pomóc pamiętajmy, żeby zbierać wymagania, a nie sposób ich realizacji. Ba! Zamiast wymagań, zbierajmy problemy. Niech zespół we współpracy z klientem wypracuje potencjalne rozwiązania, które trafią do realizacji. Tam z kolei, niech nasz Inkrement zostanie zbudowany kreatywnie i w sposób zapewniający twórcom samorealizację.
Na każdym etapie tego procesu zapewnijmy odpowiedni poziom szczegółowości, korzystając np. z User Stories. Niech będzie on na tyle precyzyjny, aby zaspokoić potrzeby, ale niech pozwoli też rozwinąć skrzydła zespołom i pokazać, co potrafią. Nie w kontekście bezużytecznych wodotrysków, ale w kreatywnym spełnianiu dobrze odczytanych oczekiwań użytkowników.
Pracując dla kogoś nie musimy wcale pozbywać się naszych ambicji. Powinniśmy jednak wybierać te, które najlepiej służą potrzebom zamawiającego. Nie zawsze dostaniemy tę informację. Czasami musimy to odkryć sami, a czasami musimy przekonać odbiorcę, że to jest dla niego najbardziej korzystne rozwiązanie.
Wtedy wodotrysk przestaje być wodotryskiem, a staje się wymaganiem. A wówczas, miejmy nadzieję, wszyscy będą zadowoleni.
