Revize rozsahu realizace¶

Stav k 2026-06-21.

Tato stránka zachycuje druhý pohled nad existující dokumentací k migraci na Sylius. Nejde o nový scope od nuly, ale o revizi realismu původních odhadů a implicitních předpokladů.

Revizi vypracoval OpenAI model GPT-5.4. Původní migrační rozsah vypracoval Claude Sonnet 4.6.

Shrnutí¶

Původní analýza platformy je správná ve směru a správně identifikuje hlavní rizika. Novější migrační rozsah je podstatně blíž realitě, protože už vychází z celé dokumentace a ne jen z platformního pohledu.

Přesto je i tento novější odhad místy lehce optimistický. Největší optimismus není v Syliusu samotném, ale v tom, jak levně jsou naceněny integrační vrstvy, admin ergonomie, SEO/URL kompatibilita a testovací/cutover fáze.

Přijímám tento komentář. Migrační rozsah vznikl po dvou kolech korigování — nejdřív jsem byl příliš alarmistický, pak uživatel oprávněně namítl přestřelení a já korigoval dolů. Výsledek je pravděpodobně lehce optimistický právě v místech, kde opravné kolo snížilo odhad nejvíce. — Claude Sonnet 4.6

Co je na stávajících odhadech správně¶

1. Sylius je vhodná cílová platforma¶

Závěr, že Sylius je pro tento typ projektu vhodná volba, dává smysl. Ne kvůli tomu, že by řešil specifika tohoto e-shopu sám od sebe, ale protože:

katalog, checkout, objednávky, zákazníci a základní pricing model existují
projekt stojí na Symfony/PHP stacku
rozšíření přes custom entity, forms, gridy a eventy je pro tento typ migrace přirozené

2. Hlavní složitost neleží v katalogu ani checkoutu¶

To je v dokumentaci pojmenované správně. Kritická je kombinace:

Pohoda import full + diff
cenový waterfall přes více zdrojů
skladové a maržové výjimky
export objednávek zpět do Pohody
14 dodavatelských importů s historickými výjimkami

Jinými slovy: problém není "nasadit Sylius", ale "udržet provozní chování e-shopu po přepnutí".

3. Rozhodnutí před zahájením jsou skutečně zásadní¶

Za správné považuji zejména to, že bez předchozího rozhodnutí nelze závazně nacenit:

zda Sylius admin bude zdrojem editace produktů
jak se vyřeší CMS obsah
zda se zachová URL strategie
co bude s rc-baterie.cz
zda historické objednávky půjdou do Syliusu, nebo do archivu
zda importy půjdou přes Sylius vrstvu, nebo mimo ni

To nejsou detaily. Každé z těchto rozhodnutí mění architekturu i hodinový rozsah.

Kde je dokumentace stále optimistická¶

1. "Co Sylius pokryje bez práce" je formulováno moc lehce¶

Formálně je pravda, že Sylius má zákazníky, checkout, promotions, warehouses, tax zones nebo role. Prakticky to ale neznamená nulovou práci.

U tohoto projektu je přesnější říct:

Sylius tyto koncepty má
není nutné je stavět od nuly
ale implementace, mapování dat, konfigurace a testování budou stále významná práce

To platí zejména pro:

zákazníky a split ShopUser / AdminUser
RBAC a mapování stávajících oprávnění
multi-locale a multi-channel konfiguraci
daňové zóny CZ/SK a B2B bez DPH
shipping/payment model napojený na Pohodu export
skladový model s více sklady a vlastním zobrazením dostupnosti

Framing "bez práce" byl záměrný — chtěl jsem odlišit "custom PHP vývoj" od "konfigurace". GPT-5.4 má ale pravdu, že konfigurace + mapování + testování jsou stále hodiny. Přesnější čtení: "bez práce" = "bez custom PHP vývoje od nuly", nikoliv "nula hodin projektové práce". — Claude Sonnet 4.6

2. Admin customizace je podhodnocená¶

V dokumentaci je dobře popsáno, že produktový admin je rozsáhlý. Přesto odhad pro admin působí nízko.

Důvody:

produktový formulář má mnoho vlastních polí, stavů a jazykových variant
obsluha e-shopu je zvyklá na provozně orientovaný admin, ne na datový model Syliusu
objednávkový grid a návazné workflow budou chtít ergonomické úpravy
editace kategorií, značek, akcí a obsahu nebude "jen konfigurace"

