Zadání Grandfinále

Charakter zadání v GRF

Ať už týmy v Grandfinále začínají úplně od nuly, nebo navazují na řešení ze Soutěžního kola, zadání GRF nemá být „ještě jeden checklist požadavků“. Má to být otevřený problém, který nejde vyřešit jen technickou správností.

Z diplomové práce mi jednoznačně vyšlo, že pokud chceme posunout kvalitu týmů, musíme změnit samotné zadání. Nestačí, aby jen plnily požadavky – potřebujeme, aby začaly přemýšlet o softwaru jako o produktu.

Smyslem je, aby:

zadání ponechávalo dostatek prostoru pro interpretaci,
neexistovalo jedno „správné“ řešení,
tým byl nucen navrhnout vlastní koncept, ne jen implementovat cizí představu.

Klíčový moment GRF je práce s klientem:

tým si musí sám ujasnit, co je vlastně problém,
ověřit si své předpoklady,
a průběžně validovat, zda navržené řešení dává smysl i mimo jejich hlavy.

Změna konceptu

Z tohoto důvodu jsme odstranili v TdA26 „servírovaná“ zadání. V minulosti týmy v podstatě jen replikovaly komunikaci s klientem – sbíraly požadavky, doptávaly se na detaily a implementovaly. Dnes už to ale nefunguje. S nástupem AI se kódování samo o sobě stává komoditou – rozhodující není, kdo lépe programuje, ale kdo lépe přemýšlí.

Nový koncept staví týmy do úplně jiné role: nedáváme jim přesné zadání, ale komplexní prostředí. Pracují s personami z fiktivní firmy – metodik, lektor, CFO a další. Každá z nich má vlastní cíle, které si často protiřečí. Některá rozhodnutí dávají smysl z byznysového pohledu, ale mohou zničit samotnou podstatu produktu. Typický příklad: monetizace vs. dostupnost vzdělávání.

Úkolem týmů je tyto konflikty pochopit, identifikovat reálné problémy a navrhnout řešení. Ne všechno lze stihnout – musí prioritizovat, rozhodovat se pod tlakem a nést odpovědnost za směr produktu. Výsledek? Během jednoho dne vzniká dvacet naprosto odlišných aplikací a přístupů.

Změnili jsme i formát obhajob. Místo klasického tabulkového hodnocení probíhá uzavřené, komentované demo. Tým má 15 minut, aby před „klientem“ ukázal, co vytvořil – jaký problém řeší, jak funguje a jakou má hodnotu. Nejde o designy ve Figmě. Produkt musí být reálně funkční. Zároveň ale dáváme prostor, aby každý tým dokázal svůj výstup obhájit a stát si za ním.

Dobře navržené zadání v GRF:

podporuje kreativní řešení,
nutí týmy dělat kompromisy,
a umožňuje porotě hodnotit kvalitu rozhodnutí, ne jen výsledek.

Technická dokonalost je pořád důležitá. Ale v GRF je až druhá v pořadí – po schopnosti pochopit zákazníkův problém a navrhnout řešení, které dává smysl v reálném světě.

Tvroba zadání

Principy návrhu

Tvorba zadání pro Grandfinále nevychází z klasického modelu „seznam požadavků“, ale z návrhu prostředí, ve kterém jsou týmy nuceny rozhodovat. Cílem není definovat, co mají vytvořit, ale vytvořit situaci, ve které musí samy přijít na to, co dává smysl.

Příliš konkrétní zadání

Z analýzy předchozích ročníků vyplývá, že pokud je zadání příliš konkrétní, týmy po úvodní fázi přestanou objevovat. Typicky proběhnou jedna až dvě schůzky s klientem, během nichž si doplní chybějící informace, a následně přecházejí přímo k implementaci. Tím se ztrácí prostor pro rozvoj klíčových kompetencí, zejména schopnosti ptát se, interpretovat problém a rozhodovat se v nejistotě.

Zadání proto musí:

vytvářet informační nedostatek, který nutí týmy aktivně zjišťovat kontext,
obsahovat vnitřní napětí, které znemožňuje optimalizaci jedním směrem,
a umožnit vznik více validních řešení, která se liší přístupem, nikoliv jen kvalitou implementace.

Práce s konfliktem

Klíčovým konstrukčním prvkem zadání je konflikt. Ne ve smyslu komplikace, ale jako záměrně vytvořené napětí mezi různými očekáváními.

V reálném vývoji software téměř nikdy neexistuje řešení, které by maximalizovalo všechny cíle zároveň. Zadání by tuto realitu mělo simulovat.

Typické konflikty, které můžeš zkusit využít:

monetizace vs. dostupnost služby,
rychlost vývoje vs. kvalita řešení,
jednoduchost UX vs. míra kontroly,
krátkodobý efekt vs. dlouhodobá udržitelnost.

Bez tohoto napětí týmy optimalizují triviálně. S konfliktem jsou nuceny:

prioritizovat,
obhajovat rozhodnutí,
a nést důsledky zvoleného směru.

Právě zde vzniká prostor pro hodnocení kvality rozhodování, nikoliv pouze výsledku.

Role a perspektivy (persony)

Jedním z funkčních způsobů, jak konflikt do zadání dostat, je práce s různými perspektivami v rámci jedné organizace.

Tyto perspektivy (např. metodik, lektor, CFO, produktový manažer) reprezentují:

