Od toho je analýza. Ostatně i standardní vodopádové metodiky jako je Prince 2 nebo RUP s tím umí pracovat.
Já mám zase velmi špatné zkušenosti s použitím agilních metodik u dodavatelských projektů. Ony vyžadují aktivní zapojení stakeholdera na straně zákazníka a takový člověk se najde jen výjimečně. Většinou takové projekty skončily hrubým rozčarováním a konfliktem mezi očekáváním zákazníka a dodavatele.
Jak sebelepší analýza zjistí zkušenosti uživatelů z reálného provozu? (“Nejlepší test použitelnosti služby je její používání uživateli.”)
Za mně je právě tohle zásadní chyba, která komplikuje úspěšnost dodávky - bez ohledu na metodiku. Bez silného produkťáka/business ownera jde vybrat auto z katalogu (které pak budu jen řídit a jezdit do servisu). Už stavba bytu/domu na zakázku vyžaduje aktivní zapojení toho, kdo tam pak chce 10-30 let spokojeně bydlet - nestačí poslat výkresy 
Na druhou stranu kdejaká malá komerční firma je na tom s IT projekty stejně - produktu u nich nikdo nerozumí a já jej pak klidně stavím podle sebe a koncové uživatele ani neznám (chtěli by e-shop na zakázku, ale ideálně tak, aby se o něj nemuseli vůbec starat, vylepšovat, hledat chyby…?! 
).
Jinak viz taky https://data.cesko.digital/prirucka/prirucka.pdf výše, kde je to jako základní předpoklad, str. 11, 18 a taky 20-21:
Veřejná správa musí
přijmout odpovědnost za vlastní projekty a riziko jejich selhání;
externí dodavatelé by měli fungovat pouze jako najatá pomocná
síla, kterou lze v případě nespokojenosti snadno nahradit.
Účastníci projektu nepovažují externí dodavatele za
„vlastníky“ projektu nebo jeho výstupů, ale za nahraditelné
pomocníky.
…
Projekt má vyhrazeného vlastníka s dostatečně silným
mandátem. Vlastník je zaměstnancem zadavatele, nikoliv
externistou nebo zaměstnancem nějaké státní IT společnosti.
…
Je produktový vlastník připraven investovat do své role
většinu svého pracovního času?
…
Aneb kdyby to bylo na mně, pak jako první nařídím povinně vytvořit či insourcovat role produkťáků pro každou službu - a hned potom je začnu učit agilní metody (jinak já mám za sebou cca 10 let jako korporátní produkťák, tehdy ještě vše vodopádem, a teď dalších 10 jako externí dodavatel - ale leckde dělám i suplujícího-externího produkťáka, protože sami to neumí)
Všichni účastníci projektu si uvědomují, že stávající přístup
metodou vodopád většinou nevede k úspěchu a přechod
k agilnímu vývoji a modulárním zakázkám toto riziko výrazně
snižuje.
V komerčním světe bude toto všechno určitě platit (nebo by alespoň mělo). Ve veřejné správě to je nereálné. Tam to prostě takto fungovat nemůže.
Mimochodem - přesně na tuto naivní představu dojeli Piráti, kteří se pokusili napasovat zkušenosti z komerční sféry na veřejnou správu. A nic na tom nezměnil ani Bartošův pokus vytvořit DIA jako “znalostní a servisní organizaci”.
Aneb kdyby to bylo na mně, pak jako první nařídím povinně vytvořit či insourcovat role produkťáků pro každou službu - a hned potom je začnu učit agilní metody
Tohle je právě ten ten problém - díváte se na to z pohledu korporátního produkťáka. Jenže takhle veřejná správa nefunguje. Vezměte si jako příklad třeba něco jednoduššího - Ministerstvo dopravy. Spektrum jeho produktů je extrémně široké, od mořského práva, přes silniční síť až po kosmické aktivity. Od agendy řidičských průkazů po standardy pro drony. Produkťáků by tam musela být celá armáda. Navíc některé (i velmi složité agendy) má na starosti oddělení, které má třeba 3-5 lidí. A k těm chcete přidat produkťáka? A jak, když tabulková místa nejsou a vzniknout nemohou, protože se přece “musí bojovat proti rozrůstající hydře byrokratů”.
Kromě toho jako korporátní produkťák máte jednu velkou výhodu - v podstatě vám do Vaší práce nikdo nemluví a zodpovídáte se jen šéfovi. Ve veřejné sféře to je úplně jinak - mluví vám do toho kde kdo (od poslanců, přes lobbisty a ž po různé aktivisty) a při jakýchkoli rozhodnutích jste pod drobnohledem novinářů a s nimi spojených lobbistů, koalice, opozice, poslanců, aktivistů a dalších. A nakonec i úředníků, protože jako produkťák nikdy nebudete agendě rozumět tak, jako úředníci samotní. Takový produkťák by si rovnou mohl na čelo namalovat terč, protože by v podstatě byl lovnou zvěří.
Nesnažte se aplikovat zkušenosti z komerční sféry na veřejnou správu - takové pokusy musí nutně končit epickým výbuchem.
Přesně ta musí vzniknout. Software je dneska jedna z klíčových komponent, bez kterých ty státní organizace nebudou schopny naplňovat svou misi. Outsourcovat takovou roli je pak organizační sebevražda.
Tomu se říká profesionální deformace. Člověk má tendenci zveličovat význam oboru, ve kterém se pohybuje.
Úředníci to vidí jinak - pro ně je IT nutné zlo. A naopak nechápou, jak nemůžete neznat “vyhlášku XY z roku ABCD o pravidlech přepravy hub na námořních lodích”. Nebo něco konkrétního: “zákon 134/2016 Sb. Zákon o zadávání veřejných zakázek” - řada komentářů, která tady zazněla je v hrubém rozporu s tímto zákonem.
Proto je tak kriticky nutná analýza, protože jen ta dokáže překlenout příkop mezi oběma světy. A zabránit nedorozuměním při nasazování aplikace do provozu.
Já si nemyslím, že bych význam IT systémů ve veřejné správě nějak zveličoval. Konstatuju jen očividné – pokud IT systémy nefungují dobře, stát neposílá sociální dávky, nevyřizuje stavební povolení, nevybírá daně, nepřijímá žactvo na školy, zkrátka nefunguje. Na tomhle faktu vztah úředníků k IT nic nemění. A, opakuju se, pokud je zákon o veřejných zakázkách v rozporu s tím, jak lze úspěšně vyvíjet IT systémy, pak se musí změnit zákon. Jinak náš stát nebude schopen dobře fungovat.
Tak pozor! S dávkami problémy nejsou - alespoň si nepamatuji, že bych o tom něco slyšel. Totéž platí o daních - ADIS možná není “HYPE” aplikace, ale už pomalu 30 let spolehlivě funguje přes usilovnou snahu poslanců to co nejvíc zkomplikovat. Totéž se týká stavebního řízení od VITA a dalších.
Katastrofou skončily pokusy nahradit tyto páteřní systémy novým řešením od firem, které netuší o co jde. Ať už jde o sociální dávky, které se pokusil “dodat nově OK systém” v letech 2016/2017 nebo DSŘ.
Ani s tou změnou zákona to není tak jednoduché. Umíte si představit, jak budou řvát protikorupční organizace, pokud se pokusíte dát do zákona model - je jedno co bude dodáno, je jedno kdy to bude dodáno a je jedno kolik to bude stát? O tom totiž agilní metodiky jsou (a nijak tím nezpochybňuji jejich význam).
A znovu opakuji - generační obměna pátečních agendových systémů je nutná. Pokud ale nechcete, aby to skončilo průšvihem a soudy, a pokud to nemá dělat ten, kdo dodává stávající řešení, pak se to metodou velkého třesku dělat nedá. A tyto systémy není ani možné vyvíjet agilně. Pokud si někdo myslí, že to jde, pak vůbec netuší, o čem je řeč.
K problémům s dávkami doporučuju například příspěvky pana Hůleho:
Ale to jen na okraj, jde mně spíš o ten základni princip.
U agilního vývoje zákazník nakupuje kapacitu vývojářského týmu. Není jedno, co bude dodáno, a není jedno, kolik to bude stát. Jen nekupujeme zajíce v pytli za náhodné hausnumero, které se bude následně libovolně navyšovat v okamžiku, kdy se poprvé pokusíme zajíce vytáhnout z pytle.
Ale jasně, jakákoliv změna zákona o veřejných zakázkách nebo obecně praxe nakupování vývojářských kapacit je velmi složitá a křehká věc, na které se toho dá mraky pokazit. Vyhodit peníze lze nezávisle na metodice a neexistuje žádné neprůstřelné řešení se zaručenými výsledky.
Kolik máte zkušeností s vedením projektů v řádu stovek milionů korun? A kolik máte za sebou větších projektů ve veřejné správě?
Já su naprosté zero, ale to je v téhle diskuzi přece irelevantní. Podstatná jsou data. A podle všech studií, co jsem kdy viděl, jsou vodopádově řízené IT projekty obří shit show. A ty problémy jsou furt stejné – zejména představa, že dokážeme nějaký IT systém popsat předem v nějakém pětisetstránkovém RFP, které pak banda kopáčů implementuje, otestuje a nasadí.
Šedivá je teorie a zelený strom života.
Jenže ta příručka i ostatní odkazy okolo popisují metodiku a aktuální stav právě pro veřejnou správu jinde ve světě - čím to, že jinde to jde a zrovna v ČR ne? Čím jsme tak vyjímeční? A sám píšete, že nedostatečné vlastnictví “produktu” je často příčinou neúspěchu projektu…?
Ano. A taky si myslím, že většina těch produkťáků si na sebe dokáže vydělat - každý milión ročně investovaný do šikovného produkťáka může ušetřit desítky, možná i stovky miliónů na předražených IT zakázkách - financí je na to dost.
Produkťák to má řídit a stejně jako projekťák přece nemusí rozumět úplně všemu - od toho má další lidí v týmu
S dávkami problémy nejsou - až na to, že je úřady nestíhají vyplácet (těm, kdo peníze potřebují úplně nejvíc Výplaty sociálních dávek se v Praze stále zpožďují | iROZHLAS - spolehlivé zprávy). ADIS je brutální a zastaralý vendor-lock a samotná FS se jej chce už min. 8 let zbavit - letos sotva začali https://financnisprava.gov.cz/assets/cs/prilohy/f-novinky/2016-GFR-studie-posouzeni-ADIS.pdf
Já mám za sebou několik deseti až stomiliónových projektů, následovaných několikaletou interní prioritizací, přepisováním zadání, hromadou change requestů… Viděl jsem v korporátu odepsat neúspěšný projekt za miliardu Kč - následovalo rozdělení na menší etapy, tj. MVP a následné rozšiřování, které teprve uspělo . A všude jinde to dělají stejně, nebo se o to aspoň snaží:
To reduce risk of failure and enable a greater chance of success for product development efforts to succeed, the government needs to take back some of the control that it has been outsourcing. This is done by appointing a government employee to serve in the role of product owner for a development effort. The product owner will help set the team’s vision and priorities, and accept the contractor’s work.
The goal of a product owner is to build a product people want to use. This is different from traditional government jobs, such as project and program managers, who focus on making sure an initiative runs well, and delivers on-time or on-budget.
A common problem government custom software development projects face is that leadership has not set up the product owner to succeed.
https://ddat-capability-framework.service.gov.uk/role/product-manager
https://www.reddit.com/r/ProductManagement/comments/10zyoze/are_there_jobs_like_product_manager_in_the/
…
Jenže ta příručka i ostatní odkazy okolo popisují metodiku a aktuální stav právě pro veřejnou správu jinde ve světě - čím to, že jinde to jde a zrovna v ČR ne? Čím jsme tak výjimeční?
Dejte mi příklad jednoho jediného páteřního systému veřejné správy kdekoli na světě, který byl/je vyvíjen agilně.
Já mám za sebou několik deseti až stomiliónových projektů, následovaných několikaletou interní prioritizací, přepisováním zadání, hromadou change requestů…
To je ten zádrhel. Pro vývoj interních systémů - i velmi velkých, jako jsou bankovní core systémy - je agilní vývoj dobrou volbou. S termíny se dá hýbat podle potřeby, priority se stanovují a mění podle okamžité potřeby firmy. Agilní metodiky jsou pro toto použití skvělá volba.
Začíná to drhnout v případě dodavatelských projektů (a tím nemyslím bodyshopping - to je druh interního vývoje, kde všechna rizika nese objednatel). Tady se objevuje spousta faktorů, které se mohou pokazit. A funguje to pouze v případě, kdy jde všechno podle plánu. Jakmile se objeví problémy, začne se to celé komplikovat, protože ani jedna strana (logicky nechce být ta špatná). Už jsem zažil pár podobných projektů, kde se ukázalo, že produkt manager přestal být ve shodě s managementem společnosti a všechno šlo do kopru - pro mě dobrý, vede to na krizové řízení a to mám rád.
A teď se dostáváme k veřejné správě, která je ještě úplně jiný level. Jak rozsahem, tak podmínkami.
Já celkem rozumím Vašemu postoji, ale ten je dán tím, že si ani vzdáleně neumíte představit rozsah, požadavky a specifika takových projektů - a znovu opakuji, mluvíme o páteřních IS veřejné správy. Právě naivita založená na neznalosti problému byla důvodem, proč I. Bartoš pohořel s DSŘ.
Především páteřní IS veřejné správy slouží jako podpora procesů definovaných zákonem (+ vyhláškami). Ze zákona plyne, jaké funkce a služby musí daný systém poskytovat. A také kdy. Nesmí být dostupné ani o den dříve a ani o den později. A jestliže tyto služby splňuje, pak není důvod pro vývoj dalších částí - to už je jen plýtvání penězi. Tak o jaké road mapě se můžeme bavit? Je začátek projektu a jsou termíny dané zákonem a seznamem požadavků, které v té době musí být dostupné.
U páteřních IS veřejné správy jsou navíc extrémní požadavky na dostupnost, spolehlivost, bezpečnost, nakládání s osobními údaji a ještě spousta dalších požadavků, daných zákony a vyhláškami, o kterých nejspíš ani nevíte, že existují (a je velmi dobrý důvod mít takové požadavky).
Nemyslím si, že máte představu o objemu zpracovávaných dat. Když jste se zmiňoval o ADIS - počty daňových subjektů jsou v desítkách milionů, počty písemností v řádu miliard a tým, který se o ADIS stará má řádově stovky členů (reálně by stačily i třetina, pokud by poslanci neměnili na pomalu na každé schůzi daňové zákony).
A v neposlední řadě, ve veřejné správa, stejně jako ve velkých korporátech, si všichni dávají velký pozor, aby v případě problémů nezbyl Černý Petr v jejich rukách (existuje proto květnaté: “mít oplechovanou p*del”). Jenže ve veřejné správě, na rozdíl od korporátů, si zásluhy přisvojí ti nahoře a problémy nechají spadnout na někoho dole.
Kromě toho se o velkých projektech rozhoduje na velmi vysoké úrovni - obvykle náměstků. Ale ani ti nechtějí riskovat neúspěch a tak se všechno posvěcuje na úrovni vedení úřadu, protože to je kolektivní orgán a tam nezodpovídá nikdo na nic. Náměstci přichází a odchází podle toho, jak se mění v čase politické a mocenské rozložení sil. Takže to, co bylo prioritou včera nemusí být prioritou dnes. Zažil jsem pár nadšenců, kteří přišli na centrální úřad s naivní představou, že to začnou dělat jinak. Jejich životnost byla v řádu měsíců. Reálně se stali ideálním obětním beránkem, na kterého se snesly průšvihy za posledních několik let a daný člověk byl velmi rychle odejit pro neschopnost.
Pro úspěšnou realizaci jakéhokoli projektu ve veřejné správě prostě musíte respektovat její specifika. Včetně toho, že organizační struktura úřadu je spíš taková základní orientační pomůcka a rozhodovací procesy mohou probíhat fakticky mimo ni. A včetně toho, že vám nikdy nikdo neřekne, a už vůbec nedá písemně, všechny informace o tom, jak vlastně procesy fungují. Jediným způsobem jak tyto velké procesy dotáhnout, za stranu dodavatele, úspěšně do konce je mít přesně definováno kdy a co bude dodáno. Určitě to někdo vytáhne a bude kontrolovat, jestli se to opravdu stalo.
Omlouvám se, že se opakuju, ale tohle je bezvadné shrnutí toho, co se musí změnit Jinak se příčetných (nejen) digitálních služeb státu nedočkáme.
Ale jinak – ptal jsem se na příklady agilně vyvinutých klíčových služeb a Waldo Jaquith mně jako příklad nabízí třeba Login.gov (centrální digitální identitu) nebo Direct File (systém pro vyplňování daňových přiznání?).
My si asi nerozumíme. Já jsem mluvil o páteřních core systémech veřejné správy.
Pokud tomu správně rozumím, tak login.gov je ekvivalent naší NIA, což je infrastrukturní služba, ne core IS. Ta se klidně agilně vyvíjet dá, pokud je road mapa známa dostatečně dopředu a nemění se - je to kvůli tomu, aby se navazující systémy třetích stran mohly přizpůsobit změnám. A pokud mám nastavený dostatečně robustní systém pro testování, protože výpadek infrastrukturní služby má dalekosáhlé dopady.
A pokud jde o Direct File - stejnou funkci a mnohem víc toho dělá “Portál moje daně”. Což je taková malá nadstavba nad ADIS. Malá ale celkem zajímavá, např. proto, že z bezpečnostních důvodů nemůže mít aplikace Portál moje daně přímý přístup do databází, ale přitom musí být možnost s daty z databází pracovat, protože jinak by nebylo možné např. předvyplnit formuláře nebo zobrazit informace o nedoplatcích. Ale jinak to je služba pro veřejnost a jako taková klidně může být vyvíjena agilně - ostatně v jednom z předchozích příspěvků jsem psal, že zrovna služby pro veřejnost mohou být klidně vyvíjeny i agilně. Když se něco nepovede a služba nebo její část přestane fungovat, tak to sice bude hloupé a novináři to rozmáznou, ale není to tragédie.
Mimochodem tím příkladem s daňovým přiznáním jste mě přivedl ještě na jedno specifikum core systémů - musí být zpětně kompatibilní, protože v mnoha případech se musí pracovat s daty, které jsou i desítky let staré. A je potřeba zajistit, aby při nasazení změny nedošlo k poškození dat - případně mít mechanismus, jak to opravit.
Ptám se znovu - můžete mi uvést příklad CORE systému veřejné správy (například ekvivalent ADIS, IS celní správy, správní soudnictví, důchody nebo třeba to stavební řízení), který byl vyvíjen agilně. Protože to je úplně jiný příběh.
Abych předešel nedorozumění - to, co píšu není v žádném případě míněno jako útok na Vaši osobu. Jen se snažím vysvětlit, že ty úlohy jsou mnohem, mnohem komplikovanější, než si představujete.
Vůbec to jako útok neberu, povídáme si o něčem, co nás oba zajímá, je to v pohodě. A oceňuju shodu nad tím, že řada věcí se ve veřejné správě agilně vyvíjet dá.
Můžem si ty „core“ systémy definovat jinak než příkladem? V čem jsou specifické, jiné? Díky!
Co to stavební řízení v Polsku? Nedaří se mi dohledat větší detaily a jak moc to jede či nejede agilně - to by chtělo nějakého insidera Každopádně zvládají rozdělení na menší etapy, postupné testování s uživateli, 5 měsíců pilotní provoz pro 13 úřadů… (a hádám, že po něm nenásleduje výběrko a vodopád na úpravy, které se v pilotu objevily?) Cyfryzacja | Główny Urząd Nadzoru Budowlanego . I kdyby to nebylo agilní, asi vždycky to jde rozdělit na menší části a snížit tak riziko selhání každé z nich.
Podobně mají na etapy rozdělené spouštění “moje daně” - ale není z toho poznat, jak moc je to jen frontend, (“E-Tax Office využívá moderní IT řešení a slučuje data z různých systémů KAS = finanční správy.” - tj. nejspíš i něco v core, “Zákazník je na prvním místě…”) Startuje e-Urząd Skarbowy - Aktualności - Urząd Skarbowy Poznań-Jeżyce
To je zajímavá otázka. Pokusím se to vymezit, ale zatím jsem to nikdy nepotřeboval a proto se mi to možná nepovede na první dobrou.
Za “core” systém veřejné správy bych označil IS, který splňuje tyto požadavky:
Netvrdím, že ten seznam nemá chyby, je to první nástřel.
Je důležité říct že existuje Nařízení vlády č. 432/2010 Sb. o kritériích pro určení prvku kritické infrastruktury, resp. její příloha, která definuje prvky (v tomto případě aplikace) kritické pro chod státu. Jedna z kapitol je věnována veřejné správě. Nicméně ne všechny prvky uvedené v nařízení vlády spadají do mé definice - zejména kvůli bodu 3.
Faktem ale je, že na aplikace aplikace kritické infrastruktury jsou ze zákona kladeny velmi vysoké požadavky na bezpečnost a spolehlivost a to dost omezuje praktické využití agilních metodik - ze zkušenosti je průměrná doba testování významné úpravy takové aplikace 1-2 měsíce. A pokud jde o zásadní změnu, pak může testování trvat půl roku i déle. To značně komplikuje použití agilních metodik, protože po každém sprintu by se muselo dělat velmi důkladné testování většinou delší než je délka sprintu.
Čímž netvrdím, že při vývoji/změně takového systému nebo v rámci jednotlivých etap tohoto vývoje vývoje nemůže být použita agilní metodika. Klidně může a dělá se to, ale ve finále je dodávka, jako celek, řízena vodopádem, protože rozsah a termíny jsou dány zákonem.
Stejně tak je možné dělat agilně různé nadstavby, které nezasahují do jádra systému a hlavně jeho datových struktur - a dělá se to. Příkladem takové nadstavby je Portál moje daně nad ADIS.
Je to srozumitelné?
Použití etap u takových projektů je normální. Dokonce všechny vodopádové metodiky, se kterými jsem pracoval, mají jako poslední krok etapy něco jako “vyhodnocení zkušeností”. A v rámci toho posledního kroku může dojít k úpravě požadavků na další etapu. Není pravda, že u vodopádu se všechno stanoví na počátku a pak přes to nejede vlak. Na počátku vznikne plán celého projektu, který se v případě potřeby může upravit. Výhodou je, že se dají celkem snadno zmapovat dopady takových změn na průběh projektu jako celku.
Nicméně ani použití etap neřeší problém, jak nahradit stávající systém novým. Problém je v tom, že náhrada jednoho systému jiným je obrovský projekt, u kterého se může zvrtnout opravdu hodně věcí. Dokonce jsem přesvědčen, že šance na úspěch je u takových systémů mizivá. Problém je v nutnosti zachovat zpětnou kompatibilitu minimálně na úrovni datové základny (těch problémů je tam víc, ale tento je největší).
Je potřeba si uvědomit, že všechny systémy, o kterých se tu bavíme, vznikaly, prakticky na zelené louce a problém se zpětnou kompatibilitou řešit nemusely. A kromě toho v době svého vzniku byla digitalizace v plenkách a tak šlo o relativně jednoduchá řešení. Až vývojem z toho vznikly obří, vzájemně prointegrované obludy. Proto přechod na nové řešení metodou “velkého třesku” je extrémně obtížné, až nereálné.
Navrhuji jiný přístup. I když jde o velké a navenek homogenní aplikace, uvnitř jdou rozděleny na jednotlivé moduly. Jsem přesvědčen, že mnohem bezpečnější cestou je náhrada původních IS novými po modulech. A aby se ten systém nezhroutil, tak prvním krokem je vytvoření ESB, které oddělí původní aplikaci a tu novou. Díky tomu je možné budovat nový systém po jednotlivých, vzájemně izolovaných krocích a mít prostor pro důkladné testování. Jistě, bude to znamenat, že po nějakou dobu poběží systémy dva, nicméně jeden bude nabíhat a druhý se bude utlumovat, takže rozdíl zase tak velký nebude.
Jsou různé názory, jak by se mělo v takovém případě postupovat, jestli nejprve zmigrovat datovou základnu (a speciálně písemnosti) a pak pokračovat tím ostatním. Nebo jestli postupovat po jednotlivých agendách. Nebo jestli začít od zhora od uživatelského rozhraní. To už je pak věcí diskuse nad variantami postupu. Nicméně základní princip je budování nového systému po krocích, které postupně nahrazují jednotlivé moduly původního řešení a hlavně jsou vratné. Pokud se něco u nového modulu zvrtne, pak se na ESB prostě zruší přesměrování na nový modul a jede se po staru, dokud není problém odstraněn.
A z vašeho pohledu je zajímavé to, že jednotlivé nové moduly se už dají vyvíjet agilně.
Rychlá odbočka – GitHub má starší ultra zajímavý blog post o přístupu, který použili právě pro nahrazení starších částí systému novými. Stručně řečeno když nahrazují třeba API endpoint, nasadí ten nový, ale nechají v provozu ten starý a porovnávají, jestli ten nový dělá v reálném provozu totéž. Takhle vychytají věci, které jim utekly, a časem můžou přehodit na tu novou implementaci. Nikdy jsem to nepoužil, ale vždycky mně to přišlo chytré
Myslím, že to je příklad takzvaného strangler patternu modernizace systémů.
