W każdym projekcie IT kluczem do sukcesu jest jak najlepsze zrozumienie celów i potrzeb Klienta oraz pewność, że software house może dostarczyć produkt, który spełni jego oczekiwania. Często na etapie wyboru potencjalnego wykonawcy możesz natrafić na trudności w klarownym przedstawieniu wymagań, a narzędziem, które może być Ci pomocne, jest brief dla software house.

W tym artykule znajdziesz szczegółowy plan dobrego briefu oraz dowiesz się, dlaczego warto poświecić czas na jego przygotowanie. Zapraszamy do lektury.

Czym jest brief dla software house’u?

Brief jest materiałem, w którym Klient w zwięzły sposób przedstawia informacje na temat swojej firmy oraz szczegółów zlecenia. Z niego software house, który ma przygotować propozycję i wycenę swojej usługi, powinien dowiedzieć się między innymi, jakiego typu rozwiązanie miałby opracować, dla kogo, jakie są cele projektu, a także jakie są wymagania funkcjonalne oraz niefunkcjonalne wobec oprogramowania.

Im więcej informacji będzie zawierać przesłany do software house’u brief, tym lepiej będzie on w stanie zrozumieć Twój projekt i potrzeby, a przygotowana wycena będzie dzięki temu dokładniejsza.

Z drugiej strony warto pamiętać, że dobrze przygotowany brief nie musi być bardzo rozbudowany, gdyż najczęściej przedstawiciele software house’u będą mieli dodatkowe pytania i skontaktują się z Tobą, aby doprecyzować Twoje oczekiwania.

Dlaczego warto przygotować brief dla software house’u?

Brief jest pomocnym narzędziem, które pozwala potencjalnemu partnerowi nie tylko zrozumieć Twoje cele i potrzeby w zakresie zamawianego oprogramowania, ale również poznać lepiej Twoją firmę, jej specyfikę oraz oczekiwania.

Z kolei dla Ciebie czas poświęcony na przygotowanie briefu dla software house’u usprawni poszukiwanie odpowiedniego wykonawcy. Dobry brief będzie zwierać większość podstawowych informacji potrzebnych oferentom do przygotowania propozycji, dlatego nie będziesz musiał odpowiadać osobno na te same pytania kierowane przez różne firmy.

Jakie są korzyści z dobrze przygotowanego briefu oprogramowania?

1. Pozwala na lepsze poznanie i zrozumienie Twoich potrzeb, celów i specyfiki projektu.
2. Oszczędza Twój czas, gdyż potencjalni wykonawcy od razu znają zakres zamówienia i są w stanie szybko określić, czy mogą się podjąć tego zadania, dzięki czemu dalsze rozmowy prowadzisz z mniejszą liczbą firm.
3. Pozwala oferentom na określenie na wczesnym etapie, jakie będą odpowiednie dla projektu technologie i narzędzia, dzięki czemu przesłana wycena jest dokładniejsza.
4. Pomaga wybrać odpowiedniego wykonawcę, gdyż od początku widzisz, jak poważnie podchodzi on do określonych przez Ciebie celów i potrzeb, dzięki czemu możesz ocenić, jak mogłaby wyglądać dalsza współpraca.
5. Stanowi zabezpieczenie dla obu firm, gdyż dzięki szczegółowemu opisowi potrzeb i oczekiwań pomaga uniknąć wielu nieporozumień na dalszych etapach.
6. Dobrze napisany brief pomaga przyspieszyć rozpoczęcie prac nad oprogramowaniem.

Aby brief dla software house’u przyniósł oczekiwane rezultaty, należy go odpowiednio przygotować. W dalszej części artykułu znajdziesz wskazówki, co powinno się w nim znaleźć, aby spełnił swoje zadanie.

Co powinien zawierać brief dla software house?

Dobrze przygotowany brief będzie stanowić dla software house’u podstawę do przygotowania dla Ciebie oferty, a im więcej informacji w nim zawrzesz, tym większa szansa, że propozycja ta spełni Twoje oczekiwania.

