VulCode

Brief aplikacji i systemu

Problem, użytkownicy, platformy, funkcje, dane, integracje i zakres pierwszej wersji.

Brief aplikacji: Zlecenia serwisowe
Problem
  1. Technicy dostają zlecenia telefonicznie, a raporty z wizyt wpisujemy ręcznie do arkusza na koniec tygodnia.
Miara sukcesu
  1. Każde zlecenie ma status widoczny dla biura w ciągu godziny od wizyty.
Role użytkowników
  1. •Biuro: tworzy zlecenia i przydziela technika
  2. •Technik: widzi swoje zlecenia i dodaje raport ze zdjęciami
Platformy
  1. •Przeglądarka
  2. •PWA zamiast aplikacji ze sklepu
Pierwsza wersja: funkcje konieczne
  1. •Technik otwiera zlecenie na telefonie i zamyka je raportem ze zdjęciem
  2. •Biuro widzi listę zleceń z filtrem po statusie
Na później
  1. •Podpis klienta na telefonie
Integracje
  1. •Eksport do programu księgowego (do sprawdzenia, jaki format przyjmuje)
Dane i dostęp
  1. Adresy klientów i zdjęcia z wizyt. Technik widzi tylko swoje zlecenia.
Termin, budżet i utrzymanie
  1. •Termin: pierwsza wersja na sezon grzewczy
  2. i 2 kolejne punkty

Wypełnij i pobierz

Dokument zmienia się na bieżąco, gdy wypełniasz 12 pól. Wszystko dzieje się w Twojej przeglądarce, nic nie wysyłamy.

Problem
Użytkownicy i platformy
Platformy
Funkcje i dane
Termin i budżet
brief-aplikacji.md
Brief aplikacji: do uzupełnienia

Problem

do uzupełnienia

Miara sukcesu

do uzupełnienia

Role użytkowników

  • do uzupełnienia

Platformy

  • do uzupełnienia

Pierwsza wersja: funkcje konieczne

  • do uzupełnienia

Na później

  • do uzupełnienia

Integracje

  • do uzupełnienia

Dane i dostęp

do uzupełnienia

Termin, budżet i utrzymanie

  • Termin: do uzupełnienia
  • Budżet: do uzupełnienia
  • Utrzymanie: do uzupełnienia

Kiedy użyć briefu aplikacji

Funkcje opisuj jako sytuacje: kto, co robi i po czym poznasz, że działa.

Jeśli aplikacja ma się łączyć z innymi systemami,

to opisz integracje nazwami systemów i dokumentacją ich API. To w nich najczęściej kryją się niespodzianki.

Jeśli nie wiesz jeszcze dokładnie, czego potrzebujesz,

to opisz problem, użytkowników i proces, a w miejscu funkcji napisz, że ich lista jest otwarta. Taki brief jest punktem wyjścia do płatnego etapu analizy.

Jeśli masz już szczegółowy opis funkcji, ekranów i kryteriów odbioru,

to masz w ręku specyfikację, a nie brief. Specyfikacja powstaje z briefu, nie zamiast niego. Generator specyfikacji

Jeśli projekt jest współfinansowany z UE albo zamawiasz jako podmiot publiczny,

to sprawdź tryb wyboru wykonawcy, zanim wyślesz brief pierwszej firmie. Wybór poza wymaganą procedurą może sprawić, że wydatek nie zostanie uznany za kwalifikowalny.

Jeśli każda funkcja wydaje się konieczna,

to ustal priorytety. Jeśli wszystko jest konieczne, każda firma sama zdecyduje, co pominąć, i każda pominie co innego.

Co dalej: ten sam brief do kilku firm

Brief jest najcenniejszy wtedy, gdy wszyscy wykonawcy dostają dokładnie to samo. Na przykład tydzień na pytania i kolejny tydzień na oferty, żeby odpowiedzi zdążyły trafić do wszystkich.

Ty
zamawiający
  • WysyłkaJedna wersja briefu, z datą albo numerem wersji
  • Tydzień na pytaniaOdpowiedzi dla wszystkich, bez wskazywania, kto pytał
  • RozmowyPół godziny rozmowy z każdą firmą
Wykonawcy
firmy, od których chcesz wyceny
  • Tydzień na pytaniaPytania do briefu
  • Tydzień na ofertyOferty w tej samej strukturze: zakres, wyłączenia, założenia, model rozliczenia, harmonogram
  1. Brief

    Ty Wykonawcy. Jeśli coś zmieniasz, wysyłasz nową wersję wszystkim.

  2. Pytania

    Wykonawcy Ty. Firma, która przeczytała brief uważnie, zwykle wraca z kilkoma konkretnymi pytaniami.

  3. Oferty

    Wykonawcy Ty. Pół godziny na omówienie pytań pokazuje więcej niż sama oferta.

Pytania

Najpierw o tym, co dzieje się z wpisanymi danymi, potem o samym dokumencie.

Masz gotowy dokument?

Wyślij go nam razem z pytaniem. Odpiszemy w godzinę z wyceną.