Průzkum
6 min16. dubna 2026

Váš AI přestal učit před půl rokem

Ticket byl napsán minulý měsíc. Funkce vychází příští měsíc. Mezitím konkurent vydal něco podobného, API se změnilo a nový compliance požadavek tiše vstoupil v platnost.

Zastaralý ticket pod lupou s cenovými a verzovými změnami, které zůstaly mimo původní rozsah
Slepé místo je vše, co se změnilo poté, co byl ticket napsán.

Mezera mezi napsáním a dodáním

Ticket byl napsán minulý měsíc. Funkce vychází příští měsíc. Mezitím konkurent vydal něco podobného, API se změnilo a nový povinný požadavek tiše vstoupil v platnost. Nic z toho se do ticketu nedostalo.

To není hypotéza. To je úterní standup uprostřed sprintu. Někdo z týmu zmíní API, které se chová jinak, než ticket popisuje. Druhý člověk otevře changelog konkurenta a zjistí, že před třemi týdny vydali skoro totéž. Ticket byl v pořádku, když vznikal. Svět se prostě pohnul dříve, než sprint začal.

Cena není jen v přepracování. Je v erozi důvěry. Ve sprintovém cíli, který se tiše stane fikcí. V PM, který stakeholderům vysvětluje, proč tým dodal něco, co bylo zastaralé hned první den.

Každý tým má svou verzi tohoto příběhu. Většina ho vyprávěla víckrát, než cokoliv změnila.

AI má hranici znalostí

Většina týmů nyní používá AI při psaní, plánování a zpřesňování Jira ticketů. A funguje to. AI modely jsou skutečně dobré ve strukturování požadavků, generování akceptačních kritérií a navrhování implementačních přístupů. Kdo chce pochopit širší rámec, proč jsou vágní tickety zvlášť nebezpečné, jakmile je předáme přímo AI, najde detailní rozbor v tomto článku: Proč většina AI nástrojů pro Jira problém sladění zhoršuje, ne řeší.

Co většina týmů nezohledňuje: tréninková data každého AI modelu mají cutoff — typicky šest až dvanáct měsíců před aktuálním datem. Model neví, co se stalo po skončení jeho tréninku. Nespekuluje, neodhaduje. Jednoduše to nemůže vidět.

To znamená, že model neví, že Next.js 16.1 v prosinci 2025 odstranil podporu Node 18 a rozbil buildy týmů, které počítaly s kompatibilitou. Neví, že OpenAI v únoru 2026 trvale odstranil endpoint chatgpt-4o-latest, čímž zlikvidoval každou integraci, která na ten string stále odkazovala. Neví, že tři americké státy přijaly 1. ledna 2026 komplexní zákony o ochraně soukromí, které přes noc rozšířily požadavky na opt-out.

Znalosti vašeho AI asistenta se někde zastavily před přibližně šesti měsíci. Zákony a platformy nečekají.

To není problém kvality modelu — je to strukturální problém. Model dělá svou práci v mezích toho, na čem byl trénován. V mezeře mezi touto hranicí a dneškem se hromadí breaking changes, konkurenti vydávají novinky a compliance požadavky se posouvají. Pokud váš plánovací proces tuto mezeru nezohledňuje, každý AI-asistovaný ticket nese skryté datum expirace.

Dokumentace v době odhadování ticketu srovnaná s tutéž dokumentací dnes — s deprecacemi, verzovými skoky a cenovými změnami
Dokumentace v době odhadování ticketu srovnaná s tutéž dokumentací dnes — s deprecacemi, verzovými skoky a cenovými změnami

Tři případy, kdy to skutečně bolí

To nejsou abstraktní rizika. Jsou to přesně ty věci, které se v retrospektivách sprintu objevují pod názvem „to jsme nemohli předvídat" — přestože to předvídat šlo, s pěti minutami průzkumu.

  1. Breaking changes v závislostech. Ticket předpokládá, že knihovna nebo API funguje tak, jak fungovaly při poslední integraci. Tým napíše implementační plán. Uprostřed sprintu začnou selhávat buildy nebo API volání vracejí chyby, které nikdo nečekal. Přesně to se stalo, když OpenAI 17. února 2026 odstranil snapshot chatgpt-4o-latest. Každý tým s ticketem odhadnutým koncem roku 2025, který odkazoval na tento string, narazil na zeď — endpoint jednoduše přestal odpovídat.
  2. Konkurenti to už vydali. Nutně to není důvod ticket zrušit, ale vždy je to důvod se podívat a poučit se, než začnete stavět. Když konkurent vydal totéž, už prošel edge cases, získal zpětnou vazbu od uživatelů a někdy narazil na problémy, do kterých vy narážet nemusíte. Pět minut průzkumu konkurence může ušetřit dva týdny discovery — nebo zabránit demoralizaci z dodání něčeho, co trh už překonal.
  3. Regulatorní a compliance změny. Nejcitlivější případ, protože důsledky nejsou jen ztracené sprinty — jsou to právní rizika. Ticket napsaný v listopadu 2025 pro americké uživatele nebude zohledňovat změny zákonů o soukromí z 1. ledna 2026, pokud to někdo před sprintem nezkontroluje. Regulátoři Jira tickety nezakládají. Váš sprint cyklus jim nic neříká.
