Nasz proces discovery — jak 2 tygodnie oszczędzają 6 miesięcy

Projekty IT nie umierają podczas implementacji. Umierają na etapie definicji — tylko tego nie widać od razu, bo śmierć jest powolna. Przez pierwsze miesiące wszyscy są dumni z demo, zespół wypala story pointy, a KPI dashboard świeci na zielono. Problem wypływa dopiero w miesiącu szóstym, kiedy system dotyka rzeczywistego procesu biznesowego i okazuje się, że rozwiązuje zły problem. Albo właściwy problem w zły sposób. Discovery to antidotum. Pod warunkiem, że jest robione dobrze.

Przez ostatnie osiem lat przeprowadziliśmy kilkadziesiąt procesów discovery dla firm od 20 do 500 pracowników. Wzorce powtarzają się z matematyczną regularnością. Ten tekst jest destylatem tych wzorców do formy wdrożeniowej — nie teorii z podręcznika, tylko frameworka, który produkuje decyzje biznesowe w 10 dni roboczych.

Dlaczego projekty umierają na etapie definicji

Klient FMCG (producent bakalii, ~180 osób, obrót 90 mln PLN) przyszedł do nas z briefem na nowy CRM, bo „konkurent wdrożył Salesforce i nam też tak trzeba”. Brief miał 14 stron wymagań skopiowanych jeden do jednego z webinaru dostawcy. Pierwsze pytanie na kick-offie: „jakie KPI ma poprawić ten CRM?”. Odpowiedź: cisza, potem „no… digitalizację”. To jest archetyp pierwszej przyczyny — brief skopiowany z konkurencji. Kopiujesz rozwiązanie, a nie rozumiesz problemu, który ono rozwiązuje. W efekcie dostajesz system wyglądający jak u konkurenta, ale niegenerujący tej samej wartości, bo nigdy nie był dostosowany do twojej rzeczywistości.

Druga przyczyna jest mniej widoczna z poziomu zarządu: brief powstaje wyłącznie na bazie rozmów z managerami. Kierownik działu opisuje, jak proces „powinien działać”. Pracownik, który wykonuje ten proces osiem godzin dziennie, wie, jak on faktycznie działa — z workaroundami, z arkuszami w shadow IT, z tribal knowledge, które nigdzie nie jest spisane. Systemy zaprojektowane wyłącznie na bazie rozmów z managerami zawsze opisują fikcję. Implementacja zderza się z rzeczywistością w miesiącu czwartym, kiedy użytkownicy końcowi zaczynają testy UAT i mówią, że „tak się nie pracuje”.

Trzecia przyczyna: cel biznesowy przesłonięty listą funkcjonalności. Brief zawiera 87 wymagań, ale żadne zdanie nie opisuje, po co ten system powstaje w kategoriach P&L. Funkcjonalność to środek, nie cel. Kiedy discovery nie zadaje pytania „o ile procent ma wzrosnąć marża / spaść koszt / przyspieszyć cycle time?”, zespół implementacyjny nie ma kryterium priorytetyzacji. Każda funkcja jest równie ważna, projekt pęka budżetowo, a zarząd nie potrafi ocenić, czy dostał to, co chciał, bo nigdy nie zdefiniował, czego chce.

Nasza definicja discovery — co to NIE jest

Discovery to nie workshop z post-itami. Dwa dni w sali z flipchartem generują empatię w zespole, ale nie produkują decyzji biznesowej. Decyzja biznesowa wymaga danych — wywiadów z 12-18 osobami, mapy procesu as-is z metrykami czasowymi i kosztowymi, porównania trzech scenariuszy architektonicznych. Post-it nie zastąpi analizy TCO.

Discovery to nie technical audit. Audyt technologiczny dotyczy tego, co już istnieje — jakości kodu, długu technologicznego, skalowalności obecnej architektury. Discovery dotyczy tego, co ma powstać i czy w ogóle powinno powstać. Audyt odpowiada na pytanie „jak jest?”. Discovery odpowiada na pytanie „co budujemy, dlaczego, za ile i z jakim zwrotem?”. To dwa różne procesy, często mylone w briefach klientów.

