Jak převzít webovou aplikaci nebo dokončenou etapu prací?

Převzetí aplikace by nemělo spočívat v náhodném klikání a sbírání nesourodých připomínek. Nejprve se vraťte k dohodnutému rozsahu a sepište nejdůležitější scénáře: kdo akci provádí, s jakými daty, jaký výsledek má získat a co se má stát v nestandardní situaci.

Každý výsledek zapisujte na jednom místě. Připomínky rozdělte na nesoulad s rozsahem, překážku testu, nejasnou dohodu nebo novou potřebu. Teprve potom lze vědomě etapu převzít, převzít ji podmíněně nebo určit prvky, které je nutné opravit.

Kritéria převzetí je nejlepší dohodnout před začátkem vývoje. Pokud se tak nestalo, mohou obě strany očekávané chování popsat ještě před testováním. Nesmí se tím však potichu rozšiřovat původní rozsah.

Nejprve ověřte, co přesně přebíráte

Výchozím bodem je dohodnutý výsledek, ne všechno, co by aplikace mohla dělat v budoucnu. Shromážděte nabídku, popis etapy, schválené změny a prvky výslovně vyloučené z rozsahu. Pokud jsou dohody rozptýlené v několika zprávách a dokumentech, připravte před převzetím jedno shrnutí platné verze.

Shrnutí by mělo obsahovat:

• problém, který měla etapa vyřešit;
• funkce a procesy zahrnuté v rozsahu;
• uživatele a jejich role;
• data, soubory a integrace potřebné pro provoz;
• výslovně vyloučené prvky;
• osobu oprávněnou rozhodnout o převzetí;
• příklady nebo kritéria, podle kterých lze poznat dokončení etapy.

Pokud firma přebírá první část většího systému, neměla by ji hodnotit podle funkcí plánovaných do budoucna. Musí však ověřit, zda tato etapa sama poskytuje výsledek popsaný v nabídce. Článek Jak vybrat dodavatele webové aplikace? ukazuje, proč je vhodné tato pravidla stanovit ještě před zahájením spolupráce.

Připravte scénáře převzetí

Scénář převzetí popisuje skutečný úkol uživatele. Nemusí být technickou dokumentací, ale měl by odpovědět na pět otázek:

1. Kdo akci provádí?
2. Z jakého stavu vychází?
3. Jaká data používá?
4. Jaké kroky provede?
5. Jaký výsledek má vidět v aplikaci a propojených systémech?

Nejprve zapište hlavní průběh procesu. Potom doplňte nejdůležitější nestandardní situace, které mohou reálně nastat. Podle typu řešení může jít například o chybějící povinné pole, opakování stejné operace, duplicitní data, nedostatečné oprávnění nebo nedostupný externí systém.

Neexistuje jediný správný počet scénářů. Jednoduchý formulář potřebuje jiný rozsah kontroly než systém s několika rolemi, platbami a integracemi. Počet testů má vycházet z dohodnutého rozsahu, významu procesu a následků chyby.

Dohodněte bezpečná data a testovací prostředí

Před testováním určete, kde bude probíhat a jaká data lze použít. Nejbezpečnější je začít v testovacím prostředí s demonstračními daty nebo vhodně připraveným vzorkem.

Do běžné tabulky s připomínkami nevkládejte hesla, API klíče ani úplná data klientů. Pokud může akce odeslat zprávu, vytvořit účetní doklad, změnit stav skladu nebo spustit platbu, nejprve ověřte, zda test nebude mít skutečné následky.

Zapište:

• adresu nebo název prostředí;
• verzi aplikace předanou k převzetí;
• datum a přibližný čas testu;
• roli použitého účtu;
• označení sady testovacích dat;
• aktivní integrace a funkce, které byly záměrně vypnuty.

Díky tomu může dodavatel problém zopakovat. Bez těchto informací může stejný scénář skončit jinak kvůli změně verze, konfigurace nebo dat.

Zapisujte výsledky do jedné tabulky

Jednotlivé snímky obrazovky rozeslané několika kanály rychle ztrácejí souvislosti. Užitečnější je společná tabulka, ve které má každá důležitá připomínka odpovědnou osobu a rozhodnutí.

Tabulka usnadňuje komunikaci, ale nenahrazuje technické testy dodavatele. Není ani úplným bezpečnostním či výkonnostním auditem. Pokud tyto oblasti ovlivňují rozhodnutí o převzetí, potřebují vlastní rozsah a kritéria.

