Tvorba zadání

Ta nejkreativnější část celé soutěže!

Tvorba zadání je srdíčkem Tour de App – správně navržená výzva rozhodne o tom, jestli se soutěžící skutečně něco naučí, jak rozvinou klíčové kompetence, a zda neodpadnou při prvním pohledu na požadavky n a ně kladené. Zadání v TdA není pouze technickým specifikačním dokumentem. Je nástrojem řízeného učení a zároveň mechanismem selekce a diferenciace výkonu týmů.

V této kapitole najdeš doporučení pro každou fázi soutěže, principy rovnováhy front- vs. back-endu a tipy, jak navrhnout úkoly, které vyžadují vlastní kreativitu.

Zvládnu to?

Vezmi si čas, o kterém si myslíš, že strávíš na zadání... a vynásob to 10. Tvorba zadání je velmi náročná, každý má svůj názor, kritiku a tváří se, že moc dobře ví, jak to dělat.

Zadání pro vzdělávací soutěž musí obstát před třemi typy kritik: didaktickou (učitelé), technickou (vývojáři) a organizační (hodnotitelé).

Při tvorbě zadání musíš být: učitel, grafik, detailista, spisovatel, kreativec, manažer, psycholog a v neposlední řadě také ajťák. Easy kombinace, ne? Naštěstí není nutné vymýšlet celé kolo pokaždé znovu, nebo alespoň metodiku k jeho vytvoření. Ta totiž již existuje a i když je samozřejmě možné ji stále zlepšovat, i doslovné aplikování bude stačit. Tak tedy do práce!

Základní principy kvalitního zadání

Pokud má být soutěž vzdělávací, musí zadání:

mít smysluplnou learning curve – týmy se musí mít kam posouvat,
být navázané na ,
vyžadovat rozhodování na straně soutěžících, ne jen implementaci,
obsahovat prostor pro vlastní návrh
a zároveň mít jasně definované technické minimum.

Každý z těchto principů musí být při návrhu zadání explicitně ověřen – pokud jej nelze v zadání dohledat, pravděpodobně v něm chybí.

Learning curve

Zadání by mělo mít několik vrstev:

Minimum, které zvládne průměrný tým.
Prostor pro optimalizaci a zlepšení.
Možnost jít nad rámec, pokud má tým kapacitu.

Začátečník by měl mít šanci „projít“ a něco si odnést. Pokročilý tým by měl mít možnost se utrhnout a ukázat kvalitu.

Diferenciace

Pokud obě skupiny dosahují podobného výsledku bez rozdílu v náročnosti řešení, learning curve není dostatečně diferencovaná.

Navázání na vzdělávací rámec

Zadání nemá vznikat „protože je to cool téma“. Má vycházet z / , které chceme rozvíjet. Pokud ze zadání není jasné, co se tím má kdo naučit, je něco špatně.

Není to one-prompt problém

Jedno z největších rizik současnosti:

Tým vezme zadání → hodí ho do AI → dostane hotový kód → upraví styling → hotovo.

To je problém.

Řešení není zakázat AI, ale navrhovat zadání tak, aby:

vyžadovalo návrh systému, ne jenom bezmyšlenkovitou implementaci,
obsahovalo požadavky na architektonické rozhodnutí,
do budoucna možná vyžadovalo i dokumentaci, UML, vysvětlení řešení,
nutilo tým obhájit, proč něco udělal právě takhle.

Takže... co?

Ha! To sice zní dobře, ale co s tím mám skutečně dělat?

Některé části zadání mohou být definovány otevřeně, například formou user stories, nekompletního briefu, nějak omezeného externího black-box kódu, nebo třeba skrze business problému, který mají týmy aplikací pomoci vyřešit.

Klíčové je vytvořit situace, kde existuje více legitimních řešení a kde kvalita volby hraje roli. Otevřenost však nesmí znamenat nejasnost. Týmy musí rozumět cíli, ale nikoli nutně cestě k jeho dosažení.

Proces přípravy

