Blog - Syntanea

Software development discovery phase to praca przed rozpoczęciem budowy, która chroni zespół przed pewnym siebie tworzeniem złego rozwiązania.

Większość problemów w projektach software nie zaczyna się od złego frameworka, języka czy chmury. Zaczyna się wcześniej. Proces był zrozumiany tylko częściowo. Manager uznał wyjątek za rzadki. Vendor wycenił listę funkcji, która brzmiała jasno na spotkaniu, a dwa tygodnie później rozpadła się na dziesięć szczegółów.

Discovery oznacza krótkie zwolnienie tempa, żeby później projekt mógł iść szybciej. Przy małym narzędziu wewnętrznym może wystarczyć pięć konkretnych dni. Przy systemie dotykającym finansów, operacji, integracji i danych klientów lepsze będą trzy albo cztery tygodnie.

Abstrakcyjna granatowo-turkusowa mapa discovery dla planowania software

Na jakie pytania odpowiada software development discovery phase

Dobre discovery to nie warsztat, po którym wszyscy wychodzą z kolorowymi karteczkami i ładnym PDF-em. Powinno dać odpowiedzi na trudne pytania: co budujemy najpierw, czego jeszcze nie budujemy i co może rozbić plan.

Na końcu powinniście wiedzieć:

Kto będzie używał systemu i jaką pracę chce wykonać

Który workflow dzieje się codziennie, a który dwa razy w roku, ale jest krytyczny

Jakich danych potrzebuje system, skąd pochodzą i kto za nie odpowiada

Które integracje są potrzebne w wersji pierwszej, a które mogą poczekać

Jakich reguł bezpieczeństwa, audytu, compliance albo akceptacji nie wolno zgadywać później

Co pierwsza wersja musi udowodnić, zanim firma dołoży kolejny budżet

Jeśli te odpowiedzi nadal są mgliste, fixed delivery plan jest głównie teatrem.

Dlaczego project discovery obniża koszt software

Discovery kosztuje, więc część firm próbuje je pominąć. To zrozumiałe. Nikt nie chce płacić za spotkania, zanim zapłaci za kod.

Problem w tym, że niejasna praca nie znika. Przenosi się do developmentu, gdzie jest droższa. Brakujący edge case w pierwszym tygodniu może być rozmową. Ten sam edge case po zbudowaniu bazy, ekranów, uprawnień i raportów może oznaczać przebudowę.

Prosty przykład: firma chce wewnętrzne narzędzie do akceptacji kosztów. Pierwszy brief mówi o trzech poziomach akceptacji. W discovery zespół znajduje sześć prawdziwych ścieżek: tryb pilny, zastępstwa podczas urlopów, limity krajowe, akceptację według cost center, nadpisania audytowe i miesięczny raport wyjątków. To zmienia model danych. Zmienia też wycenę.

Znalezienie tego przed developmentem nie jest opóźnieniem. Jest ograniczeniem szkód.

Deliverables z discovery, które naprawdę pomagają

Po dobrym discovery kupujący i zespół developerski powinni mieć decyzje robocze, nie tylko notatki.

W większości projektów custom software przydają się:

Krótki opis problemu prostym językiem

Grupy użytkowników i zadania, które muszą wykonać

Mapa obecnego workflow, razem z wyjątkami i ręcznymi obejściami

Priorytetowy zakres wersji pierwszej oraz osobna lista na później

Kluczowe ekrany, wireframe-y albo prosty prototyp ryzykownych ścieżek

Lista integracji z właścicielami, potrzebnymi dostępami i ograniczeniami

Szkic modelu danych albo lista głównych obiektów biznesowych

Rejestr ryzyk technicznych, operacyjnych i decyzyjnych

Widełki wyceny z założeniami, nie udawanie dokładności co do euro

Plan pracy na pierwsze cztery do ośmiu tygodni

Format może być prosty. Dwunastostronicowy dokument decyzyjny często działa lepiej niż siedemdziesięciostronicowa specyfikacja, której nikt nie czyta.

Ile powinien trwać software discovery phase

Długość discovery zależy od ryzyka, nie od wielkości firmy.

Orientacyjnie:

3 do 5 dni dla małej automatyzacji, proof of concept albo narzędzia wewnętrznego z jednym właścicielem

1 do 2 tygodni dla MVP z kilkoma rolami użytkowników, płatnościami, raportami albo jedną ważną integracją

2 do 4 tygodni dla systemu operacyjnego z danymi legacy, integracją z ERP lub CRM, audytem albo kilkoma działami

Dłużej tylko wtedy, gdy wchodzą dane regulowane, procurement, ciężka migracja albo wielu zewnętrznych interesariuszy

Jeśli vendor proponuje sześć tygodni discovery dla małego MVP opartego na landing page, zapytaj dlaczego. Jeśli ktoś chce pominąć discovery przy systemie dla finansów albo operacji, zapytaj ostrzej: na czym opiera wycenę?

Co omówić na warsztatach discovery

Najlepsze warsztaty mniej przypominają burzę mózgów, a bardziej uważne rozmowy. Celem jest pokazanie, jak praca dzieje się naprawdę.

Pytaj na przykład:

Pokaż ostatni prawdziwy przypadek, nie idealny proces.

Co się dzieje, gdy danych brakuje albo są błędne?

Kto może obejść regułę i jak jest to zapisane?

Który arkusz, mailbox albo wątek na Slacku jest cichą częścią procesu?

Jaki raport ktoś ręcznie odtwarza co miesiąc?