Discovery to nie lista wymagań. Dokument 87 wymagań funkcjonalnych to produkt fazy implementacji, nie fazy definicji. Discovery produkuje coś twardszego: decyzję go / no-go / pivot z przewidywaną wartością biznesową, modelem kosztów TCO i analizą alternatyw. Lista wymagań jest konsekwencją tej decyzji, nie jej wejściem.

DoMoreSoft Discovery Framework — 5 faz wyjaśnionych

Framework nazwaliśmy nie dlatego, że lubimy nazywanie rzeczy, ale dlatego, że nazwany proces jest replikowalny. Nienazwany proces umiera wraz z jedną osobą, która go „umie”. Pięć faz, dziesięć dni roboczych, dwójka seniorów po stronie Do More Soft (architekt systemów + konsultant procesowy), zdefiniowane deliverable’y na koniec każdej fazy.

Faza 1 (Dzień 1-2): Stakeholder map i artykulacja problemu

Pierwsze dwa dni spędzamy na rozpoznaniu pola bitwy. Stakeholder map odpowiada na cztery pytania: kto płaci za decyzję, kto jej używa, kto jest jej ofiarą, kto ma prawo weta. Te role prawie nigdy nie pokrywają się w jednej osobie, a ignorowanie którejkolwiek jest najczęstszą przyczyną porażki projektu.

Z tej obserwacji wynika konkretna decyzja operacyjna: równolegle siadamy z zarządem nad artykulacją problemu i wymuszamy odpowiedź na pytanie „jak rozpoznamy, że projekt był sukcesem?” w kategoriach metryki P&L, a nie listy funkcjonalności. Jeśli na to pytanie nie ma odpowiedzi w 48 godzin, dalsze fazy nie mają sensu — discovery zatrzymuje się i wraca do zarządu po decyzję.

Output fazy 1: stakeholder map z zaznaczonymi konfliktami interesów, problem statement w jednym akapicie, zatwierdzone przez sponsora projektu metryki sukcesu z wartością docelową.

Faza 2 (Dzień 3-5): Wywiady z użytkownikami — 12-18 osób w minimum 3 rolach

Trzy dni na wywiady indywidualne. Nie grupowe. Grupowe wywiady produkują konsensus, a konsensus ukrywa prawdę. Minimum trzy role: user końcowy (osoba, która pracuje z systemem codziennie), manager (osoba, która raportuje w oparciu o system) i interesariusz zewnętrzny (klient firmy, partner, regulator). Każdy wywiad trwa 45-60 minut, ma strukturyzowany skrypt i produkuje transkrypt tagowany pod kątem pain pointów, workaroundów i ukrytych procesów.

Output fazy 2: baza 12-18 transkryptów z taxonomią problemów, lista top-10 bolączek uszeregowanych częstotliwością, mapa shadow IT (arkuszy, prywatnych makr, grup WhatsApp zastępujących procesy).

Faza 3 (Dzień 6-7): Mapowanie procesów i identyfikacja wąskich gardeł

Na podstawie wywiadów budujemy mapę procesu as-is z metrykami — ile kroków, ile czasu na każdy krok, ile punktów ręcznego przepisywania danych, ile punktów decyzyjnych, ile transferów między systemami. W tym projekcie mapa as-is miała 47 kroków, mapa to-be 12. Różnica między as-is a to-be jest wartością biznesową projektu, wyrażoną w roboczogodzinach i kosztach operacyjnych. Równolegle używamy naszej metodyki identyfikacji wąskich gardeł — 5 typów wąskich gardeł, od ręcznego przepisywania po over-reporting.

Output fazy 3: diagram procesu as-is z metrykami, mapa to-be ze zidentyfikowanymi wąskimi gardłami, rejestr wąskich gardeł z szacowanym kosztem rocznym każdego z nich.