Trzeba wziąć pod uwagę, że im bardziej skomplikowany jest projekt, tym więcej informacji powinien zawierać brief dla software house’u, ale też nikt po drugiej stronie nie oczekuje od Ciebie opracowania na kilkadziesiąt stron. Wartościowy brief jest dopasowany zawartością do skali projektu, ani zbyt szczegółowy, ale też nie nazbyt ogólnikowy.

Jakie informacje powinien uwzględniać dobry brief dla software house’u?

1. Informacje o Twojej firmie.
2. Cele i oczekiwania stawiane oprogramowaniu.
3. Skrócony opis projektu oraz aktualny stan zaawansowania prac.
4. Wstępny harmonogram projektu.
5. Informacje o ewentualnej konkurencji.
6. Ograniczenia dotyczące formy współpracy oraz budżetu.
7. Dodatkowe kryteria wyboru partnera.

Tak jak wspominaliśmy, stopień rozbudowania briefu będzie uzależniony od kilku czynników, między innymi typu oraz skali projektu. Charakteryzując poszczególne elementy, które powinien zawierać brief, przyjęliśmy założenia typowe dla dużych, skomplikowanych projektów, takich jak tworzenie rozbudowanego oprogramowania dedykowanego.

Co powinien zawierać brief dla software house’u #1

Informacje o Twojej firmie

Dobry software house będzie chciał poznać Twoją firmę, aby lepiej dopasować swoją ofertę do indywidualnej specyfiki i oczekiwań. Dlatego, mimo iż informacje dotyczące przedsiębiorstwa nie mają na ogół wpływu na wysokość wyceny, to nie powinno się ich pomijać, przygotowując brief oprogramowania.

Warto uwzględnić w briefie następujące informacje:

• krótką historię firmy oraz opis wartości, którymi się kieruje w swoich działaniach,
• profil działalności zamawiającego,
• sektor lub sektory, w których działa firma,
• wielkość przedsiębiorstwa,
• oferowane produkty lub usługi,
• na jakich rynkach działa przedsiębiorstwo,
• wielkość i skład zespołu projektowego po stronie Klienta, o ile jest wydzielony,
• adres strony internetowej firmy oraz dane osoby kontaktowej.

Dysponując takimi informacjami, software house będzie w stanie lepiej Cię poznać i przedstawić dopasowaną ofertę.

Co powinien zawierać brief dla software house’u #2

Cele i oczekiwania względem oprogramowania

Po wstępnym przedstawieniu firmy i jej specyfiki kolejnym punktem powinno być zarysowanie Twoich oczekiwań względem oprogramowania, a dokładniej: jaki problem (lub jakie problemy) ma rozwiązywać oraz komu służyć.

W ramach ogólnej charakterystyki projektu warto zawrzeć informacje takie jak:

• typ oprogramowania, którym jesteś zainteresowany,
• czy chcesz stworzyć nowy system czy zmodyfikować już istniejący,
• ideę, która stoi za projektem,
• główne cele, które chcesz osiągnąć dzięki systemowi,
• opis grup odbiorców i ich wymagań (w podziale na zewnętrznych oraz wewnętrznych, takich jak administratorzy i pracownicy),
• kierunek, w którym będzie rozwijany projekt w przyszłości.

Dzięki odpowiednio zdefiniowanym i mierzalnym celom będziesz mógł ocenić, czy projekt został zrealizowany zgodnie z Twoimi oczekiwaniami.

Z kolei odpowiednie scharakteryzowanie grup docelowych oraz ich potrzeb pozwoli już na wstępnym etapie lepiej oszacować wymagania, które spełniać musi system.

Co powinien zawierać brief dla software house’u #3

Informacje o ewentualnej konkurencji

Nie jest to element niezbędny i nie będzie mieć zastosowania w przypadku niektórych projektów, ale w sytuacji, kiedy Twój system ma być konkurencyjny względem innych, dostępnych już na rynku rozwiązań, warto, aby software house lepiej zrozumiał otoczenie konkurencyjne, w którym działasz.

