Jak przygotować brief dla software house'u, żeby dostać trafną wycenę

Co powinno się znaleźć w dobrym briefie

Opis problemu biznesowego, nie tylko listy funkcji — „chcemy skrócić czas obsługi zamówienia" mówi wykonawcy więcej niż sucha lista ekranów do zbudowania. Kontekst pozwala zaproponować lepsze rozwiązanie, czasem prostsze niż to, które klient wyobrażał sobie na starcie.

Konkretne dane: przybliżona liczba użytkowników systemu, istniejące narzędzia do zintegrowania, termin, w którym rozwiązanie jest potrzebne, oraz orientacyjny budżet — nawet w widełkach. Brak budżetu w briefie to najczęstszy powód, dla którego wyceny od różnych firm zupełnie się rozjeżdżają.

Czego nie trzeba wiedzieć na etapie briefu

Nie trzeba znać technologii, w jakiej ma powstać rozwiązanie — dobór stacku to zadanie wykonawcy, nie zamawiającego. Nie trzeba też mieć gotowego projektu graficznego ani pełnej specyfikacji technicznej — to część procesu, którą przeprowadza software house na etapie analizy.

Warto za to unikać zbyt szczegółowego opisywania „jak" ma działać system, kosztem wyjaśnienia „po co" — dobry wykonawca może zaproponować lepsze „jak", jeśli rozumie cel.

Jak porównywać oferty przygotowane na podstawie tego samego briefu

Poproś każdą firmę o rozbicie wyceny na etapy i o pytania, jakie mają po przeczytaniu briefu — brak pytań to często sygnał, że oferta jest szablonowa, a nie dopasowana do konkretnego problemu.

Częste pytania