News10 min czytania

Brief aplikacji mobilnej – wszystko, co musisz wiedzieć, aby rozpocząć projekt rozwiązania mobilnego

Karol Wegner

Board Member

Dowiedz się, czego potrzebujesz, aby otrzymać dobrą estymację swojego projektu. Artykuł od ludzi, którzy estymują, dla ludzi, którzy estymacji potrzebują.

Spis treści

  1. Intro
    „To zależy” nie jest odpowiedzią
    Prawdziwa odpowiedź nie jest prosta
    Dlaczego potrzebujemy briefu?
    Szczegóły mają znaczenie
  2. Co musimy wiedzieć, aby oszacować i zaplanować rozwój Twojej aplikacji
    Cel projektu
    Użytkownicy i problem, który rozwiązujesz
    Stan obecny, zasoby własne i potrzeby
    Aby uzyskać szczere odpowiedzi, zadawaj uczciwe pytania
  3. Opis aplikacji – główne funkcje
    User story
    Przykłady User stories
  4. Komponenty i zakres prac
  5. Ramy czasowe i terminy
  6. Pytanie o pieniądze
    Odpowiednie rozwiązanie w stosunku do budżetu
    Myślimy o wydaniu kwoty X…
  7. Wybór dewelopera
    Kryteria wyboru wykonawcy
    Priorytetyzacja wymagań
  8. Aktualizacja brief

Intro

Jeśli myślisz o stworzeniu pierwszej (lub drugiej lub trzydziestej pierwszej) aplikacji mobilnej, musisz oczywiście wiedzieć, ile będzie to kosztować. Niestety „to zależy” jest najczęstszą odpowiedzią, jaką otrzymasz, próbując porozmawiać z programistami o kosztach i szacunkach.

„To zależy” nie jest odpowiedzią

Jako, że rozwój aplikacji mobilnych faktycznie zależy od wielu różnych czynników, samo słowo „to zależy”, jest najłatwiejszym sposobem na szybką odpowiedź. Jednocześnie, nie pozostawia Cię z żadnymi, konkretnymi informacjami.

A kiedy słyszysz taką odpowiedź, pytasz „zależy od czego?”. Następstwem jest zazwyczaj połączenie technik sprzedaży z próbą ustalenia, jakie są Twoje wymagania. Dlatego też, proces właściwego oszacowania i przygotowania się do wyceny jest kluczowy dla sukcesu twojego projektu. Ważnym jest, abyście, zarówno Ty, jak i developer, zrobili to dobrze.

Prawdziwa odpowiedź nie jest prosta

Postaram się, aby proces brief’owania był nieco bardziej znaczący i mniej zależny od technik sprzedażowych. Najbardziej zależy mi na możliwości podjęcia przez Ciebie świadomej decyzji, niezależnie od tego, czy wybierasz itCraft, czy innego wykonawcę, z którym chcesz pracować.

Poniższy artykuł jest próbą wyjaśnienia „briefu aplikacji mobilnej” tak dokładnie i przyjaźnie, jak to możliwe. Jeżeli jednak masz jakieś uwagi lub potrzebujesz więcej informacji, daj mi znać. Zwłaszcza jeśli cokolwiek nie jest wystarczająco jasne. Chcę, aby była to pomoc dla każdego, kto rozważa rozwój oprogramowania.

Dlaczego potrzebujemy briefu?

To proste. Im więcej wiemy o twoim pomyśle, tym lepiej. Nie dlatego, że chcemy go ukraść, ale dlatego, że chcemy pomóc Ci odnieść sukces. Zgodnie z naszą najlepszą wiedzą i umiejętnościami. Część wiedzy na temat projektu, który mamy tworzyć, a przynajmniej większa jego część, przyjdzie właśnie od Ciebie.

Szczegóły mają znaczenie

Właściwie to są one najważniejsze. Jeśli jest coś, w co należy włożyć największy wysiłek, przygotowując brief, to właśnie szczegóły. Gdy oceniamy Twoje wymagania, skrupulatnie zebrane informacje okazują się bezcenne.

Tak więc bez zbędnych ceregieli porozmawiajmy o brief’ie Twojej aplikacji mobilnej. Będzie trochę czytania, ale postaram się uczynić to tak bezbolesnym i zwięzłym jak tylko mogę. Jeśli uda ci się przejść przez cały artykuł, mogę zagwarantować, że będziesz mieć to, czego potrzebujesz, aby zacząć szukać odpowiedniego programisty.

