Na pierwszą rozmowę z nami o nowym systemie nie potrzebujesz listy technologii, gotowych ekranów ani wielostronicowej specyfikacji. Wystarczy, że opiszesz sytuację, którą dobrze znasz: co dziś utrudnia pracę w Twojej firmie, kto uczestniczy w procesie, gdzie znajdują się dane i co powinno zmienić się po wdrożeniu.
Taki materiał nie musi rozstrzygać wszystkiego. Ma pomóc Ci uporządkować potrzebę, a nam — zadać właściwe pytania, wskazać niewiadome i zaproponować następny krok.
Zacznij od problemu, nie od nazwy systemu
Zdanie „potrzebujemy CRM” albo „chcemy aplikację do zamówień” mówi niewiele o rzeczywistej pracy firmy. Ta sama nazwa może oznaczać prosty rejestr, integrację kilku narzędzi albo rozbudowany system z różnymi rolami i wyjątkami.
Zacznij od konkretnej trudności:
Zapytania klientów przychodzą e-mailem. Handlowcy przepisują dane do arkusza, a dostępność produktów sprawdzają telefonicznie z magazynem. Trudno ustalić, kto przygotowuje odpowiedź i czy używa aktualnej ceny.
Nie musisz od razu proponować rozwiązania. Opisz sytuację własnymi słowami. Dzięki temu możemy najpierw zrozumieć źródło problemu, zamiast dopasowywać Twoją firmę do przypadkowej nazwy produktu.
Pokaż nam obecny proces krok po kroku
Opisz nam zwykły dzień pracy. Zacznij od zdarzenia, które uruchamia proces, i zakończ na rezultacie otrzymywanym przez pracownika lub klienta.
Pomagają następujące pytania:
- Skąd przychodzi zgłoszenie, zamówienie albo inna informacja?
- Kto wykonuje pierwszy krok i komu przekazuje sprawę?
- Z jakich arkuszy, wiadomości lub aplikacji korzystają uczestnicy?
- W którym miejscu dane są przepisywane albo sprawdzane ponownie?
- Jak wygląda zakończenie procesu?
- Co dzieje się w nietypowej sytuacji?
Wyjątki są szczególnie ważne. Proces może działać dobrze dla standardowego zamówienia, a zatrzymywać się przy braku produktu, zmianie ceny lub niepełnych danych klienta. Jeśli opiszesz tylko najprostszą ścieżkę, pierwsza wersja systemu może nie uwzględnić pracy, która naprawdę zabiera najwięcej czasu.
Opisz rezultat, który można sprawdzić
Zamiast projektować przyciski, napisz, co użytkownik powinien móc zrobić po zmianie.
W przykładowym procesie rezultatem może być:
- zapisanie zapytania w jednym miejscu;
- sprawdzenie, kto się nim zajmuje;
- korzystanie z jednego, aktualnego źródła cen;
- przygotowanie szkicu oferty bez ponownego przepisywania danych;
- rozpoznanie spraw oczekujących na decyzję.
„System ma być wygodny” nie daje jeszcze kryterium odbioru. Więcej mówi zdanie: „handlowiec widzi status zapytania i nie przepisuje drugi raz danych podanych przez klienta”.
Rezultat nie musi być liczbą. Powinien jednak opisywać zmianę, którą użytkownik potrafi zauważyć i sprawdzić podczas pracy.
Nazwij użytkowników i granice dostępu
Nie potrzebujemy listy pracowników. Wystarczą role, orientacyjna liczba osób oraz najważniejsze różnice w dostępie.
Przykładowo:
- handlowiec tworzy i aktualizuje własne oferty;
- kierownik widzi pracę całego zespołu;
- magazyn potwierdza dostępność, ale nie zmienia warunków handlowych;
- administrator zarządza kontami i ustawieniami.
Dodaj informację, czy praca odbywa się na komputerze, telefonie, tablecie albo stanowisku magazynowym. Ma to znaczenie dla sposobu obsługi systemu, ale nadal nie wymaga od Ciebie projektowania interfejsu.
Wskaż nam dane i obecne narzędzia
Napisz, gdzie dziś znajdują się potrzebne informacje. Może to być arkusz, poczta, papierowy dokument, program księgowy, sklep internetowy albo istniejąca aplikacja.
Jeżeli system ma wymieniać dane z innym rozwiązaniem, podaj:
- nazwę lub przeznaczenie obecnego systemu;
- rodzaj potrzebnych danych;
- oczekiwany kierunek przepływu;
- informację, czy istnieje dokumentacja API lub kontakt do producenta albo administratora używanego programu.
Odpowiedź „nie wiemy, czy system ma API” jest użyteczna. Pokazuje punkt, który trzeba sprawdzić przed potwierdzeniem zakresu integracji.
Nie wklejaj do briefu haseł, tokenów, kluczy API, kopii bazy ani prawdziwych danych klientów lub pracowników. Wystarczy nazwać rodzaj informacji, na przykład dane kontaktowe, dokumenty finansowe albo dane wymagające ograniczonego dostępu.
Oddziel pierwszy etap od pomysłów na później
Lista, na której wszystko jest konieczne, nie pomaga podjąć decyzji. Podziel potrzeby na dwie grupy:
- zakres potrzebny, aby jeden ważny proces działał od początku do końca;
- funkcje, które mogą powstać po sprawdzeniu pierwszego etapu.
W przykładowym systemie pierwszy etap może obejmować rejestr zapytań, statusy, role i przygotowanie szkicu oferty. Panel klienta, płatności i rozbudowane raporty mogą pozostać na później, jeżeli nie są potrzebne do osiągnięcia pierwszego rezultatu.
Warto również dopuścić prostsze rozwiązanie. Jeżeli problem można usunąć przez uporządkowany formularz, wspólny szablon albo lepsze wykorzystanie obecnego narzędzia, budowa dedykowanego systemu nie musi być pierwszym wyborem.
Zapisz ograniczenia i niewiadome
Dobry brief nie udaje, że wszystkie decyzje już zapadły. Powinien jawnie pokazywać również to, czego jeszcze nie wiadomo.
Wskaż:
- ważny termin biznesowy i przyczynę, z której wynika;
- orientacyjny budżet, jeśli został ustalony;
- osobę podejmującą decyzję;
- rolę osoby najlepiej znającej codzienny proces;
- pytania, których Ty lub Twój zespół nie potraficie jeszcze rozstrzygnąć.
Sam termin nie jest obietnicą realizacji. Informuje nas jednak, czy projekt wynika z sezonu sprzedażowego, końca umowy, zmiany przepisów albo innego zdarzenia, które trzeba uwzględnić przy planowaniu.
Przykład: od ogólnego pomysłu do briefu
Poniższy przykład jest fikcyjny. Pokazuje, jak może wyglądać opis wysłany do nas, a nie gotowy zakres rzeczywistego wdrożenia.
Ogólny pomysł:
Potrzebujemy systemu do przygotowywania ofert.
Problem i kontekst:
Zapytania przychodzą na wspólną skrzynkę. Handlowcy przepisują dane do własnych arkuszy, dlatego kilka osób może rozpocząć pracę nad tą samą sprawą. Informacje o cenach i dostępności są sprawdzane w oddzielnym programie.
Obecny proces:
Handlowiec odczytuje wiadomość, zapisuje dane klienta w arkuszu, kontaktuje się z magazynem, wybiera ceny z kolejnego pliku i przygotowuje ofertę w dokumencie. Wyjątkiem są produkty wymagające indywidualnego potwierdzenia ceny.
Oczekiwany rezultat:
Każde zapytanie ma jeden rekord i właściciela. Handlowiec widzi jego status, korzysta z aktualnego źródła danych i przygotowuje szkic oferty bez ponownego wpisywania informacji.
Użytkownicy i role:
Handlowcy obsługują własne zapytania, kierownik widzi cały zespół, a magazyn potwierdza dostępność produktów.
Dane i integracje:
Dane zapytań znajdują się w poczcie i arkuszach. Informacje o produktach przechowuje program magazynowy. Dostępność jego API wymaga potwierdzenia u producenta lub administratora programu magazynowego.
Pierwszy etap:
Rejestr zapytań, przypisanie osoby, statusy, role i przygotowanie szkicu oferty.
Później:
Panel klienta, rozbudowane raporty oraz obsługa płatności.
Ograniczenia i pytania:
Firma chce przygotować rozwiązanie przed kolejnym sezonem sprzedażowym, ale możliwość realizacji w tym terminie wymaga oceny. Do ustalenia pozostają sposób pobierania cen oraz obsługa niestandardowych ofert.
Taki opis nadal nie jest specyfikacją techniczną. Wystarcza jednak, abyśmy mogli porozmawiać z Tobą o realnym procesie, wskazać ryzyka i ustalić, co trzeba sprawdzić przed wyceną.
Czego nie musisz rozstrzygać samodzielnie
Przed pierwszą rozmową nie musisz wybierać:
- języka programowania i architektury;
- serwera, bazy danych ani frameworka;
- dokładnego wyglądu wszystkich ekranów;
- sposobu technicznego wykonania integracji;
- ostatecznej ceny i terminu;
- pełnego zakresu kolejnych etapów.
Jeżeli rozwijasz istniejącą aplikację, jej kod, zależności i sposób wdrażania mogą wymagać osobnego sprawdzenia. Gdy do wiarygodnego określenia zakresu potrzebna jest płatna analiza, uzgadniamy ją oddzielnie przed rozpoczęciem.
Ten artykuł pomaga przygotować pierwszy opis. Jeżeli masz już ustalony zakres i przechodzisz do organizacji ludzi, danych oraz odbiorów, kolejnym materiałem jest poradnik Jak przygotować firmę do wdrożenia systemu lub aplikacji webowej.
Co zrobimy z przygotowanym opisem
W Domin Software zaczynamy od sprawdzenia związku między problemem, obecnym procesem i oczekiwanym rezultatem. Dopytujemy o wyjątki, dane, role oraz zależności od istniejących narzędzi.
Na tej podstawie możemy wskazać, czy kolejnym krokiem powinno być doprecyzowanie małego zakresu, analiza istniejącej aplikacji, sprawdzenie integracji czy podział większego projektu na etapy. Sam brief nie przesądza jeszcze o technologii, cenie ani terminie.
Zakres usług programistycznych Domin Software obejmuje rozwój aplikacji, integracje oraz nowe oprogramowanie dla firm.
Ułóż opis projektu w kreatorze
Nie musisz tworzyć dokumentu od pustej kartki. Kreator opisu projektu prowadzi przez pięć kroków i porządkuje odpowiedzi w siedmiu sekcjach briefu.
Wszystkie pola są opcjonalne. Wynik powstaje lokalnie w przeglądarce, bez konta, modelu AI i automatycznego wysyłania odpowiedzi. Możesz go skopiować, pobrać jako Markdown albo wydrukować do PDF.
Jeżeli zdecydujesz się rozpocząć rozmowę z nami, osobny przycisk przeniesie brief do edytowalnego formularza kontaktowego. Nic nie zostanie wysłane, dopóki samodzielnie nie zatwierdzisz formularza.
Główne CTA: Przejdź do kreatora opisu projektu
Jeżeli masz już własny opis, możesz również skontaktować się z nami bezpośrednio.