1. Vyjasnění cíle a hranic
První fáze zjišťuje, jaký problém má změna vyřešit a kdo jej dnes zažívá. Mapa procesu zahrnuje uživatele, jejich cíle, kroky mimo obrazovku, zdroje dat a situace, kdy standardní postup selže. Současně se zapisuje, co už je podloženo pozorováním a co je zatím pouze předpoklad. Bez této hranice se snadno změní odhad nákladů v neověřený slib. Výchozí měření může být jednoduché, ale musí být reprodukovatelné.
Discovery má skončit rozhodnutím o dalším kroku. Někdy je to prototyp kritické uživatelské cesty, jindy test rozhraní externího systému nebo zjištění kvality migrovaných dat. Je legitimní doporučit také koupený produkt či změnu procesu, pokud problém nevyžaduje vlastní aplikaci. Užitečné výstupy jsou krátké a konkrétní: formulace cíle, seznam rolí, mapa dat, největší rizika, možnosti řešení a kritéria, podle kterých se vybere první etapa.
2. Návrh architektury a důkazů
Architektura začíná hranicemi odpovědnosti. Který systém vlastní údaj, kdo může změnit stav a jak se výsledek předá další části procesu? Odpovědi se zachycují ve smlouvách rozhraní, modelu oprávnění a několika popsaných scénářích. Vedle ideálního průchodu je třeba navrhnout timeout, duplicitu, částečné selhání a návrat k předchozímu stavu. Bez těchto případů může diagram působit elegantně a přitom být v provozu nečitelný.
Důkaz má odpovídat největšímu riziku. Pro neznámé API může jít o integrační pokus, pro zatížený tok o měření na reprezentativních datech a pro nejasnou použitelnost o prototyp s reálnými uživateli. Ne každý systém potřebuje mikroservisy nebo distribuovanou platformu. Přehledná modulární aplikace může zjednodušit vývoj i provoz. Složitější dělení má smysl pouze tehdy, když konkrétní požadavky převáží jeho náklady na komunikaci, testy a dohled.
3. Průběžná dodávka
Vývoj se rozděluje podle výsledků, které lze ověřit. První dokončený průchod má spojit rozhraní, pravidla, data a pozorování v provozním prostředí, byť v malém rozsahu. Takový průchod odhalí problémy na hranicích dříve než samostatně hotové obrazovky nebo izolované služby. Další priority se upravují podle zjištění, nikoli pouze podle původní délky backlogu. Vlastník produktu musí vidět, co je hotové, co je stále nejisté a jak rozhodnutí mění rozsah.
U stabilního zadání lze podrobněji vymezit akceptační kritéria. U neznámého prostředí je poctivější pracovat s intervalem a předem říci, jak se odhad zpřesní. V obou případech se průběžně udržuje kód, dokumentace rozhodnutí, migrační postupy a automatizované kontroly kritických pravidel. Kvalita není závěrečná etapa, ale vlastnost každé dodávky. Technický dluh se zapisuje včetně dopadu, aby se o něm dalo rozhodnout vědomě.
4. Testování významných rizik
Testy mají chránit chování, jehož chyba by bolela uživatele nebo provoz. U finančního toku to může být nemožnost provést operaci dvakrát, u migrovaných dat zachování významu záznamu a u interní AI vyloučení zdroje, na který uživatel nemá oprávnění. Vedle automatických testů se kontroluje přístupnost, srozumitelnost chyb a chování na mobilu. Testovací data musí reprezentovat výjimky, ne jen šťastnou cestu.
Bezpečnostní kontrola vychází z konkrétních aktiv a rolí. Kdo může číst osobní údaje, kdo mění nastavení, kde se ukládají tajemství a co se zapisuje do logů? Kritické závislosti se aktualizují a změny se kontrolují. Externí audit může být součástí projektu, ale jeho rozsah a provedení musí být doloženy; obecný text na webu jej nenahrazuje. Stejně tak automatické skóre přístupnosti nedokazuje, že uživatel zvládne celý skutečný úkol.
5. Nasazení a předání
Před vydáním nové verze musí být jasné, jak se mění data, jak se změna ověří a kdo rozhodne o návratu. Migrační krok bývá méně vratný než kód, proto se plánuje zvlášť. Záloha má hodnotu jen tehdy, když je možné z ní obnovit použitelnou službu v přijatelném čase. Monitoring sleduje nejen dostupnost serveru, ale i důležité kroky: neúspěšné požadavky, zaostávání integrací a výjimky, které čekají na lidský zásah.
Předání zahrnuje přístup ke zdrojovému kódu, popis nasazení, vlastníka konfigurace, seznam závislostí a postup při incidentu. Uživatel webu nebo aplikace musí vědět, jak získá podporu a co se stane s jeho údaji. Klient musí rozumět významným architektonickým rozhodnutím, aby nebyl závislý na jediném člověku. Dokumentace má být stručná, ale použitelná v okamžiku, kdy se něco pokazí nebo když nový tým převezme údržbu.
6. Měření a další změna
Po spuštění se porovnává skutečný výsledek s výchozím stavem. Kratší doba vyřízení je přínos jen tehdy, pokud se nezvýší chybovost nebo náklady na opravy. U produktu mohou být důležitá jiná měřítka: dokončení úkolu, kvalita údajů, počet manuálních zásahů nebo dostupnost kritického toku. Metriky potřebují vlastníka a otázku, kterou pomáhají zodpovědět. Samotný dashboard bez návazného rozhodnutí žádnou hodnotu nevytváří.
Provozní data mohou ukázat, že původní architektonická volba přestala stačit, nebo naopak potvrdit, že složitější řešení není potřeba. Následující etapa by měla vycházet z těchto důkazů. Rozvoj systému neznamená nekonečné přidávání funkcí; zahrnuje také odstranění překážek, zjednodušení toku a ukončení nepoužívané části. Když jsou odpovědnosti a důvody rozhodnutí dohledatelné, může se produkt měnit bez nutnosti začínat pokaždé od nuly.