Co musimy wiedzieć, aby oszacować i zaplanować rozwój Twojej aplikacji

Cel projektu

Dlaczego myślisz o stworzeniu aplikacji mobilnej? Zrozumienie Twojego pomysłu i rozumowania, które za nim stoi, pomoże nam wybrać odpowiednie technologie, dostosować się do krótko- i / lub długoterminowej strategii i doradzić najbardziej efektywne podejście.

Użytkownicy i problem, który rozwiązujesz

Aby zapewnić odpowiednią usługę, developerzy muszą znać wartość, jaką chcesz dać swoim użytkownikom. Niezależnie od tego, czy są to klienci, ogół społeczeństwa czy Twoi pracownicy, wprowadzenie nowego systemu ma na celu rozwiązanie problemu, zaspokojenie potrzeby lub przyniesienie korzyści użytkownikowi końcowemu. Zrozumienie propozycji wartości i grupy docelowej Twojej aplikacji pomoże nam zaprojektować odpowiednie rozwiązanie i wykorzystać technologie odpowiednie do Twoich potrzeb.

Stan obecny, zasoby własne i potrzeby

Określ aktualny stan swojego projektu. Czy jest to tylko pomysł wymagający analizy i oceny? Czy może już je przeprowadziłeś, a twój projekt jest już w fazie projektowania? Czy masz własny zespół pracujący nad projektem?

Gdy znamy odpowiedzi na te pytania, możemy wykorzystać te informacje, aby lepiej ocenić zakres usług, które będą potrzebne. Zasadniczo chcielibyśmy wiedzieć:

  • jeśli masz zespół ludzi odpowiedzialnych za projekt. Jakie role są już zapewnione. Czy zapewniasz dedykowanego właściciela produktu czy planujesz samodzielnie nadzorować rozwój,
  • czy możesz podać informacje biznesowe, dokumentację, inną wiedzę na temat problemu, który system rozwiąże,
  • czy istnieją konkretne wytyczne dotyczące proponowanego systemu w odniesieniu do pojemności, technologii, standardów lub procesów dostawcy, których powinien przestrzegać dostawca usług (programista).

Mając powyższe informacje, potencjalny Wykonawca będzie mógł szybko stwierdzić, czy posiada wymagane cechy i zasoby do pracy nad Twoim projektem.

Aby uzyskać szczere odpowiedzi, zadawaj uczciwe pytania

Podając powyższe informacje lub jakiekolwiek inne szczegóły, zalecam nie zatrzymywać żadnych informacji / wymagań, które możesz mieć, dla siebie. Jeśli przegapisz ważny szczegół, celowo lub przypadkowo, może to mieć znaczące konsekwencje. Dlatego, że coś, co może wydawać się małe i nieistotne dla Ciebie, nie oznacza, że nie jest poważnym i złożonym problemem dla programisty. Tego rodzaju nieporozumienia najczęściej prowadzą do komplikacji i konfliktów. Lepiej unikać tego od samego początku.

Opis aplikacji – główne funkcje

W tej kluczowej części brief’u będziesz opisywać zadania i procesy, które użytkownik końcowy będzie realizował za pomocą aplikacji. Innymi słowy – jaka ma być Twoja aplikacja. Po pierwsze, musisz zdefiniować typy użytkowników, którzy będą obsługiwać Twoją aplikację – admin, klient, dostawca (w systemie Uber to administrator, pasażer, kierowca). Następnie dla każdego z nich musisz opisać funkcje, do których będą mogli uzyskać dostęp.

User story

Standardowy sposób opisywania funkcji aplikacji to tzw. user story. Zwykle w następującej formie: Jako < rodzaj użytkownika >, chcę < jakiś cel >, żeby < powód >. Historie mówią nam kto (użytkownik), jak (cel) i dlaczego (powód) wykorzystają konkretne funkcje. Informacje te stanowią podstawę zarówno dla projektantów, jak i programistów UX, do planowania i szacowania czasu i technologii wymaganych do opracowania aplikacji.

Przykłady User stories

Jako użytkownik chcę zalogować się do aplikacji, aby móc korzystać z jej głównych funkcji,
lub
Jako system administrator chcę zarządzać kontami użytkowników, aby móc modyfikować, dostosowywać, usuwać i tworzyć nowe konta użytkowników.

Komponenty i zakres prac

Każdą aplikację / system można podzielić na 2 części:
1. Komponenty, które należy opracować,
2. Praca do wykonania.

