Brief do software house: co przekazać, żeby rozpocząć rozmowę o projekcie

Brief to początek rozmowy

Dobry brief do software house nie musi przypominać dokumentacji technicznej. Powinien pozwolić drugiej stronie zrozumieć, co dzieje się w firmie, gdzie pojawia się trudność i jakiej decyzji oczekujesz po pierwszej rozmowie. Nie musisz znać nazwy frameworka ani rysować wszystkich ekranów. Jeśli jednak wiesz, że zgłoszenia giną pomiędzy skrzynką a arkuszem, warto powiedzieć właśnie to.

Sam pomysł „potrzebujemy aplikacji” nie wyjaśnia jeszcze, kto będzie z niej korzystać ani co ma się zmienić w jego pracy. Brief może zmieścić się na kilku stronach, ale jego długość nie jest celem. Liczy się możliwość odróżnienia rzeczy ustalonych od takich, które wymagają sprawdzenia. Brak pewności też jest informacją, o ile zostanie uczciwie nazwany.

Ten tekst pomoże przygotować materiał do rozmowy o konkretnym projekcie. Jeśli dopiero zastanawiasz się nad samym wyborem sposobu współpracy, zacznij od artykułu o tym, jak zamówić aplikację dla firmy. Tutaj skupiamy się na tym, co wpisać do briefu i jakie pytania zostawić otwarte.

Opisz stan obecny jednym przypadkiem

Zacznij od krótkiego obrazu pracy: jaka sprawa trafia do firmy, kto ją przyjmuje, jak przechodzi między ludźmi i kiedy się kończy. Wymień narzędzia używane po drodze, nawet jeśli są nimi zeszyt, e-mail lub rozmowa telefoniczna. Zewnętrzny wykonawca nie zna Waszych skrótów myślowych, a nazwa działu nie tłumaczy jeszcze, co faktycznie dzieje się z zadaniem.

Możesz napisać: „Klient zgłasza potrzebę serwisu przez telefon albo formularz. Koordynator zapisuje ją w arkuszu, a termin potwierdza po kontakcie z technikiem. Historia napraw jest w osobnym systemie”. To fikcyjny przykład, który pokazuje formę opisu. Dzięki niemu łatwiej zapytać o brakujące dane, przekazanie sprawy i dostęp do historii niż po haśle „system do serwisu”.

Dopisz, co obecnie zajmuje najwięcej uwagi albo powoduje poprawki. Nie wymyślaj procentów. Jeśli nie mierzysz czasu realizacji, napisz, że wymaga on ustalenia. Przykłady pojedynczych sytuacji są użyteczne, ale nie dowodzą jeszcze skali problemu. Po rozmowie można wspólnie zdecydować, czy i jak ją sprawdzić.

Pokaż również, co działa dobrze i ma pozostać. Być może pracownicy lubią obecny sposób przydzielania zadań, a problem dotyczy jedynie odnajdywania historii. Nie warto przebudowywać całego procesu tylko dlatego, że jedna jego część wymaga wsparcia.

Przedstaw również, co uruchamia proces i jakie zdarzenie go kończy. Zlecenie może zacząć się od telefonu, a zakończyć dopiero po potwierdzeniu wykonania i przekazaniu informacji do rozliczenia. Jeśli w briefie opiszesz wyłącznie etap przydzielenia pracownika, wykonawca może nie wiedzieć, że później potrzebna jest jeszcze korekta dokumentu. Używaj nazw zrozumiałych w firmie, ale wyjaśniaj skróty i wewnętrzne określenia.

Kto ma korzystać z rozwiązania

Wypisz grupy użytkowników i zadania, które chcą wykonać. „Kierownik chce sprawdzić, które zlecenia czekają na decyzję”, „technik chce zobaczyć adres i zakres pracy”, „klient chce poznać status zgłoszenia” to różne potrzeby. Nie musisz jeszcze rozstrzygać, czy każda z tych osób dostanie osobny ekran.

Zaznacz warunki pracy: biuro, hala, teren, telefon, komputer współdzielony z inną osobą, słabe połączenie. Warto dopisać również potrzeby dostępności, jeśli są znane. Jeżeli z aplikacji mają korzystać pracownicy różnych oddziałów, wskaż obszary wspólne i różnice, które już znasz. Pomocny będzie tekst o projektowaniu systemu dla wielu oddziałów.

Przy grupach użytkowników nie zapomnij o osobach, które zarządzają dostępem, poprawiają błędy lub odpowiadają na pytania klientów. Nie zawsze są widoczne na pierwszym diagramie, a po uruchomieniu systemu często jako pierwsze zobaczą jego niedoskonałości. Dobrze wskazać przedstawiciela każdej istotnej grupy do późniejszych konsultacji.