Oddělte chybu, překážku a novou potřebu

Nejvíce nedorozumění vzniká, když jsou všechny připomínky označeny jako „chyby“. Čtyři typy připomínek vyžadují rozdílná rozhodnutí.

Ne každá připomínka uživatele je chybou. To ale neznamená, že ji lze ignorovat. Každá důležitá připomínka má dostat klasifikaci, odpověď a informaci o dalším postupu.

Zkontrolujte role, oprávnění a výjimky

Hlavní průběh nestačí, pokud má aplikace více skupin uživatelů nebo provádí operace s důležitými následky. Při převzetí zkontrolujte alespoň zásadní hranice:

• zda uživatel vidí pouze data určená jeho roli;
• zda systém nepovolenou operaci blokuje, a nejen skrývá v nabídce;
• zda chybná nebo neúplná data vedou ke srozumitelné zprávě;
• zda systém po chybě zůstane v bezpečném a pochopitelném stavu;
• zda opakování operace nevytvoří nekontrolovaný duplikát;
• zda je známo chování při výpadku externí integrace.

Tato kontrola nenahrazuje bezpečnostní audit webové aplikace. Pouze ukazuje, zda hlavní proces odpovídá dohodnutému rozsahu a nezpřístupňuje zjevné operace nesprávné roli. Technická bezpečnostní kontrola má odpovídat typu dat a následkům chyby.

Příklad jednoho scénáře převzetí

Předpokládejme, že etapa má umožnit vytvoření pracovního příkazu ze schválené objednávky. Jde o smyšlený příklad, nikoli popis hotového produktu nebo konkrétní realizace klienta.

Takový zápis umožňuje ověřit výsledek bez řešení technické implementace. Pokud test neprojde, je zřejmé, zda se problém týká hlavního výsledku, opakování operace nebo zpracování chybějících dat.

Větší projekt přebírejte po etapách

Odkládání všech testů na konec projektu zvyšuje počet nejasností řešených najednou. U většího rozsahu je lepší přebírat jednotlivé oblasti ve chvíli, kdy jsou dostatečně stabilní pro spolehlivou kontrolu.

Před další kontrolou:

• uzavřete předchozí připomínky nebo zapište jejich stav;
• určete jednu verzi aplikace pro testování;
• zopakujte opravený scénář;
• znovu prověřte nejdůležitější související činnosti, které mohla změna ovlivnit;
• nové nápady přesuňte na oddělený seznam dalšího rozvoje.

Nevnucujeme jednu metodiku všem projektům. Způsob převzetí má odpovídat rozsahu, riziku a organizaci práce klienta. V naší práci oddělujeme dohodnutý výsledek etapy od dalších nápadů, aby obě strany rozhodovaly podle stejného seznamu.

Po testování udělejte jedno jasné rozhodnutí

Seznam připomínek ještě není rozhodnutím. Po skončení kola převzetí jasně určete jeden ze tří výsledků.

Převzato

Dohodnutá kritéria jsou splněna. Další nápady nebo funkce vyloučené z etapy se přesunou do dalšího rozvoje.

Převzato podmíněně

Zůstaly přesně popsané prvky, které nebrání dohodnutému použití. Každý má odpovědnou osobu, termín nebo dohodnutý další krok. Tato možnost má vycházet z dohody stran, nemá vznikat automaticky.

Předaný rozsah nebyl převzat

Důležitý dohodnutý scénář nefunguje nebo ho nelze spolehlivě ověřit. Místo obecného tvrzení, že „aplikace není hotová“, uveďte konkrétní výsledek, data a podmínku opakovaného testu.

Význam převzetí pro platbu a smlouvu závisí na konkrétní spolupráci. Tento článek není právní radou ani vzorem předávacího protokolu.

Před nasazením ověřte provozní připravenost

Převzatý rozsah ještě nemusí být připraven k bezpečnému spuštění. Před nasazením určete:

• kdo a kdy nasazení provede;
• zda existuje aktuální záloha a použitelný způsob návratu změny;
• kdo dodá chybějící konfiguraci, účty a přístupy;
• které důležité operace budou po spuštění sledovány;
• kdo na straně klienta a dodavatele rozhoduje při problému;
• kde a v jakých hodinách se hlásí naléhavé problémy.

