Discovery przed developmentem: dlaczego Tech Lead od początku oszczędza budżet i czas

Co trzeci projekt IT nie jest realizowany w założonym budżecie, a 4 na 10 nie jest dowożonych w terminie. Tak przynajmniej deklarują to respondenci w PMI Pulse of the Profession 2025 (68% projektów dostarczonych w planowanym budżecie oraz 59% zgodnie z harmonogramem).

W dużych projektach IT robi się jeszcze ciekawiej: McKinsey + University of Oxford (5 400+ projektów) pokazuje średnio ~45% przekroczenia budżetu, ~7% opóźnienia i ~56% mniej dostarczonej wartości niż zakładano.

Często źródłem tych problemów nie jest „zły wykonawca”, tylko słaba faza discovery w IT (product discovery / discovery workshop). To moment, w którym biznes i zespół techniczny domykają kluczowe decyzje: zakres, ryzyka, integracje i konsekwencje techniczne. Gdy discovery jest pomijane albo robione „symbolicznie”, możemy się spodziewać klasyki: zmian wymagań w trakcie prac, niedoszacowania, opóźnień i rosnących kosztów, a w efekcie frustracji zarówno zespołu biznesowego jak i produktowego. Nie dlatego, że zespół robi coś źle, tylko dlatego, że za wcześnie zaczęto budować bez kluczowych decyzji.

Po dobrym discovery masz MVP, mapę integracji, listę ryzyk i estymację w widełkach - czyli bazę, żeby wejść w development w pełni świadomie.

TL;DR

• Discovery to etap przed developmentem, w którym doprecyzowujesz cele, zakres, ryzyka, architekturę i plan MVP.
• Tech Lead przekłada potrzeby biznesowe na decyzje techniczne i wyłapuje zagadnienia, które później najczęściej „wybuchają” (integracje, dane, bezpieczeństwo, skalowanie).
• Efekt: lepsze estymacje, mniej kosztownych zmian w trakcie prac i większa przewidywalność dostarczenia produktu.

Dla kogo: PM/PO, CTO/Tech Lead, firmy planujące nowy produkt lub duży refactor z integracjami.

Czym jest faza discovery w projektach IT?

Faza discovery (czasem: product discovery, discovery phase, warsztaty discovery) to pierwszy etap pracy nad produktem cyfrowym, który dzieje się zanim zespół zacznie kodować. Jej celem nie jest „wymyślenie wszystkiego”, tylko doprowadzenie do sytuacji, w której projekt startuje na realnych założeniach, a nie na domysłach.

Discovery odpowiada na pytania:

• Po co budujemy produkt (cel biznesowy, KPI)?
• Co jest naprawdę potrzebne (zakres i priorytety)?
• Jak to dostarczyć (warianty techniczne i konsekwencje)?
• Co może pójść nie tak (ryzyka, ograniczenia, zależności)?

Dobrze przeprowadzone discovery w IT zwykle kończy się konkretnymi artefaktami: MVP, backlogiem startowym, architekturą high-level, mapą integracji, listą ryzyk i estymacją w realistycznych widełkach. Oczywiście, ilość artefaktów jest zależna od wielkości i poziomu złożoności projektu. Jednak, jeśli po discovery nie ma żadnych decyzji ani artefaktów, to development staje się fazą „odkrywania” problemów. Tyle że wtedy każda korekta ma wyższą cenę: w czasie, kosztach i frustracji zespołów.

Dlaczego discovery ma kluczowy wpływ na budżet i terminy?

Co generuje największy koszt po starcie developmentu?

Najdroższe w projektach IT są nie błędy w kodzie, tylko zmiany wynikające z decyzji podjętych za późno. Kiedy projekt już działa, zmiana jednej rzeczy pociąga kolejne: model danych, integracje, uprawnienia, procesy, testy, monitoring, bezpieczeństwo.

Przykład z życia: „to tylko płatności online”

Załóżmy, że firma chce zbudować platformę kursów online. Wymaganie brzmi prosto:

„Posiadamy bardzo dużą grupę odbiorców, dla których chcemy zbudować system E-Learningowy wraz z płatnościami online”.

Temat brzmi prosto, każdy wie co należy zbudować, zespół rusza: wybiera operatora, integruje się z jego systemem, buduje podstawowy flow zakupowy. Aż nagle w połowie prac ze strony klienta pada informacja:

„Jak wszyscy wiemy chcemy działać w kilku krajach, z lokalnymi operatorami i potrzebujemy płatności ratalnych”

To co dla klienta może wyglądać na proste rozwiązanie „to już działa, wystarczy skopiować”, zwykle nie jest drobną poprawką. To potencjalnie:

• zmiana lub dodanie więcej integracji (różne API, różne modele rozliczeń),
• wielowalutowość i inne podatki,
• zwroty, chargebacki, różne ścieżki reklamacji,
• różne wymagania prawne i compliance,
• wyższe wymagania dot. bezpieczeństwa i audytu,
• potrzeba przeprojektowania architektury (żeby to utrzymać i skalować).