Możesz podejść do tej części briefu na dwa sposoby:

1. Przedstawić, jakie funkcje lub rozwiązania zastosowane w Twoim oprogramowaniu mają wyróżnić je na tle konkurencji, podkreślając czego w innych systemach obecnie brakuje;
2. wskazać, które z rozwiązań wykorzystanych przez konkurencję Twoim zdaniem powinny się znaleźć w podobnej formie w Twoim systemie, oraz które są według Ciebie zbędne i nie powinny być brane pod uwagę na przykład w ramach propozycji ze strony wykonawcy.

Ideą stojącą przed wyborem software house’u jest najczęściej opracowanie dedykowanego rozwiązania lub zmiana już używanego przez Ciebie systemu, tak aby lepiej odpowiadał Twoim potrzebom. Dlatego im więcej informacji o podobnych rozwiązaniach, na których opierałeś się, decydując o zamówieniu własnego systemu, przekażesz wykonawcy, tym lepiej.

Co powinien zawierać brief dla software house’u #4

Opis projektu oraz aktualny stan zaawansowania prac

Zawarta w tej części briefu charakterystyka projektu będzie bez wątpienia jednym z najważniejszych punktów dla software house’u, gdyż to od funkcji, które będzie miało posiadać oprogramowanie w znacznym stopniu będzie uzależniona wysokość wyceny.

Zdajemy sobie sprawę, że ilość informacji, które możesz tu zawrzeć, będzie uzależniona od tego, jak skonkretyzowana jest Twoja wizja oprogramowania, które chciałbyś zamówić. Jeśli masz tylko ogólny pomysł oraz wskazówki co do głównych funkcji, firmy takie jak SOFTIQ będą w stanie pomóc Ci w doprecyzowaniu pozostałych istotnych szczegółów.

Im więcej jednak wiesz, tym więcej postaraj się przekazać potencjalnemu wykonawcy. W ramach opisu projektu warto jest zawrzeć takie informacje, jak:

• zadania, które ma spełniać oprogramowanie,
• funkcje, które system musi posiadać,
• platformy, na których ma być dostępne oprogramowanie,
• wymagania niefunkcjonalne, o ile jesteś w stanie je określić na tym etapie (dotyczące na przykład wydajności lub bezpieczeństwa),
• konkretne języki programowania lub technologie, o ile z jakiegoś powodu muszą być wykorzystane i uwzględnione w propozycji przez software house,
• wymagane integracje z innymi systemami lub bazami danych, wykorzystywanymi w Twojej firmie.

Jeśli będziesz w stanie określić, które funkcje system musi posiadać na początku, a które są mniej ważne i chciałbyś dodawać je sukcesywnie w miarę rozwoju projektu w przyszłości, warto jest również tę informację zawrzeć w briefie.

Warto również wspomnieć, których funkcji, często spotykanych w podobnych systemach nie będziesz potrzebować ze względu na specyfikę swojej działalności – dzięki temu masz pewność, że wycena (a w efekcie produkt końcowy) będzie dopasowany do Twoich indywidualnych potrzeb.

Często zdarza się również, że Klienci zgłaszają się do nas, mając już wykonaną na przykład większą część prac koncepcyjnych, dlatego brief dla software house’u powinien informować również, co w ramach projektu zostało już zrealizowane.

Software house powinien wiedzieć, czy posiadasz na przykład:

• szkice, diagramy lub mockupy, które na tym etapie ilustrują Twoją wizję i oczekiwania względem projektu,
• analizy, badania rynkowe, testy i ankiety wśród docelowych użytkowników,
• plan rozwoju oprogramowania,
• ewentualne prototypy lub wersje MVP oprogramowania, o ile były opracowane.