Zadání se netvoří měsíc před spuštěním daného kola (i když to tak občas vypadá). Ideálně začíná práce na něm paralelně s revizí vzdělávacího rámce, což se ale může stát i dřív. Větší detail a rychlou kontrolu můžeš udělat v . Tyto kroky nejsou specifické jen pro Nominační kolo, ale platí pro všechny fáze soutěže s rozdílem toho, že ubývá času a přibývá potřeba navazovat na předchozí části soutěže.

Předpoklad: vzdělávací rámec

Zadání vychází z , který popisuje, co se má v soutěži naučit. Poté, co si vytáhneš tématické okruhy a zařadíš je na správné body timeline soutěžících, můžeš začít s přípravou zadání. Zadání by mělo být časově sladěno s tím, kdy jsou soutěžící schopni daný koncept absorbovat.

Krok 1: Brainstorming témat

Ideálně v rámci offline akce vzniká potenciál využití velkého množství organizátorů na jednom místě. Toto může být zdrojem inspirace k výběru:

vzdělávacího okruhu (takže např. i konkrétní technologie jako je SSE, AI...)
a příběhové linky (e-shop, vzdělávání, piškvorky).

Brainstorming by však neměl končit výběrem „zajímavého tématu“, ale měl by pokračovat filtrováním podle vzdělávací hodnoty, realizovatelnosti a hodnotitelnosti.

Krok 2: Vymezení scope

Tady si musíš odpovědět:

Jaké kompetence má tato část primárně rozvíjet?
Jaký je minimální výstup, který považujeme za „splněno“?
Jaký je očekávaný skill-level cílové skupiny po absolvování této části?

Detailní otázky, na které je super se ptát:

Krok 3: Technická dekompozice

Tady už máš high-level overview a všechny informace, které potřebuješ.

Vizuální mapa

Vytvoř si vizuální znázornění, kde popíšeš:

Funkcionality (core vs bonus)
API požadavky (swagger specifikace)
Datové entity
Potřebné testy (kde sledujeme implementaci, do jaké hloubky)
Hodnoticí vazby (část se složitým UX, jako třeba hrací plocha XO...)
Omezení (např. exportovaný soubor se musí jmenovat...)

Informace bez omáčky musí být samy o sobě dostatečné k vytvoření funkční aplikace.

Krok 4: Obsahová specifikace

Teď to musíš napsat. Tady se často dělá chyba, že text vzniká paralelně s vymýšlením obsahu, což vede k vágnosti, nepřesnostem a duplicitám. Ať už vzniká zadání NK, SK nebo GRF, je potřeba zadání textovat až po návrhu obsahu.

Doporučení:

Rozděl text zadání na vrstvy, které popíšeš . Jasně odděl zadání na vrstvu příběhu, funkčních požadavků, technických požadavků, hodnoticího rámce a otevřené části.

Tady opravdu potřebuješ „písaře“.

Technický mozek není vždy dobrý textař. Zadání musí porozumět i lidé, kteří programování vidí poprvé.

V rámci je zadání předáno týmům, takže zde je kontrola textů velmi důležitá.

TdA26: Roztříštěné zadání NK na klikání

Myšlenka byla dobrá: když se soutěžícím bude zadání prezentovat po částech, nebudou z něho tak vyděšení. Bohužel v kombinaci poměrně přepálené náročnosti (8 entit + přihlašování) a zadání v záložkách rozdělených do fází se zadání zdálo týmům na začátku až moc jednoduché a protože si nepřečetli celý obsah, nezvládli si naplánovat práci.

Zároveň si několik týmů ani nepřečetlo celé zadání a divili se, proč jim prochází testy jen 1. fáze.

Poučení: Pokud dělíš zadání na části, udělej to přehledně a ujisti se, že mají soutěžící big picture celé apliace v hlavě ještě před tím, než začnou proklikávat záložky. Hodila by se např. nějaká vizualizace s color-codingem jednotlivých fází a nebo se více opírat o vrstvy zadání!