Jak napisać brief dla software house: wzór z wypełnionym przykładem

Brief dla software house’u to jednostronicowy dokument opisujący problem biznesowy, cel, użytkowników i granice projektu na tyle precyzyjnie, żeby kilka firm policzyło dokładnie to samo zadanie. Jak napisać brief dla software house, jeśli nie znasz się na technologii? Opisujesz problem i liczby, które już masz w firmie, a nie rozwiązanie. Każdą sekcję pokazujemy tu na wypełnionym przykładzie: hurtownia materiałów elektrycznych, 40 stałych klientów B2B, zamówienia spływające mailem — podmieniasz nazwy i wysyłasz.

Co musi znaleźć się w briefie, żeby oferty dało się porównać

Brief potrzebuje jedenastu sekcji: kontekst firmy, problem, cel mierzalny, użytkownicy i ich ścieżka, zakres MUST/SHOULD, wyłączenia, systemy do integracji, ograniczenia, budżet, termin z uzasadnieniem i osoba decyzyjna. Każda odpowiada na pytanie, które i tak padnie — różnica polega na tym, czy padnie przed wyceną, czy dwa tygodnie po podpisaniu umowy, gdy zmiana zakresu kosztuje już realne pieniądze.

Jeśli wolisz nie zaczynać od pustej strony, przez te same pola przeprowadza w sześciu krokach (projekt, firma, cel, zasięg, ramy, kontakt) kreator briefu: odpowiedzi zostają w karcie przeglądarki i składają się na gotową wiadomość.

Wypełniony przykład: kontekst, problem, cel i użytkownicy

Pierwsze cztery sekcje mają jedno zadanie: pokazać, że problem jest policzalny. Poniżej wersja dla przykładowej hurtowni.

• Kontekst firmy. „Hurtownia materiałów elektrycznych, 18 pracowników, magazyn w jednej lokalizacji, 40 stałych klientów B2B (instalatorzy i mniejsze hurtownie), około 3 tysięcy indeksów w ofercie.”
• Problem. „Zamówienia przychodzą mailem i telefonicznie w dowolnym formacie. Dwie osoby z biura obsługi przepisują je ręcznie do systemu magazynowego, co zajmuje im łącznie około 3 godzin dziennie. Pomyłki w indeksach kończą się zwrotami, a klient nie widzi stanu magazynu ani statusu swojego zamówienia.”
• Cel mierzalny. „W ciągu sześciu miesięcy od uruchomienia 80% zamówień od stałych klientów ma powstawać w panelu bez udziału biura obsługi, a czas przepisywania ma spaść poniżej 30 minut dziennie.”
• Użytkownicy i ścieżka. „Trzy role: klient B2B (loguje się, widzi swoje ceny i stany, składa zamówienie, śledzi status), pracownik biura obsługi (zatwierdza nietypowe zamówienia, obsługuje wyjątki), administrator (zakłada konta, ustala limity kupieckie).”

Funkcje opisuj szablonem user story: „Jako [rola] chcę [funkcja], aby [korzyść]”. Zdanie „Jako instalator chcę widzieć swoją cenę netto przy każdym indeksie, aby nie dzwonić po potwierdzenie” niesie więcej informacji niż punkt „cenniki indywidualne”.

Wypełniony przykład: zakres, wyłączenia, integracje i ograniczenia

Te cztery sekcje decydują o cenie, bo mieszczą się w nich niewiadome, które wykonawca musiałby obłożyć buforem. Priorytety zapisuj według MoSCoW (Must, Should, Could, Won’t have) — w briefie wystarczą dwie pierwsze kategorie i lista wyłączeń.

• MUST. „Logowanie klienta z indywidualnym cennikiem, koszyk z aktualnym stanem magazynowym, historia zamówień, powiadomienie mailowe o zmianie statusu, panel administratora do zakładania kont.”
• SHOULD. „Limity kupieckie i blokada przy przekroczeniu, szablony zamówień cyklicznych, eksport historii do pliku CSV.”
• Poza zakresem. „Aplikacja mobilna, sprzedaż detaliczna, płatności online, wersje językowe inne niż polska, migracja zamówień starszych niż 24 miesiące.”
• Systemy do integracji. „System magazynowo-sprzedażowy Subiekt GT — zamówienie ma powstawać w nim automatycznie. Nie wiemy, czy nasza wersja udostępnia API; prosimy o wskazanie w ofercie, jak zamierzacie to sprawdzić i jaki jest wariant zapasowy.”
• Ograniczenia. „Dane kontaktowe klientów podlegają RODO, więc panel ma działać na serwerze w Unii Europejskiej. Firma korzysta z Microsoft 365 i tam chcemy trzymać logowanie.”

Sekcja o wyłączeniach jest najbardziej opłacalnym akapitem briefu, bo przenosi cztery decyzje z etapu realizacji na etap wyceny. Jak głęboko ciąć pierwszą wersję, opisuje tekst o tym, co powinno wejść do zakresu MVP, a wymianę danych — poradnik o tym, jak działa integracja systemów w firmie.

Czy podawać budżet w zapytaniu ofertowym