Pamiętaj, że lista funkcji i wymagań, którą zawiera brief dla software house’u, nie jest ostateczna, zaś finalny kształt systemu zostanie ustalony przez Ciebie wspólnie z zespołem pracującym po stronie wykonawcy.

Mając jednak jak najbardziej szczegółowe informacje o Twoich oczekiwaniach i potrzebach, dzięki naszemu wieloletniemu doświadczeniu w realizacji podobnych projektów, możemy przygotować dla Ciebie ofertę odpowiadającą Twoim potrzebom oraz zaproponować dodatkowe opcje, które być może będziesz chcieć wykorzystać w produkcie końcowym.

Co powinien zawierać brief dla software house’u #5

Wstępny harmonogram projektu

W miarę możliwości brief dla software house’u powinien zawierać informacje o ograniczeniach czasowych, które mogą mieć ewentualnie odniesienie do Twojego projektu. Nikt na tak wczesnym etapie nie oczekuje od Ciebie dokładnego harmonogramu projektu, szczególnie, iż jego przygotowanie będzie po stronie wykonawcy, we współpracy z Tobą.

Jeśli jednak z jakiegoś powodu poszczególne etapy prac nad projektem lub przekazanie gotowego rozwiązania muszą nastąpić w określonych terminach, to informację taką powinien zawierać dobrze przygotowany brief.

Jakie informacje związane z terminami dotyczącymi projektu warto uwzględnić w materiałach przesłanych do software house?

1. Zakładany czas na analizę otrzymanych ofert oraz wybór wykonawcy.
2. Termin na przygotowanie wersji MVP, jeśli planujesz jej wykonanie w ramach projektu.
3. Preferowany przez Ciebie termin rozpoczęcia prac nad projektem.
4. Ostateczny deadline na przekazanie gotowego rozwiązania.

Każda informacja dotycząca Twoich oczekiwań względem terminów związanych z realizacją projektu będzie mieć znaczenie dla wykonawcy. W przypadku wyjątkowo krótkich terminów konieczne może być zwiększenie zespołu projektowego, co finalnie znajdzie odzwierciedlenie w wycenie.

W przypadku, gdy software house już na początku będzie wiedzieć, jakie są ograniczenia czasowe projektu, będzie w stanie odpowiednio przygotować ofertę. Jeśli na przykład termin wykonania jest bardzo krótki, opcją może być zebranie odpowiednio dużego teamu lub zawężenie zakresu prac do wykonania (jeśli nie da się ich wykonać w zbyt krótkim terminie ze względu na jakość).

Co powinien zawierać brief dla software house’u #6

Ograniczenia dotyczące formy współpracy oraz budżetu

Niektórzy z naszych Klientów od początku wiedzą, na jaki model współpracy chcą się zdecydować, w innych przypadkach zaś proponujemy rozwiązanie, które naszym zdaniem będzie najbardziej optymalne w przypadku ich projektów.

Najczęściej stosowane w branży modele współpracy to Fixed Price lub Time&Material, a każdy z nich przekłada się w znacznym stopniu na sposób, w jaki zorganizowana będzie praca zespołu, jakie będzie Twoje zaangażowanie w projekt oraz na wysokość i stałość budżetu.

Poniżej znajdują się główne różnice między tymi dwoma modelami współpracy, szczególnie w aspekcie budżetu.

1. W modelu Fixed Price – rozliczanie projektu wymaga jak najdokładniejszego oszacowania zakresu prac, aby uniknąć sytuacji, w której software house opracuje zbyt niską lub wysoką wycenę, nie mogąc dość precyzyjnie oszacować wszystkich kosztów. Mając pewność co do wysokości budżetu projektu, Klient może z odpowiednim wyprzedzeniem planować wydatki. Ma to kluczowe znaczenie w przypadku projektów, w których budżet jest stały lub ograniczony.
2. W modelu Time&Material – możliwe jest dynamiczne zarządzanie budżetem projektu i dostosowanie bieżących wydatków do możliwości Klienta. Jednak duża elastyczność w modyfikacji zakresu prac może stanowić ryzyko w sytuacji, gdy w zespole Klienta brakuje osoby mogącej zweryfikować, które funkcje są tak naprawdę zbędne, ponieważ nie przełożą się na efekty biznesowe. W takiej sytuacji rzetelny software house będzie nieocenionym wsparciem, służąc radą, a nie jedynie dodając nowe zadania do listy.

