„Moja aplikacja nie będzie miała sensu, jeśli nie dodam jeszcze jednej funkcji” – brzmi znajomo? Jedna funkcja często wymaga stworzenia kilku następnych, wywołując efekt Diderota, czyli rozrastania się zakresu potrzeb. Jak to zjawisko wpływa na proces tworzenia aplikacji, jakie są jego konsekwencje i co możesz z tym zrobić – o tym wszystkim opowiadamy w artykule.
Czytaj dalej, aby dowiedzieć się:
- Czym jest efekt Diderota w przypadku tworzenia aplikacji.
- Jakie konsekwencje ma on dla Ciebie na etapie planowania jej zakresu oraz otrzymania oferty od wykonawcy?
- Dlaczego tak łatwo jest ulec pokusie dodawania kolejnych funkcjonalności?
- Mając świadomość tego zjawiska, co możesz zrobić?
Czym jest efekt Diderota w przypadku tworzenia aplikacji?
Efekt Diderota to w skrócie sytuacja, kiedy zakup jednego produktu pociąga za sobą potrzebę zakupu kolejnego. Nazwa pochodzi od nazwiska francuskiego filozofa, który opisał to zjawisko po tym, jak znalazł się w posiadaniu nowej, pięknej szaty. To skłoniło go do wymiany innych elementów swojej garderoby i wyposażenia domu, które… nie dorównywały estetyką nowemu ubraniu.
Na pewno znasz to z życia codziennego.
Zakupione przez nas produkty często pociągają za sobą potrzebę nabycia kolejnych. Jeśli kupujesz sprzęt sportowy, np. rower, zawsze będzie on w parze z towarzyszącym mu osprzętem, wyposażeniem i elementami garderoby (kask, rękawiczki, bidon, okulary sportowe). Często kolejnym zakupem będą narzędzia do konserwacji Twojego sprzętu lub elementy zapasowe, takie jak klucze, dętki, smary, pompka. Potrzebujesz teraz wydzielić miejsce na przechowywanie roweru oraz sprzętu. Ale same metry sześcienne rzadko wystarczą – będziesz potrzebować, aby zorganizować miejsce przechowywania swoich nabytków, takie jak szafki czy wieszaki.
No dobrze, ale jak to się ma do tworzenia oprogramowania?
W wielu miejscach tworzenie produktu, jakim jest aplikacja, działa na podobnej zasadzie: stworzenie jednej funkcji pociąga za sobą potrzebę stworzenia kolejnej.
Sprawdźmy to na konkretnym przykładzie, jakim jest rejestracja użytkowników w aplikacji mobilnej.
Sama możliwość rejestracji oznacza automatycznie potrzebę stworzenia następujących funkcji:
“must-have” (bez tego nie działać)
- sprawdzenie poprawności adresu e-mail oraz ustawienie hasła
- możliwość przywrócenia zapomnianego hasła
- możliwość usunięcia konta i danych (wymagane przez sklepy z aplikacjami), a więc zaprojektowanie miejsca w aplikacji przeznaczonego do tego działania, takiego jak ustawienia profilu
“should-have” (bez tego może nie działać poprawnie)
- możliwość zmiany hasła
- dwuetapowa weryfikacja (np. potwierdzenie założenia konta mailowo, wraz z linkiem aktywacyjnym)
- zarządzanie użytkownikami po stronie panelu admina, możliwość zawieszenia lub usunięcia konta przez admina
“could-have” (doświadczenie użytkownika znacznie się poprawi)
- dodawanie zdjęcia lub informacji o użytkowniku
- logowanie za pomocą konta na social media
- opcje ustawienia preferencji, np. możliwość ukrycia niektórych informacji przed innymi użytkownikami, możliwość wyboru języka interfejsu aplikacji, innego niż automatycznie przypisany itp.
Jakie konsekwencje ma to dla Ciebie na etapie 1) planowania aplikacji oraz 2) porównywania ofert od wykonawców?
1) Gdy planujesz aplikację
Więcej funkcji = dłuższy czas wykonania aplikacji, dodatkowe integracje, większe zasoby serwera = większe koszty.
Planując listę funkcji, ważne jest, aby mieć świadomość, że prawie każda funkcja po stronie zarejestrowanego użytkownika będzie musiała mieć odzwierciedlenie w panelu administratora. Czasem jest to kwestia lekkiej personalizacji, czasem wymagać to będzie wiele godzin programowania.
Zakupy w aplikacji, to nie tylko koszyk zakupowy i zapłata.
To również historia zakupów. Możliwość zwrotu. Możliwość zarządzania zakupem po stronie administratora. Tworzenie komunikatów o niedostępności produktu wcześniej dodanego do koszyka. Wybór sposobu doręczenia produktów, a więc integracje z firmami kurierskimi.
Ocena produktu, to nie tylko zostawienie gwiazdki i komentarza.
To również stworzenie historii recenzji użytkownika. Filtrowanie produktów oceną i liczbą recenzji. Analityka po stronie administratora lub (jako could-have) możliwość odniesienia się do nieprzychylnej recenzji w formie komentarza.
2) Gdy porównujesz oferty od wykonawców
Istnieje ryzyko, że Twój potencjalny wykonawca nie wycenił funkcji, których nie ma w Twojej liście wymagań, a są one niezbędne do prawidłowego funkcjonowania aplikacji.
Jak mogło się to stać?
Wykonawca przygotowuje estymację kosztowo-czasową w oparciu o listę założeń funkcjonalnych (szacunki są wtedy mniej dokładnie) lub o zaprojektowane już ekrany UX/UI wraz z opisem funkcji (dokładniejsze szacunki). Może zdarzyć się tak, że wykonawca nie przeanalizuje dogłębnie zależności między funkcjami i nie zauważy, że brakuje w projekcie ważnego ekranu.
Możliwa jest również sytuacja, w której wykonawca zauważy te braki, lecz nie zasugeruje wprost, że należy uwzględnić nowe funkcje, a wycena powinna być dużo wyższa, obawiając się, że będzie przez to mniej konkurencyjny.
Zwracaj więc uwagę na jakość komunikacji z wykonawcą. To, że wykonawca zadaje ci dużo pytań, jest dobrym znakiem.
Dlaczego tak łatwo jest ulec pokusie dodawaniu kolejnych funkcjonalności?
Prawdopodobnie szukasz pewności, że inwestycja w aplikację Ci się zwróci. Być może czujesz, że aplikacja nie jest wystarczająco “doskonała”, aby ją opublikować bez szeregu funkcji. Chcesz mieć poczucie, że robisz wszystko, aby Twój przyszły użytkownik pokochał Twoją aplikację i dlatego, zanim nawet zweryfikujesz swój pomysł z realnym użytkownikiem, planujesz już kolejne ulepszenia w Twojej aplikacji.
Często wydaje nam się, że ilość włożonej pracy, przełoży się proporcjonalnie na uzyskane rezultaty. To sprawia, że możemy wpadać w pułapkę myślenia, że nasza inwestycja prędzej czy później się zwróci, więc od razu lepiej zainwestować w rozbudowaną aplikację, a potem wystarczy tylko czekać na zwrot inwestycji.
Niestety, może się okazać, że 1) w założonym budżecie zrealizujesz tylko 70% planowanego zakresu zamiast 100% planu o mniejszym rozmiarze, 2) stworzysz wiele funkcji, które finalnie okażą się niepotrzebne dla użytkownika.
Mając świadomość tego zjawiska, co możesz zrobić?
1) Gdy planujesz aplikację
Niezależnie od tego czy reprezentujesz startup czy dużą organizację, warto, aby do planowania aplikacji podejść w duchu MVP (Minimum Viable Product). W skrócie podejście to można przetłumaczyć na:
Najbardziej Wartościowe Najpierw
Podejście to zakłada stworzenie jednej lub dwóch naprawdę priorytetowych funkcji, które dają największą wartość użytkownikowi. Celem jest jak najszybsze opublikowanie aplikacji, aby w możliwie najkrótszym czasie pozwolić realnym osobom na jej użytkowanie. Dzięki temu zbadasz rynek, zbierzesz opinie i dowiesz się, w którym kierunku rozwijać swój produkt dalej. Jest to etap, po którym często pojawiają się nieoczywiste pomysły.
Ilość funkcji w MVP: nie tylko “co”, ale “jak”
Zamiast tworzenia wielu funkcji, które na wczesnym etapie powstawania aplikacji mogą być zbyt wielkim ciężarem, warto wykonać ich mniej, lecz zrobić to naprawdę dobrze. Zastanów się, co może być „dźwignią”, która sprawi, że użytkownicy bardziej pokochają aplikację. Mamy tu na myśli pozornie niewielkie ulepszenia, które potrafią dać bardzo duże rezultaty, szczególnie obszarze UX/UI (doświadczenia użytkownika i estetyka).
Użytkownicy często zaprzestają używania aplikacji, ponieważ jest zbyt wolna lub skomplikowana. Nie są pewni czy rozumieją dobrze jej funkcje lub mają trudność w jej swobodnym użytkowaniu, na przykład jeśli potrzebują kilku klików, aby dostać się do pożądanej funkcji. Poprawa tych czynników ma ogromny wpływ na sukces produktu cyfrowego.
Pamiętaj, że MVP nie oznacza brzydkiego i nieprzyjaznego użytkownikowi produktu.
Zaprojektowanie MVP o wysokiej wartości dla użytkownika wymaga znajomości możliwości technologicznych oraz zasad dobrych praktyk UX/UI. Zastosowanie ich sprawi, że Twoja aplikacja od początku będzie atrakcyjna wizualnie oraz praktyczna, nawet bez dużej ilości funkcji. Na samym początku powstawania aplikacji warto zainwestować w warsztaty Product Design, podczas których wraz z naszymi ekspertami zaprojektujesz jak aplikacja ma wyglądać i działać.
2) Gdy porównujesz oferty od wykonawców
Jeśli masz przed sobą oferty od różnych wykonawców, a różnica w wycenie znacznie się różni, zapytaj wykonawców:
a) Jakie założenia zostały podjęte podczas estymacji danej funkcji, to znaczy, opisanie krok po kroku, w jaki sposób dokładnie użytkownik będzie z niej korzystał.
Dlaczego?
Może się zdarzyć, że wraz z wykonawcą odkryjecie, że ścieżka użytkownika wymaga zaplanowania dodatkowych funkcji, które nie zostały uwzględnione w estymacji, szczególnie gdy jest ona zbyt niska.
b) Czy stworzenie danej funkcji może wiązać się z dodatkowymi funkcjami, również tymi po stronie administratora aplikacji i w jaki sposób wykonawca rekomenduje to zrobić.
Dlaczego?
Kolejną częstą sytuacją, z którą spotykamy się, jest ta, w której lista funkcji aplikacji skupiona jest wyłącznie na użytkowniku końcowym. Należy pamiętać, że panel administratora jest odzwierciedleniem możliwości aplikacji po stronie użytkownika. W zależności od przypadku panel będzie potrzebował, aby np.: mieć podgląd użytkowników i móc nimi zarządzać (edytować dane, dodawać ręcznie, usuwać); mieć możliwość dodawania zawartości reklamowej (np. banner), oraz określania żywotności komunikatów; panel do zarządzania notyfikacjami. Jeśli w panelu administracyjnym przewidujesz wiele ról (super-admin, zwykły admin), będziesz potrzebować funkcji dodawania administratorów i określania ich uprawnień.
Różnice w wycenie mogą zależeć także od zaproponowanych technologii. W przypadku zbudowania panelu administracyjnego aplikacji dla startupów często rekomendujemy wykorzystanie FireCMS. Jest to platforma od Google pozwalająca zoptymalizować czas budowy takiego panelu, ze względu na użycie gotowych komponentów, które jedynie wymagają dostosowania do potrzeb danego projektu.
Jeśli reprezentujesz większą organizację, a Twoja aplikacja integruje się z istniejącymi systemami firmy lub przewiduje wiele niestandardowych rozwiązań funkcjonalnych, najczęściej najlepszym rozwiązaniem będzie stworzenie panelu dedykowanego.
Podsumowanie
Zakładany budżet na stworzenie aplikacji bardzo łatwo jest przekroczyć i stracić kontrolę nad zakresem projektu. Dzieje się tak z powodu problemów w oszacowaniu realnej ilości funkcji w aplikacji oraz chęci nadmiernego jej rozbudowania już na początkowym etapie. Dokładna analiza wymagań aplikacji oraz szczera rozmowa z potencjalnym wykonawcą powinny pomóc w określeniu rzeczywistego zakresu oraz wysokości inwestycji.