Tak — podawaj widełki, nie kwotę jednostkową. Bez nich każdy wykonawca sam zgaduje skalę: jeden policzy panel na gotowym silniku e-commerce, drugi rozwiązanie pisane od zera z osobną warstwą integracyjną. Dostajesz oferty na trzy różne projekty i porównujesz nie ceny, tylko cudze założenia.

Widełki działają jak ograniczenie zakresu: wykonawca, który je zna, odpowiada „w tej kwocie mieści się MUST i dwa punkty z SHOULD, reszta w drugim etapie”. Bez nich tracisz tygodnie na rozmowy o projektach, na które nie masz środków.

Przed zawyżeniem chroni Cię nie ukrywanie budżetu, tylko struktura zapytania: rozbicie ceny na moduły, lista przyjętych założeń i jedno pytanie kontrolne — co wypada z zakresu, jeśli budżet będzie niższy o 30%. Odpowiedź pokazuje, czy wykonawca rozumie priorytety, czy tylko dopasował kwotę do Twoich widełek. Z czego składa się taka wycena, rozbieramy w tekście o tym, ile kosztuje aplikacja mobilna.

Czego nie musisz wiedzieć, żeby napisać brief

Nie musisz znać technologii, architektury ani nazw frameworków — brief opisuje problem, nie rozwiązanie. Narzucenie stosu technologicznego bez powodu zawęża pole wyboru i potrafi podnieść cenę, bo wykonawca dopasowuje się wtedy do decyzji, której nic nie uzasadnia.

Nie musisz też wiedzieć, ile potrwa realizacja ani jak wygląda kolejność prac; to element oferty, a nie zapytania — cały przebieg opisuje poradnik o tym, jak stworzyć aplikację mobilną. W briefie wystarczy zdanie: „nie mamy zdania co do technologii, prosimy o rekomendację wraz z uzasadnieniem”.

Nie musisz mieć listy wszystkich funkcji. Musisz mieć problem opisany liczbami, cel i informację, czego na pewno nie chcesz — resztę doprecyzuje warsztat.

Jak sformułować kryteria oceny i format odpowiedzi

Narzuć w briefie strukturę oferty, inaczej dostaniesz trzy dokumenty w trzech układach i nie zestawisz ich jeden do jednego. To najczęstszy błąd w zapytaniach ofertowych. Gotowy układ dokumentu, kryteria z wagami i wymagany format odpowiedzi pokazuje wzór na zapytanie ofertowe na oprogramowanie.

Poproś o wycenę w rozbiciu na moduły, listę założeń, harmonogram z kamieniami milowymi, skład zespołu, formę rozliczenia (stała cena czy rozliczenie za czas pracy), zakres gwarancji po wdrożeniu oraz zasady przeniesienia praw do kodu. Dopisz kryteria wyboru z wagami — wtedy wykonawca wie, co naprawdę ważysz. O tym, czy w Twoim przypadku lepszy jest fixed price czy time and material, przesądza dojrzałość zakresu opisanego w briefie, więc warto mieć tę odpowiedź jeszcze przed wysyłką zapytania.

Trzy oferty w jednym formacie mówią więcej niż pięć w pięciu układach. Odpowiedzi na pytania rozsyłaj wszystkim firmom w tym samym brzmieniu — inaczej porównujesz oferty oparte na różnych informacjach. Sam format nie rozstrzyga jednak, jak wybrać software house — o tym decydują pytania zadane przy pierwszej rozmowie i to, które odpowiedzi wypadną wymijająco.

NDA i prawa do kodu: co ustalić, zanim wyślesz brief

W pierwszym mailu z zapytaniem o dostępność i orientacyjny koszt nie ujawniaj informacji poufnych: struktury cen, listy klientów, danych osobowych ani kodu — opis problemu i skali wystarczy do wstępnej rozmowy. Umowę o zachowaniu poufności zawiera się, zanim przekażesz materiały wrażliwe, najpóźniej przed warsztatem discovery, na którym wykonawca zbiera szczegóły potrzebne do rzetelnej oferty.

Prawa do kodu ustal na etapie briefu, a nie po odbiorze. Zapłata faktury sama w sobie nie przenosi autorskich praw majątkowych: potrzebna jest umowa, która zgodnie z art. 53 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych wymaga formy pisemnej pod rygorem nieważności. Umowa obejmuje wyłącznie pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2), więc pola pominięte zostają przy twórcy — ogólnikowy zapis o „wszystkich polach” nie zastąpi ich wyliczenia. Które konkretnie klauzule muszą znaleźć się w kontrakcie, żeby prawa autorskie do kodu rzeczywiście przeszły na Twoją firmę, rozkłada osobny tekst.

Zapytaj też, kto fizycznie pisze kod. Art. 74 ust. 3 tej samej ustawy przyznaje prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy pracodawcy, o ile umowa nie stanowi inaczej — ale przepis dotyczy stosunku pracy. Kod pisany przez współpracowników B2B i podwykonawców wymaga osobnego, pisemnego przeniesienia praw w całym łańcuchu umów. W briefie dopisz więc zdanie, że oczekujesz przeniesienia praw z wymienionymi polami eksploatacji oraz przekazania kodu źródłowego, specyfikacji i dokumentacji użytkownika i deweloperskiej. Ten opis ma charakter informacyjny i nie jest poradą prawną.