Znacie ten dowcip: Przychodzi klient do programisty i mówi „Chciałbym zlecić zrobienie aplikacji do zamawiania jedzenia, ile to będzie kosztować”, a programista odpowiada „od dziesięciu tysięcy do pół miliona”? Tak, wiem, to wcale nieśmieszny dowcip.
Problem w tym, że firmy takie jak nasza każdego tygodnia dostają przynajmniej kilka zapytań o wycenę, brzmiących mniej więcej tak, jak w cytacie powyżej. Klienci - co wcale nie dziwi - nie zdają sobie jednak sprawy, że podanie, choćby orientacyjnej, kwoty tak opisanego zlecenia jest praktycznie niemożliwe. To tak jakby spytać: „ile kosztuje samochód”. Ale jaki samochód? O jakiej mocy silnika? Automat czy manualna skrzynia biegów? Z jakim wyposażeniem?
No właśnie.
Dobry brief to ten, który pozwoli wyceniającemu zrozumieć istotę zlecenia i zorientować się potrzebach klienta w stopniu umożliwiającym zaproponowanie choćby orientacyjnych - ale jednak rzetelnych widełek kwotowych. Takich, które można uwzględnić we wniosku o dofinansowanie, biznesplanie czy budżecie dla inwestora.
O procesie wyceniania projektów w software house’ach pisałam już trochę tutaj: www.jcd.pl/jak-wyglada-proces-wyceny-zlecen-w-software-house - dzisiaj pomogę Wam przygotować dobry brief aplikacji mobilnej.
Możecie skorzystać też od razu z naszego szablonu (do pobrania wersja .pdf, .doc i .odt) lub umówić się na rozmowę, podczas której wspólnie wypracujemy brief:
1. Skrócony opis, który pozwoli nam umieścić kolejne informacje w odpowiednim kontekście
Na początku po prostu opowiedz o swoim pomyśle. Jakie funkcje ma spełniać aplikacja? Jaki problem rozwiązywać? Jak ją sobie wyobrażasz? Przeznaczenie aplikacji jest ważne bo różne ich rodzaje mogą wymagać różnych rozwiązań technologicznych a co za tym idzie - generować różne koszty. Na przykład aplikacja lub gra wymagająca użycia silnika 3D wymusza zastosowanie technologii natywnych, w innym przypadku - wystarczy web view lub rozwiązanie hybrydowe kompilowane do natywnego (jeśli nie wiesz o czym mowa - nie szkodzi, nie musisz! Aby zgłębić to zagadnienie bardziej szczegółowo, odsyłam Cię do tekstu Adama, skrótowo opowiadającego o różnych typach aplikacji: https://jcd.pl/aplikacja-mobilna-czy-da-sie-dobrze-i-tanio).
2. Cele biznesowe pomysłodawcy aplikacji - czyli Twoje
Do projektów naszych klientów staramy się podchodzić jak do własnych. Dlatego elementem każdej wyceny jest zrozumienie celów biznesowych, które przyprowadziły Cię do nas. Jedno z pierwszych pytań, na które powinien odpowiadać dobry brief, brzmi: czego - jako zlecający ją pomysłodawca i przedsiębiorca - oczekujesz od aplikacji? W jaki sposób ma pomóc Twojej firmie? Jaką potrzebę biznesową zaspokoić? Zwiększyć sprzedaż? Zbudować zasięg? Dotrzeć do kolejnych segmentów rynku? Wspierać działania PRowe? Jaki model biznesowy aplikacji wybrałeś? Zrozumienie celu pomoże nam wytyczyć do niego drogę.
3. Użytkownik - dla kogo przeznaczona będzie aplikacja?
To bardzo ważny punkt, determinujący zarówno technologiczne jak i wizualne aspekty prac nad aplikacją. Możliwie najdokładniejsza wiedza o tym, kto będzie z niej korzystał, pozwoli zaprojektować aplikację odpowiadającą na potrzeby użytkowników. Opisz grupę docelową i bliskie jej wartości, możliwości, ograniczenia. Przydatnym narzędziem jest persona - sposób analizowania i prezentowania informacji o typowym, pożądanym użytkowniku. W jakim jest wieku? W jakich sytuacjach będzie korzystać z aplikacji? Jak dobrze jest zaznajomiony z nowymi technologiami - jak swobodnie z nich korzysta, jakich urządzeń mobilnych używa? Inaczej zaprojektujemy aplikację dla nastolatków używających smartfona niemal cały czas, inaczej dla profesjonalistów korzystających z niej w kontekstach zawodowych, inaczej dla kierowców ciężarówek, a jeszcze inaczej dla młodych matek…
4. UX: user experience, czyli doświadczenie użytkownika.
Opisz funkcje aplikacji z punktu widzenia osoby korzystającej - najwygodniej jest użyć tzw user stories, czyli historii użytkownika rozpisanych według schematu:
| “jako [użytkownik/administrator] robię [co?- akcja] aby [cel, rezultat, problem do rozwiązania]”. |
Na przykład historie użytkownika w przypadku aplikacji do zamawiania jedzenia mogą zostać pokazane tak:
- jako użytkownik filtruję listę dostępnych restauracji po czasie dostawy, aby wybrać najszybszy dowóz;
- jako użytkownik dodaję restaurację do “ulubionych” aby potem móc wrócić do wybranych restauracji z poziomu ekranu głównego;
- jako administrator zarządzam cechami/atrybutami restauracji (czas, koszt dostawy, rodzaj kuchni) aby uaktualniać ważne dla użytkownika informacje o restauracji;
- jako administrator pobieram dzienny raport zamówień aby analizować sprzedaż, archiwizować dane i optymalizować pracę restauracji.
Chcemy poznać i przewidzieć sposoby w jakie użytkownicy mogą korzystać z aplikacji, by projektując produkt nie tylko atrakcyjny ale także ergonomiczny, funkcjonalny i użyteczny, zaoferować im możliwie najbardziej satysfakcjonujące doświadczenie.
Co ważne dla wyceny - na podstawie user stories możemy również oszacować liczbę ekranów do zaprojektowania i zakodowania, a także wstępnie ocenić poziom skomplikowania funkcjonalnego.
5. UI, czyli user interface:
Choć często omawiany na jednym wydechu z UX, my celowo rozbijamy go na kolejny punkt briefa. Wygląd interfejsu jest kwestią wtórną do doświadczeń użytkownika; rolą grafiki jest umożliwienie użytkownikowi sprawnego korzystania z aplikacji, kropka. Użyteczność i dostarczenie pozytywnych wrażeń, maksymalna intuicyjność i łatwość korzystania z aplikacji - to główne cele, które stawiamy przed projektantem ekranów aplikacji. Dobry design musi bazować na doskonałym zrozumieniu potrzeb użytkownika oraz celów biznesowych klienta (zamawiającego aplikację). Często pomysłodawca przychodzi do nas z określoną wizją: kolorystyką, przykładami podobnych realizacji, moodboardem lub choćby mglistym wyobrażeniem końcowego efektu. W tym punkcie chcemy je poznać aby - łącząc wszystkie te informacje w całość - dostarczyć projektantom najlepszego paliwa do procesu kreatywnego.
Zdarza się też, że klient ma już rozrysowane makiety lub gotowy projekt graficzny; ten punkt briefa to dobre miejsce na taką informację - może ona zmienić wycenę nawet o 30%.
6. Budżet
Wiem od klientów, że to pytanie budzi niekiedy dyskomfort. Budżet bywa czasem zbyt szeroki lub nieokreślony (bo pracujecie dopiero nad biznesplanem dla inwestora), by deklarować się na tak wstępnym etapie. Zdarza się też, że klient nie chce podać maksymalnej kwoty w obawie, że zafiksuje wycenę na takim - granicznym dla jego firmy - poziomie.
Jednak my pytamy o to w zupełnie innym celu - poznanie Waszego budżetu umożliwia nam zaproponowanie rozwiązania optymalnego; w sytuacji gdyby wycena przekroczyła Wasze możliwości możemy także doradzić, które elementy zastąpić lub z czego zrezygnować, aby obniżyć koszty bez znaczących zmian w ogólnym doświadczeniu użytkownika, mając przy tym na względzie najważniejsze cele biznesowe aplikacji.
7. Co już masz, czego potrzebujesz?
Na etapie briefu warto również przemyśleć wszystkie inne - poza technologicznymi i graficznymi - elementy potrzebne do wprowadzenia aplikacji na rynek. Niektóre z nich będą potrzebne jeszcze w trakcie kodowania (jak mikrocopy na przyciski), inne dopiero na etapie wprowadzania aplikacji do sklepu - jednak brak każdej z nich może znacząco opóźnić moment premiery. Umieszczenie tych informacji w briefie usprawnia współpracę i ułatwia utrzymanie harmonogramu.
A zatem czy zaplanowałeś już:
- copywriting, a zwłaszcza mikrocopy lub UX copywrting, czyli wszystkie te zgrabne sformułowania i podpowiedzi do umieszczenia na przyciskach i polach wyszukiwania;
- opisy do sklepów (Appstore, Google store);
- landing page, czyli strona przeglądarkowa z informacjami o aplikacji;
- regulamin, klauzule RODO, audyt prawny;
- planowany termin wdrożenia i harmonogram działań marketingowych?
8. Technikalia
Czas na zagadnienia techniczne. Idealnie jest, gdy klient przychodzi z pełną specyfikacją, składającą się z dwóch części: specyfikacji funkcjonalnej i specyfikacji technicznej. Taki dokument przygotowywany jest przez programistę lub pod jego okiem i powinien wyczerpująco opisywać wymagania techniczne oraz poszczególne funkcjonalności.
|
Specyfikacja funkcjonalna zawiera:
Specyfikacja techniczna uwzględnia kwestie takie jak:
|
-
klient przychodzi z pełną specyfikacją - prosta sytuacja, czytamy dokument i odsyłamy wycenę;
-
klient przychodzi z planem funkcjonalności i ścieżkami użytkowników - na tej podstawie możemy zdefiniować potrzeby i wymagania, zaproponować konkretne rozwiązania technologiczne i zamknąć je w dokładnej specyfikacji;
-
klient przychodzi ze wstępnym pomysłem i wspólnie, w ramach warsztatów projektowych, przy wsparciu programisty i specjalisty UX, wypracowujemy finalną specyfikację, w tym listę widoków do zaprojektowania.
Masz pomysł na aplikację? napisz do nas, umów się na niezobowiązującą rozmowę
Autor:
Newsletter
Zero spamu - tylko wartościowe treści!:
