Jak jsme postupovali
Dne 15. června 2026 jsme se sešli na meetingu, kde jsme
probrali obě portfolia — týmové (tymove.xlsx)
i individuální (individualni.xlsx). Na základě diskuze jsem
pak každý list vytiskl jako samostatnou kartičku, fyzicky je rozložil
na stůl a detailně prošel.
Na základě poznatků z meetingu jsem je pak seřadil podle těchto kritérií:
- Implementační náročnost (1–5): jak složité je danou funkcionalitu postavit. Čím vyšší číslo, tím víc vývojářské práce.
- Friction reduction (1–5): jak moc daná funkce odstraní tření oproti současnému Excelu. Snížení počtu kliků, hledání, ručního přepisování.
- Frekvence používání (1–5): jak často s danou částí studenti pracují během semestru. Něco se vyplňuje denně, něco jednou za semestr.
Z těchto tří hodnot jsme sestavili priority score:
Čím vyšší score, tím dříve by se daná funkce měla dělat — protože přináší hodně hodnoty za málo úsilí. Tento princip vychází z klasické prioritizační matice, kde se funkce dělí do čtyř kvadrantů:
U každé kartičky jsme také zaznamenali závislosti (modré podtržení na papírcích) — některé moduly nejde postavit, dokud nejsou hotové jiné (např. Crossfertilizace potřebuje hotový Training Session). Tyto závislosti jsme zohlednili při řazení do fází.
Výsledkem je 5 fází (4 vývojové + testování), které postupně pokrývají všechny části portfolia. Každá položka má svůj GitHub issue, kde se sleduje její stav.
Co jsme zdokumentovali
Pro každý sheet z obou portfolií jsme vytvořili samostatnou wiki stránku, která obsahuje:
- Popis účelu listu a jeho datovou strukturu
- Návrh digitalizace — jak by měla funkce v Tappce vypadat
- Hodnocení z fotografií (náročnost, friction, frekvence)
Všechny wiki stránky jsou dostupné v přehledu na této stránce.
Proč děláme převod
Současný stav: studenti zapisují svá portfolia do Excelu, ale zároveň používají Tappku na rezervace a eseje. To znamená práci na dvou místech, ruční přepisování a zbytečné tření.
Filozofie převodu je jednoduchá: nejdřív core, pak nástavby. V první vlně nejde o to postavit dokonalý nástroj se vším vychytáním — jde o to dostat portfolio z Excelu do Tappky v digitální podobě tak, aby v ní studenti reálně začali zapisovat svoje data. Jakmile budou data jednou v Tappce, dá se na nich stavět cokoliv — dashboardy, statistiky, propojení mezi moduly, automatické reporty. Bez tohoto core to nejde vůbec; s ním to půjde rychle.
Proto chceme, aby přechod byl pro studenty co nejpříjemnější — ideálně to, co dělali v Excelu, jen lépe a na jednom místě, bez učení se novému systému navíc. A na naší straně chceme, aby šel vývoj co nejrychleji: žádné přeinženýrování, žádné předčasné optimalizace pro featury, které ještě nikdo nepoužívá. Postavit jednoduše, dostat to studentům do rukou, a teprve pak nad tím stavět chytřejší věci.
Cílem je do 1. října překlopit portfolio do Tappky, aby od září 2026 všechno běželo na jednom místě. Velká část portfolia se skládá z jednoduchých záznamů (řádků v tabulce), které není složité převést — viz fáze Quick Wins. Komplexnější celky (Training Session, Skill Profile, Rocket Model) na sebe přirozeně navazují a jejich hotová podoba spadá až do pozdějších fází.
Co znamená "core" v praxi — příklad T03
Příklad: Zákaznické schůzky (T03)
Abychom si filozofii "nejdřív core" ukázali na něčem konkrétním, vezměme si Zákaznické schůzky (T03) z Fáze 1. V praxi to znamená následující implementaci:
| Pole | Typ | Popis | Hodnota |
|---|---|---|---|
| Datum | label | Datum schůzky | — |
| Zákazník | value | Jméno / firma zákazníka | uživatelem zadaná hodnota |
| Typ schůzky | value | Osobně / online / telefon | uživatelem zadaná hodnota |
| Cíl schůzky | value | Co bylo cílem setkání | uživatelem zadaná hodnota |
| Průběh | value | Jak schůzka probíhala | uživatelem zadaná hodnota |
| Výsledek | value | Co se podařilo / domluvilo | uživatelem zadaná hodnota |
| Akční kroky | value | Co je potřeba udělat po schůzce | uživatelem zadaná hodnota |
- user_id (FK)
- datum
- zakaznik
- typ_schuzky
- cil_schuzky
- prubeh
- vysledek
- akcni_kroky
To je celý core. Formulář s těmito poli, jedna databázová tabulka napojená na uživatele přes cizí klíč, a seznam zápisů, které si student může prohlédnout. Nic víc. Tím dostaneme uživatelská data dovnitř Tappky — a teprve poté má smysl je dál vylepšovat.
Co core řeší a co ne
Teď — core
- 1 tabulka v databázi, FK na uživatele
- jednoduchý formulář se 7 poli
- seznam zápisů, žádné propojení jinam
Později — nástavby
- auto-redirect z time trackingu po skončení aktivity
- zobrazení v kalendáři odpracovaných hodin, proklik na detail
- propojení s historií zákazníka, dashboardy a statistiky
Vpravo je všechno, co by dávalo smysl postavit někdy — ale dnes by to jen oddálilo to nejdůležitější: dostat uživatelská data do Tappky. Stejné dělení (core teď / nástavba později) platí pro každou položku v roadmapě.
Náročnost v kontextu
Implementační náročnost je jedna ze tří kategorií, podle kterých jsme celé portfolio hodnotili (viz výše) — a u core verze skoro každé položky vychází nízká (většina N1–N2). Bez srovnání ale desítky položek v roadmapě mohou působit jako nezvládnutelné množství práce. Zkusme to porovnat s tím, co už dnes běží v produkci a reálně to funguje:
Esejbanka (hotovo, čeká na nasazení)
- 6 provázaných tabulek (eseje, knihy, komentáře u obou, sledování zobrazení, potvrzení přečtení koučem)
- stavový automat: schvalování knih + needitovatelnost po schválení
- fulltextové vyhledávání (tsvector + trigram indexy)
- desítky RLS politik podle role
Rezervační systém (v provozu)
- 6 provázaných tabulek (místnosti, rezervace, opakující se rozvrhy, cowork účastníci, nahlášené problémy, blackout dny)
- detekce časových překryvů (EXCLUDE constraint)
- víc stavových automatů + časová validace napříč tabulkami
- 14 RLS politik, 14 indexů
Tohle obojí už máme hotové a v reálném provozu — tedy úroveň náročnosti N4–N5. Oproti tomu je každá jednotlivá core položka z roadmapy o řád jednodušší: jedna tabulka, žádné překryvy, žádný stavový automat, žádné fulltextové vyhledávání. I když je v roadmapě hodně položek, jejich souhrnná implementační náročnost je pořád menší, než jeden z těchto dvou systémů, které jsme už zvládli postavit.
Sledování progresu
Veškerý progress je sledovaný v
GitHub Issues.
Každá funkce má vlastní issue s detaily, hodnocením z fotografií a fází.
Issues jsou rozdělené podle fází pomocí labelů
(phase:01-quick-wins až phase:04-testing).
Stav jednotlivých issue (otevřeno / rozpracováno / hotovo) je vidět na přehledu projektu. Kdykoliv se můžete podívat, co se právě dělá a co zbývá.
vysoká hodnota, nízká náročnost
základní vzdělávací moduly
moduly navazující na core
integrace všeho dohromady
Testování probíhá průběžně v rámci každé fáze. Na konci každé fáze nasazujeme hotové funkce na produkci, ale zobrazí se jen uzavřené skupině lidí (feature flagy). Tím získáme zpětnou vazbu ještě během vývoje, aniž bychom ovlivnili všechny.
Vrcholem je zářijové testování: naplánujeme focus group s vybranými studenty a individuální testování (1v1) s kouči. Cílem je ověřit, že portfolio v Tappce opravdu funguje v reálném provozu a že noví studenti od září můžou všechno dělat na jednom místě.
Rozšiřování informací a přístupu do širší komunity nad rámec této uzavřené testovací skupiny probíhá vždy postupně a v koordinaci s kouči — nic nezpřístupňujeme celé komunitě bez jejich vědomí a souhlasu.
Bez ohledu na to, jak daleko se dostaneme s jednotlivými moduly, je garantovaným cílem k 1. říjnu, aby si každý student mohl vyexportovat svá data z Tappky do podoby portfolia tak, jak je vyžadováno. Pokud by se do deadline nepodařilo dokončit úplně všechno, export bude obsahovat zvýrazněná pole, která zůstanou k manuálnímu doplnění — aby žádný student nezůstal bez portfolia.
oprava a optimalizace, žádné nové moduly
Po 1. říjnu se vývoj nezastavuje, ale otáčí směr. Celý semestr, kdy budou v Tappce poprvé reálně pracovat noví studenti, věnujeme primárně tomu, aby core, který jsme postavili rychle a bez vychytávek, fungoval spolehlivě — oprava chyb z reálného provozu, optimalizace a postupné splácení tech dluhu, který jsme si při rychlém vývoji vědomě vzali na sebe.
Žádné nové moduly ani nástavby (dashboardy, automatizace, propojení mezi moduly) v této fázi neplánujeme — ty mají smysl až na stabilním core. Priorita je jasná: core musí být ověřeně spolehlivý, než na něm začneme stavět cokoliv dalšího.
Poznámka: konkrétní rozdělení a priority uvnitř Fáze 5 jsou zatím jen nynější odhad. Upřesníme je blíže k 1. říjnu, až uvidíme, v jakém stavu core skutečně bude a co reálný provoz ukáže za problémy.
Již hotovo
Eseje (individual.xlsx ID 22) #76
Vývoj je hotový, ale ještě nenasazeno do produkce. Původní esejbanka zatím zůstává jediná v provozu, protože na ni všichni odkazují v portfoliích.
1. srpna proběhne překlopení (migrace) všech dat ze staré esejbanky do Tappky a nasazení nové verze do produkce. Poté nahradíme tlačítko "Přidat esej" ve staré bance redirectem na Tappku a na hlavní stránku dáme jasné info, že stará verze je legacy. Přechod bude 1:1 — stejně jako u rezervačního systému.
Rezervační systém
V provozu na tiimi.cz. QR/NFC, kalendář, správa místností.
Mimo scope
Ukončení činnosti (tymove.xlsx ID 18)
Přeškrtnuto na fotce — není relevantní pro digitalizaci do Tappky.