Faza 4 (Dzień 8-9): Szkic architektury i model kosztowy

Dwa dni na architekturę biznesową i techniczną oraz model TCO. Architekt przygotowuje trzy scenariusze: build (budowa custom), buy (wdrożenie gotowego produktu z konfiguracją) i hybrid (gotowy core + custom moduły). Każdy scenariusz ma trzyletni model TCO — koszt wdrożenia, koszt utrzymania, koszt długu technologicznego i prognozę skalowalności. To nie są szacunki z sufitu. To modele oparte na benchmarku z naszych wcześniejszych projektów w tej samej klasie.

Output fazy 4: trzy scenariusze architektoniczne z diagramem komponentów, trzyletni model TCO dla każdego scenariusza, analiza ryzyk implementacyjnych z planem mitygacji.

Faza 5 (Dzień 10): Raport decyzyjny z trzema scenariuszami

Ostatni dzień to konsolidacja i prezentacja zarządowi. Raport decyzyjny ma strukturę: problem statement, diagnoza (mapa as-is, wąskie gardła), trzy scenariusze z rekomendacją, model ROI/TCO na trzy lata, roadmapa 90-dniowa i 12-miesięczna. Prezentacja trwa 90 minut — 30 minut raportu, 60 minut dyskusji i pytań zarządu. Na koniec sesji zapada decyzja: go, no-go lub pivot. Jeśli go — rozpoczynamy fazę scoping i planowania wdrożenia, której metodyką dzielimy się w MVP w 8 tygodni.

Output fazy 5: raport decyzyjny (30-50 stron PDF), prezentacja executive summary, decyzja zarządu udokumentowana i podpisana.

Co klient dostaje na koniec 10 dni

Lista deliverable’ów jest zawsze taka sama, bo skonsolidowaliśmy ją po kilkudziesięciu discovery:

• Mapa procesów as-is i to-be z metrykami czasowymi oraz kosztowymi każdego kroku.
• Rejestr wąskich gardeł z szacunkiem rocznego kosztu każdego z nich.
• Trzy scenariusze rozwiązania (build / buy / hybrid) z trzyletnim modelem TCO.
• Ocena długu technologicznego istniejącego systemu, jeśli klient ma już rozwiązanie.
• Analiza luk kompetencyjnych zespołu — kogo brakuje, żeby utrzymać nowe rozwiązanie.
• Rekomendowana roadmapa: plan 90-dniowy (kwartalne kamienie milowe) i plan 12-miesięczny (strategiczne cele roczne).
• Raport decyzyjny z jednoznaczną rekomendacją go / no-go / pivot.

Case: jak 10 dni discovery uratowało 6 miesięcy rozwoju

Klient z branży FMCG — producent i dystrybutor suszonych owoców i bakalii — przyszedł do nas z briefem „potrzebujemy nowego CRM, obecny nas ogranicza”. Brief miał 14 stron wymagań funkcjonalnych. Zamiast od razu estymować, zaproponowaliśmy 10 dni discovery. Wywiady z handlowcami, pracownikami magazynu i logistyki wykazały coś, czego brief nie pokazywał: prawdziwy problem nie był w CRM, tylko w procesie przepływu zamówienia między działem handlowym, magazynem i logistyką. CRM działał — ale każde zamówienie przechodziło przez 4 ręczne transfery danych między systemami, generując opóźnienia i błędy.

Rekomendacja po discovery: pivot. Zamiast budowy nowego CRM za 6 miesięcy i 300 tys. EUR, zaproponowaliśmy warstwę integracyjną — moduł synchronizacji między istniejącymi systemami — za 8 tygodni i 85 tys. EUR. Wdrożenie opisujemy w case study Terra i w narracyjnym artykule „Terra — od arkuszy do systemu”. 10 dni discovery przesunęło projekt z budowy niewłaściwej rzeczy na rozwiązanie właściwego problemu. Oszczędność: 6 miesięcy pracy zespołu i 215 tys. EUR netto.