Główne składniki systemu / aplikacji są następujące:

  • Aplikacja mobilna na Androida – aplikacja przeznaczona tylko dla urządzeń z systemem Android,
  • Aplikacja mobilna iOS – aplikacja na iPhone’a,
  • Aplikacja zaplecza – rozwiązanie serwerowe zawierające bazę danych i / lub interfejs programowania (API),
  • Panel administracyjny sieci Web – aplikacja administracyjna dla administratorów systemu,
  • Aplikacja internetowa dla użytkowników końcowych – aplikacja oparta na przeglądarce,
  • Integracja z usługami innych firm – systemy zewnętrzne, interfejsy API,
  • Strona docelowa – strona internetowa z informacjami o projekcie.

W zależności od złożoności i preferencji Twój projekt będzie wymagał wszystkich lub tylko niektórych z tych komponentów. Większość aktualnych programistów sugeruje rozpoczęcie od MVP (Minimum Viable Product) systemu. Ponadto projekt można zdefiniować, określając zakres wymaganych prac i osiąganych rezultatów:

  • Projekt UX / UI – przygotowanie zaległości wymagań, makiet hi-fi i lo-fi, prototypu,
  • Implementacja aplikacji (rozwój Androida, iOS, web, backend, API itp.),
  • QA – proces testowania obejmujący akceptację, bezpieczeństwo, wydajność, testy automatyczne, jednostkowe, alfa i beta (oraz testy zadowolenia użytkowników),
  • Przygotowanie dokumentacji projektowej (specyfikacja, scenariusze techniczne, funkcjonalne, testowe, API, integracja),
  • Transfer własności intelektualnej (IP) – kod źródłowy lub rozwiązanie licencyjne,
  • Implementacja Google Play i App Store,
  • Zarządzanie projektem, dokumentacja zarządcza – czasem wykonywana przez Project Managera dedykowanego dla projektu (jeżeli zadaniem wykonawcy jest jedynie dostarczenie zespołu programistów) lub przez wewnętrznego Project Managera po stronie developera,
  • Wsparcie powdrożeniowe, utrzymanie i rozwój aplikacji (zdefiniowane w ramach umowy SLA – link do artykułu o SLA).

Ramy czasowe i terminy

Czas jest zawsze najważniejszy. Jeśli potrzebujesz swojej aplikacji uruchomionej w określonym terminie, wtedy Twój programista musi o tym wiedzieć jak najwcześniej. Wiedząc, ile czasu mamy, dostosujemy wielkość zespołu do Twoich wymagań, ale również poinformujemy Cię, czy dane ramy czasowe są możliwe.

Jeśli nie masz wymagającego harmonogramu to również taka informacja pomoże Wykonawcy i będzie miał możliwość zaoferować lepszą cenę za realizację projektu.

Pytanie o pieniądze

Celem Twojej inwestycji w nowe rozwiązanie informatyczne (lub istniejące) jest osiągnięcie celu (celów) przedstawionych w streszczeniu aplikacji. Inwestycje nie mogą się udać bez budżetu.

Ponieważ rozwój oprogramowania jest w dużej mierze procesem twórczym, z wieloma zmiennymi pod względem rozwiązań, technologii, czasu itp. Znajomość budżetu pozwoli programistom dostosować ich propozycję do wymagań budżetowych.

Odpowiednie rozwiązanie w stosunku do budżetu

Kiedy już wiedzą, ile planujesz zainwestować w projekt, twórcy aplikacji mobilnych mogą zaoferować najbardziej odpowiednie rozwiązanie. Bez tej wiedzy będą zmuszeni do oszacowania „niewiadomych”, co zazwyczaj oznacza oferowanie najtańszych i najniższych opcji jakości, aby być konkurencyjnymi wobec innych dostawców. Uzyskane szacunki są zazwyczaj w dużej mierze nieodpowiednie i niedokładne. Najgorszy scenariusz polega na tym, że w końcu zapłacisz za nieudaną usługę lub otrzymasz oprogramowanie, które będzie wymagało miesięcy poprawiania błędów i czyszczenia przez innego dostawcę.

Większość firm zajmujących się tworzeniem aplikacji zazwyczaj odmawia tego typu zadań, ponieważ doświadczenie nauczyło nas, że naprawianie cudzych błędów jest zarówno bolesne, jak i kosztowne. Poza tym nasi analitycy techniczni zwykle mówią nam, że „taniej będzie zrobić nowy, niż naprawić ten worek…”.

Myślimy o wydaniu kwoty X…