Co sprawiłoby, że pierwsza wersja byłaby bezużyteczna?

Jakiej decyzji unikamy, bo jest politycznie niewygodna?

To ostatnie pytanie bywa niewygodne. I często ratuje projekt. Wiele problemów software to problemy decyzyjne przebrane za techniczne.

Discovery dla projektów AI i automatyzacji

Projekty AI potrzebują discovery jeszcze bardziej niż zwykłe projekty software, bo demo może wyglądać użytecznie, zanim workflow będzie bezpieczny.

Przy automatyzacji AI discovery powinno rozdzielić trzy rzeczy:

Wejścia, które model może odczytać: dokumenty, maile, tickety, faktury, rozmowy albo formularze

Decyzje, które biznes może bezpiecznie automatyzować

Wyjątki, które nadal muszą trafiać do człowieka

Nie zaczynaj od zdania "potrzebujemy agenta AI". Zacznij od kolejki, przekazania, kosztu błędu i ścieżki przeglądu. Automatyzacja 70 procent spraw może być świetna, jeśli pozostałe 30 procent trafia w jasne miejsce. Deklaracja 95 procent accuracy nic nie daje, jeśli nikt nie wie, co dzieje się przy pomyłce.

Jeśli planujesz szersze wdrożenie AI, zobacz nasz plan wdrożenia AI.

Czerwone flagi w discovery projektu software

Discovery pozwala też sprawdzić, czy projekt jest gotowy.

Uważaj na te sygnały:

Stakeholderzy nie zgadzają się co do celu, ale chcą jednej wyceny

Nikt nie odpowiada za ostateczne decyzje

Obecny proces ma wiele wyjątków, ale nikt nie umie ich nazwać

Integracje są opisane jako "proste", zanim ktokolwiek sprawdzi dostęp do API

Użytkownicy nie są dostępni do rozmów

Budżet zakłada wersję trzecią, a harmonogram wersję pierwszą

Zespół chce fixed price, ale ciągle zmienia reguły biznesowe

Żaden z tych sygnałów nie musi zabić projektu. Oznacza jednak, że pierwsza faza powinna ograniczyć niepewność, zanim powstanie zbyt dużo kodu.

Praktyczna agenda discovery na dwa tygodnie

Oto prosta struktura dwóch tygodni dla średniej aplikacji biznesowej.

Tydzień 1: rozmowy z właścicielami procesu i użytkownikami, mapa obecnego workflow, zebranie przykładowych danych, przegląd istniejących systemów, lista integracji i cel pierwszej wersji.

Tydzień 2: szkic głównych przepływów, potwierdzenie reguł danych, sprawdzenie dostępów integracyjnych, oddzielenie must-have od późniejszego zakresu, wycena opcji delivery i wybór pierwszego milestone.

Wynikiem powinien być pakiet decyzyjny: co budujemy najpierw, dlaczego ten kawałek ma znaczenie, ile kosztuje, co może pójść źle i jakie decyzje trzeba podjąć przed startem developmentu.

FAQ

Co to jest software development discovery phase?

Software development discovery phase to krótki etap planowania przed developmentem. Zespół mapuje użytkowników, workflow, dane, integracje, ryzyka, zakres i kryteria sukcesu, żeby pierwsza wersja wynikała z faktów, a nie założeń.

Czy discovery jest potrzebne w każdym projekcie software?

Nie zawsze. Bardzo małe, dobrze opisane zadanie może go nie potrzebować. Custom business software, MVP, automatyzacje, workflow AI i praca z legacy system zwykle potrzebują discovery, bo ukryte reguły i integracje potrafią zmienić projekt oraz budżet.

Ile kosztuje software discovery phase?

Małe discovery często kosztuje kilka tysięcy euro. Bardziej rozbudowane discovery dla aplikacji biznesowej może mieścić się w przedziale od 5 000 do 20 000 EUR, zależnie od warsztatów, UX, researchu technicznego i sprawdzania integracji.

Co powinno się wydarzyć po discovery?

Po discovery powinieneś mieć dość informacji, żeby zaakceptować pierwszą wersję, odłożyć projekt, zmienić zakres albo wybrać inny model delivery. Następny krok to zwykle mała faza budowy z jasnymi milestoneami i cotygodniowym review.

Czy discovery może być częścią projektu fixed price?

Tak. W wielu przypadkach najbezpieczniejszy fixed price wygląda tak: najpierw discovery, potem stała cena za węższą fazę budowy. Wycena całego produktu przed discovery zwykle chowa niepewność w buforach i change requestach.

Potrzebujesz jaśniejszego planu przed budową?

Syntanea pomaga firmom zamieniać luźne pomysły produktowe, ręczne workflow i koncepcje automatyzacji AI w opisane projekty software. Działamy we Wrocławiu i pracujemy z europejskimi zespołami, które chcą praktycznego dowożenia bez ceremonii.

Jeśli planujesz custom software i zakres nadal się ślizga, porozmawiaj z Syntanea. Możemy poprowadzić konkretne discovery, zmapować ryzyka i pomóc zdecydować, co naprawdę powinno wejść do wersji pierwszej.

Powiązane artykuły

Koszt custom software development w Europie - widełki budżetowe i powód, dla którego niejasny zakres robi się drogi

Jak wybrać partnera do tworzenia aplikacji na zamówienie w Europie - pytania przed wyborem zespołu

Koszt MVP development w Europie - budżet pierwszej wersji

Plan wdrożenia AI - jak zaplanować użyteczne AI w firmie przez 90 dni

Software development discovery phase: co zrobić przed budową systemu