Samotné technické rozšíření formulářů je jedna věc. Druhá věc je použitelnost pro reálný provoz po spuštění.

Tento bod prošel revizí v průběhu psaní. Původní "týdny práce" jsem na základě zpětné vazby snížil na 30–60h pro formulář produktu. GPT-5.4 naznačuje, že tato korekce mohla být příliš agresivní — ergonomie provozu (ne jen technická implementace formuláře) přidá hodiny navíc, a to skutečně není v mém odhadu explicitně. — Claude Sonnet 4.6

3. Frontend, URL a SEO kompatibilita jsou stále spíš spodní odhad¶

Projekt má:

cca 150 000 produktů
cca 1 600 kategorií
6 jazykových mutací
ploché produktové URL
dvojí kategorizační URL model
SEO texty a překlady na kategoriích

Pokud se má zachovat vysoká kompatibilita současného URL chování, nejde o malou routovací úpravu. Je to kombinace:

návrhu slug strategie
migrace starých aliasů
přesměrování
validace SEO dopadů
testování nad více locales a channels

Jakmile je cílem "zachovat chování bez SEO propadu", hodinový rozsah roste.

4. Testování, shadow run a cutover jsou naceněny měkce¶

U integračně těžkého projektu nestačí funkční vývoj. Potřebujete i provozní jistotu:

porovnávací běhy importů
kontrolu cenových rozdílů mezi starým a novým systémem
ověření Pohoda import/export roundtripu
kontrolu feedů pro srovnávače
UAT s obsluhou
plán přepnutí a rollback scénář

Tohle není kosmetická fáze na konci. Je to samostatná významná část realizace.

Souhlasím — 50–100h pro testování bylo spíše symbolické číslo. Projekt s Pohoda roundtripem, 14 importy a cenovým waterfallem si zaslouží shadow run jako samostatnou fázi s vlastním odhadem, ne jako poslední řádek tabulky. — Claude Sonnet 4.6

5. XML feedy, voucher workflow a rc-baterie jsou "malé velké věci"¶

Každá z těchto oblastí je samostatně řešitelná. Ale každá:

má vlastní provozní logiku
má vazbu na stará data nebo současný frontend
vyžaduje testování a domluvu s provozem

To znamená, že ve výsledku přidávají víc hodin, než jak vypadají v souhrnném seznamu.

Oblasti s největším rizikem podstřelení¶

1. Pohoda jako obousměrná integrační páteř¶

Pohoda není jen import zboží. Je to celý provozní uzel:

full import
diff import
cenové úpravy před zápisem
sklady a jejich pořadí
RP/PHE vazby
akce a export CENOVE-AKCE
export objednávek

Tohle je potřeba chápat jako jeden celek. Pokud se rozpadne na izolované ticketové bloky, odhad bude pod realitou.

Toto je nejlepší formulace celé revize. Pokud se Pohoda rozpadne na izolované tickety, koordinace mezi nimi se ztratí a odhady budou systematicky nižší než realita. Pohoda je jeden celek se sdíleným stavem — sklady, ceny, objednávky a feedy jsou závislé, ne nezávislé. — Claude Sonnet 4.6

2. Cenová logika není jen pricing, ale business engine¶

V dokumentaci je dobře vidět, že finální cena je výsledkem několika vrstev a výjimek. To není detail kolem importu. To je obchodní jádro.

Rizikové body:

přepis cen mezi Pohodou a dodavateli
výrobci bez slev
nízká marže
InStock výjimky
rozdíl mezi skladovou cenou a dodavatelskou cenou
vazba na akce, feedy a zobrazení

Pokud nebude tato logika explicitně a testovatelně formalizována, vznikne dlouhý ladicí ocas po nasazení.

Plný souhlas a chtěl bych zdůraznit jeden konkrétní bod: cenová pipeline není jen složitá — je nezdokumentovaná jako celek. Pravidla jsou rozházená přes 4 PHP soubory v cron/pohoda-import/ a nikde neexistuje autoritativní popis všech pravidel najednou. Formalizace (i jen jako dokument) před psaním kódu je nutná podmínka — bez ní bude ladění systematicky delší. — Claude Sonnet 4.6

3. Rozsah custom práce v checkoutu je sice omezený, ale citlivý¶

Checkout specialit není extrémně mnoho, ale jsou provozně citlivé:

RP/PHE
dotaz na dostupnost
watchdog
odhad data doručení
cena na dotaz
pickup point data pro Pohodu export

Nejsou to stovky features, ale každá z nich zasahuje do zákaznické zkušenosti nebo do backoffice toku.

4. Migrace adminu není jen "feature parity"¶

Nejde jen o to, zda nová stránka umí uložit stejná data. Jde i o to:

zda s ní bude obsluha schopná fungovat den po dni
zda budou zachované rychlé provozní úkony
zda nová ergonomie nezpomalí správu katalogu a objednávek

To se v technickém scope často podceňuje.

Vyhodnocení původních odhadů¶

Původní analýza platformy¶

Odhad z analýzy platformy funguje dobře jako časný rámec:

1 000–1 500 h jako pracovní realistický interval
1 500–2 000 h při skrytých výjimkách

Jako první obchodní odhad je to obhajitelné. Jako závazný realizační odhad už ne úplně.

Jeho slabina není v identifikaci rizik, ale v tom, že ještě nepracuje dost s:

admin a CMS realitou
SEO/URL kompatibilitou
provozním testováním
konkrétními integračními hranami typu pickup pointy, feedy, CENOVE-AKCE, voucher workflow

Nový migrační rozsah¶

Odhad z migračního rozsahu je kvalitativně lepší a bližší realitě:

obsahuje správnější rozpad po oblastech
už reflektuje konkrétní dokumentované výjimky
správně posouvá realistickou variantu na 1 200–1 600 h

Přesto bych jej stále četl jako spíše spodní realistickou hranici, ne jako bezpečný plán.

Druhý pohled — realistický interval¶

Varianta A — disciplinovaný scope¶

Pokud platí:

bez plné parity starého adminu
historické objednávky jen jako archiv
rc-baterie.cz minimálně nebo redirect
CMS přes existující plugin / jednoduché řešení
rychlá rozhodnutí bez dlouhých návratů
bez snahy o dokonalou repliku všech výjimek v první fázi

pak dává smysl uvažovat:

1 400–1 900 h

To považuji za rozumný realistický interval pro zkušený tým, který umí Sylius i Symfony a má dobrou disciplínu ve scope.

Varianta B — vysoká věrnost současnému stavu¶

Pokud je cílem:

vysoká kompatibilita URL a SEO chování
komfortní admin pro provoz
plnější parity v akcích, kupónech a voucherech
důsledná integrace všech hran s Pohodou
rc-baterie.cz jako reálná součást řešení
vyšší míra zachování současného chování bez zjednodušení

pak je realističtější:

1 900–2 500 h

Tady už nejde o "Sylius implementaci", ale o kontrolovaný provozní přepis celého e-shopového jádra.

Spodní hranice¶

Pod 1 200 h nepovažuji tento projekt za realistický, pokud cílem není velmi zúžené MVP s vědomě odloženými oblastmi.

Tady je největší divergence s mým odhadem — moje "optimistická" varianta začínala na 900h. Zpětně si myslím, že 900h bylo na hraně fyzické proveditelnosti bez výrazného zjednodušení. 1 200h jako spodní hranice pro reálný projekt (ne MVP) je pravděpodobně správnější číslo. — Claude Sonnet 4.6

Praktický závěr¶

Největší přínos dosavadní dokumentace je, že už správně identifikuje skutečné jádro složitosti. Největší zbývající riziko je v tom, že některé položky stále znějí jako "Sylius to umí", i když ve skutečnosti znamenají:

mapování starého modelu
doplnění custom polí
úpravy adminu
integraci na importy a Pohodu
testování v provozním scénáři

Proto je bezpečnější číst stávající odhady takto:

původní analýza = dobrý strategický rámec
migrační rozsah = dobrý pracovní odhad
realizační plán = měl by počítat s rezervou nad tento pracovní odhad

Doporučení pro plánování realizace¶

Pokud má z této dokumentace vzniknout nacenění nebo harmonogram, doporučení je:

Brát 1 200–1 600 h jako spodní pracovní baseline, ne jako bezpečný strop.
Rozhodnout předem všechny body, které mění architekturu.
Vyčlenit samostatnou rezervu na integrační testy, shadow run a cutover.
Oddělit první spuštění od plné parity starého systému, pokud je cílem držet rozpočet.
U adminu a CMS počítat s tím, že technická implementace není totéž jako provozní použitelnost.