Więcej informacji na temat zalet i wad model rozliczenia Fixed Price oraz Time & Material znajdziesz w artykule na naszym blogu.

Jeśli chodzi o wysokość budżetu, to wielu Klientów nie chce dzielić się informacją o planowanych wydatkach na tak wczesnym etapie. Zawsze podkreślamy jednak, że warto poinformować software house w briefie, jeśli Twój budżet jest ograniczony.

Dzięki temu możliwe będzie dobranie odpowiednich narzędzi oraz technologii, które pozwolą zrealizować projekt w zakładanym czasie oraz przy akceptowalnym dla Ciebie poziomie kosztów. Pamiętaj, że zawsze jest kilka sposobów na rozwiązanie danego problemu, a znając Twoje ograniczenia, software house może dobrać najlepszy z nich.

Co powinien zawierać brief dla software house’u #7

Dodatkowe kryteria wyboru partnera

Ostatnim elementem, o którym warto pamiętać tworząc brief dla software house’u, są ewentualne dodatkowe kryteria wyboru partnera, którymi będziesz się kierować.

Mogą być to wymagania organizacyjne bądź technologiczne, ale niezależnie od tego, jakiego będą typu, dobrze ująć je w Twoich materiałach. Dzięki temu będziesz mieć pewność, że dalsze rozmowy prowadzisz już tylko z odpowiednimi kandydatami, a przygotowane przez nich oferty będą najlepiej dopasowane do Twoich oczekiwań.

Dobry brief jest pomocą, ale nie zastępuje osobistego kontaktu

Dobry brief dla software house jest naprawdę przydatny, ale nie zawsze dostarczy potencjalnemu wykonawcy pełnych informacji, szczególnie gdy jesteś zainteresowany rozbudowanym, dedykowanym rozwiązaniem.

Często software house skontaktuje się z Tobą, aby zadać dodatkowe pytania i upewnić się, że nie pominąłeś jakiejś informacji, która mogła wydawać Ci się oczywista, ale ma znaczenie pod kątem wyceny.

Zdarza się również, że Klient ma jedynie ogólny pomysł, wie co chce osiągnąć, a bezpośredni kontakt z software house będzie wtedy pomocny w doprecyzowaniu wizji rozwiązania, które miałoby powstać.

Podsumowanie

Dobrze przygotowany brief dla software house’u jest narzędziem, które pomaga potencjalnemu wykonawcy zrozumieć Twoje cele oraz potrzeby i przygotować ofertę na rozwiązanie, które najpełniej je zrealizuje.

Jednocześnie brief nie powinien być utożsamiany z pełną specyfikacją projektu. Często wiele opisanych w briefie elementów może ulec zmianie na etapie dalszych rozmów z software housem, a dalsze modyfikacje w zakresie funkcji pojawić się mogą już na etapie prac. Jest to normalne, ale warto poświęcić czas na przygotowanie odpowiedniego briefu, gdyż dzięki niemu przygotowanie oferty dla Ciebie będzie łatwiejsze, a Ty poświęcisz mniej czasu na poszukiwanie najlepszego wykonawcy.

Jeśli masz trudności w przygotowaniu takiego dokumentu, zachęcamy do kontaktu z jednym z naszych konsultantów, który pomoże Ci ustalić, czego możesz jeszcze potrzebować.

Przygotowaliśmy dla Ciebie również przykładowy szablon briefu do wypełnienia, który możesz pobrać z naszej strony internetowej po kliknięciu w ten link.

---

Zapraszamy do lektury naszych artykułów
oraz pobrania przydatnych materiałów!

This post is also available in: English (Angielski)