Przy każdej grupie warto odróżnić potrzeby od proponowanego uprawnienia. Informacja „klient musi znać status” nie oznacza automatycznie, że powinien widzieć wszystkie notatki pracowników. Opisz, jakie informacje są mu potrzebne i dlaczego. Zasady dostępu można następnie doprecyzować z osobą odpowiedzialną za bezpieczeństwo oraz z właścicielem procesu.

Co ma się wydarzyć po wdrożeniu

Zamiast listy modnych funkcji opisz rezultat na przykładzie zadania. „Uprawniony pracownik widzi, czy zgłoszenie ma przypisanego wykonawcę i termin” daje się omówić znacznie konkretniej niż „inteligentny panel zarządzania”. Dopiero potem można zdecydować, czy potrzebny jest dashboard, powiadomienie, raport czy zmiana istniejącego narzędzia.

Jeśli myślisz o automatyzacji lub AI, nazwij czynność oraz osobę odpowiedzialną za wynik. Czy chodzi o przygotowanie propozycji odpowiedzi, przypisanie kategorii czy wykonanie zmiany w innym systemie? Co powinno się wydarzyć, gdy wynik jest niepewny? Rozważania o granicach automatycznej decyzji rozwijamy w tekście o zatwierdzaniu decyzji agenta AI.

Warto oznaczyć potrzeby, bez których pierwsza wersja nie rozwiąże problemu, oraz te, które mogą poczekać. Nie chodzi o obietnicę, że reszta zniknie na zawsze. Chodzi o wybór sensownego pierwszego etapu i zachowanie wiedzy o dalszych zamiarach. O takim wyborze piszemy w artykule o MVP aplikacji.

Jeśli celem jest lepsze planowanie pracy, zapisz, jakie decyzje dziś podejmujecie i czego brakuje do ich podjęcia. Sam wykres nie odpowie na pytanie, czy termin zamówienia jest zagrożony, jeżeli system nie otrzymuje aktualnego statusu. Dobrze przygotowany opis rezultatu pozwala wykonawcy dopytać o źródła informacji i zaproponować kolejność prac, zanim powstanie projekt panelu.

Dane, integracje i ograniczenia

Wymień systemy, z którymi nowe rozwiązanie ma wymieniać informacje, oraz dane potrzebne do działania. Zamiast samej nazwy programu podaj cel: „pobieramy listę produktów”, „przekazujemy status realizacji” albo „sprawdzamy dostępność terminu”. Jeśli nie wiesz, czy dostawca udostępnia odpowiedni interfejs, zaznacz to jako pytanie. Znana nazwa systemu nie potwierdza jeszcze możliwości konkretnej integracji.

Przy każdej ważnej informacji zapisz, skąd pochodzi i kto może ją zmienić. Jeżeli dwa programy pokazują różne adresy klienta, trzeba ustalić, który zapis będzie podstawą decyzji i jak rozwiązać rozbieżność. Wprowadzenie do tego problemu znajdziesz w tekście o źródle danych w integracji.

Podaj też ograniczenia organizacyjne: ważne terminy wynikające z pracy firmy, osoby potrzebne do decyzji, obowiązujące procedury i dostępność zespołu. Jeśli znasz przedział budżetu przeznaczonego na projekt, możesz go podać, wyjaśniając, czy obejmuje wyłącznie wykonanie, czy również późniejsze utrzymanie. Nie musisz deklarować kwoty, której jeszcze nie ustalono.

Nie dołączaj do pierwszej wiadomości haseł, kluczy API, danych kart, pełnych baz klientów ani dokumentów z danymi wrażliwymi. Do omówienia struktury często wystarczy oczyszczony lub fikcyjny przykład. Gdy przyjdzie czas na dostęp, uzgodnij jego zakres, sposób przekazania i osobę odpowiedzialną. Zasady OWASP dotyczące zarządzania sekretami pomagają zaplanować bezpieczne obchodzenie się z takimi danymi.

Przy integracjach zapisz również, kto opiekuje się danym systemem i może odpowiedzieć na pytania techniczne. Być może dostęp do dokumentacji ma wewnętrzny administrator, a może wymaga on kontaktu z dostawcą. Jeżeli przewidujesz przeniesienie starych danych, zaznacz orientacyjnie ich rodzaje i miejsca przechowywania. Dokładny stan oraz jakość zbiorów trzeba sprawdzić osobno.