Wyraźne określenie wymagań budżetowych to najlepszy sposób na znalezienie odpowiedniej firmy opracowującej aplikacje. Najlepszym sposobem na ujawnienie tego jest powiedzenie nam „Myślimy o wydaniu kwoty X na ten projekt i zdecydowanie nie chcemy przekraczać kwoty Y”. Pozwoli nam to zaproponować rozwiązanie spełniające wymagania X i rozszerzone, które będą bliższe sumie Y.

Jednocześnie zachęcamy do zapoznania się z naszym cennikiem, w którym pokazujemy przykłady tego, ile kosztuje stworzenie aplikacji mobilnej.

Wybór dewelopera

Szukając odpowiedniego programisty aplikacji, powinieneś mieć ustalone kryteria, które decydują o Twoim wyborze. Dzięki temu uzyskasz jasny obraz firmy, z którą najprawdopodobniej będziesz współpracować. Stwierdzenie tego otwarcie i szczerze na początkowych etapach wyszukiwania pozwoli Ci również zaoszczędzić czas na negocjacje z dostawcami, którzy nie mogą zaspokoić Twoich potrzeb.

Kryteria wyboru wykonawcy

Kiedy szukasz Wykonawcy Twojego projektu powinieneś dobrze określić, w jaki sposób, przy pomocy jakich kryteriów będziesz dokonywał wyboru Wykonawcy. Taka informacja jest również cenna dla potencjalnego Wykonawcy – dzięki tej informacji, Wykonawca będzie dokładnie rozumiał w jaki sposób powinien dostosować swoją ofertę, aby spełnić wymagania Zamawiającego. Zarówno dla Zamawiającego jak i Wykonawcy czas spędzony na przygotowanie i omawianie niedopasowanej oferty do prawdziwych potrzeb to po prostu niepotrzebna strata czasu.

Określ kryteria jakimi będziesz kierował się przy wyborze Wykonawcy:

  • Koszty realizacji – jest to często bardzo ważny parametr projektu, na szczęście coraz częściej nie najważniejszy. Jeśli natomiast zależy Tobie na najniższej cenie to powiedz to jasno swoim potencjalnym Wykonawcom – część z nich naturalnie odrzuci Twoje zapytanie, ale za to druga część skupi się bardziej na dopasowaniu projektowanego rozwiązania do możliwości budżetowych i uzyskasz lepsze pomysły na realizację projektu,
  • Czas wdrożenia – niektóre rozwiązania muszą zostać wdrożone “na czas” lub możliwie jak najszybciej. Wtedy Wykonawca oferujący dostępność zespołu “od zaraz” może uzyskać dodatkowe punkty nawet jeśli oferuje wyższą cenę,
  • Jakość – coraz częściej klienci są świadomi tego, że inwestycje w rozwiązania informatyczne są planowane na lata i w dłuższej perspektywie lepiej zainwestować w rozwiązanie, którego zbyt szybko nie trzeba będzie tworzyć od nowa. Jakość finalnego produktu może być różnie rozumiana. Jeśli zależy Tobie na zakupie usługi jakościowej określ Wykonawcy jak definiujesz jakość – czy zależy Tobie na wysokich ocenach użytkowników (idealny UX/UI), niezawodności produktu, wydajności, czystym kodzie źródłowym (clean code), dokładnej dokumentacji czy po trochu na wszystkich wymienionych powyżej elementach.

Priorytetyzacja wymagań

Który z powyższych czynników wpłynie na Twoją decyzję, zależy od potrzeb, możliwości i wymagań Twojej firmy. Dobrym pomysłem jest również poinformowanie deweloperów o swoich priorytetach, aby mogli lepiej dostosować swoją ofertę i oszacować.

Aktualizacja brief

Po przygotowaniu i wysłaniu brief do oferentów otrzymasz na pewno mnóstwo dodatkowych szczegółowych pytań lub propozycji spotkania, na których może się okazać, że któryś z Wykonawców zaproponuje rozwiązanie, które wpłynie na zmianę brief, zmianę wymagań lub odpowiedzi. Wtedy Twoim zadaniem jest odpowiednie zaktualizowanie dokumentu i poinformowanie o tym potencjalnych Wykonawców. Zmiana lub określenie nowych wymagań wpłynie na oferty, które otrzymasz.


Jeżeli myślisz o własnym rozwiązaniu mobilnym,
skontaktuj się z nami a prześlemy brief do wypełnienia.



Karol Wegner

Board Member

Post article


5/5 - (3 votes)

Masz projekt? Porozmawiajmy

Skontaktuj się