Jak przygotować brief projektu, żeby software house wycenił to, czego naprawdę potrzebujesz? Opisz problem, a nie rozwiązanie. Dobry brief odpowiada na kilka pytań: co dziś nie działa i po czym poznasz, że projekt się udał, kto będzie korzystał z systemu i co robi krok po kroku, które funkcje są konieczne w pierwszej wersji, jakie dane wchodzą i wychodzą, z czym system ma się łączyć, jakie obowiązują Cię wymagania prawne, ile możesz wydać, do kiedy i kto podejmuje decyzje. Nie musi zawierać ani jednego słowa o technologii.
Brief pisze się raz, a korzysta z niego każdy wykonawca, do którego go wyślesz. Od jego jakości zależy, czy dostaniesz wyceny tego samego projektu, czy kilka wycen kilku różnych projektów, których nie da się porównać.
- Brief opisuje problem, użytkowników i ograniczenia. Technologię dobiera wykonawca, chyba że masz konkretny powód, żeby ją narzucić, i ten powód zapisujesz.
- Funkcje opisuj jako sytuacje: kto, co robi i po czym poznasz, że działa. Hasło "panel administracyjny" każdy wykonawca wyceni inaczej.
- Ustal priorytety. Jeśli wszystko jest konieczne, każda firma sama zdecyduje, co pominąć, i każda pominie co innego.
- Integracje opisuj nazwami systemów i dokumentacją ich API. To w nich najczęściej kryją się niespodzianki.
- Podaj widełki budżetu i powód terminu. Wyślij ten sam brief wszystkim firmom, a odpowiedzi na pytania jednej przekaż pozostałym.
Brief, specyfikacja i zapytanie ofertowe: czym się różnią
Te trzy dokumenty często są mylone, a każdy ma innego autora i inny cel.
| Dokument | Kto go zwykle pisze | Co zawiera |
|---|---|---|
| Brief | Zamawiający | Problem, cel, użytkownicy, procesy, priorytety, ograniczenia, budżet i termin |
| Specyfikacja funkcjonalna | Wykonawca albo analityk, razem z zamawiającym | Szczegółowy opis funkcji, ekranów, reguł i kryteriów odbioru |
| Zapytanie ofertowe | Zamawiający, czasem według wymogów formalnych | Brief plus warunki: termin składania ofert, kryteria wyboru, wzór umowy |
Najczęstszy błąd to próba napisania specyfikacji zamiast briefu. Zamawiający bez doświadczenia technicznego zaczyna opisywać tabele w bazie danych i kolory przycisków, a pomija to, co wie najlepiej: jak dziś wygląda praca, gdzie są problemy i jakie są wyjątki od reguły. Specyfikacja powstaje z briefu, często w płatnym etapie analizy, a nie zamiast niego. Jak taki etap wpisuje się w rozliczenie całego projektu, opisaliśmy w tekście fixed price czy time and material.
Jeśli projekt jest współfinansowany ze środków Unii Europejskiej albo zamawiasz jako podmiot publiczny, wybór wykonawcy może podlegać osobnym zasadom: zasadzie konkurencyjności albo Prawu zamówień publicznych. Tryb, progi i miejsce publikacji zapytania, na przykład Baza Konkurencyjności, wynikają z umowy o dofinansowanie i przepisów, które Cię obowiązują. Sprawdź je, zanim wyślesz brief pierwszej firmie, bo wybór wykonawcy poza wymaganą procedurą może sprawić, że wydatek nie zostanie uznany za kwalifikowalny.
Co musi się znaleźć w briefie projektu: struktura do skopiowania
Poniższa struktura pasuje do strony, sklepu, panelu i aplikacji. Przy małej stronie część punktów zajmie jedno zdanie, przy systemie z integracjami kilka stron. Pustych punktów nie usuwaj, tylko wpisz "nie dotyczy" albo "nie wiem". Obie odpowiedzi są dla wykonawcy informacją.
Czym zajmuje się firma, dla kogo pracuje, jakich słów używacie na co dzień i co w Waszej branży działa inaczej niż wszędzie.
Co dziś nie działa, ile to kosztuje czasu albo pieniędzy i po czym za pół roku poznasz, że projekt się udał.
Kto będzie korzystał z systemu, ile jest osób w każdej roli i co każda rola może widzieć oraz zmieniać.
Co dzieje się krok po kroku, od początku do końca, razem z wyjątkami i sytuacjami spornymi.
Lista funkcji opisanych sytuacjami, z podziałem na konieczne, ważne, mile widziane i świadomie odłożone.
Jakie dane system przechowuje, ile ich jest, gdzie są dziś i czy trzeba je przenieść.
Z jakimi systemami projekt ma się łączyć, w którą stronę płyną dane, jak często i czy jest dokumentacja.
Kto dostarcza teksty, zdjęcia, tłumaczenia, logotyp i dokumenty prawne, i do kiedy.
Urządzenia, przeglądarki, wersje językowe, spodziewany ruch, dostępność, bezpieczeństwo, kopie zapasowe.
Dane osobowe, dostępność cyfrowa, faktury, regulaminy, branżowe przepisy, które Cię dotyczą.
Widełki budżetu, termin i jego powód, narzucona technologia albo hosting, z uzasadnieniem.
Kto będzie utrzymywał system, jakie są plany rozwoju i czy zespół wewnętrzny ma kiedyś przejąć kod.
Kto podejmuje decyzje, kto odpowiada na pytania, jak szybko i kiedy jest niedostępny.
Kolejność nie jest przypadkowa. Wykonawca, który przeczyta najpierw kontekst i problem, inaczej zrozumie listę funkcji, niż gdyby zaczął od niej. Punkty, przy których briefy najczęściej zawodzą, opisujemy niżej dokładniej.
Cel i miara sukcesu: zacznij od tego, co dziś nie działa
"Potrzebujemy nowej strony" nie jest celem, tylko pomysłem na rozwiązanie. Cel zaczyna się od problemu: "zapytania przychodzą głównie z polecenia, a ze strony prawie wcale", "trzy osoby przepisują zamówienia z maili do arkusza", "klienci dzwonią z pytaniem o status zamówienia, bo nigdzie go nie widzą". Taki opis pozwala wykonawcy zaproponować rozwiązanie, o którym być może nie pomyślałeś, albo powiedzieć, że problem leży gdzie indziej.
Druga połowa celu to miara sukcesu. Zapisz, po czym za pół roku poznasz, że projekt się udał: liczba zapytań z formularza, czas od zamówienia do wysyłki, liczba ręcznych przepisań tygodniowo, liczba telefonów z pytaniem o status. Jeśli możesz, podaj obecną wartość. Miara nie musi być dokładna, ale musi istnieć, bo bez niej każda funkcja wydaje się tak samo ważna.
Dobrze jest też dopisać, co się stanie, jeśli projekt nie powstanie. Odpowiedź "nic szczególnego, będziemy pracować jak dziś" jest uczciwą informacją, że projekt może poczekać albo wystarczy mniejszy zakres.
Użytkownicy i procesy: opisz pracę razem z wyjątkami
Dla każdej roli zapisz trzy rzeczy: kim jest, ile jest takich osób i co robi w systemie. "Klient hurtowy, około 200 firm, składa zamówienia i sprawdza ich status" mówi wykonawcy więcej niż "użytkownicy zewnętrzni". Liczba osób wpływa na wydajność i koszty usług zewnętrznych, a lista czynności na uprawnienia.
Proces opisz tak, jak opowiedziałbyś go nowej osobie w zespole. Krok po kroku, kto co robi i co jest sygnałem do następnego kroku. Najważniejsza część tego opisu to wyjątki, bo w nich kryje się większość pracy programistycznej:
- Co się dzieje, gdy klient zmienia zamówienie po jego opłaceniu?
- Co, jeśli towaru zabraknie w magazynie po przyjęciu zamówienia?
- Kto może anulować zamówienie i na jakim etapie?
- Jak traktujecie klienta, który ma indywidualne ceny albo termin płatności?
Każdy wyjątek, który pojawi się dopiero w trakcie projektu, to zmiana zakresu i dodatkowy czas. Każdy wpisany do briefu to pozycja w wycenie. Jeśli nie wiesz, jakie są wyjątki, zapytaj osoby, które wykonują tę pracę na co dzień. One znają je lepiej niż ktokolwiek w zarządzie.
Funkcje opisane sytuacjami, nie hasłami
Hasło w briefie brzmi konkretnie, ale każdy wykonawca rozumie je inaczej. "Panel administracyjny", "system rezerwacji" i "integracja z płatnościami" mogą oznaczać dwa dni pracy albo dwa miesiące. Funkcję opisuje się dobrze wtedy, gdy wiadomo, kto ją wykonuje, co robi i po czym poznasz, że działa.
Wygodny format to krótka historia użytkownika z kryteriami:
Jako pracownik magazynu chcę widzieć listę zamówień opłaconych i niewysłanych, posortowaną od najstarszego, żeby pakować je w kolejności.
Działa, gdy:
- lista nie pokazuje kwot ani danych płatności,
- po wpisaniu numeru przesyłki zamówienie zmienia status na "wysłane", a klient dostaje maila z numerem,
- zamówienie bez numeru przesyłki nie może dostać statusu "wysłane".
Trzy linijki kryteriów zastępują godzinę dyskusji przy odbiorze. Wykonawca wie, co wycenić, a Ty wiesz, co sprawdzić. Kryteria nie muszą być kompletne. Wystarczy, że opisują to, co dla Ciebie ważne, a resztę wykonawca dopyta.
Jeśli funkcji jest dużo, nie musisz każdej rozpisywać w ten sposób. Rozpisz te, które są konieczne w pierwszej wersji albo nietypowe dla Twojej branży. Funkcje standardowe, na przykład reset hasła albo formularz kontaktowy, mogą zostać jednym zdaniem.
Priorytety: co jest konieczne w pierwszej wersji
Lista funkcji bez priorytetów to częsty powód, dla którego wyceny tego samego briefu bardzo się od siebie różnią. Jedna firma wyceni wszystko, druga tylko to, co uzna za najważniejsze, trzecia zaproponuje własny podział. Każda będzie miała rację, bo brief na to pozwolił.
Prosty sposób na priorytety to cztery kategorie:
| Kategoria | Co oznacza | Test |
|---|---|---|
| Konieczne | Bez tego nie uruchomisz systemu | Czy wystartowałbyś bez tej funkcji? Jeśli nie, jest konieczna |
| Ważne | Bez tego system działa, ale z wyraźnymi brakami | Czy przez pierwszy miesiąc da się to obejść ręcznie? |
| Mile widziane | Ułatwienia, które poprawiają wygodę | Czy ktoś zauważy brak w pierwszym tygodniu? |
| Świadomie odłożone | Pomysły na kolejne wersje | Czy wykonawca powinien o nich wiedzieć, żeby nie zablokować ich architekturą? |
Ostatnia kategoria jest niedoceniana. Jeśli planujesz za rok aplikację mobilną albo drugą wersję językową, napisz o tym, nawet jeśli nie chcesz jej teraz wyceniać. Wykonawca zaprojektuje system tak, żeby dodanie tej funkcji nie wymagało przebudowy.
Jeśli wszystko trafia do kategorii "konieczne", zrób test inaczej: wyobraź sobie, że budżet jest o połowę mniejszy. Funkcje, z których zrezygnowałbyś najpierw, nie są konieczne. Priorytety przydają się też później. Przy modelu ze stałym budżetem i zmiennym zakresem to one decydują, co wypada, gdy coś zajmie więcej czasu, niż zakładano.
Dane i integracje: najczęstsze źródło niespodzianek
Dane opisz liczbami i przykładami. Ile jest produktów, klientów, zamówień miesięcznie, jak szybko ta liczba rośnie. Gdzie dane są dziś: w arkuszu, w starym systemie, w programie księgowym, w głowach pracowników. Czy trzeba je przenieść i w jakim są stanie. Najlepszym opisem stanu danych jest próbka: kilkadziesiąt wierszy z prawdziwego pliku, z zachowanym formatem i bałaganem, ale z zanonimizowanymi danymi osobowymi.
Integracje wymagają jeszcze większej precyzji, bo każda zależy od systemu, którego wykonawca nie zna, dopóki go nie zobaczy. "Integracja z księgowością" to nie jest opis. Dla każdej integracji podaj:
| Informacja | Przykład | Po co wykonawcy |
|---|---|---|
| Nazwa systemu i wersja lub plan | Konkretny program do faktur w wersji chmurowej | Różne wersje mają różne możliwości |
| Kierunek przepływu danych | Panel wysyła zamówienia, program odsyła numer faktury | Wymiana w obie strony to więcej pracy |
| Częstotliwość | Na bieżąco czy raz dziennie | Wymiana na bieżąco wymaga obsługi błędów i ponowień |
| Dokumentacja API | Link do dokumentacji albo informacja, że jej nie ma | Brak dokumentacji to największa niewiadoma |
| Dostęp | Kto założy konto testowe i kto ma kontakt z dostawcą | Bez dostępu nie da się zacząć pracy |
Jeśli system ma wystawiać albo pobierać faktury, wpisz wprost, który program je wystawia. Od 1 lutego 2026 roku obowiązek wystawiania faktur w Krajowym Systemie e-Faktur objął podatników, których sprzedaż w 2024 roku przekroczyła 200 mln zł, a od 1 kwietnia 2026 roku większość pozostałych. Najmniejsi podatnicy mogą do końca 2026 roku wystawiać faktury poza KSeF, dopóki ich miesięczna sprzedaż udokumentowana fakturami nie przekracza 10 000 zł brutto. Aktualny harmonogram publikuje Ministerstwo Finansów na stronie ksef.podatki.gov.pl. Dla briefu oznacza to jedno: wykonawca musi wiedzieć, czy faktury powstają w programie, który obsługuje KSeF, czy integrację z KSeF ma obsłużyć budowany system.
Wymagania niefunkcjonalne i prawne
Wymagania niefunkcjonalne opisują nie to, co system robi, ale jak ma działać. Wpływają na architekturę, więc wykonawca musi je znać przed wyceną, a nie po wdrożeniu:
- Urządzenia i przeglądarki. Czy system będzie używany głównie na telefonie, na komputerze w biurze, czy na tablecie w magazynie.
- Wersje językowe. Ile języków, czy od startu i kto przygotuje tłumaczenia.
- Ruch. Ile osób korzysta naraz i czy są szczyty, na przykład kampania albo sezon.
- Bezpieczeństwo. Jakie dane system przechowuje, czy potrzebne jest logowanie dwuskładnikowe, jak często mają powstawać kopie zapasowe.
- Dostępność cyfrowa. Czy system ma spełniać wymagania dostępności i do jakiego poziomu WCAG ma się odnosić wykonawca. Aktualną rekomendacją W3C jest WCAG 2.2.
Przy dostępności sprawdź, czy dotyczą Cię przepisy. Od 28 czerwca 2025 roku obowiązuje ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, która wdraża europejski akt o dostępności. Obejmuje między innymi usługi handlu elektronicznego świadczone konsumentom, czyli w praktyce sklepy internetowe. Nie stosuje się jej do usług świadczonych przez mikroprzedsiębiorców (art. 4 pkt 1), czyli w uproszczeniu firm zatrudniających mniej niż 10 osób, z rocznym obrotem albo sumą bilansową nieprzekraczającą równowartości 2 mln euro. Jeśli ustawa Cię obejmuje, zapisz to w briefie, bo dostępność projektuje się od początku, a nie dodaje po odbiorze.
Przy danych osobowych zapisz, jakie dane system będzie przetwarzał, kto jest ich administratorem i czy masz wymagania co do miejsca ich przechowywania. Jeśli wykonawca będzie miał do nich dostęp, na przykład przy imporcie albo utrzymaniu serwera, potrzebna będzie umowa powierzenia przetwarzania danych zgodna z art. 28 RODO. Napisz też, kto przygotowuje regulamin i politykę prywatności. Zwykle robi to prawnik zamawiającego, a wykonawca wdraża mechanizmy, które te dokumenty opisują, na przykład zgody i ich zapis.
Budżet i termin: podaj widełki i powód
Wielu zamawiających nie podaje budżetu, licząc, że wykonawcy zaproponują niższe ceny. W praktyce dostają oferty, których nie da się porównać, bo każda firma zgadywała skalę projektu. Jedna wyceniła prosty wariant, druga rozbudowany, trzecia coś pomiędzy. Widełki budżetu nie zdradzają Twojej pozycji negocjacyjnej, tylko mówią wykonawcy, który wariant ma zaproponować.
Podaj przedział i napisz, co w nim jest: tylko wykonanie, czy także treści, licencje i koszty pierwszego roku utrzymania. Jeśli budżet jest twardy, napisz to. Wykonawca zaproponuje wtedy mniejszy zakres pierwszej wersji, zamiast wyceniać całość i zostawiać Cię z wyborem "wszystko albo nic".
Przy terminie najważniejszy jest powód. "Do 30 października" mówi mniej niż "do 30 października, bo wtedy zaczynają się targi i chcemy pokazać system klientom". Z drugiej wersji wykonawca wie, że w razie problemów lepiej oddać na czas mniejszy zakres niż pełny po terminie. Dopisz też, kiedy Ty i osoby decyzyjne jesteście niedostępni. Dwa tygodnie urlopu w środku projektu to dwa tygodnie bez akceptacji, które potrafią przesunąć termin bardziej niż trudność techniczna.
Przykład: fragment briefu panelu zamówień
Poniżej skrócony przykład dla fikcyjnej hurtowni. Pokazuje poziom szczegółu, który wystarcza do pierwszej wyceny.
Problem. Przyjmujemy zamówienia hurtowe mailem i telefonicznie. Trzy osoby przepisują je do arkusza, a potem do programu do faktur. Pomyłki w ilościach zdarzają się kilka razy w miesiącu. Klienci dzwonią z pytaniem o status, bo nigdzie go nie widzą.
Cel i miara. Klient sam składa zamówienie i widzi jego status. Za pół roku chcemy, żeby żadne zamówienie nie było przepisywane ręcznie, a telefonów o status było wyraźnie mniej niż dziś.
Użytkownicy. Około 150 klientów hurtowych, 3 osoby w biurze, 2 osoby w magazynie, właściciel. Magazyn nie widzi cen.
Proces. Zamówienie, potwierdzenie przez biuro, kompletacja, wysyłka, faktura. Wyjątki: klient dopisuje pozycje do potwierdzonego zamówienia, brak towaru po potwierdzeniu, indywidualne ceny dla części klientów.
Konieczne. Składanie zamówień przez klienta, statusy z historią, widok magazynu bez cen, indywidualne cenniki, przekazanie zamówienia do programu do faktur.
Ważne. Powiadomienia mailowe o zmianie statusu, eksport do arkusza.
Odłożone. Aplikacja na telefon dla handlowców.
Integracje. Program do faktur w wersji chmurowej, ma udokumentowane API, konto testowe założymy. Dane o produktach eksportujemy dziś do pliku CSV z programu magazynowego.
Budżet i termin. Przedział kwot netto (w prawdziwym briefie wpisz konkretne liczby), bez kosztów utrzymania. Start przed sezonem jesiennym, bo wtedy liczba zamówień rośnie. Decyzje podejmuje właściciel, odpowiada na pytania w ciągu dwóch dni roboczych, niedostępny przez dwa tygodnie w październiku.
Ten opis mieści się na jednej stronie, a wykonawca może na jego podstawie zadać konkretne pytania i podać widełki. Specyfikacja z ekranami i regułami powstanie później.
Typowe braki w briefie i co z nich wynika
Każdy z poniższych braków ma ten sam skutek: wykonawca sam uzupełnia lukę założeniem, a każdy robi to inaczej. Wyceny się rozjeżdżają, a różnice w kwotach wynikają z różnych założeń, nie z różnej jakości.
| Brak | Co się dzieje w wycenie | Jak uzupełnić |
|---|---|---|
| Lista funkcji bez priorytetów | Każda firma wycenia inny zakres | Cztery kategorie priorytetów |
| Hasła zamiast funkcji | Szerokie widełki albo wąska interpretacja | Sytuacje z kryteriami |
| Integracja bez nazwy systemu | Duży zapas w cenie albo wyłączenie z zakresu | Nazwa, wersja, dokumentacja, dostęp |
| Brak informacji o danych | Przeniesienie danych nie jest wycenione i wraca w trakcie | Liczby i próbka danych |
| Nie wiadomo, kto dostarcza treści | Termin się przesuwa, pojawia się dodatkowy koszt | Lista materiałów z osobą i datą |
| Brak budżetu | Oferty w różnych wariantach, nieporównywalne | Widełki i co obejmują |
| Termin bez powodu | Wykonawca nie zaproponuje mniejszej pierwszej wersji | Data i powód |
| Brak osoby decyzyjnej | Pytania czekają, akceptacje się opóźniają | Imię, rola, czas odpowiedzi |
| Pominięte wymagania prawne | Zgody, dostępność albo faktury wychodzą po wycenie | Lista przepisów, które Cię dotyczą |
| Brief opisuje gotowe rozwiązanie | Wycena dotyczy rozwiązania, nie problemu | Opis problemu, a narzucenie z uzasadnieniem |
Ostatni wiersz wymaga komentarza. Jeśli masz dobry powód, żeby narzucić technologię, na przykład zespół wewnętrzny, który zna jeden system, albo istniejącą licencję, napisz to razem z powodem. Wtedy wykonawca uszanuje ograniczenie albo uczciwie powie, że w Twojej sytuacji nie jest najlepsze. Jeśli powodem jest tylko to, że ktoś polecił konkretne narzędzie, opisz problem i pozwól wykonawcom zaproponować rozwiązanie.
Załączniki, które oszczędzają tygodnie pytań
Brief może być krótki, jeśli ma dobre załączniki. Każdy z poniższych odpowiada na pytania, które inaczej padną w trakcie projektu:
- Próbka danych. Kilkadziesiąt wierszy z arkusza albo eksportu, z prawdziwym formatem.
- Zrzuty ekranu obecnych narzędzi. Arkusz, stary system, formularz, na którym dziś pracujecie.
- Przykładowe dokumenty. Zamówienie, faktura, raport miesięczny, mail z potwierdzeniem.
- Dokumentacja systemów do integracji. Link do dokumentacji API albo kontakt do dostawcy.
- Materiały marki. Logotyp w wersji wektorowej, kolory, fonty, jeśli istnieją.
- Przykłady, które Ci się podobają. Z jednym zdaniem przy każdym, co konkretnie: układ, sposób wyszukiwania, prosty formularz. Sam link nic nie mówi.
- Lista obecnych adresów stron. Przy wymianie strony na nową, żeby wykonawca mógł zaplanować przekierowania.
Nie wysyłaj w briefie prawdziwych danych osobowych klientów. Próbka danych powinna mieć zachowany format i bałagan, ale fikcyjne nazwiska, adresy i numery telefonów. Jeśli wykonawca będzie potrzebował prawdziwych danych, na przykład do importu, przekaż je dopiero po podpisaniu umowy powierzenia przetwarzania danych. Jeśli brief zawiera tajemnice handlowe, poproś o podpisanie umowy o zachowaniu poufności przed wysłaniem.
Jak wysłać brief kilku firmom, żeby wyceny były porównywalne
Brief jest najcenniejszy wtedy, gdy wszyscy wykonawcy dostają dokładnie to samo. Przy kilku firmach pomaga prosty porządek:
Ten sam plik z datą albo numerem wersji. Jeśli coś zmieniasz, wysyłasz nową wersję wszystkim.
Na przykład tydzień na pytania i kolejny tydzień na oferty, żeby odpowiedzi zdążyły trafić do wszystkich.
Pytanie zadane przez jedną firmę i Twoją odpowiedź przekazujesz pozostałym, bez wskazywania, kto pytał.
Prosisz o zakres według Twojej listy funkcji, listę wyłączeń, założenia, model rozliczenia i harmonogram.
Pół godziny na omówienie pytań pokazuje więcej niż sama oferta.
Liczba pytań od wykonawcy jest dobrym sygnałem. Firma, która przeczytała brief uważnie, zwykle wraca z kilkoma konkretnymi pytaniami, na przykład o wyjątki w procesie albo dostęp do API. Firma, która odsyła kwotę bez jednego pytania, wyceniła swoje wyobrażenie o projekcie, a nie Twój brief. Jak potem porównać oferty, opisaliśmy w tekście jak czytać wycenę software house'u, a jak sprawdzić samych wykonawców, w tekście jak wybrać software house.
Najczęściej zadawane pytania
Jak długi powinien być brief projektu?
Tak długi, żeby odpowiadał na pytania ze struktury. Przy stronie firmowej wystarczą dwie, trzy strony. Przy panelu z integracjami kilka stron i załączniki. Długość nie jest zaletą: dwadzieścia stron bez priorytetów jest mniej użyteczne niż trzy strony z jasnym podziałem na konieczne i odłożone.
Czy brief musi określać technologię?
Nie. Technologię dobiera wykonawca na podstawie wymagań. Narzucasz ją tylko wtedy, gdy masz konkretny powód, i ten powód zapisujesz, żeby wykonawca mógł go ocenić.
Czy w briefie podawać budżet?
Tak, w formie widełek z informacją, co obejmują. Bez budżetu każda firma zgaduje skalę projektu i dostajesz oferty, których nie da się porównać.
Co zrobić, jeśli nie wiem, czego dokładnie potrzebuję?
Opisz problem, użytkowników i proces, a w miejscu funkcji napisz, że ich lista jest otwarta. Taki brief jest dobrym punktem wyjścia do płatnego etapu analizy, którego wynikiem jest specyfikacja. To uczciwsze niż wymyślanie funkcji tylko po to, żeby lista była pełna.
Czy software house może napisać brief za mnie?
Może pomóc go uporządkować, ale wiedzy o Twojej firmie, procesach i wyjątkach nie dostarczy nikt poza Tobą i Twoim zespołem. Najlepiej działa wersja robocza napisana przez Ciebie i rozmowa, w której wykonawca zadaje pytania i uzupełnia luki.
Wyślij brief, nawet niedokończony
Brief nie musi być kompletny, żeby był użyteczny. Wersja z wypełnionymi punktami o problemie, użytkownikach i procesie wystarczy, żeby zacząć rozmowę i dostać pierwsze widełki. Resztę uzupełnia się pytaniami.
Jeśli chcesz, żebyśmy spojrzeli na Twój brief albo pomogli go uzupełnić, wyślij go przez formularz kontaktowy. Jak wygląda dalsza współpraca, od wyceny po wdrożenie, opisaliśmy na stronie Jak pracujemy. Działamy od 2020 roku, a po zakończeniu każdego projektu dostajesz prawa do kodu i dokumentację, dzięki której system może przejąć inny zespół.