Dlaczego 2 tygodnie, a nie 2 miesiące

Discovery może trwać dowolnie długo — znamy firmy, które prowadzą je po sześć miesięcy. W praktyce marginalna wartość każdego dodatkowego dnia spada eksponencjalnie po dziesiątym dniu. W pierwszych 10 dni odkrywamy 80% problemu. Następne 10 dni? Kolejne 15%. To nie opinia — to wzorzec z 50+ discovery, które przeprowadziliśmy w domenach od FMCG przez automotive po SaaS.

Druga przyczyna jest kulturowa: prawo Parkinsona mówi, że praca rozszerza się do czasu, który jest jej przyznany. Dyskusje rozciągnięte na miesiące produkują analitykę paraliżu, nie decyzje. Sztywne ramy 10 dni wymuszają dyscyplinę priorytetyzacji — jeśli coś nie zmieści się w 10 dniach, nie zmieści się nigdy, bo nie jest tak ważne, jak się wydaje. Zespoły, które mają dwa miesiące na discovery, produkują 300-stronicowe raporty, których nikt nie czyta. Zespoły, które mają 10 dni, produkują 40-stronicowy raport decyzyjny, który zarząd czyta w 45 minut i na podstawie którego podejmuje decyzję.

ROI discovery — konkretna matematyka

Koszt discovery w modelu DoMoreSoft: 15-25 tys. EUR za 10 dni pracy dwójki seniorów. Koszt błędnej implementacji 6-miesięcznego projektu: 200-400 tys. EUR w budżecie wdrożenia plus koszt alternatywny — sześć miesięcy, które zespół biznesowy spędził na sponsorowaniu niewłaściwego projektu, zamiast na innej inicjatywie.

Rachunek break-even jest banalny. Przy projekcie implementacyjnym o budżecie 300 tys. EUR, discovery kosztujące 20 tys. EUR zwraca się, jeżeli pozwoli uniknąć 6,7% błędnego scope’u. W praktyce discovery redukuje scope o 15-30% (funkcje, które wydawały się krytyczne, okazują się zbędne po wywiadach z użytkownikami) i redukuje ryzyko całkowitego fiaska o rzędy wielkości. Discovery zawsze ma dodatni ROI. Matematyka jest przeciwko każdej alternatywie.

Powyższe liczby można sprawdzić na naszych własnych projektach i case studies. Discovery Terra oszczędziło 215 tys. EUR. Discovery w projektach dla grup dealerskich oszczędzało od 120 do 380 tys. EUR na pojedynczym wdrożeniu. Nie znamy ani jednego discovery, które w ostatecznym rozrachunku nie zwróciło się kilkunastokrotnie.

Kiedy discovery jest niepotrzebne

Jesteśmy zwolennikami discovery, ale nie fanatykami. Są trzy sytuacje, w których discovery jest marnotrawstwem pieniędzy klienta:

Pierwsza: masz już działający prototyp z realnymi użytkownikami i zwalidowanym problemem. Jeśli twój prototyp ma 200 aktywnych użytkowników, którzy płacą za produkt, problem jest już zwalidowany rynkowo. Kolejna faza to scoping i skalowanie, nie discovery. Próba zrobienia discovery po fazie prototypu jest kosztowna i redundantna.

Druga: zakres projektu to jedna usługa na istniejącej platformie. Dodanie modułu raportowego do systemu, który już znamy, nie wymaga discovery. Wymaga 2-3 dniowej sesji scoping’u i estymacji. Discovery jest narzędziem do problemów złożonych, a nie do każdego ticketu.

Trzecia: budujesz coś, co już zbudowałeś dwa razy wcześniej w tej samej domenie. Jeśli jako Do More Soft wdrożyliśmy trzy CRM-y dla branży automotive, czwarty wdrożymy bez discovery — mamy wzorce procesów, wzorce architektury i wzorce integracji. Discovery ma wartość w eksploracji. Kiedy eksploracja jest już zrobiona, kolejne discovery jest teatrem.

