Vyplatí se to?¶

Tahle stránka je jiná než ostatní. Všechny předchozí popisují, jak by to fungovalo. Tahle odpovídá na otázku, jestli to má smysl stavět — a odpověď není příjemná.

Nechávám to tu první a nezměkčené, protože přesně kvůli tomuhle jsem se ptal. Zbytek stránky vysvětluje, za jakých podmínek to neplatí.

Čísla¶

Při sazbě 1 200–1 600 Kč/h je to 2,5 až 8 milionů korun, než je to zralé. Bez ceny vlastního času a bez obchodního rizika.

Prototyp je samozřejmě mnohem levnější. Ale:

Kdy to smysl dává¶

Ne „když uděláš dost webů". Musí platit všechno tohle najednou:

• 8–15 podobných realizací během tří až pěti let
• 60–70 % komponent a 50–70 % datového modelu se přenese beze změny základního principu
• projekty žijí aspoň čtyři roky
• po spuštění se pravidelně mění obsah, jazyky, kampaně, integrace
• jeden projekt má dnes 800–1 500 hodin práce
• chyby při publikaci mají měřitelnou cenu
• někdo platformu vlastní jako produkt — ne „udržuje, když zbude čas"

Ta poslední odrážka není administrativní detail. Je to nejčastější způsob, jak se to rozpadne.

Kdy to smysl nedává¶

• dva až čtyři vzájemně odlišné weby ročně
• běžný projekt má 200–600 hodin
• klienti kupují hlavně originální vizuál a jednorázové spuštění
• po spuštění se web skoro nemění
• každý projekt má jiné externí systémy
• platformu chceš financovat ze zakázek, ale klienti za její vývoj platit nechtějí

Velikost projektu rozhoduje víc, než jsem čekal¶

Tady jsem se spletl. Myslel jsem si, že rozhoduje životnost a četnost změn, a že velikost je vedlejší. Není:

Zpětně je to zjevné. Režie na definici pravidel je skoro fixní — u malého projektu je poměrově vražedná, u velkého se rozpustí.

Konkrétně¶

Co se stane u druhého, pátého a desátého projektu¶

Všimni si pravého sloupce: u různorodých projektů se přenositelnost nezlepšuje s pořadím vůbec. Pořád 15–40 %, ať je to druhý nebo dvacátý.

A test, jestli to selhalo:

Jak se změní práce¶

Postup dnes a potom¶

DNES                          POTOM
grafik navrhne v Figmě        vybere se podporovaný typ projektu
vývojář udělá HTML/SCSS       popsat entity, vazby, vlastníky hodnot  ← nové
napojí to na DB přes SQL      grafik vybere tokeny a povolené varianty ← nové
naplní se obsah               namapovat potřeby na hotové komponenty  ← nové
hotovo                        doplnit jen to, co v katalogu chybí
                              nakonfigurovat zdroje dat a publikaci
                              naplnit nebo naimportovat obsah
                              systém ověří celý release               ← nové
                              publikuje se konkrétní verze            ← změna
                              další změny = nový release              ← nové

Zmizí: kreslení každé stránky jako originálu, šablona pro každou konkrétní stránku, datové zkratky podle okamžité potřeby, improvizované opravy publikovaného webu — a představa, že „naplní se obsah a je hotovo".

Kdo to odnese nejvíc¶

Čekal jsem, že grafik. Je to backendista:

Rozdíl, který jsem sléval dohromady: největší profesní změna je u backendisty. Největší kulturní odpor přijde od grafika a klienta — pokud jsou zvyklí považovat každou výjimku za projev kreativity.

A jedna věta, kterou stojí za to brát vážně:

Jak to prodat klientovi¶

Prodává se funkční první verze za dva týdny, předvídatelná cena dalších jazyků a webů, bezpečné publikování, rychlost následných kampaní a nižší závislost na konkrétním vývojáři.

Jenže první verze za dva týdny jde dodat jen tehdy, když už katalog pro jeho typ webu existuje. Když ne, jsou tři poctivé možnosti:

1. klient zaplatí analýzu a pilot, ne hotový web
2. investici zaplatíš sám a nabídneš standardizovaný produkt
3. zakázku uděláš jednodušším postupem

Největší riziko¶

Není technické.

Jakmile se „znovupoužitelná" komponenta pro každého klienta upravuje, úspora mizí a roste cena podpory všech variant.

Tři věci, které v té odpovědi neobstály¶

Odhad hodin je nejspíš pro chudší platformu¶

1 500–4 000 hodin je odhad pro „vlastní platformu" obecně. Tahle má za sebou dvanáct kol návrhu a je nad průměrem: generace a atomická validace cache, neměnné revize s manifesty, autorita pole se čtyřmi reprezentacemi, mandáty agentů, migrace živých kořenů.

A účet Z říká, že jen invalidace potřebuje testovací aparát velikostí srovnatelný se samotným mechanismem.

Buď je odhad nízký, nebo počítá s výrazně jednodušší implementací. Obojí posouvá bilanci k horšímu.

Rozhodující číslo se dá zjistit levněji, než odpověď říká¶

Za největší neznámou označuje procento skutečně opakovatelné práce a dodává, že bez dat z pěti až deseti minulých projektů je návratnost jen hypotéza.

