--- title: "Mit adjon egy fizetős feltáró szakasz a szoftverprojektben?" description: "Mit kell hoznia egy fizetős feltáró szakasznak, mielőtt a fejlesztés mellett dönt: döntések, tesztelt kockázatok, becsült sávok, első mérföldkő, tiszta kiút." canonical: https://sdk.enterprises/hu/insights/what-a-paid-discovery-phase-should-deliver language: hu --- # Mit adjon egy fizetős feltáró szakasz a szoftverprojektben? Frissítve: 2026-09-26 > Egy fizetős feltáró szakasz (discovery) végén döntéseknek kell születniük, nem csak dokumentumoknak: mit építsenek meg először és mit hagyjanak ki, melyek a fő kockázatok és hogyan tesztelték őket, egy sávként megadott becslés a feltételezéseivel, és egy indulásra kész első mérföldkő. Egyetlen próbával ítélje meg: el tudná-e vinni az eredményeket egy másik csapathoz, és elkezdhetnék-e a fejlesztést anélkül, hogy elölről kezdenék? ## A feltáró szakasz arra való, hogy a nagy döntések akkor szülessenek meg, amikor még olcsók A feltáró szakasz, más néven discovery, scoping vagy inception, egy rövid, fizetős szakasz a szoftverfejlesztés előtt. Az a feladata, hogy megszüntesse a becsléseket megbízhatatlanná tevő bizonytalanságot, és rendezze a nagy döntéseket, amíg még olcsó megváltoztatni őket. Egy papíron hozott döntés megváltoztatása egy beszélgetésbe kerül; a kód megírása után átdolgozásba. A korai szoftveres becslések tágak, és csak akkor szűkülnek, amikor a döntések csökkentik a bizonytalanságot; ezt a jelenséget gyakran a bizonytalanság kúpjának (cone of uncertainty) nevezik. Önmagukban a megbeszélések nem szűkítik őket. A feltáró szakaszért akkor érdemes fizetni, ha kikényszeríti ezeket a döntéseket: mit kell a terméknek először tudnia, mely korlátok rögzítettek, és mely műszaki kockázatok valósak. ## A kezdés előtt egyezzenek meg, mit fog kapni A feltáró szakaszt úgy vásárolja meg, mint bármely más eredményterméket: rögzített időtartammal, rögzített árral, megnevezett emberekkel és a kimenetek írásos listájával. Ha egy partner nem tudja megmondani, mi lesz a kezében a végén, a szakasz nyílt végű workshopokba csúszhat át. A kimenetek teljes köre általában a következőket tartalmazza. - Problémaleírás: kik a felhasználók, mire van szükségük, és hogyan mérik majd a sikert - Az első kiadás munkaterjedelme: mi van benne, mi marad ki, és mi kerül későbbre - A fő felhasználói utak, felvázolva vagy prototípusként ott, ahol bizonytalanok - Architektúravázlat: fő komponensek, integrációk, adatok és tárhely, a mérlegelt lehetőségekkel - Kockázati nyilvántartás, amely rangsorolja, mi okozhatja a projekt kudarcát, és hogyan kezelik az egyes kockázatokat - Sávként megadott becslés a feltételezéseivel, és egy első mérföldkő átvételi kritériumokkal - Döntési napló, amely rögzíti, mit, ki és miért döntött el ## Döntéseket keressen, ne dokumentumhalmot Egy feltárási jelentés lehet hosszú, és mégsem dönt el semmit. Kötelezettségvállalásokat keressen benne: mely funkciók kerülnek az első kiadásba és melyek nem, milyen technológiai és tárhelydöntések születtek, mely integrációkra van szükség, és mely kérdések maradtak nyitva, mindegyik egy felelőssel és egy határidővel. Hasznos jelzés, hogy mit nem javasolt a partner. Ha a munkaterjedelem a végén nagyobb, mint az elején volt, és semmit sem vágtak ki, a feltáró szakasz valószínűleg csak rögzítette a kívánságlistáját, ahelyett hogy tesztelte volna. Néha az a helyes következtetés, hogy vásároljon meg egy meglévő terméket, építsen kevesebbet, vagy egyáltalán ne építsen, és egy jó feltáró szakasz ezt ki is mondja. ## A legkockázatosabb feltételezéseket tesztelni kell, nem csak felsorolni Minden projekt néhány olyan feltételezésen nyugszik, amely mindent megváltoztatna, ha tévesnek bizonyulna: egy külső API, amely nem támogatja a szükséges műveletet, a vártnál rendezetlenebb adatok, egy teljesítménycél, amelyet a választott terv nem tud teljesíteni, vagy felhasználók, akik nem fognak változtatni a munkamódszerükön. Kérje meg a partnert, hogy korán nevezze meg ezeket a feltételezéseket, és a legrosszabbakat tesztelje a feltáró szakasz alatt, egy műszaki próbával (spike), egy kattintható prototípussal vagy egy munkaüléssel azokkal, akik az érintett rendszert üzemeltetik. A tesztelt kockázat információ. A csak leírt kockázat még mindig találgatás. ## Az őszinte becslés egy sáv, a hozzá tartozó feltételezésekkel Egyetlen szám a feltáró szakasz végén elrejti a megmaradó bizonytalanságot. Kérjen sávot az első kiadásra, fő komponensek szerint bontva, azokkal a feltételezésekkel, amelyek felfelé vagy lefelé mozdítanák. Például: a becslés feltételezi, hogy a fizetési szolgáltató API-ja már támogatja a részleges visszatérítést; ha nem, adja hozzá a külön felsorolt integrációs munkát. Kérdezze meg, a becslés mely részei szilárdak és melyek még bizonytalanok, és hogyan kezeli majd az üzleti modell az egyes részeket. A szilárd részek fix áron árazhatók; a bizonytalan részekhez költségkeret kell, és egy pont, ahol újra dönt. Az első mérföldkövet olyan pontosan kell meghatározni, hogy fix áron le lehessen szállítani. ## Minden lépésnél legyen kiút A feltáró szakasz a legolcsóbb pillanat a kilépésre is. Győződjön meg róla, hogy minden, amit létrehoz, az Öné, a dokumentumoktól és ábráktól a prototípusokig és a kódig, és hogy a kimenetek bármely hozzáértő csapat számára készülnek, nem csak annak a partnernek, amely írta őket. Szabadon dönthessen, hogy ezzel a partnerrel fejleszt, átadja az eredményeket egy másik csapatnak, házon belül fejleszt, vagy leállítja a projektet. Ugyanezt a gondolatot vigye tovább az ezt követő tervbe: egy első mérföldkő átvételi kritériumokkal, majd egy döntési pont, ahol folytathatja, irányt válthat vagy befejezheti az együttműködést. Az SDK Enterprisesnél így indítjuk a projekteket: írásos munkaterjedelem, rögzített első mérföldkő és a megnevezett mérnökök, így látja a tervet, mielőtt egy nagyobb költségkeret mellett elköteleződne. Ha csak tanácsra van szüksége, írásos választ kap, amely alapján a saját csapata cselekedni tud, akár velünk fejleszt, akár nem. ## Hat kérdés, amelyből kiderül, megérte-e fizetni a feltáró szakaszért Amikor a szakasz véget ér, vesse össze az eredményeket ezekkel a kérdésekkel. Ha a legtöbb válasz igen, a pénzén világosságot vásárolt. Ha a legtöbb nem, workshopokért fizetett. - Elkezdhetné egy másik csapat a fejlesztést ezekből a kimenetekből a feltárás megismétlése nélkül? - Beszélt a partner a felhasználókkal és az érintett rendszereket üzemeltetőkkel is, nem csak a szponzorral? - Tesztelték a legkockázatosabb feltételezéseket, és leírták az eredményeket? - A becslés egyértelmű feltételezésekkel megadott sáv, nem pedig egyetlen szám? - Vágtak ki, halasztottak el vagy kérdőjeleztek meg valamit? - Elég pontosan meghatározták az első mérföldkövet ahhoz, hogy át lehessen venni vagy el lehessen utasítani? ## A legfontosabbak - A feltáró szakaszt rögzített időtartammal, rögzített árral, megnevezett emberekkel és a kimenetek írásos listájával vásárolja meg. - Az eredményeket a bennük foglalt döntések alapján ítélje meg, azt is beleértve, mit vágtak ki vagy mit nem javasoltak. - A legkockázatosabb feltételezéseket a feltáró szakasz alatt tesztelni kell, nem csak felvenni egy kockázati nyilvántartásba. - A becslést sávként várja, feltételezésekkel, és egy olyan pontosan meghatározott első mérföldkővel, hogy be lehessen árazni. - Minden kimenet legyen az Öné, hogy fejleszthessen ezzel a partnerrel, egy másik csapattal, vagy egyáltalán ne. ## GYIK ### Fizetős legyen a feltáró szakasz, vagy egy partner ingyen is elvégezheti? Az ingyenes munkaterjedelem-felmérés az értékesítés része, ezért ott áll meg, ami belefér egy ajánlatba. Ha fizet a feltáró szakaszért, időt vásárol arra, hogy elolvassák a kódját, beszéljenek a felhasználóival és teszteljék a kockázatokat, valamint olyan kimeneteket, amelyek az Önéi. A szakasz legyen rövid és fix áras, hogy a kötelezettségvállalás kicsi maradjon. ### Mennyi ideig tartson egy feltáró szakasz? Addig, amíg megválaszolja a megbízható becslést akadályozó kérdéseket, és ne tovább. Az időtartamot előre egyeztessék a termék mérete és az érintett rendszerek száma alapján, és a szakasz az első mérföldkőről szóló döntéssel záruljon, ne a feltárás meghosszabbításával. ### Mi van, ha a feltáró szakaszból kiderül, hogy nem éri meg megépíteni a projektet? Akkor a lehető legalacsonyabb költséggel végezte el a dolgát. Egy jó feltáró szakasz arra is juthat, hogy vásároljon meg egy meglévő terméket, építsen kisebb első változatot, vagy álljon le, és az eredmények mindenképpen Önnél maradnak. ## Induljon ki az igényéből - [Mobilalkalmazás-fejlesztés](https://sdk.enterprises/hu/mobile-app-development) ## Kapcsolódó szolgáltatások - [Technikai audit és tanácsadás](https://sdk.enterprises/hu/services/consulting) - [Egyedi szoftver](https://sdk.enterprises/hu/services/product-engineering) ## További olvasnivaló - [Mit kérdezzen, mielőtt szoftverfejlesztő partnert választ?](https://sdk.enterprises/hu/insights/choosing-a-software-partner) - [Így írjon szoftverprojekt-leírást összevethető ajánlatokért](https://sdk.enterprises/hu/insights/writing-a-software-project-brief)