W każdym innym przypadku — szczególnie gdy zmieniasz fundamentalny proces biznesowy, wchodzisz w nową domenę lub integrujesz systemy, które dotąd żyły niezależnie — discovery się opłaca. Zawsze.

Robimy to sami — nasze własne produkty przeszły discovery

Łatwo jest kazać klientom wody, a samemu pić wino. Dlatego budując własne produkty w modelu Venture Builder, każdy z nich przechodził wewnętrzne discovery zanim napisaliśmy linijkę kodu. MoreSales — nasz CRM/ERP dla e-commerce — powstał po trzytygodniowym discovery z dziesięcioma firmami e-commerce, które walczyły z tym samym problemem. MyCarApp — platforma dla branży automotive — powstał po sześciu tygodniach wywiadów z dilerami, logistyką fabryczną i klientami końcowymi.

Każdy z naszych 12 produktów jest dowodem, że discovery działa także na własnym P&L. Gdybyśmy pomijali discovery, dzisiaj mielibyśmy 4 produkty zamiast 12 — bo reszta upadłaby w pierwszych sześciu miesiącach po launchu, nie znajdując rynku. To nie hipokryzja „kazania wody, a picia wina”. To skin in the game — używamy tej samej metodyki, której uczymy klientów, i pokazujemy, że ona działa na nas.

Discovery jako najwyższa dźwignia ROI

Jeśli jesteś CTO lub founderem planującym projekt wart 200 tys. EUR lub więcej, pytanie nie brzmi „czy zrobić discovery?”, tylko „kiedy”. Odpowiedź: na samym początku, zanim pierwsza linia kodu zostanie napisana, zanim architekt zacznie rysować diagramy, zanim PM zacznie układać backlog. Discovery to 5-8% budżetu projektu, który chroni pozostałe 92-95% przed błędną alokacją.

Nie wiesz, czy twój projekt potrzebuje discovery? Napisz na office@domoresoft.com z tematem „Discovery check” — 30 minut rozmowy wystarczy, żebyśmy wspólnie zdecydowali, czy discovery się opłaci, czy to jeden z trzech przypadków, w których można je pominąć. Jeśli wolisz format ustrukturyzowany, użyj naszego konfiguratora — zajmie 4 minuty. Obie ścieżki prowadzą do tej samej rozmowy, na której rozstrzygamy, czy jest sens iść dalej. To pierwsza decyzja, którą warto podjąć świadomie, bo kolejne już zależą od niej.

FAQ — discovery w pigułce

Co znaczy proces discovery w software development?

Ustrukturyzowana faza poprzedzająca implementację, której celem nie jest spisanie wymagań, tylko podjęcie decyzji biznesowej: go, no-go albo pivot. W modelu DoMoreSoft trwa 10 dni roboczych, obejmuje 12-18 wywiadów ze stakeholderami, mapowanie procesów as-is/to-be, trzy scenariusze architektoniczne i trzyletni model TCO.

Ile kosztuje discovery w porównaniu do całego projektu?

5-8% budżetu projektu implementacyjnego. Przy projekcie wartym 300 tys. EUR discovery kosztuje 15-25 tys. EUR i zwraca się, jeśli pozwoli uniknąć 6,7% błędnego scope’u. W praktyce redukuje scope o 15-30%.

Dlaczego 90% projektów IT pada bez discovery?

Bo bez discovery zespół implementacyjny pracuje nad złym problemem albo nad właściwym problemem w zły sposób. Trzy archetypy: brief skopiowany z konkurencji, rozmowy tylko z managerami, cel biznesowy zastąpiony listą funkcjonalności.

Czym różni się discovery od audytu technicznego?

Audyt techniczny odpowiada na pytanie „jak jest?” w istniejącym systemie. Discovery odpowiada na pytanie „co budujemy, dlaczego, za ile i z jakim zwrotem?”. W projekcie wymagającym jednego i drugiego, audyt jest jednym z inputów do fazy 3 discovery, nie jej substytutem.