Malá pětiminutová kontrola na jedné misce vah oproti těžkému balíku zablokovaných, přepracovaných a znovu odhadovaných sprint karet na druhé
Malá pětiminutová kontrola na jedné misce vah oproti těžkému balíku zablokovaných, přepracovaných a znovu odhadovaných sprint karet na druhé

Kdy kontrolu provést

Načasování je důležitější než samotná kontrola.

  • Ne při vytváření ticketu. To je příliš brzy. Ticket může v backlogu ležet týdny nebo měsíce. Cokoliv zkontrolujete teď, bude zastaralé, až ho někdo vezme do práce.
  • Ne uprostřed sprintu. To je příliš pozdě. Tým už svázal kapacitu. Odhalit breaking change nebo compliance posun teď znamená přepracování, zablokované stories a sprintový cíl, který už není dosažitelný.
  • Když se ticket detailuje a plánuje do dalšího sprintu. Právě tehdy tým do ticketu investuje reálný čas — zpřesňuje rozsah, píše podúkoly, potvrzuje přístup. Přidat v tomto momentě pětiminutovou tržní kontrolu je levné a přináší vysoký výnos. Kdo pak hledá šablonu, jak má vypadat ticket připravený k vývoji po tomto kroku, najde přirozené pokračování zde: Přeměna vágních Jira ticketů na jasné implementační plány.

Co zkontrolovat před tím, než ticket definitivně zařadíte do sprintu:

  • Změnilo se něco v relevantní závislosti nebo platformě od napsání ticketu?
  • Vydal to již konkurent, a co se z toho naučil?
  • Existují nové regulatorní nebo compliance signály relevantní pro tuto oblast funkcionality?
  • Jsou k dispozici nové nástroje, vzory nebo přístupy, které při odhadu ticketu neexistovaly?

Tyto čtyři otázky zaberou minuty. Jejich přeskočení stojí sprinty.

Workflow pruh, kde je ticket zvýrazněn právě ve fázi detailování sprintu — mezi backlogem a prací v průběhu
Workflow pruh, kde je ticket zvýrazněn právě ve fázi detailování sprintu — mezi backlogem a prací v průběhu

Jak Just tento krok automatizuje

Nejtěžší část není vědět, že byste měli kontrolovat. Nejtěžší je udělat z kontroly součást procesu místo něčeho, co závisí na paměti jednoho člověka.

Just zahrnuje krok webového vyhledávání přímo do plánovacího a insights workflow — ne jako plošný výchozí stav pro každý ticket, ale jako možnost, kterou tým zapne pro tickety, kde záleží na externím kontextu. Když je aktivován, Just načte aktuální informace relevantní pro issue ještě před generováním plánu — nedávné změny závislostí, vzory konkurentů, regulatorní signály a posuny v ekosystému se promítnou přímo do strukturovaného výstupu.

Výsledkem je plán, který odráží to, co platí dnes — ne to, co platilo v době tréninku modelu. To je nejpřímější integrace aktuálního tržního průzkumu do plánování v Jira, která je v Atlassian ekosystému aktuálně k dispozici.

Kontrola se stane krokem, ne zvykem. Kroky přežijí změny v týmu. Zvyky ne. Kdo chce produkt přímo vidět, najde ho na stránce Just v Marketplace.

Pětikrokový plánovací tok, kde je tržní a ekosystémová kontrola zvýrazněna před plánováním realizace a revizí
Pětikrokový plánovací tok, kde je tržní a ekosystémová kontrola zvýrazněna před plánováním realizace a revizí

Pět minut teď — nebo celý sprint pak

Trh se nepozastavuje, zatímco backlog stárne. Závislosti přinášejí breaking changes. Konkurenti vydávají funkci, kterou právě stavíte. Zákony vstupují v platnost k datům, která se vašim sprint cyklům vůbec nepřizpůsobují.

Mezera mezi napsáním ticketu a jeho dodáním je místo, kde předpoklady zastarávají. Rychlá tržní kontrola před detailováním sprintu není nadbytečný proces. Je to minimální míra péče pro každý ticket, který se dotýká čehokoliv, co se hýbe.

Anton Velychko, Zakladatel Just

Anton Velychko

Zakladatel Just