Ale existuje levná cesta: projít zpětně už hotové projekty a spočítat, kolik z toho, co se dělalo znovu, bylo strukturálně totéž. To je jediná věc, která jde udělat před rozhodnutím a která ho zásadně zpřesní.

Ústupová varianta není menší verze téhož¶

Závěr nabízí: použít existující systém a investovat jen do omezeného katalogu komponent.

Jenže celá tahle dokumentace stojí na vlastnostech, které existují jenom když platforma vlastní celý řetězec. Invalidace podle závislostí potřebuje kontrakty komponent. Release potřebuje připnutý renderer. Autorita nad polem potřebuje zápisovou cestu.

Katalog komponent nad cizím CMS nedá ani jednu z nich. Je to jiná věc, ne skromnější verze téže věci — a tohle v odpovědi nezaznělo.

Doplněk: co na to říká praxe¶

Po první verzi téhle stránky přišly dvě zkušenosti z terénu, které tu analýzu posunuly. Proběhlo k nim další kolo a jeho závěr je konkrétnější než ten předchozí.

Dvouletý cyklus¶

Firmy, které mají peníze, berou web jako spotřební zboží: po dvou letech kompletní redesign — a u jiné agentury. Přitom to bývá strukturálně přesně ten typ klienta, pro který má být platforma vhodná: výrobce, rozsáhlý katalog, hodně jazyků.

Ptal jsem se technicky: přežije to platforma, když je design systém verzovaný artefakt? To byla špatná otázka. Odpověď je jinde:

A test na konkrétní firmu je jedna věta: používá strukturovaný katalog a překlady ještě někde jinde než na aktuálním webu? Pokud ne, dvouletý cyklus ji vylučuje. Pokud ano, neprodává se to jako webová platforma, ale jako produktová a publikační infrastruktura firmy.

E-shop není totéž co e-shopová platforma¶

Aby vlastní platforma v tom segmentu vůbec soutěžila, musela by umět košík, checkout, platby a refundace, dopravy a výdejní místa, objednávky, storna a vratky, daně a fakturaci, B2B ceníky a schvalování, slevy a jejich kombinovatelnost, fulltext a merchandising, feedy, fraud a audit — šestnáct oblastí.

Celá tahle dokumentace přitom popisuje jen tu obsahovou část. Odhad 1 500–4 000 hodin je odhad poloviny problému.

Nekupuje se to, co to umí¶

Formulace provozovatele e-shopu: „rozhoduje spousta jiných funkcí uvnitř než naše aktuálnost stavu dat." Odpověď to potvrdila bez okolků:

Prodat jde čas a cena chyb: nový trh za tři týdny místo čtyř měsíců · změna parametru bezpečně do dvanácti zemí a pěti kanálů · redesign nebude vyžadovat migraci katalogu · při chybě vrátíme celou změnovou sadu, ne jednotlivé stránky.

A balast? Nic ho nezastaví¶

Tohle je nejtvrdší odpověď z celé debaty. Zeptal jsem se, co zaručí, že se za deset let nenashromáždí znovu tolik výjimek, že systém zabijí:

Tím padá největší nevyslovený slib celého návrhu. Deklarované závislosti, typované vazby a capability zabrání technickému nepořádku. Nezabrání tomu, aby se výjimky nakupily — protože ty nevznikají z technických důvodů.

Obrana existuje, ale je provozní, ne technická: každá výjimka má vlastníka, důvod, cenu a datum revize; „dočasné" řešení má datum odstranění; klient platí i budoucí náklad výjimky; někdo má právo požadavek odmítnout.

Menší varianta, která přežije obojí¶

Verdikt kola 13:

Osm součástí:

Pod tím běží existující systémy. Vlastní hodnota je v pravidlech mezi nimi, ne v jejich náhradě.

Tři důkazy, bez kterých do toho nejít¶

1. konkrétní klient za tu vrstvu zaplatí
2. dva další dostupní klienti mají tentýž problém — ne seznam firem, ale dvě tři, se kterými to jde ověřit
3. přínos jde vyjádřit penězi nebo dobou uvedení změny na trh

Jak začít¶

Konkrétní e-shop jako placený design partner — ne zakázka, ne obecný produkt.

Co si z toho odnést¶

Návrh je technicky v pořádku. Po dvanácti kolech v něm není žádná známá díra ve správnosti a u každého rozhodnutí je dohledatelné, co stálo.

Obchodně to ale není nástroj agentury a není to ani celá platforma. Je to řídicí vrstva nad systémy, které už existují — a ta je dost úzká, aby ji malý tým zvládl, a dost oddělená, aby přežila redesign i výměnu e-shopového enginu.

Takže než cokoli dalšího:

1. Projít zpětně poslední projekty a zjistit, kolik z nich bylo opravdu strukturálně stejné. Bez toho čísla je všechno ostatní hádání.
2. Ověřit ty tři důkazy — zvlášť druhý, protože bez něj je to zakázka, ne produkt.
3. Teprve potom se ptát, co postavit — a nejspíš to bude těch osm součástí, ne tahle dokumentace celá.

A varianta, kterou je poctivé nechat na stole: nestavět nic. Přečíst si tohle jako dobře prozkoumaný návrh a použít z něj jednotlivé myšlenky tam, kde se hodí — autoritu nad polem, release místo publikování stránky, graf dopadu změny. Každá z nich dává smysl i samostatně a žádná nevyžaduje vlastní platformu.