--- title: "Płatna faza discovery w projekcie IT: co powinna dostarczyć" description: "Co powinna dać płatna faza discovery, zanim zapadnie decyzja o budowie: decyzje, sprawdzone ryzyka, widełki wyceny, pierwszy kamień milowy i czyste wyjście." canonical: https://sdk.enterprises/pl/insights/what-a-paid-discovery-phase-should-deliver language: pl --- # Płatna faza discovery w projekcie IT: co powinna dostarczyć Zaktualizowano: 2026-09-26 > Płatna faza discovery powinna kończyć się decyzjami, a nie tylko dokumentami: co zbudować najpierw, a co pominąć, jakie są główne ryzyka i jak je sprawdzono, wycena w postaci widełek z założeniami i pierwszy kamień milowy gotowy do rozpoczęcia. Ocenia się ją jednym testem: czy z tymi wynikami można pójść do innego zespołu i zacząć budowę bez zaczynania od nowa? ## Discovery służy podejmowaniu dużych decyzji, póki są tanie Discovery, nazywane też fazą rozpoznania, analizą zakresu lub inception, to krótka płatna faza przed budową oprogramowania. Jej zadaniem jest usunięcie niepewności, przez którą wyceny są niewiarygodne, i rozstrzygnięcie dużych decyzji, póki ich zmiana jest jeszcze tania. Zmiana decyzji na papierze kosztuje rozmowę; zmiana po napisaniu kodu kosztuje przeróbki. Wczesne wyceny oprogramowania mają szerokie widełki, które zwężają się dopiero wtedy, gdy decyzje usuwają niepewność; zjawisko to często nazywa się stożkiem niepewności. Same spotkania ich nie zwężają. Za discovery warto zapłacić, gdy wymusza te decyzje: co produkt musi robić najpierw, które ograniczenia są stałe i które ryzyka techniczne są realne. ## Uzgodnione rezultaty, zanim discovery się zacznie Discovery kupuje się jak każdy inny rezultat: z ustalonym czasem trwania, stałą ceną, wskazanymi osobami i spisaną listą rezultatów. Jeśli partner nie potrafi powiedzieć, co będą Państwo mieli w rękach na końcu, faza może rozmyć się w niekończących się warsztatach. Pełny zestaw rezultatów zwykle obejmuje następujące elementy. - Opis problemu: kim są użytkownicy, czego potrzebują i jak będzie mierzony sukces - Zakres pierwszego wydania: co wchodzi, co nie wchodzi i co zostaje odłożone - Kluczowe ścieżki użytkownika, naszkicowane lub w formie prototypu tam, gdzie są niepewne - Zarys architektury: główne komponenty, integracje, dane i hosting, wraz z rozważanymi opcjami - Rejestr ryzyk, który szereguje to, co mogłoby doprowadzić do porażki projektu, i sposób postępowania z każdym ryzykiem - Wycena w postaci widełek z założeniami oraz pierwszy kamień milowy z kryteriami odbioru - Dziennik decyzji: co postanowiono, kto i dlaczego ## Liczą się decyzje, a nie stos dokumentów Raport z discovery może być długi i niczego nie rozstrzygać. Warto czytać go pod kątem zobowiązań: które funkcje wchodzą do pierwszego wydania, a które nie, jakie wybory technologiczne i hostingowe zapadły, jakie integracje są potrzebne i które pytania pozostają otwarte, każde z przypisaną osobą i terminem. Przydatnym sygnałem jest to, przed czym partner przestrzegł. Jeśli na końcu zakres jest większy niż na początku i nic nie wycięto, discovery prawdopodobnie zapisało listę życzeń, zamiast ją sprawdzić. Czasem właściwy wniosek brzmi: kupić gotowy produkt, zbudować mniej albo nie budować wcale, i dobra faza discovery mówi to wprost. ## Najbardziej ryzykowne założenia trzeba sprawdzić, a nie tylko spisać Każdy projekt opiera się na kilku założeniach, które zmieniłyby wszystko, gdyby okazały się błędne: zewnętrzne API, które nie obsługuje potrzebnej operacji, dane bardziej chaotyczne niż oczekiwano, cel wydajnościowy, którego wybrany projekt nie osiągnie, albo użytkownicy, którzy nie zmienią sposobu pracy. Warto poprosić partnera, by wcześnie nazwał te założenia i sprawdził najgorsze z nich w trakcie discovery, za pomocą spike'a technicznego, klikalnego prototypu lub sesji roboczej z osobami, które obsługują dany system. Sprawdzone ryzyko to informacja. Ryzyko, które tylko zapisano, to nadal domysł. ## Uczciwa wycena to widełki z dołączonymi założeniami Pojedyncza liczba na koniec discovery ukrywa pozostałą niepewność. Warto poprosić o widełki dla pierwszego wydania, w podziale na główne komponenty, z założeniami, które mogłyby je przesunąć w górę lub w dół. Na przykład: wycena zakłada, że API dostawcy płatności już obsługuje częściowe zwroty; jeśli nie, należy doliczyć osobno wymienioną pracę integracyjną. Trzeba zapytać, które części wyceny są pewne, a które nadal niepewne, i jak model rozliczeń potraktuje każdą z nich. Pewne części można wycenić stałą ceną; niepewne wymagają budżetu i punktu, w którym zapada kolejna decyzja. Pierwszy kamień milowy powinien być opisany na tyle dobrze, by dało się go zrealizować za stałą cenę. ## Możliwość wyjścia na każdym etapie Discovery to także najtańszy moment na rezygnację. Należy upewnić się, że wszystko, co powstanie, od dokumentów i diagramów po prototypy i kod, należy do Państwa, a rezultaty są napisane dla każdego kompetentnego zespołu, a nie tylko dla partnera, który je przygotował. Powinni Państwo mieć swobodę budowania z tym partnerem, przekazania wyników innemu zespołowi, budowy we własnym zakresie albo zakończenia projektu. Tę samą zasadę warto przenieść na dalszy plan: pierwszy kamień milowy z kryteriami odbioru, a potem punkt decyzyjny, w którym można kontynuować, zmienić kurs lub zakończyć współpracę. Tak zaczynamy projekty w SDK Enterprises: spisany zakres, pierwszy kamień milowy o stałej cenie i wskazani z nazwiska inżynierowie, aby plan był znany, zanim zapadnie zobowiązanie do większego budżetu. Gdy potrzebna jest tylko porada, otrzymują Państwo pisemną odpowiedź, na podstawie której może działać Państwa zespół, niezależnie od tego, czy budują Państwo z nami. ## Sześć pytań, które pokazują, czy discovery było warte swojej ceny Po zakończeniu fazy warto sprawdzić wyniki według tych pytań. Jeśli większość odpowiedzi brzmi „tak”, pieniądze kupiły jasność. Jeśli większość brzmi „nie”, zapłacili Państwo za warsztaty. - Czy inny zespół mógłby zacząć budowę na podstawie tych rezultatów bez powtarzania discovery? - Czy partner rozmawiał z użytkownikami i z osobami obsługującymi zaangażowane systemy, a nie tylko ze sponsorem projektu? - Czy najbardziej ryzykowne założenia zostały sprawdzone, a wyniki spisane? - Czy wycena to widełki z jasnymi założeniami, a nie pojedyncza liczba? - Czy coś wycięto, odłożono lub zakwestionowano? - Czy pierwszy kamień milowy jest opisany na tyle dobrze, by można go było przyjąć lub odrzucić? ## Najważniejsze wnioski - Discovery kupuje się z ustalonym czasem trwania, stałą ceną, wskazanymi osobami i spisaną listą rezultatów. - Wyniki ocenia się po decyzjach, które zawierają, łącznie z tym, co wycięto lub przed czym przestrzeżono. - Najbardziej ryzykowne założenia trzeba sprawdzić w trakcie discovery, a nie tylko wpisać do rejestru ryzyk. - Wycena powinna mieć postać widełek z założeniami, a pierwszy kamień milowy być opisany na tyle dobrze, by dało się go wycenić. - Każdy rezultat powinien należeć do Państwa, aby można było budować z tym partnerem, z innym zespołem albo wcale. ## FAQ ### Czy discovery powinno być płatne, czy partner może je zrobić za darmo? Bezpłatne określanie zakresu jest częścią sprzedaży, więc kończy się na tym, co mieści się w ofercie. Płacąc za discovery, kupuje się czas na przeczytanie kodu, rozmowy z użytkownikami i sprawdzenie ryzyk, a także rezultaty, które należą do Państwa. Faza powinna być krótka i mieć stałą cenę, aby zobowiązanie pozostało niewielkie. ### Ile powinna trwać faza discovery? Tyle, ile potrzeba, by odpowiedzieć na pytania blokujące wiarygodną wycenę, i ani dnia dłużej. Czas trwania warto uzgodnić z góry na podstawie wielkości produktu i liczby zaangażowanych systemów, a zakończyć decyzją o pierwszym kamieniu milowym, a nie przedłużeniem discovery. ### Co jeśli discovery pokaże, że projektu nie warto budować? Wtedy spełniło swoje zadanie najniższym możliwym kosztem. Dobra faza discovery może dojść do wniosku, że lepiej kupić gotowy produkt, zbudować mniejszą pierwszą wersję albo przerwać, a ustalenia i tak zostają u Państwa. ## Zacznijmy od Państwa potrzeby - [Tworzenie aplikacji mobilnych](https://sdk.enterprises/pl/mobile-app-development) ## Powiązane usługi - [Audyt techniczny i doradztwo](https://sdk.enterprises/pl/services/consulting) - [Oprogramowanie na zamówienie](https://sdk.enterprises/pl/services/product-engineering) ## Warto przeczytać - [Jak wybrać firmę programistyczną: pytania przed umową](https://sdk.enterprises/pl/insights/choosing-a-software-partner) - [Jak napisać brief projektu IT, by dostać porównywalne oferty](https://sdk.enterprises/pl/insights/writing-a-software-project-brief)