odlišné cíle,
odlišné potřeby,
a často i protichůdné požadavky.

Je důležité zdůraznit, že persony nejsou cílem samy o sobě. Jsou pouze nástrojem, jak:

rozbít jednoznačnost zadání,
vytvořit přirozený konflikt,
a přiblížit soutěž realitě práce v týmu.

Dobře navržené role:

mají jasně definovaný cíl („čeho chtějí dosáhnout“),
mají konkrétní motivace a tlaky,
a zároveň nejsou plně kompatibilní s ostatními.

Například:

CFO maximalizuje příjmy a hledá monetizační modely,
metodik prosazuje kvalitu vzdělávání a metodickou čistotu,
lektor řeší každodenní použitelnost a UX,
produktový manažer tlačí na rychlé dodání hodnoty.

Pokud by všechny tyto role byly v souladu, nevzniká rozhodování – pouze implementace.

Míra konkretizace zadání

Zadání by nemělo být ani příliš vágní, ani příliš konkrétní.

Příliš konkrétní zadání vede k „checklistovému“ řešení, omezuje kreativitu, a zvýhodňuje týmy s lepší implementací.

Příliš vágní zadání naopak vede ke ztrátě orientace, zvyšuje frustraci, a penalizuje méně zkušené týmy.

Doporučený přístup:

definuj prostředí a kontext (firma, produkt, problémová oblast),
poskytni částečné informace (materiály, výstupy, reporty),
ale nedefinovat konkrétní funkcionalitu jako povinnost.

Týmy by měly mít dostatek informací k tomu, aby mohly začít, ale zároveň dostatek nejistoty, aby musely přemýšlet. Klient na schůzkách tak nebude popisovat konkrétní funkcionalitu, ale měl by ve většině případech jenom kývat hlavou. Ano, tohle chci. Ne, tohle nechci.

Podklady k zadání

Součástí zadání by neměl být pouze text, ale i doprovodné materiály, které simulují reálné prostředí.

Typické podklady:

interní dokumenty (např. reporty, analýzy),
ukázky dat,
screenshoty nebo návrhy,
krátké texty reprezentující pohled jednotlivých rolí,
jednoduché tabulky nebo metriky.

Tyto materiály nemusí být perfektní ani plně realistické. Je zcela v pořádku, pokud jsou vytvořeny rychle nebo generovány pomocí AI. Jejich účelem není přesnost, ale vytvoření kontextu, inspirace pro týmy a rozšíření prostoru pro interpretaci.

Zároveň ne každý klient je schopný na místě si danou roli představit. Nemůžeme prostě vzít organizátora a říct mu: "Teď se chovej jako metodik." Pokud to je role, o které vůbec nic neví, jak v praxi vypadá, bude zmatený. Takže podklady slouží i jako nějaké doprovodné materiály pro naše organizátory.

Hravost a role-playing

Důležitým, ale často podceňovaným prvkem zadání je jeho forma. Pokud mají týmy pracovat s rolemi a simulovaným prostředím, výrazně pomáhá, když je zadání dostatečně hravé.

Zkušenost ukazuje, že pokud organizátoři dokážou role „odžít“ (např. i s lehkou nadsázkou nebo přehnanými charakteristikami), týmy:

lépe chápou jejich motivace,
snáze si je zapamatují,
a aktivněji s nimi pracují.

Hravost zde neznamená zjednodušení. Naopak snižuje bariéru vstupu a umožňuje lépe pochopit komplexní situace.

Jak začít?

Při návrhu zadání je vhodné začít nikoliv funkcionalitou, ale otázkami:

Jaký typ rozhodování chci, aby týmy dělaly? Jaký konflikt je k tomu donutí? Jaké perspektivy tento konflikt reprezentují? Co se stane, pokud tým optimalizuje jen jeden směr?

Teprve následně má smysl tvořit konkrétní role, materiály a kontext.

Ostatní tipy

Ještě než půjdou v nedělní části týmy obhajovat, je dobré jim dát kvalitní nalejvárnu o tom, jak má vypadat správný sales pitch.
Mentoři by měli mít alespoň nějakou ideu o tom, jak jsme to prostředí nadefinovali a jakým způsobem z nás mají možnost tymy vytahovat informace.
Na sobotní večerní obhajoby, které jsou koncipované jako komentovaná demo s užším kruhem zástupců klientů, je vhodné vyhradit dostatečně velké množství času alespoň dvacet minut.

TdA26: Příliš krátké obhajoby

V TdA26 jsme počítali s 10 minutami na tým, což se ukázalo extrémně krátké. Potřebujeme alespoň dvacet minut na každou obhajobu. To je minimální čas, kdy může porota týmu klást smysluplné dotazy a pochopit, co vytvořily.

Při komunikaci vůči týmům je vhodné zvolit transparentní strategii. Aby věděli, že to, co vytvoří, musí být opravdu MVP. Takže to musí pokrývat ty potřebné funkcionality pro účely obhajoby tak, aby se to nerozsypalo jakmile na něco kllikneme. Není však třeba dělat corporate-ready produkt.
O formátu Grandfinale bychom měli týmy informovat s předstihem na webu a v pravidlech.

Zpětná vazba

Otevřenou otázkou do budoucna je, jak moc se chceme přiblížit Prezentiádě v oblasti zpětné vazby. Mnoho týmů se zajímá, jak mohou svoji prezentaci od příště vylepšit a čeká na konkrétní zpětnou vazbu.