Některé produkty se přestanou rozvíjet ne proto, že by o ně nebyl zájem, ale proto, že jim přestal někdo rozumět. Přesně s tímto problémem se na nás klienti někdy obracejí. A právě v takových situacích se ukáže, co AI v rukou zkušeného týmu skutečně dokáže.
Bugy se opravují, něco nového se nasadí, tým funguje. Přesto se v určitém bodě ukáže, že každá větší změna je příliš drahá, příliš pomalá a příliš nejistá. Odhady přestávají fungovat, scope se rozplývá. A veškerá znalost systému se nenápadně uzamkne v hlavách několika lidí, v horším případě dodavatele. Vendor lock-in, i když ho možná nikdo takto nahlas nepojmenuje.
Ambiciózní produkt s vysokou komplexitou
Náš klient je evropská fintech společnost, která staví komplexní platební infrastrukturu. Jejich platforma propojuje card processing s open bankingem, direct debitem a byznysovými workflows jako fakturace, collections nebo settlement orchestrace. Pracují s partnery jako Mastercard, Worldpay nebo Worldline.
Jejich produkt má reálnou hodnotou pro trh a jasný směr. Přesto se dostali do situace, která je ve světě softwaru běžná: platforma narostla, dokumentace za ní nestíhala a další rozvoj začal být nepředvídatelný.
V rámci jejich softwaru nad finanční infrastrukturou se otevírala nová produktová linie: Payment Collection Platform pro payment processory, s minimálním merchant rozhraním, bez payer portálu, se třemi základními akcemi: založit účet, založit zákazníka a vytvořit platbu. Tedy produktový rámec určený ke škálování v jiném obchodním modelu.
Klíčový problém byl jasný: aby bylo možné tohle všechno plánovaně rozvíjet, bylo nejdřív potřeba vědět, co přesně existující systém dělá.
Proč chybějící dokumentace bolí víc, než se zdá
Když chybí aktuální zadávací dokumentace, obchodní záměr, reálné chování systému a technická implementace se postupně rozjedou.
Každá větší změna je risk. Místo rozvoje přichází paralýza. A v krajním případě se znalost celého systému nenápadně přesune k dodavateli. Ne záměrně, ale přirozeně. Produkt přestane být váš.
V Argo22 na dokumentaci vždy dbáme a vendor lock-in považujeme za jednu z věcí, které se v práci s klientem nesmí stát. Právě proto umíme poznat, kdy je potřeba tuhle situaci aktivně řešit, a máme na to nástroje.
Od problému k řešení: AI analýza
Aby bylo možné produkt znovu plánovaně rozvíjet, muselo nejdřív dojít k rekonstrukci dokumentace z existujících zdrojů a ze softwaru samotného. Tedy sestavit přesný obraz toho, co systém dělá, jak se chová a na čem závisí.
Tohle je práce, která dřív bolela hlavně svou šířkou. Projít repozitáře, interní materiály, historická rozhodnutí a z toho vystavět strukturovanou specifikaci zabralo analytikovi týdny až měsíce.
Právě proto jsme sáhli po AI. Ne jako po zkratce, ale jako po nástroji, který zpracuje objem, který byl dřív prostě příliš velký.
Jak AI analýza v praxi vypadá
Nejde o to nechat si od modelu vygenerovat kus textu nebo kus kódu. Jde o to zapojit AI jako řízený pracovní nástroj do analýzy, rozhodování a postupné rekonstrukce systému tak, aby po sobě zanechala něco ověřitelného a použitelného pro celý tým.
V praxi to znamená orchestraci více specializovaných analytických průchodů nad repozitáři, existující dokumentací a dalšími zdroji pravdy. Neptáme se modelu, co si myslí o systému. Vedeme ho k tomu, aby postupně skládal architekturu, pravidla, entity, use casy, interní funkcionality, externí služby a zprávy mezi systémy do jedné provázané specifikace.
AI tady není náhrada za analytika. Je to násobič jeho práce. Zkušený člověk určuje směr, hloubku a kontrolní body. AI zpracovává objem, hledá vztahy, vrací hypotézy, porovnává je s dalšími artefakty a pomáhá proměňovat nejasnosti v ověřené závěry.
Velkou část práce, která dřív bolela hlavně svou šířkou a únavností, dnes umíme výrazně zrychlit, aniž bychom rezignovali na přesnost.
Výsledek: produkt je opět pod kontrolou
Pro klienta to mělo okamžitý dopad ve dvou rovinách.
První byla praktická: existující produkt se dal znovu uchopit jako něco, co je možné plánovaně rozvíjet.
Druhá byla strategická: z původně širšího produktu jsme byli schopni vytáhnout užší collection core a začít nad ním definovat další generaci řešení určenou pro payment processory.
A právě to je moment, kdy dokumentace přestává být archivem a stává se výrobním nástrojem.
Výsledek přitom nekončí u textu pro management. Když je specifikace postavená správně, dá se napojit na způsob, jak tým skutečně pracuje. Discovery oddělené od Delivery. Nejdřív se scope formuluje, zpřesňuje a schvaluje, teprve potom se transformuje do implementace, s dohledatelnou vazbou mezi záměrem a realizací.
Je to způsob, jak dostat digitální produkt opět pod kontrolu i ve chvíli, kdy na něm pracuje více lidí, více týmů nebo více dodavatelů.
AI jako reálná výhoda, ne marketingová nálepka
To nejcennější, co si z podobných projektů odnášíme, není „AI umí psát dokumentaci“. To je příliš slabé tvrzení.
Důležitější je tohle: když je AI zapojená správně, umí výrazně zkrátit cestu od nejasného, historicky narostlého systému k nové sdílené pravdě o tom, co produkt je, co dělá, co má zůstat a co už naopak nemá dál přežít.
V praxi to znamená rychlejší onboarding nových lidí, menší závislost na paměti jednotlivců, srozumitelnější plánování a výrazně lepší připravenost na změnu. Ať už jde o interní rozvoj, zapojení nové agentury, nebo přípravu produktu, který má oslovit větší partnery a jiné trhy.
Na tomto projektu jsme si znovu ověřili, že správně vedená AI analýza neumí jen „něco vygenerovat“. Umí vrátit software jeho majiteli.
Pokud řešíte podobnou situaci, rádi si o ní popovídáme. Ozvěte se nám.