Reakční doby, hodiny podpory a další pohotovost se stávají závazkem až po zapsání do nabídky nebo smlouvy. Rozdělení těchto povinností popisuje stránka správy aplikací a e-shopů.

Zajistěte řádné předání výsledku etapy

Před uzavřením práce potvrďte, co firma získává kromě přístupu k fungující aplikaci. Podle projektu to mohou být:

• přístup k aplikaci, repozitáři a příslušným účtům;
• návody potřebné uživatelům nebo správci;
• informace o závislostech, licencích a externích službách;
• známá omezení a rozhodnutí odložená na později;
• dohodnuté informace o zálohách, nasazení a správě;
• výsledky převzetí a seznam dalších nápadů.

Pokud je převzetí spojené se změnou dodavatele nebo převzetím celého systému, použijte kontrolní seznam převzetí aplikace. Pomáhá ověřit kód, data, účty, infrastrukturu a dokumentaci. Zadané informace automaticky neodesílá.

Nejčastější otázky

Kdo by měl aplikaci za firmu přebírat?

Osoba, která zná kontrolovaný proces a dokáže potvrdit očekávaný výsledek. U důležitějších řešení je vhodné spojit znalost uživatele procesu s rozhodnutím osoby odpovědné za rozsah. Dodavatel by neměl být jedinou stranou potvrzující vlastní práci.

Lze převzetí provést bez technických znalostí?

Ano, pokud scénáře popisují úkoly uživatele, data a očekávaný výsledek. Netechnická osoba může prověřit obchodní proces. Testy kódu, bezpečnosti, výkonu a infrastruktury však vyžadují odpovídající technický rozsah.

Co dělat, když nebyla kritéria převzetí zapsána předem?

Před testováním shromážděte potvrzené dohody, příklady a výjimky. Potom společně popište scénáře vyplývající z dohodnutého rozsahu. Pokud vznikne spor, neskrývejte ho za nové kritérium. Označte bod jako vyžadující vysvětlení.

Jaký je rozdíl mezi chybou a novou funkcí?

Chyba nebo nesoulad nastává, když dohodnuté chování nefunguje podle rozsahu. Nová funkce tento rozsah rozšiřuje nebo mění. Pro určení hranice může být nutné vrátit se k nabídce, schváleným změnám a příkladům z plánování.

Blokuje každá připomínka převzetí etapy?

Ne. Význam připomínky závisí na dohodnutém výsledku a dopadu na používání. Závažný nesoulad v hlavním procesu může převzetí zablokovat. Drobný bod lze vyřešit podle dohodnutého postupu podmíněného převzetí.

Nahrazují uživatelské testy testy dodavatele?

Ne. Uživatelské převzetí ověřuje především proces z pohledu firmy. Dodavatel nadále odpovídá za dohodnuté technické testy. Při vyšším riziku bezpečnosti nebo výkonu mohou být potřeba samostatné audity.

Musí se aplikace testovat se skutečnými daty?

Ne vždy. Začněte demonstračními daty nebo vhodně připraveným vzorkem. Skutečná data mohou být potřebná při řízené migraci nebo zvláštním případu, ale jejich rozsah, přístup a ochrana se musí dohodnout předem.

Co se má předat po převzetí?

Záleží na rozsahu. Potvrďte přístup k aplikaci a dohodnutým materiálům, výsledky převzetí, známá omezení, externí služby a informace potřebné pro nasazení a další správu.

Dohodněte převzetí před zahájením další etapy

Pokud plánujete novou aplikaci nebo rozvoj současného systému, podívejte se na vývojářské služby PHP a Laravel od Domin Software. V prvním rozsahu určujeme problém, výsledek, potřebná data a způsob ověření práce. Větší nebo nejasný projekt lze nejprve uspořádat pomocí business analýzy a stanovení MVP.

Pro první rozhovor připravte popis současného procesu, uživatelů, důležitých dat a výsledku, který má po první etapě fungovat. Neposílejte hesla, klíče ani databázi klientů. Po posouzení popisu uvedeme, jaké informace ještě chybějí pro stanovení rozsahu a odhadu.

Zdroje

• OWASP Application Security Verification Standard, OWASP, stabilní verze 5.0.0 zveřejněná 30.05.2025, přístup ověřen 30.10.2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, publikováno v únoru 2022, přístup ověřen 30.10.2026.