Poproś trzech wykonawców o wycenę "aplikacji dla naszej firmy", a dostaniesz trzy liczby, których nie da się porównać, bo każdy zgadywał coś innego. Jasny brief na aplikację to rozwiązuje. Nie musi być techniczny ani długi. Ma powiedzieć, kto będzie korzystał z oprogramowania, co musi móc robić, z jakimi systemami się łączy i co dzieje się po uruchomieniu. Oto jak go napisać dla aplikacji webowej, mobilnej lub obu.

Co powinien obejmować brief na aplikację

Potraktuj brief jako mapę do pierwszej rozmowy, a nie umowę. Dla większości projektów wystarczą dwie do pięciu stron, a brief powinien obejmować:

  • Problem. Co jest dziś powolne, podatne na błędy lub niemożliwe? "Wyceny trwają dwa dni, bo ceny są w trzech arkuszach" jest użyteczniejsze niż "potrzebujemy aplikacji do wycen".
  • Ludzie. Kto będzie z niej korzystał, mniej więcej ilu i na jakich urządzeniach.
  • Cel. Co będzie inaczej, gdy zadziała: mniej telefonów, szybsze fakturowanie, zlecenia niegubiące się między biurem a terenem.
  • Ograniczenia. Prawdziwe terminy, przedział budżetu i systemy, których nie można zmieniać.

Czy nazwiesz wynik oprogramowaniem na zamówienie, czy aplikacjami webowymi i mobilnymi na zamówienie, brief jest tym samym dokumentem i to najlepsze przygotowanie do pierwszego spotkania z każdym wykonawcą.

Role użytkowników i zadania, które mają znaczenie

Większość oprogramowania biznesowego ma kilka ról użytkowników, z których każda widzi co innego: administrator zarządzający ustawieniami, pracownicy biura obsługujący rekordy, pracownicy w terenie z telefonem i być może klienci logujący się do portalu. Dla każdej roli wypisz pięć do dziesięciu zadań, które będzie wykonywać najczęściej, ich własnymi słowami. "Technik oznacza zlecenie jako wykonane i dodaje zdjęcia" to zadanie; "moduł zarządzania zleceniami" nie.

Zaznacz, kto czego nie może widzieć. Uprawnienia znacznie łatwiej zaprojektować na początku niż dobudowywać po uruchomieniu.

Kluczowe funkcje, funkcje na później i kryteria akceptacji

Podziel listę funkcji na kluczowe funkcje pierwszego wydania i całą resztę. Pierwsze wydanie, często nazywane minimalnym produktem (MVP), powinno być najmniejszą wersją, z którą prawdziwi użytkownicy mogą pracować codziennie. Późniejsze funkcje łatwiej uszeregować, gdy ludzie już z niej korzystają i mówią, czego im brakuje.

Dla każdej kluczowej funkcji dodaj kryteria akceptacji: zdanie mówiące, po czym poznasz, że działa. "Gdy klient wgrywa dokument, biuro widzi go w rekordzie zlecenia i dostaje powiadomienie" da się przetestować; "łatwe wgrywanie dokumentów" nie. Kryteria akceptacji są też najuczciwszym sposobem rozstrzygnięcia, czy funkcja jest skończona.

Dane, integracje systemów i urządzenia

  • Istniejące dane. Co trzeba zaimportować z arkuszy lub starego systemu i jak są uporządkowane.
  • Integracje systemów. Księgowość, CRM, płatności, poczta, mapy lub wysyłka. Podaj nazwę oprogramowania i kierunek przepływu danych; wiele takich połączeń realizuje się jako integrację API obok samej aplikacji.
  • Urządzenia i warunki. Komputery biurowe, prywatne telefony lub wzmocnione firmowe urządzenia przenośne; wewnątrz lub na budowach ze słabym zasięgiem. Jeśli ludzie muszą pracować offline, napisz to, bo kształtuje to cały projekt.
  • Funkcje telefonu. Aparat, skanowanie kodów kreskowych, lokalizacja lub powiadomienia push wskazują na aplikację zainstalowaną na urządzeniu, a nie webową.

Aplikacja webowa na zamówienie działająca w przeglądarce często wystarcza do zadań biurowych, a aplikacja mobilna na zamówienie zasługuje na miejsce, gdy liczy się sprzęt telefonu lub praca offline. Brief nie musi tego rozstrzygać; ma dostarczyć fakty, które rozstrzygną.

Konta, własność i życie po uruchomieniu

Na pytania o własność najłatwiej odpowiedzieć, zanim powstanie jakikolwiek kod. Brief powinien stwierdzać, że repozytorium kodu, hosting, domena i konta w sklepach z aplikacjami należą do Twojej firmy. Publikacja w App Store pod nazwą firmy oznacza rejestrację jako organizacja, a Apple wymaga do jej weryfikacji podmiotu prawnego i numeru D-U-N-S; zobacz wymagania rejestracji Apple. Google Play też weryfikuje konta organizacji, więc zacznij oba wcześnie.

Zaplanuj także lata po uruchomieniu. Systemy operacyjne telefonów dostają co roku dużą aktualizację, a aplikacje w sklepach wymagają aktualizacji, by nadążać. Rozwiązania mobilne na zamówienie i aplikacje webowe potrzebują hostingu, aktualizacji zabezpieczeń i kogoś odpowiedzialnego, więc zapytaj w briefie, jak będą wyglądać aktualizacje i wsparcie. W naszych projektach aplikacji na zamówienie dokumentacja, dostęp do repozytorium kodu oraz plan aktualizacji i hostingu są częścią przekazania.

Najczęściej zadawane pytania: brief na aplikację

Jak szczegółowy musi być brief?

Na tyle, aby dwóch wykonawców wyobrażało sobie to samo oprogramowanie. Opisuj zadania i wyniki, a nie ekrany i technologie; dobry wykonawca zamieni to w projekt i dopyta o luki.

Czy podawać budżet w briefie?

Przedział pomaga. Ten sam cel można osiągnąć szczupłą pierwszą wersją lub w pełni wyposażoną, a przedział pozwala wykonawcom zaproponować pasujący zakres zamiast zgadywać.

Czy potrzebuję makiet przed kontaktem z wykonawcą?

Nie. Szkice lub zrzuty ekranu narzędzi, które lubisz, są przydatne, ale nie musisz sam projektować ekranów. W naszych projektach klikalne ekrany głównych zadań powstają po fazie analizy i są omawiane z osobami, które faktycznie będą korzystać z oprogramowania.

Masz proces, który wyrósł z arkuszy? Nasza usługa tworzenia aplikacji webowych i mobilnych na zamówienie zaczyna się od analizy i klikalnego prototypu, jest realizowana etapami i kończy przekazaniem dokumentacji oraz dostępu do kodu, dla firm w Los Angeles, Long Beach i poza nimi. Wyślij nam swój brief, nawet szkicowy, i napisz, kto będzie używał oprogramowania oraz z jakimi systemami ma współpracować.