Odbiór i pytania do wykonawcy

Opisz, po czym poznacie, że rezultat nadaje się do pracy. Dla zgłoszenia serwisowego może to być możliwość zarejestrowania sprawy, przypisania jej do pracownika i sprawdzenia statusu przez uprawnioną osobę. To przykładowy scenariusz, który trzeba dopasować do firmy. Warto dopisać również, co ma się stać przy braku wymaganej informacji albo odrzuceniu zadania.

Nie musisz przygotowywać wszystkich testów samodzielnie. W briefie wystarczy wskazać najważniejsze scenariusze i osobę, która zna proces. Zespół projektowy może później doprecyzować kryteria razem z użytkownikami. O tym, dlaczego „działa na pokazie” nie zastępuje odbioru, piszemy w artykule o kryteriach i testach odbiorowych.

Na końcu zapisz pytania, na które potrzebujesz odpowiedzi. Jak wykonawca sprawdzi możliwość integracji? Co obejmuje pierwsza wycena? Kto przygotuje prototyp i jak będzie testowany? W jaki sposób omawia się zmianę zakresu? Kto po uruchomieniu ma dostęp do kodu, kont i dokumentacji? Porównanie odpowiedzi bywa bardziej wartościowe niż porównanie samych nazw etapów.

Dopisz też, jaka decyzja ma zapaść po pierwszej rozmowie: czy potrzebny jest warsztat, wstępne rozpoznanie integracji, czy oferta na jasno opisany zakres. Dzięki temu obie strony wiedzą, jakie informacje powinny ze spotkania wynieść. Brief nie musi odpowiadać na wszystko, ale powinien pomagać w zadaniu właściwych pytań.

Przy odbiorze pomyśl o urządzeniu i warunkach, w których zadanie będzie wykonywane. Czy osoba w terenie musi zobaczyć dane na telefonie? Czy konieczna jest praca przy przerwach w dostępie do sieci? Czy użytkownik powinien móc poprawić omyłkowo wprowadzoną informację? Takie pytania nie są gotową specyfikacją, ale pomagają rozpoznać, jakie sytuacje powinny zostać uwzględnione w rozmowie o zakresie.

Prosty układ briefu do skopiowania

W praktyce brief można zacząć od zdania o firmie i jednej grupie odbiorców, a następnie opisać wybrany przebieg sprawy. Dopiero pod nim wpisz pozostałe informacje. Dzięki temu osoba czytająca dokument nie musi najpierw odgadywać, po co potrzebne są kolejne systemy i role. Jeżeli istnieją materiały o obecnym procesie, podaj ich nazwy oraz właściciela, nie zakładając, że wszystkie są aktualne.

Możesz uporządkować dokument w kilku punktach: kim są użytkownicy i co robią; jak wygląda sprawa od początku do końca; gdzie pojawia się problem; jaki rezultat ma osiągnąć pierwsza wersja; z jakich systemów i danych korzysta proces; jakie ograniczenia oraz terminy są znane; czego jeszcze nie wiadomo i o co pytasz wykonawcę. Pod każdym punktem wystarczy kilka rzeczowych zdań.

Do takiego szkicu można wrócić z pracownikami przed wysłaniem. Poproś osobę wykonującą zadanie, aby zaznaczyła brakujące kroki, a osobę decyzyjną o potwierdzenie celu. Jeśli pojawią się dwie wersje procesu, zachowaj obie z informacją, kogo dotyczą. Wspólne wyjaśnienie różnicy jest cenniejsze niż szybkie wygładzenie opisu.

Jeśli chcesz omówić pomysł, zobacz zakres tworzenia oprogramowania na zamówienie i napisz przez formularz kontaktowy Archifutura. W wiadomości opisz cel, obecny sposób pracy oraz pytania, które chcesz rozstrzygnąć. Nawet niepełny brief może rozpocząć dobrą rozmowę, jeśli jasno pokazuje, co już wiadomo, a co wymaga wspólnego sprawdzenia.

Przed wysłaniem sprawdź jeszcze, czy czytelnik rozpozna trzy rzeczy: problem, oczekiwany rezultat oraz osobę, z którą można omówić szczegóły. Usuń dane, których nie trzeba przekazywać na tym etapie. Zostaw natomiast pytania bez odpowiedzi i obszary niepewności. Wykonawca może dzięki nim zaproponować sposób rozpoznania, zamiast opierać ofertę na niewidocznych założeniach. Jeżeli pytania z briefu wymagają wspólnego rozpoznania, sprawdź, jakie decyzje może przynieść warsztat discovery przed budową aplikacji.