Jak discovery zmniejsza koszt zmian w trakcie developmentu?

Discovery pomaga wyłapać takie rzeczy na początku, kiedy zmiana planu jest tania. Jednak, aby to było możliwe, trzeba realnie połączyć świat biznesu ze światem technologii. I tu na scenę wchodzi Lider Techniczny, którego zadaniem jest przygotowanie i zaproponowanie odpowiednich wariantów rozwiązań (w tym architektury czy integracji), które pozwolą dostarczyć realny produkt.

Powiązany temat: Koszty projektów IT – co je najczęściej winduje

Jak discovery uratowało MVP przed budową „mini-telkomu”

Klient chciał zbudować „hub komunikacyjny” w jednym miejscu: SMS, e-mail, szablony, preferencje, historia wysyłek, raporty. W pierwszym podejściu w zakresie wylądowały też: własna bramka GSM/SMPP i własna infrastruktura do wysyłki maili.

Dzięki temu, że w fazie discovery uczestniczył także Lider Techniczny, udało się już na wstępnym etapie ustalić, że „własna bramka” to osobny produkt z ciężarem operacyjnym i ryzykiem, które nie dawało wartości biznesowej na starcie. Zamiast tego zostawiliśmy po naszej stronie to co wyróżniało produkt (szablony, routowanie, mechanizm niezawodności wysyłki, raportowanie, preferencje), a wysyłkę przenieśliśmy na integracje z zewnętrznymi dostawcami (SMS/e-mail), tak żeby dało się ich wymieniać.

Efekt: MVP powstało szybciej, a zespół skupił się na tym, co faktycznie różnicuje produkt, bez dokładania sobie telekom/antyspamowego “core’a”.

Kim jest Tech Lead i jaka jest jego rola w discovery?

Lider Techniczny (Tech Lead) to doświadczony inżynier oprogramowania, który nie tylko zna technologie, ale rozumie też biznesowy kontekst projektu.

To osoba, która:

• potrafi przełożyć język biznesu na język techniczny i odwrotnie,
• odpowiada za dobór technologii i architektury systemu,
• wspiera zespół developerski w rozwiązywaniu trudnych problemów,
• dba o jakość kodu i spójność rozwiązań,
• patrzy na projekt z perspektywy długoterminowego rozwoju produktu.

Ważne: Tech Lead nie zastępuje PM-a ani Analityka Biznesowego. On uzupełnia ich perspektywę o to, co w IT najczęściej generuje koszt i ryzyko.

Tech Lead vs Project Manager vs Business Analyst

W odróżnieniu od Kierownika Projektu (PM) czy Analityka Biznesowego (BA), Tech Lead myśli o projekcie nie tylko w kategoriach „co ma powstać”, ale przede wszystkim: „jak to zbudować, żeby działało, dało się rozwijać i nie zjadło budżetu”. Niemniej każda z tych ról jest niezwykle istotna w projektach IT.

• PM pilnuje procesu, komunikacji, planu, ryzyk projektowych.
• BA doprecyzowuje wymagania, procesy, reguły biznesowe, scenariusze.
• Tech Lead podejmuje/komentuje decyzje techniczne i mówi, jak one wpływają na koszt, czas i jakość.

Jak wygląda discovery z Tech Leadem?

Discovery z Tech Leadem to nie rozmowy o „kodzie i architekturze”. To warsztaty, na których sprawdzamy, czy inicjatywa ma jasno zdefiniowaną wartość, realny zakres i sensowne podejście kosztowo-operacyjne. Dobrze przeprowadzone pozwalają odpowiedzieć na następujące pytania:

• Cele i miary sukcesu - Co ma się zmienić w biznesie? Jak poznamy, że to zadziałało (KPI/miary)?
• Zakres i priorytety - Co musi znaleźć się w MVP, co może poczekać, a co jest opcjonalne?
• Ryzyka i ograniczenia - Co może nas zablokować lub podnieść koszt: budżet, terminy, zależności, wymagania prawne, dane wrażliwe, integracje?
• Systemy i integracje - Jakie systemy muszą się połączyć, jakie dane przepływają, gdzie są wąskie gardła?
• Warianty realizacji i konsekwencje – Jakie są możliwe podejścia, co oznaczają dla: kosztu, czasu, utrzymania i skalowalności?
• Budować czy kupić - Co budować, a co lepiej kupić lub zintegrować, żeby nie przepalić budżetu?
• Plan startu (MVP) i estymacje - Od czego zaczynamy: backlog na start, zależności, widełki czas/koszt, plan pierwszych iteracji?

Co daje Tech Lead od pierwszego dnia discovery?

Lepsze decyzje na wejściu (zamiast poprawek w połowie)

Tech Lead potrafi od razu wychwycić, że:

• „niewinne” wymaganie oznacza zmianę architektury,
• integracja to nie tylko „podpięcie API”, ale też obsługa błędów, monitoring, bezpieczeństwo,
• pewne elementy muszą powstać wcześniej (np. model danych, uprawnienia), inaczej spowolnią wszystko.

Mniej kosztownych zmian w trakcie developmentu

Im później zmiana, tym droższa. Tech Lead w trakcie discovery minimalizuje ryzyko, że po kilku sprintach trzeba będzie „przebudować fundamenty”.

Dokładniejsze estymacje

Największe rozjazdy estymacji biorą się zwykle z obszarów, które widać dopiero „od środka”: zależności modułów, integracje, dane, uprawnienia, compliance, środowiska i operacyjność. Tech Lead uwzględnia je wcześniej.

Większa przewidywalność projektu

Mniej zaskoczeń, mniej gaszenia pożarów, bardziej stabilne dostarczanie produktu i większe poczucie kontroli po stronie klienta.

Ile trwa discovery w IT?

To zależy od złożoności i ryzyk, ale orientacyjnie:

• dla małych i średnich produktów: zwykle kilka dni do 2–3 tygodni,
• dla projektów z wieloma integracjami/compliance: kilka tygodni.

Kluczowe nie jest „ile trwa”, tylko czy discovery kończy się decyzjami, które realnie skracają development i zmniejszają ryzyko.

Co powinno być wynikiem discovery?

Po discovery klient powinien mieć materiał, na którym da się oprzeć start developmentu. Najczęściej są to:

Cele i definicja MVP

• 1 - 3 cele (np. chcemy zwiększyć sprzedaż o 30%)
• Co wchodzi do MVP, a co świadomie nie (out of scope)

Mapa integracji i najważniejsze ryzyka

• z czym się łączymy (systemy, API, dostawcy)
• 5 kluczowych ryzyk + jak możemy je szybko zweryfikować (krótki test/prototyp)

Zarys rozwiązania i kluczowe decyzje

• zarys architektury na poziomie komponentów
• Najważniejsze wybory i ich konsekwencje: „wybieramy X zamiast Y, bo…”

Lista prac na start + widełki estymacji + założenia

• co robimy na początku (pierwsze 1-2 iteracje)
• widełki czas/koszt + lista założeń, od których zależą

Plan pierwszych kroków

• kolejność prac, zależności (co blokuje co)
• kto musi dostarczyć jakie informacje i do kiedy

Kiedy discovery z udziałem Tech Leada jest szczególnie potrzebne?

Jeśli w Twoim projekcie występuje kilka z poniższych punktów, Tech Lead w discovery znacząco zwiększa szanse na dowiezienie projektu bez „przykrych niespodzianek”:

• integracje (płatności, ERP/CRM, SSO, marketplace, zewnętrzne API),
• dane wrażliwe lub regulacje (RODO, PSD2, compliance branżowe),
• produkt na wiele krajów/języków/walut,
• rozbudowane role, uprawnienia, procesy,
• długofalowy rozwój produktu (roadmapa na miesiące/kwartały).

FAQ: discovery w projektach IT

Kiedy robi się fazę discovery?

Najlepiej na początku projektu, zanim zacznie się development i zanim powstanie backlog oparty na niedopowiedzeniach.

Czy discovery jest płatne?

Zwykle tak, bo to realna praca (warsztaty, analiza, architektura, estymacje). Dobra wiadomość: discovery najczęściej oszczędza większe koszty, które pojawiłyby się później jako poprawki i opóźnienia.

Czy discovery ma sens w małych projektach?

Jak najbardziej, w małych projektach błędne założenia bolą proporcjonalnie bardziej. Nawet krótkie discovery pomaga podjąć decyzję: startujemy od MVP, ograniczamy zakres albo zmieniamy podejście.

Czy discovery gwarantuje brak zmian?

Nie. Zmiany są naturalne. Discovery sprawia, że zmiany są mniejsze, bardziej kontrolowane i mniej kosztowne, bo fundamenty są przemyślane.

Czy discovery jest mi potrzebne?

Jeśli chcesz szybko ocenić, czy discovery jest Ci potrzebne, zadaj sobie 3 pytania:

1. Czy mamy integracje lub obszary regulowane (płatności, dane wrażliwe, compliance)?
2. Czy MVP i priorytety są naprawdę ustalone, czy „mniej więcej”?
3. Czy mamy świadomość największych ryzyk technicznych i kosztowych?

Jeśli choć raz odpowiedź brzmi „nie wiem” - discovery jest dobrym pierwszym krokiem do poznania swojego projektu.

Jeśli planujesz aplikację webową lub mobilną i chcesz uniknąć przepalania budżetu na zmiany w trakcie developmentu, porozmawiajmy. W krótkiej rozmowie zbierzemy kluczowe założenia, wskażemy największe ryzyka (np. integracje, dane, compliance) i podpowiemy, od czego zacząć, żeby projekt był przewidywalny.

Skontaktuj się z nami