v2 · projekt v00080_drv
Jedna sekce = jeden problém. 8 bodů čeká na tebe — v obsahu je poznáš po výrazné tečce, a přepínačem si můžeš nechat zobrazit jen je.
Jedna sekce = jeden problém = jeden ticket. Všechno k danému bodu je v jeho sekci: co jsi napsala, co jsme zjistili, co jsme změnili, co se u toho našlo, a co od tebe ještě potřebujeme. Nikde se nemusí scrollovat na konec.
Stav je vždy v hlavičce sekce:
HOTOVO — opraveno a ověřeno na skutečných datech ČEKÁ NA TEBE — opraveno, ale potřebujeme od tebe potvrzení BLOKOVANÉ — nejde to vyřešit v reportu, chybí data jinde
Čísla v tomhle souboru jsou změřená z BigQuery, ne odhadnutá. Celkové součty jsou z 10. 8. 2026, rozpady lidí a záběrů z 18.–19. 8. 2026.
POZOR: dashboard ukazuje uložený snapshot. Když se data nepřetáhnou, uvidíš na některých kartách ještě čísla z doby před opravou. Není to další chyba.
Čtyři tvoje čísla se potvrdila a naše byla špatná — 455,7 bid, 229 záběrů, leadi počítaní jako overhead, a to tvrzení o procentech z ftracku. Při jejich kontrole jsme našli další čtyři chyby, na které jsi neupozornila; každá je v sekci toho bodu, u kterého se našla.
Sekce 1–10 — první kolo feedbacku Sekce 11–18 — druhé kolo Sekce 19–33 — třetí kolo (tvoje body 19 až 33) Sekce 34 — technické chyby, které jsme našli sami Sekce 35 — CHYBÍ V BIGQUERY, na samém konci
Report je jeden HTML soubor, takže dokud si ho nevezmeš znovu, vidíš tu verzi, kterou máš u sebe. Ve třetím kole se kvůli tomu tři body (21, 30 a datumy na ose) týkaly věcí, které už byly opravené. Není to tvoje chyba — je to důsledek toho, jak se ten soubor rozdává, a měli bychom ho někam nahostovat.
Report se jmenuje "Compositing Reports", ale neukazuje jen compositing.
Název sliboval jen jednu část studia, přitom report pokrývá celý projekt.
Přejmenováno na "Project Reports — Live Dashboard", v záhlaví stránky i v názvu okna prohlížeče.
Žádná.
Není poznat, kdo se počítá do které skupiny. V hodinách má roli každý, takže nechápeš, proč report u někoho žádnou nevidí.
Ty a report čtete dvě různá pole. Proto ty roli vidíš a report ne.
Report bere roli z PRACOVNÍ POZICE v hodinách — z pole, kde je "Compositor", "Production Manager", "VFX Supervisor" apod. Je jich celkem 64. NEBERE ji z departmentu.
Lidé, u kterých report roli nemá, mají vyplněný DEPARTMENT, ale nemají vyplněnou POZICI. Ty se koukáš na department, report čte pozici.
Na DRV jsou to čtyři lidi (jmenovitě a s dny jsou v sekci 3). Napříč celým studiem má department a nemá pozici 69 lidí.
Názvy departmentů se z hodin do BigQuery nepřenášejí. Přenáší se jen číslo (22 různých hodnot), tabulka s názvy vůbec. Takže i kdybychom department chtěli použít, report by umel napsat jen "department 6", což nikomu nepomůže. Podrobně v sekci 35, bod B1.
Žádná — ale doplnění pozic u těch čtyř lidí je na produkci, viz sekce 3.
Dlaždice "Worked, ftrack" ukazuje 477 dní, tobě vychází 416,75. Máš za to, že do toho počítáme i timelogy overhead lidí, což by se počítat nemělo. A ptáš se, jestli se dá udělat, že když overhead člověk pracuje jako normální artista, přihodíme ho k artistům.
Sečteme VŠECHEN zapsaný čas na VŠECH typech tasků od VŠECH lidí, kteří na projektu něco zapsali, a vydělíme osmi. Na DRV je to 25 lidí a 477,9 dne.
artisti 420,6 dne 19 lidí overhead 6,7 dne 2 lidi lidi BEZ dohledané pozice 50,6 dne 4 lidi --------------------------------------------------------- celkem 477,9 dne 25 lidí
Overhead je 6,7 dne — to mezeru 61 dnů nevysvětlí. Dělají ji ti čtyři lidé bez vyplněné pozice:
Wesam Moussa 32,0 dne (32 tasků) Silvia Rákociová 17,7 dne (9 tasků) David Teichert 0,8 dne (10 tasků) Arseniy Kozlov 0,1 dne (2 tasky) <- tenhle v hodinách vůbec není
A 420,6 (artisti) je na necelé 4 dny od tvých 416,75, takže počítáš právě artisty a ten zbytek jsou přesně tihle čtyři.
Čili: problém není v tom, že tam overhead je. Problém je, že u čtyř lidí nevíme, do které skupiny patří — stejná díra jako v sekci 2.
Dlaždice Worked se rozpadne na artisti / overhead / bez pozice, aby bylo vidět, z čeho se skládá, a nemuselo se to dopočítávat ručně.
Nemusí se nic zaškrtávat. Kdo má většinu svého času na artistických tascích (comp, dmp, roto, matchmove, lighting, plate a podobně) A ODPRACOVAL NA NICH ASPOŇ 10 DNÍ, počítá se k artistům bez ohledu na titul. Report u něj napíše důvod, ať je vidět, že to není odhad.
Ta hranice 10 dní (asi dva pracovní týdny) není vymyšlená — je ukotvená v tom, co dělá skutečný artista: přes 333 případů "člověk na projektu" je medián artisty 13,5 dne. 10 dní je tedy o něco méně než běžný artista, ale pořád skutečná práce.
NA DRV TO NEPŘEŘADÍ NIKOHO:
Tibor Meliš (Head Of Studio | VFX Supervisor) 6,4 dne, z toho 6,2 na
artistických tascích → NEPŘEŘADÍ, je pod 10 dny
Peter Morávek (Technology Supervisor) 0,3 dne → NEPŘEŘADÍNapříč studiem to přeřadí 5 případů / 5 lidí / 92 dní — lidi, kteří na jednom projektu odpracovali 12 až 31 artistických dní.
Do "artistické práce" jsme záměrně NEzapočítali refs, zero a countsheet — to je produkční administrativa, a s nimi se k artistům přihodila i produkční koordinátorka.
Když jsme kontrolovali zařazení těch 64 pozic, staré pravidlo bylo špatné v OBOU směrech. Hledalo v názvu pozice slova "supervisor / lead / manager / head of / coordinator", a co je neobsahovalo, spadlo automaticky mezi artisty.
Accountant · Chief Accountant · Chief Business Officer · Chief Executive Officer · Chief Executive Producer · Chief Financial Officer · Controller · Executive Producer · Fundraising administrator
Ve "Chief Financial Officer" žádné z těch hledaných slov není, takže finanční ředitel se počítal jako artista.
Lead Compositor · 3D Lead · FX Lead · Animation Lead · Creative Supervisor
To je ta druhá polovina tvého bodu.
Obojí je opravené. Hádací pravidlo je zrušené, všech 64 pozic je vypsaných jmenovitě, a nová pozice se označí jako nezařazená, ať se na ni někdo podívá.
A JEDNU CHYBU JSME MUSELI OPRAVIT SAMI SOBĚ. První verze toho přeřazování měla hranici 1 den, a to bylo úplně špatně: přeřadilo to 30 případů / 16 lidí / 194 dní, mezi nimi Head of Pipeline s 1,1 dnem a VFX Supervisora s 1,0 dnem. Důvod: overhead lidi si do ftracku zapisují jen zlomek své práce, a to málo obvykle padne na artistický task — takže "podíl" vyjde 100 % na nesmyslně malém základu. Podíl sám o sobě u nich neměří, jestli dělali artistu, ale na jaký task si to zapsali. Proto ta hranice ve dnech.
Přesunuli jsme Lead Compositor, 3D Lead, FX Lead, Animation Lead a Creative Supervisor z overhead k artistům. Proč se ptáme: 30. 7. produkce výslovně řekla, že "leadi" jsou overhead, a 31. 7. jsme kvůli tomu Creative Supervisora do overhead schválně dávali. Teď to obracíme, takže to chceme potvrzené od tebe, ne od nás. Poznámka: to automatické pravidlo výš by ty leady k artistům přihodilo i tak, kdykoli na projektu odpracují aspoň 10 artistických dní. Takže je možné, že ten přesun ani není potřeba.
Je to volba, ne fakt. Změřená citlivost napříč studiem:
hranice 1 den → 30 případů přeřazeno hranice 5 dní → 12 případů (na DRV by spadl Tibor Meliš s 6,2 dne) hranice 10 dní → 5 případů ← nastaveno hranice 15 dní → 2 případy
Nastavili jsme 10, protože medián skutečného artisty je 13,5 dne.
Čtyři lidi na DRV nemají v hodinách vyplněnou pozici: Wesam Moussa (32,0 d), Silvia Rákociová (17,7 d), David Teichert (0,8 d) → těm třem stačí doplnit pozici v hodinách Arseniy Kozlov (0,1 d) → ten v hodinách NENÍ vůbec, je potřeba ho založit Dohromady 50,6 dne, které report neumí zařadit. Je to jediná věc, která ještě v tomhle bodu dělá rozdíl. Podrobně v sekci 35, bod B5.
Wesam Moussa a Silvia Rákociová mají 100 % času na artistických tascích, takže bychom je klidně mohli automaticky prohlásit za artisty a ta mezera 50,6 dne by zmizela. NEDĚLÁME to schválně: kdyby to report dopočítal sám, nikdo už nemá důvod tu pozici v hodinách doplnit a díra tam zůstane navždy — jen ji nebude vidět. Radši ať čtyři lidi svítí jako "chybí pozice". Když to chceš jinak, řekni.
nahoruV reportu byla věta, že se z worked na ftracku nepočítá žádné procento. To není pravda — s worked na ftracku se v evaluacích pracuje. Worked ftrack není správný atribut pro finanční analýzu, ale je hlavní, když jde o to, v jakém stádiu se task nebo projekt nachází.
Byla to naše chybná věta. Tvrdila opak toho, jak se ten údaj používá.
Věta je pryč. Teď je napsané, na co který zdroj odpovídá:
ftrack = JAK DALEKO JE PRÁCE. Spent ÷ bid říká, kolik z bidu už task nebo
projekt spotřeboval. Na tomhle běží evaluace.
hodiny = CO PROJEKT STÁL. Je to jediný zdroj, který vidí i práci, která se
nikdy nezapsala na task, takže peníze se dělí jím.A ten poměr spent ÷ bid je teď na stránce vypsaný, ne zamlčený. Na DRV: 478,3 dne odpracováno z 455,7 dne bidu = 105 %.
Vybrali jsme první možnost. Chceme si ověřit, že to stačí, nebo jestli měly být
vybrané i další:
V ftracku nejsou všechny tasky a občas ani všechny bidy. Ten bid, co je v ftracku, tam být má, ale musí být další atribut, do kterého se dopíše bid z master breakdownu.
Bid v ftracku je jen ta část, která se dostala na task. Celkový bid, na který byl projekt prodaný, se z ftracku spočítat nedá — v žádném dotazu, protože ta informace tam není. Musí se zapsat ručně.
Odložil jsem to bez důvodu, který by obstál — zbytek kola hotový byl.
Záložka "Breakdown data entry". Hned nahoře je karta "Master bid", kde je u každého projektu vidět ftrack bid, master bid (nebo "not filled in") a rozdíl.
Ručně to jde taky: ve "New entry" vyber Field (type) → "total project bid, master breakdown", Shot nech prázdný, Value ve dnech.
Když to zapíšeš znovu, novější platí a starší zůstane v tabulce jako historie.
Pozn.: první verze tohle měla schovanou jako jednu volbu v zavřeném seznamu, takže se nedala najít, když člověk nevěděl, že tam je. Proto to tlačítko.
Žádná, ale až první master bid zapíšeš, mrkni prosím, jestli ten rozdíl proti ftracku odpovídá tomu, co očekáváš. Na DRV je ftrack bid 455,70 dne.
Dlaždice ukazovala jen comp bid (232,45 dne). Má tam být celkový bid, ten je 455,7 dne.
Máš to přesně. Ověřeno v BigQuery: bid všech 1 403 tasků na DRV je 455,70 dne. Comp bid 232,45 dne je jeho podmnožina.
Dlaždice se jmenuje "Total bid (ftrack)" a ukazuje 455,70. Comp bid zůstal pod ní menším písmem, protože comp karty se dělí jím a musí být vidět čím.
Žádná.
Dlaždice ukazuje 225 shotů, tobě vychází 229. Pošlete mi, jaké shoty to počítá? Možná na to přijdu.
Záběrů na projektu je opravdu 229. Report ukazuje 225, protože nepočítá záběry — počítá COMP TASKY. A čtyři záběry žádný comp task nemají:
007_log_2110 007_log_2230 007_log_2540 007_log_2650
Všechny čtyři jsou v sekvenci 007_log a nemají na sobě VŮBEC ŽÁDNÝ task — ani comp, ani nic jiného. Jsou v ftracku založené a prázdné.
229 záběrů
– 225 s comp taskem
------------------
4 bez comp taskuSedí to na kus. Tvoje 229 je "kolik má projekt záběrů", naše 225 je "na kolika z nich se dá měřit práce". Obojí je pravda, jen to nejsou tytéž otázky. Ověřeno dvěma nezávislými funkcemi a dvěma různými dotazy.
Původně jsme měřili 253 záběrů a kvůli tomu to vypadalo nevysvětlitelně. To číslo bylo špatné: obsahovalo 24 věcí, které nejsou záběry (16 položek pod kamerou ARRI_MiniLF_camA, 6 pod sony_venice2_cam_f a 2 pod "tools").
Náš výpis "záběry bez comp tasku" totiž srovnával jabka s hruškama: tasky bral jen z větve "shots", ale záběry bral z celého projektu včetně kamer a nástrojů. Hlásil proto 28 záběrů bez comp tasku, správně jsou 4. Opravené — a právě tahle oprava tvých 229 vysvětlila.
Report umí vypsat "záběry bez comp tasku" jmenovitě, takže tyhle čtyři jsou vidět a dá se rozhodnout, co s nimi.
Když se comp začal brát podle ftrackového typu (bod 24), vyšlo nám najednou 226 různých záběrů s comp prací — o jeden víc, než kolik jich vůbec má nějaký task. To nemohlo být správně, tak jsme to dohledali.
Ten "záběr" navíc se jmenoval test. Není to záběr. Vzniklo to tím, že jsme záběr určovali podle POZICE v cestě: bralo se "co je v cestě druhé od konce". U jednoho comp tasku, který visí o úroveň hlouběji, tak vyšlo jméno jeho rodiče. Je to úplně stejná chyba jako ta s kamerami výš, jen na jiném místě.
Opravili jsme to tak, že se záběr už neodhaduje z cesty, ale bere se rodič toho tasku — a ten je ve ftracku buď záběr, nebo není. Žádné hádání.
Že to byla opravdu chyba a ne detail, je vidět na jiných typech: u plate ten starý způsob hlásil 541 "záběrů", přitom na skutečném záběru sedí 210 tasků.
Po opravě vychází 225 záběrů s comp prací, tedy přesně to, co je v tabulce výš, a bid zůstal na 235,20 MD — ty dva tasky, které to zametlo dovnitř, žádný bid nemají.
007_log_2110, 007_log_2230, 007_log_2540 a 007_log_2650 nemají v ftracku žádný task. Mají se zadat, nebo z projektu zmizet? Podle toho bude report ukazovat 225 nebo 229 a nebude to už vypadat jako nesrovnalost.
Nechápeš, co ta dlaždice říká. Comp je vždycky hlavní department. Co to znamená, jak to na to přišlo a co znamená číslo 13?
Nepočítalo to tasky, počítalo to LIDI — kolik lidí má nejvíc svého času na compu. Těch 13 byl počet lidí, ne shotů ani tasků. Dnes by to bylo 16.
A ten "department" nebyl skutečný department. Odvozoval se z NÁZVU tasku odhadem, což je způsob, který jsme už v předchozím kole vyhodnotili jako nefunkční (kvůli němu se třeba 211 dmp tasků počítalo jako fx).
Máš pravdu, že to nedává užitečnou informaci.
Dlaždice je zrušená. A ze stejného důvodu jsme přepsali i graf "Compositors by project", který stál na tom samém odhadu — teď počítá lidi, kteří mají v hodinách skutečně pozici obsahující "Compositor".
Ten odhad z názvu tasku existuje jen proto, že skutečný typ tasku se z ftracku do BigQuery nepřenáší — je prázdný u 98,1 % tasků. Podrobně v sekci 35, bod B2.
Žádná.
Dlaždice ukazuje 23 artistů, tobě vychází 28. Pošlete mi, koho to počítá?
Počítáme jiný okruh lidí než ty, a to je celý rozdíl:
report = lidi, kteří na projektu zapsali čas v FTRACKU → 25 lidí,
z toho 19 artistů, 2 overhead, 4 bez pozice
ty = lidi, kteří na projektu zapsali hodiny v HODINÁCH → 39 lidíTy dva okruhy nejsou stejné a ani nemají být: v hodinách si čas zapíše i člověk, který v ftracku nemá žádný task.
Report umí jmenovitý výpis, kdo je v které skupině a PROČ — u každého je napsané, jestli o tom rozhodl jeho titul, jestli ho přeřadily tasky, nebo že mu chybí pozice. Dá se to porovnat člověk po člověku.
Dva lidi se vypisovali jako "je v ftracku i v hodinách", přitom v hodinách na tomhle projektu nemají nic: David Teichert a Arseniy Kozlov. Kdo by počítal lidi podle toho označení, dostal by 25 místo 23. Opravené.
Číslo "worked z ftracku" (477,8 dne) NENÍ cena projektu. V hodinách je na DRV 820,26 dne, a 173,88 dne z toho patří 16 lidem, kteří v ftracku nemají ani jeden timelog (8 z nich overhead). Kdo si 477,8 přečte jako náklad, mine se o skoro 174 dnů. Je to teď napsané i v reportu.
Žádná.
"říká mi tohle něco? Jde vůbec zapnout dva projekty naráz? Podle mě jdou buď všechny nebo jeden ne? a nedává mi smysl, aby se tam zapínaly projekty dva. Bych dala úplně do pryč. Místo toho bych to tam maximálně jen někde napsala."
Máš pravdu ve všem. Dva projekty naráz zapnout NEJDE — filtr je buď "All projects", nebo právě jeden. Takže ta dlaždice mohla navždy ukazovat jen 1 nebo počet všech, což je jen jiné vyjádření toho, co je vidět ve filtru. Navíc naznačovala volbu, která neexistuje.
Minule jsme opravili jen tu větu s seznamem projektů a dlaždici tam nechali — spletli jsme si, ke kterému obrázku ten feedback patří. Teď je opravené obojí.
Žádná.
"proč to tak řeší ten comp? A píše 23 with comp shots? Comp má skoro každej projekt (99%) takže to je jednak určitě špatně a jednat o to vůbec nejde je? By mělo jen říkat kolik projektů je ve snapshotu a jestli tam jsou všechny data. Mě nejde jenom o komp, mě jde o všechno."
Máš pravdu dvakrát. To číslo bylo špatné A ptalo se na špatnou věc.
To číslo vyžadovalo, aby comp task ležel ve složce "shots". Kde tam neleží, projekt spadl na nulu, i když comp tasky má:
v0004_fnd 84 comp tasků → 0 pod "shots" v00110_jan 36 comp tasků → 0 pod "shots" v00082_pup 21 comp tasků → 1 pod "shots" v9999_ars 4 comp tasků → 0 pod "shots" a00025_lwss 1 comp task → 0 pod "shots"
Comp tasky má 28 z 38 projektů. Test "pod shots" projde jen 22. Takže "comp má skoro každý projekt" je pravda a naše číslo to nikdy neukázalo.
Mimochodem projektů je 38, ne 39 — mirror se mezitím pohnul.
Hlavička už nemluví o compu. Říká, kolik je projektů a CO JIM CHYBÍ, jak jsi chtěla. Změřeno, co komu chybí:
7 projektů nemá ani jeden task
v00124_eska · v00123_hon · a00026_moss · v00075_twb · v9997_dev · v9999_IT_TEST · C00620_maybelline
(v00137_bal má 1 task a 0 timelogů — jiná díra, tak ho nesčítáme k těmhle) 6 projektů má tasky, ale ani jeden s bidem
v00082_pup · v9999_ars · y77777_hslib · a00025_lwss · c00000_tmp · v00141_mnr
9 projektů není v hodinách — z toho DVA velké a reálné: v00032_wan (346 comp záběrů!) a v00052_vio (134)
Detailní rozpis je v reportu v sekci Data quality a ve funkci calc-c10-project-data-coverage, která u každého projektu napíše, co mu chybí.
Těch 9 projektů mimo hodiny — u v00032_wan a v00052_vio je to škoda, jsou to velké projekty a bez hodin u nich neumíme říct, co stály. Chybí v hodinách, nebo se tam jmenují jinak? To je otázka na produkci.
"compositor - tady by nemělo být napsané compositor ale artist"
Ten filtr nikdy nefiltroval compository — vypisuje všechny lidi na projektu. Nápověda pod ním to sama říkala ("26 people on these projects in total").
Přejmenováno na "Artist", výchozí volba na "All artists".
Žádná.
"comp out/ wk + final/ wk - co to prosím znamená?"
Comp out /wk = kolik RŮZNÝCH záběrů mělo za týden publikovanou novou verzi, tedy "kolik jsme toho za týden poslali"
Final /wk = kolik záběrů poprvé dosáhlo hotového stavu, tedy schválených
Jeden záběr se posílá několikrát, ale schválí se jednou, takže "schválené" je vždycky menší číslo než "poslané".
Sloupce se jmenují "Shots sent /wk" a "Shots approved /wk". Sloupce Speed taky — "Speed (sent)" a "Speed (approved)". A v textu karty je jednou větou napsané, co to je, aby se to nemuselo hledat v tooltipu.
Sedí ti ty nové názvy? Kdyby ti šly víc české, řekni — zbytek reportu je ale anglicky, tak jsme zůstali u angličtiny.
"remaining shots - není dobře. Na ftracku jim zůstaly viset 5 shotů, asi si nezměnily status. Tzn evaluace by měla říkat 5, ne 39. Dokážeš mi napsat jaké shoty to počítá?"
Máš pravdu, že 39 je špatně. Ale příčina je jiná, než si myslíš — a stojí za to ji vědět, protože ta tvoje by se opravovala jinak.
stav ve ftracku záběrů ftrack to vede jako ------------------------------------------------------ Uploaded on FTP 186 Done (hotové) Omitted 32 BLOCKED ← zrušené záběry! For Dailies 3 In Progress Completed 1 Done (hotové) Pending QC 1 In Progress Pending Lead Review 1 In Progress Retake (QC) 1 In Progress
39 = 32 ZRUŠENÝCH + 7. Ty "Omitted" jsou záběry vyhozené z projektu — ftrack je sám označuje jako Blocked, a 29 z těch 32 nikdy nemělo ani jednu verzi. Počítat je jako "zbývá udělat" je prostě chyba.
Druhá chyba: "Completed" je ve ftracku hotový stav, ale v našem ručně psaném seznamu hotových stavů chyběl.
Myslela jsi, že většina těch 39 je hotová a jen se nezměnil stav. Prověřili jsme to proti historii verzí: u 185 ze 186 hotových tasků souhlasí stav s poslední verzí, a jen JEDEN z těch 39 má zapomenutý stav. Stavy tasků a historie verzí souhlasí skoro dokonale. To číslo nenadouvaly zapomenuté stavy, nadouvaly ho zrušené záběry.
stav sekvence záběr bid spent verzí ----------------------------------------------------------------------- Completed 006_gfx 006_gfx_0020 0,5 0,04 2 For Dailies 001_ret 001_ret_0650 1,0 3,45 28 For Dailies 004_scr 004_scr_0190 1,0 6,93 43 For Dailies 004_scr 004_scr_0200 1,0 0,66 14 Pending Lead Review 004_scr 004_scr_1210 1,0 0,28 4 Pending QC 009_oth 009_oth_0430 2,0 3,67 33 Retake (QC) 004_scr 004_scr_1208 0,75 0,25 6
"Completed" je vlastně hotový, takže tehdy nám skutečně otevřených vyšlo ŠEST.
Po opravě definice compu (body 24 a 29) report ukazuje 5 otevřených záběrů, tedy tvoje číslo. Jenže když jsme si ověřili, KTERÉ to jsou, sedí čtyři z pěti:
záběr comp status dnes ty jsi ho měla --------------------------------------------------------------- 001_ret_0650 For Dailies ano 004_scr_0190 For Dailies ano 004_scr_0200 For Dailies ano 009_oth_0430 Pending QC ano 004_scr_1210 Pending Lead Review NE, tenhle jsi vynechávala --------------------------------------------------------------- 004_scr_1208 Completed → HOTOVÝ ano, ale už hotový není otevřený
Co se stalo: 004_scr_1208 se mezitím dodělal. Když jsi to počítala, byl na "Retake (QC)"; dnes je na "Completed". To není změna definice, to je skutečný postup na projektu.
A 004_scr_1210 opravdu otevřený je — jeho comp visí na "Pending Lead Review". Ty jsi ho vynechávala proto, že nikdy nebyl na FTP, ale to z něj hotový záběr nedělá, jen to znamená, že ještě nebyl odeslaný.
Takže: číslo 5 sedí, ale kdybys ty dva záběry porovnávala jmenovitě, nesedělo by to a vypadalo by to jako chyba. Není.
Ve ftracku je "Approved (QC)" vedený jako IN PROGRESS, ne jako hotový — QC schválení není odeslání, terminální stav je "Uploaded on FTP". Náš starý seznam ho ale za hotový počítal. Takže:
v00080_drv remaining 39 → 6 (tvůj bod) v00095_bdn 140 → 86 v0021_vsm 145 → 90 v00119_hnd2 126 → 121 v00052_vio 52 → 40 v00094_ff84 17 → 1 v00056_tpip 31 → 28 v0036_prs 11 → 1 v00061_mmt 10 → 0 v00073_sel 16 → 0 v00032_wan 340 → 344 ← STOUPNE o 4
Na v00032_wan bylo těch 6 "hotových" všechno Approved (QC), takže po opravě jsou zpátky mezi otevřenými.
Je pro tebe "Approved (QC)" hotový záběr, nebo ne? My teď věříme ftracku, že není. Když to má být jinak, je to jednořádková změna — ale chceme ji od tebe, ne od nás.
"text - compare with excel? Co to znamená? Můžeme ho smazat?"
Zbytek z fáze, kdy se report porovnával proti starému Excelu. Znamenalo to "tyhle datumy jsou z ftracku, takže se dají porovnat s ručně psanými datumy v Excelu". Dneska už to nikomu nic neříká.
Smazané — a nejen tam. Stejný typ odkazu na Excel byl v podtitulku ještě u čtyř dalších karet (Client retakes, Status partition, Weekly client flow, Shots over the bid). Všechny jsou pryč a místo nich je napsané, odkud data jsou. Mapování na listy Excelu zůstává v souboru assets/reports/RECONCILIACE_EXCEL_vs_BQ.md, takže se nic neztratilo. Automatický test teď hlídá, že se žádný takový podtitulek nevrátí.
Žádná.
"comp out (jestli to znamená kolik jsme poslaly compů týdně, tak za poslední 4 týdny to bylo takto: week od 6.7. - 3 shoty, week od 29.6. - 0 shotů, week od 22.6. - 37 shotů, week od 15.6. - 21 shotů → takže za poslední 4 týdny mi vychází avarage jako 15,25"
Ano, znamená to přesně to, co si myslíš. A mýlíme se oba — každý jinak.
(různé comp záběry s publikovanou verzí, týdny od pondělí)
6.4. 24 4.5. 53 1.6. 107 29.6. 21 13.4. 39 11.5. 82 8.6. 54 6.7. 1 20.4. 49 18.5. 90 15.6. 28 13.7. 4 27.4. 49 25.5. 99 22.6. 38 20.7. 1
týden ty měřeno 15.6. 21 28 22.6. 37 38 29.6. 0 21 ← tady je ta chyba 6.7. 3 1 průměr 15,25 22,0
Ten týden od 29. 6. nebyl nulový — publikovalo se 21 různých záběrů ve 70 verzích. Zkusili jsme tvoje čísla reprodukovat i jinými způsoby (týdny od neděle, jen první publikace, jen odeslání na FTP) a ani jeden nedává 21/37/0/3. Vypadá to na ruční evidenci odeslání, ne na něco, co jde z ftracku spočítat.
Naše 6,75 je průměr posledních čtyř bodů série: 21 + 1 + 4 + 1 = 27 ÷ 4. Ale projekt měl deadline 1. 7. 2026, takže TŘI ZE ČTYŘ těch týdnů jsou už po konci projektu. Průměrovali jsme dojezd a říkali tomu tempo projektu.
Okno pro "skutečně dosažené tempo" nesmí přesahovat konec projektu:
· deadline je v budoucnosti → poslední 4 týdny do dneška (jako dřív) · deadline už proběhl → poslední 4 týdny PŘED deadlinem
Na DRV to jsou týdny 8.6., 15.6., 22.6., 29.6. → 54 + 28 + 38 + 21 = 141, tedy 35,25 záběru za týden. To je tempo, které se opravdu jelo.
Vybrali jsme tuhle variantu proto, že ostatní dvě odpovídají na otázku, kterou nikdo neklade. "Posledních 4 kalendářních týdnů včetně nulových" by na DRV dalo 1,5 — pravdivé, ale říká jen, že se na projektu už nepracuje. "Průměr za celý projekt" by dal 43,1 — stabilní, ale nereaguje na to, že tempo v čase klesá. Tohle odpovídá na "jak rychle jsme to opravdu dělali".
A hlavně: karta teď VYPISUJE, které týdny průměruje a kolik v každém bylo, přímo pod tím číslem. Spolu s bodem 18 (datumy na ose) si to můžeš ověřit sama a rovnou uvidíš, že ten týden od 29. 6. nulový nebyl.
Ta tvoje ruční evidence odeslání by nás zajímala — když ti vyšlo 0 tam, kde ftrack vidí 21 záběrů, možná se "odeslané klientovi" a "publikovaná verze" liší víc, než si myslíme. Kdybys tu evidenci měla, rádi bychom ji porovnali.
"na drivu se posílal hlavně comp, každopádně posílat se můžou i animace nebo fx_slapcompy. Ve chvíli kdy nějaký projekt bude mít ve workflow tyto approval steps, tak se reporting automaticky aktualizuje a bude ukazovat i jiné departmenty?"
Neukazoval by je. A hlavně: ono se to už dávno děje a report to neukazoval.
typ tasku tasků s verzí verzí projektů ----------------------------------------------- comp 2 339 27 177 26 fx 388 6 255 20 plate 5 407 5 969 24 lighting 967 5 819 21 slapcomp 1 111 5 199 14 animation 271 1 086 15
Non-comp je 61,3 % všeho publikovaného. A "fx_slapcomp" existuje doslova jako jméno tasku — 155 tasků typu slapcomp, plus varianty jako fx_explosion_slapcomp.
Důvod byl ten, že všechna čísla stála na taskech POJMENOVANÝCH "comp".
Karty Deadline pace a Progress over time mají teď přepínač typu tasku a výchozí stav je "every task type". Nic už není vázané na jméno "comp", takže odpověď na tvou otázku je ANO — nový approval step na animaci nebo fx se objeví sám, bez zásahu do reportu.
Jedna věc zůstává comp-only a je to napsané na kartě: "Shots approved /wk". Historii "kdy záběr poprvé dosáhl hotového stavu" dnes staví jen pro comp, tak u ostatních typů radši ukážeme pomlčku, než abychom si číslo vymysleli.
Chceš tu historii schválení dopočítat i pro ostatní typy? Jde to, ale je to vlastní práce — a chceme vědět, jestli to potřebuješ, než ji uděláme.
"tady určitě na osu z přidejte nějaké data. né jenom čísla týdnů, ale já potřebuju vědět od kdy, tzn jesti 15týden týden začíná 1.7. nebo kdy. To se bude i blbě kontrolovat, ale zkusím. EDIT: jo ono se to objeví když na to najedu. prosím dejte to na osu x. To bude mnohem lepší pro visuální hodnocení projektu."
Osa měla popisky 1, 2, 3… a datum se ukazovalo jen po najetí myší. Přesně jak píšeš.
Na ose jsou datumy začátků týdnů (15.6., 22.6., …). Navíc jsme to poskládali tak, aby to fungovalo i při víc projektech naráz: každý bod se umisťuje podle svého datumu, ne podle pořadí v řadě. Předtím se dvě řady, které nezačínají stejným týdnem, proti sobě posouvaly.
Automatický test teď hlídá, že se osa nevrátí k číslům.
Žádná.
"týden 15 sedí, týden 14 sedí, týden 13 sedí, týden 12 nesedí - mě vychází 18, týden 11 nesedí - mě vychází 16 (víc jich kontrolovat nebudu). Může mi vyjet jaký shoty do toho počítá?"
Ty čísla týdnů na ose jsou samy ten problém. "Týden 11" neznamená nic mimo ten jeden graf: je to jen pořadí bodu v řadě, a když se přidají data, celé se to přečísluje. Tvoje kontrola tedy nemohla dopadnout jinak.
Přesně tohle jsi psala v bodu 18 minulého kola a JE TO UŽ OPRAVENÉ — osa nese datumy začátků týdnů. Ty screenshoty jsou ze starší verze stránky, viz poznámka o čerstvé kopii na začátku sekce 33.
(různé záběry / všechny publishe, comp, měřeno 19. 8. po dnešním syncu)
6.4. 25/63 11.5. 83/242 15.6. 34/109 13.7. 4/5 13.4. 42/117 18.5. 93/295 22.6. 38/228 20.7. 1/4 20.4. 51/131 25.5. 101/295 29.6. 21/70 10.8. 5/11 27.4. 51/118 1.6. 107/524 6.7. 1/3
Tvoje 16 a 18 nesedí na žádný z těch týdnů ani v jedné definici. Nechceme hádat, čím to je — proto ten seznam níž.
Vyjede ti to jmenovitě. Nová funkce vrací za každý týden seznam záběrů, které se ten týden publikovaly, kolik měly verzí a kolik z nich šlo klientovi. Dá se to diffnout řádek po řádku s tím, co máš ty.
Až ten seznam projdeš u týdnů 15.6. a 22.6., dej vědět, které záběry ti tam přebývají nebo chybí. Tipujeme, že počítáš odeslání klientovi, ne všechny publishe — u týdne 22.6. je 38 různých záběrů publikovaných, ale jen 25 z nich šlo ten týden klientovi. To by tvým číslům bylo blíž.
"tady by bylo dobrý udělat nějaký přepínátko a mít možnost přepnout z unikátních shotů na všechny publishe. To nám dá rychle informaci o tom jak moc se interně retakuje a kde je bottleneck."
Na DRV v týdnu od 1. 6.: 107 různých záběrů, ale 524 publikovaných verzí. To je 4,9 verze na záběr. Přesně to, co chceš vidět.
Celý projekt: 225 různých comp záběrů, 2 393 verzí.
Graf "Progress over time" má druhé přepínátko: unikátní záběry / všechny publishe. Unikátní měří postup, publishe měří odvedenou práci, a poměr mezi nimi je ta míra interního retakování.
Jedna poznámka: pro "všechny typy tasků" to přepínátko nejde, protože sečíst verze přes typy by dvakrát počítalo záběr, který v jednom týdnu publikoval comp i fx. Karta v tom případě řekne, ať si vybereš jeden typ.
Žádná.
"je to opět jenom o compu. Mohlo by tady být i přepínátko případně vidět to samé i pro mm, fx, animaci a případně další departmenty?"
Už tam je — přidali jsme ho v minulém kole, jen to na tvé verzi stránky není vidět. Graf má přepínátko na typ tasku a výchozí stav je "every task type".
Na DRV má vedle compu vlastní řadu i plate (231 záběrů), refs (224), mograph (138), dmp, lighting, matchmove, previs, roto, zero, cleanup, lookdev, fx a layout. Tedy třináct typů, ne jeden.
Žádná — jen si prosím vezmi čerstvou kopii reportu.
"tady mi taky dejte nahoru čísílko"
Čísla jsou nad bary. A protože jsi to samé chtěla i u jiného grafu (bod 28), udělali jsme to jednou pro všechny sloupcové grafy v reportu, ne po kartách — takže to platí i tam, kde jsi to nežádala.
Nekreslí se to jen ve dvou případech, a je to schválně: když je kategorií víc než 24 (čísla by se překrývala a to je horší než tooltip) a u skládaných grafů (číslo by leželo na cizím segmentu).
Žádná.
"bere to vpotaz opět jenom komp. Mohly bychom přidat přepínátko, aby to vidělo buď všechno a nebo jednotlivý departmenty?"
Karta má přepínátko na typ tasku. Výchozí je celý projekt, dá se přepnout na jeden department. Souvisí to s bodem 25 — viz níž, tam byl větší problém.
Žádná.
"bid compu každopádně nesedí, na ftracku je 235,2 MD ne 232,45 MD"
Počítali jsme comp podle JMÉNA tasku, ty podle ftrackového TYPU:
definice tasků záběrů bid spent ------------------------------------------------------------------- jméno "comp" pod větví shots 225 225 232,45 313,79 ftrack TYP comp pod větví shots 255 225 235,20 328,66 <- tvoje
Tvých 235,2 je bid tasků, kterým ftrack říká "comp", na desetinu. Rozdíl 2,75 dne dělají comp tasky, které se nejmenují přesně "comp" — precomp a podobně. Tasků je jich víc (255 proti 225), ale záběrů zůstává 225: některé záběry mají víc než jeden comp krok. Kvůli tomu jsme skoro poslali špatná čísla u retaků, viz bod 29.
Report bere comp podle ftrackového typu. Je to správnější: typ je to, co ve ftracku ten task doopravdy je, kdežto jméno si každý píše, jak chce.
comp bid 232,45 → 235,20 comp spent 313,79 → 328,66 comp tasků 225 → 255 comp záběrů 225 → 225 (nemění se — typ přidává tasky, ne záběry) týdenní série o 0–6 záběrů výš u některých týdnů
Stará definice zůstává v datech jako kontrolní hodnota, takže se to dá kdykoli porovnat a doložit, že se pohnulo jen tohle a nic jiného.
Žádná, ale kdyby ti někde vyšlo číslo podle jména, tohle je vysvětlení.
Když sis na téhle kartě vybrala konkrétní typ tasku, sloupec "Worked" byl vždycky nula. Ne malý — nula, u všech projektů. Sahali jsme v datech po políčku, které se tam jmenuje jinak, takže se nenašlo nic a sečetla se nula. Bid vedle toho byl správně, takže to vypadalo, že se na tom typu nic neodpracovalo. Opraveno; teď se sečte to, co tam skutečně je.
"worked to každopádně bere úplně od všech departmentů. To by se mělo stejně jako bid rozdělit. Buď porovnáváme bid/spent všeho nebo jenom jednotlivých departmentů."
Máš úplně pravdu a byla to naše chyba, ne nedorozumění. Ten graf srovnával comp bid (232,45) proti worked všech departmentů (470). Z toho vypadá, že je projekt dvakrát přes, a to není pravda.
Oba pruhy teď popisují stejný rozsah, a je to celý smysl toho přepínátka:
· celý projekt → bid 455,70 proti worked 480,16 · jeden typ → bid a worked jen toho typu
Nic už nemíchá comp v čitateli s celým studiem ve jmenovateli. Automatický test to hlídá, aby se to nemohlo vrátit.
Žádná.
"nesedí. Mělo bych jich být 16. Koho to prosím počítá?"
Lidi, kteří mají v hodinách pozici obsahující "compositor":
Adam Greguš · Daria Naumova · Filip Matlák · Ivan Grozev · Jakub Szilvasi · Julian Grumer · Martin Demovič · Matej Šulek · Paloma Melis · Patrik Szekacs · Peter Knazik · Peter Zakharzhevskiy · Petr Hastik · Timea Michalčíková · Tomáš Snížek (Lead Compositor)
A ČTYŘI DALŠÍ zařadit nejdou — přitom všichni dělali comp:
člověk odpracováno z toho comp proč nejde zařadit -------------------------------------------------------------------- Wesam Moussa 32,0 d 31,2 d v hodinách je, chybí pozice Silvia Rákociová 17,7 d 8,3 d v hodinách je, chybí pozice David Teichert 0,8 d 0,8 d v hodinách je, chybí pozice Arseniy Kozlov 0,1 d 0,1 d v hodinách NENÍ vůbec
15 + Wesam Moussa = 16. To je tvoje číslo. Wesam Moussa má 31 z 32 dnů na compu, takže je to zjevně compositor — jen mu v hodinách chybí pozice. Není to chyba v počítání, jsou to čtyři chybějící záznamy.
A ještě: to 13, které vidíš na screenshotu, už neplatí ani u nás. Karta dnes ukazuje 15. Screenshot je ze starší verze stránky, viz úvod souboru.
Karta teď pod grafem sama napíše, kolik lidí nejde zařadit a kdo to je — takže příště nebudeš muset hádat, proč je číslo nižší, než čekáš.
První verze téhle odpovědi tvrdila 13 lidí a že tři z nich v hodinách nejsou vůbec. Bylo to špatně a chyba byla naše: měřili jsme to jednorázovým dotazem, který lidi páruje jen podle e-mailu a jména, kdežto report je páruje i podle uživatelského jména — a tím Petera Knazika a Jakuba Szilvasiho v hodinách najde, oba s pozicí Compositor. Správně je tedy 15, a mimo hodiny je jediný člověk.
Třem lidem stačí v hodinách doplnit pozici: Wesam Moussa (32 dnů!), Silvia Rákociová, David Teichert. Jeden člověk v hodinách není vůbec a je potřeba ho založit: Arseniy Kozlov (0,1 dne, takže drobnost).
"prosím opět přidat tlačítka na změnu departmentů. bylo by sem dobrý přidat i overhead pozice, abychom mohli snadno vidět kolik tam pracovalo produkčních apod. Overhead pozice dejte klidně do jednoho departmentu nazvaného overhead."
Karta se přejmenovala z "Compositors by project" na "People by department" a má přepínátko se třemi druhy volby:
· konkrétní typ tasku → kolik lidí na něm doopravdy pracovalo · overhead → kolik produkčních, supervizorů a back office · everyone → kdo si na projekt zapsal jakýkoli čas
Jedna věc k tomu, protože je to rozdíl: u typů tasků počítáme lidi podle PRÁCE, ne podle titulu. Kdo strávil týden na roto, je v roto — i když má v hodinách napsáno Compositor. U overhead to jinak než podle titulu nejde, takže tam se bere titul.
Žádná.
"compositors by project - prosím přidejte čísílko nahoru na ten bar taky. Ať na to nemusí nikdo najíždět a rovnou to vidí."
Hotovo, a jak píšeme v bodu 22, udělali jsme to pro všechny sloupcové grafy naráz.
Žádná.
"client retakes - client saw at leadt once. Nepotřebujeme vědět. já potřebuju vědět kolik shotů má jenom jeden retake. Suma všech 5 buckets by měla být rovná celkovému počtu shotů v projektu."
Ty buckety byly postavené špatně. "Not yet sent" a "client saw at least once" byly dvojice, která se dělila na celek, a "2", "3", "4+" byly PODMNOŽINY toho druhého — takže těch pět schválně sečetlo víc, než měl projekt záběrů. A na otázku "kolik má právě jeden retake" se z toho nedalo odpovědět vůbec.
Pět bucketů je teď počet retaků: 0 / 1 / 2 / 3 / 4+, takže se dělí na celek. Na DRV:
0 retaků 150 1 retake 35 ← to, co jsi chtěla 2 retaky 24 3 retaky 12 4+ retaků 4 --------------- celkem 225 = počet comp ZÁBĚRŮ
Tabulka ten součet vypisuje jako kontrolu a když nebude vycházet, napíše že je to chyba, ne zaokrouhlení.
První verze téhle odpovědi tvrdila 180 / 39 / 22 / 12 / 4 = 257. Ten součet vycházel, ale nebyl to počet záběrů, byl to počet comp tasků.
Jak k tomu došlo: v bodu 24 jsi měla pravdu, že comp se má brát podle ftrackového TYPU, ne podle jména tasku — jinak nevyjde bid 235,2 MD. Jenže když se comp bere podle typu, může mít jeden záběr comp tasků víc (comp a k tomu precomp). Na DRV je to 255 tasků na 225 různých záběrech. Dokud se comp poznával podle jména, měl každý záběr nejvýš jeden takový task a "počet tasků" a "počet záběrů" bylo totéž číslo — takže všechny nápisy "shots" byly pravdivé jen shodou okolností. Po přechodu na typ přestaly být, a část záběrů se počítala dvakrát.
A při opravě jsme narazili na druhou, starší chybu: záběr se určoval podle POZICE v cestě, ne podle toho, na čem task ve ftracku opravdu visí. To je popsané v bodu 7 a je to taky opravené.
Tohle je zároveň odpověď na tvůj bod 32 ("nesedí total count shotů"). Sedělo to na počet tasků. Teď to sedí na počet záběrů.
Opravené je to tak, že se retaky nejdřív sečtou po záběru (kolikrát se ten záběr vrátil, přes všechny své comp kroky) a teprve pak se zařadí do bucketu.
Přidali jsme si na to i automatickou kontrolu, aby to znovu neproteklo: report po každém přepočtu sám ověří, že pět bucketů dá počet záběrů.
Na kartě je teď navíc napsané, kolik comp TASKŮ na těch záběrech sedí (255), ať se to nedá splést s počtem záběrů.
2 retaky: 22 → 24. Podrobně v bodu 32, včetně otázky, kterou to otevírá.
Viz bod 32 — je tam jedna otázka na definici, na kterou potřebujeme tvoje rozhodnutí.
"client retakes - smaže ten text za tím nadpised excel sheet "Retakes""
Už je smazaný — v minulém kole, spolu se stejným odkazem na Excel u dalších čtyř karet. Na tvé verzi stránky to ještě je.
Žádná.
"co to počítá? píše to že counted in shots, my ale retaky porovnáváme taky po departmentech. Respektive všech krocích které se s klientem schvalují. tzn by dáválo smysl přepínátko."
Záběry, ne události. Jeden záběr, který se vrátil třikrát, je JEDEN záběr ve bucketu "3 retaky" — ne tři. Retake se pozná z historie stavů verzí: přechod do stavu, který obsahuje "Retake" a "Client".
Karta má přepínátko na typ tasku. A je to zajímavější, než jsme čekali — na DRV:
typ tasků ZÁBĚRŮ 0 ret. 1 2 3 4+ -------------------------------------------------------- comp 255 225 150 35 24 12 4 refs 224 224 224 0 0 0 0 plate 210 209 209 0 0 0 0 matchmove 62 62 62 0 0 0 0 mograph 43 43 21 6 6 3 7 ← nejvíc 4+ na projektu dmp 34 29 23 2 3 1 0 lighting 33 26 22 4 0 0 0 cleanup 29 29 28 1 0 0 0 fx 24 24 24 0 0 0 0 roto 24 24 24 0 0 0 0 zero 24 24 24 0 0 0 0 layout 15 15 15 0 0 0 0 previs 9 9 6 3 0 0 0 art 3 1 1 0 0 0 0
Každý řádek sečte na svůj počet záběrů — 150+35+24+12+4 = 225 u compu, 21+6+6+3+7 = 43 u mographu, a tak dál.
Mograph má víc záběrů se 4+ retaky než comp (7 proti 4), a to by z comp-only pohledu nikdo nikdy neviděl.
Sloupce "tasků" a "ZÁBĚRŮ" jsou tam schválně oba: u některých typů je mezi nimi velký rozdíl (plate 210 tasků na 209 záběrech, art 3 na 1) a bez toho by nebylo poznat, které z těch dvou čísel se komu porovnává s ftrackem.
Žádná.
"nesedí total ccount shotů, ale ani retaky. 4+ vidím 3x, 3 a 2 retakes sedí"
Total: nesedělo, protože jsme počítali comp TASKY a psali k tomu "shots". Správně je 225 záběrů (a 255 comp tasků na nich), ne 257. Celé vysvětlení je v bodu 29, protože se to našlo při jeho opravě.
4+ retaků: nám vychází 4 — dva záběry mají čtyři retaky a dva mají pět. Ty vidíš 3. Tady si pořád myslíme, že máme pravdu my, viz otázka níž.
3 retaky: 12, sedí.
Tohle je jediné číslo z tvého feedbacku, které ti sedělo a po naší opravě sedět přestalo, takže ho nechceme nechat bez vysvětlení.
Příčina je ta samá definice comp z bodu 24. Tvoje 22 vychází, když se comp poznává podle jména tasku — a tak to report počítal, když jsi ho viděla. Když se comp začne poznávat podle ftrackového typu, což jsi chtěla (a bez toho nevyjde bid 235,2 MD), přiberou se k záběru i precomp kroky. A dva záběry mají jeden klientský retake na compu a jeden na precompu. Sečteno po záběru z toho jsou dva retaky, ne dva záběry s jedním.
Obě definice na tom samém projektu:
definice comp záběrů 0 ret. 1 2 3 4+ --------------------------------------------------------- podle JMÉNA tasku 225 152 35 22 12 4 ← tvých 22 podle ftrack TYPU 225 150 35 24 12 4 ← bid 235,2 MD
Obě definice dávají 225 záběrů. Rozdíl je jen v tom, kolik retaků se k záběru přičte, protože podle typu se počítají i precomp kroky.
Ty dvě definice nejdou mít obě naráz. Podle typu ti vyjde bid, který jsi chtěla (235,2 MD), ale retaky se posunou o dva záběry. Podle jména ti vyjdou retaky, ale bid je 232,45 MD.
My jsme zvolili podle typu, protože jsi to tak výslovně chtěla u bidu a protože precomp je opravdu comp práce. Ale je to tvoje volba:
Napiš prosím, kterou chceš. Umíme kteroukoli, přepnutí je na náš straně jedna změna.
Ty čtyři záběry si teď rozklikneš přímo v grafu (viz bod 35). Podívej se prosím, jestli ten čtvrtý u tebe nespadl jinam — může to být záběr, který se vrátil čtyřikrát, ale poslední kolo bylo interní, ne od klienta. Podle toho upravíme definici.
Když jsme v minulém kole předělali ty buckety tak, aby se sčítaly na počet záběrů (o to jsi žádala), zapomněli jsme přepsat vysvětlující větu pod grafem. Ta pořád popisovala starou verzi, kde se buckety překrývaly. Výsledek: karta psala "prvních pět sloupců by se mělo rovnat 225 a nerovná se, nahlaste to prosím" — a přitom se rovnalo. Takže to vypadalo, že je report rozbitý, a nebyl. Věta je přepsaná na kontrolu, která dnes platí: všech pět sloupců dohromady = počet comp záběrů.
Je to ta samá chyba jako u totalu výš: legenda říkala "záběrů aspoň s jedním", ale sčítaly se comp TASKY, takže záběr s compem i precompem se počítal dvakrát. Na v00080_drv se to hne takhle:
zdroj retaku bylo je rozdíl ------------------------------------------ Client 77 75 -2 Lead 162 149 -13 Sup 124 108 -16 QC 180 180 0 Director 3 3 0
Druhý sloupec grafu (celkový počet retake verzí) se nemění — ten se sčítá, takže je jedno, jestli po taskách nebo po záběrech.
nahoru"to že má nějaký comp 0 retakes neznamená že ho klient neviděl. Mohl ho taky rovnou schválit. Takže tahle část by měla brát i v potaz jesti shot byl poslaný a jaký má status, než řekne že ho nikdo neviděl."
Máš pravdu a bylo to vyloženě zavádějící. Ten bucket se jmenoval "not yet sent to client" a spadl do něj každý záběr bez retaku, který zároveň nebyl v jednom ze tří finálních stavů. Takže záběr, který klient schválil na první dobrou, se hlásil jako neposlaný.
Jinými slovy: ze 150 záběrů s nulou retaků jich 116 klient viděl a schválil. Tvrdit u nich "neposláno" bylo špatně u tří ze čtyř.
Žádná.
Tyhle dvě se nevážou k žádnému tvému bodu, ale mohly zmást při kontrole, tak ať o nich víš.
U dvou největších projektů tvrdila, že součty nesedí. Nesedělo to o 0,05 dne a byla to jen zaokrouhlovací chyba: sečteme 55 (resp. 72) zaokrouhlených čísel a porovnáme je s jedním zaokrouhleným součtem, kde nejhorší možná odchylka je 0,275 (resp. 0,360). Tolerance teď roste s počtem řádků.
Report skládá data ze seznamu, do kterého se nová pole musí taky dopsat — a to jsme napoprvé neudělali. Funkce se nasadila i proběhla čistě, jen ta pole v datech nebyla.
Obojí je opravené a obojí teď hlídá automatický test.
Žádná.
Doteď graf řekl číslo a tím to skončilo. Když ti nesedělo, nemělas kam kliknout — musela jsi napsat nám a my jsme se šli podívat do databáze. Většina bodů v tomhle souboru je přesně tohle: spor o číslo, na který jsi neměla jak odpovědět sama.
Teď se dá kliknout na každý sloupec a na každý bod v každém grafu, a vyskočí malé okno s křížkem, ve kterém je jmenovitě to, co je v tom JEDNOM sloupci — ne v celém grafu.
Příklad, u kterého to začalo: v grafu Client retakes klikneš na sloupec "1 client retake" a dostaneš seznam těch 35 záběrů — číslo záběru, sekvence, kolikrát se vrátil, stav, kdo ho dělal, bid a odpracováno.
* Kontrolní řádek. Nahoře je napsané "sedí: 35 vypsáno = 35 v grafu". Když by to nesedělo, okno to napíše místo aby ti tiše ukázalo jiný seznam. To je celý smysl — seznam, který si protiřečí s grafem, ze kterého vyskočil, je horší než žádný. * Jak se to počítá, rozklikávací, stejný text jako u ikonky ⓘ. * U dlouhých seznamů "ukazuji prvních 250 z 1 340" — nikdy tiše useknuté.
Client retakes ....... záběry v tom bucketu, jmenovitě Retakes by source .... záběry, které se vrátily od klienta / leada / supa / QC Status partition ..... záběry v té části, s přesným ftrack stavem Status mix ........... rozpad podle projektu a typu tasku Progress over time ... záběry publikované ten týden, s počtem verzí Weekly client flow ... záběry, které ten týden šly ke klientovi / byly schválené Effort by project .... rozpad projektu po typech tasku
Bid vs worked by type rozpad typu po projektech
Per sequence ......... záběry v té sekvenci Shots over the bid ... celý detail toho jednoho záběru People by department . jmenovitě ti lidé a proč se počítají Bid vs worked/person . záběry, které ten člověk má přidělené Efficiency ........... obě čísla, ze kterých ten poměr vzniká Weeks to finish ...... celý výpočet s dosazenými čísly, ne jen výsledek
U bucketu "no client retake" okno navíc rovnou píše, kolik z těch záběrů reálně šlo na FTP a ke klientovi — to je tvůj bod 33, aby se "0 retaků" nečetlo jako "klient to neviděl".
U křivky Progress over time ve výchozím nastavení ("all task types") okno žádný seznam nedá. Ta křivka nepočítá záběry, ale úkoly napříč vším — a úkol, který nesedí na záběru, žádné jméno záběru nemá. Okno to napíše a poradí přepnout na konkrétní typ, kde už seznam je. Vymýšlet tam jména by znamenalo ukázat ti seznam, který neodpovídá té čáře.
Report je nově i na adrese, kterou si můžeš otevřít odkudkoli, bez posílání souboru: https://pfx-project-reports.pages.dev Tím padá i to, co nás stálo tři body v minulém kole — že jsi hlásila věci, které už byly dávno opravené, protože jsi měla starou kopii souboru.
nahoruco se po nás chce, ale nemáme z čeho spočítat
Tohle jsou věci, které report SÁM VYŘEŠIT NEMŮŽE, protože ta data v BigQuery nejsou. U každé je napsané, u kterého bodu to potřebujeme, proč, proč to tam není, co děláme místo toho, a co by se muselo stát.
Všechno níž je změřené 19. 8. 2026, ne odhadnuté.
BLOKOVANÉ — chybí v pipeline · potřeba u bodů 2, 3, 9
U člověka umět napsat department slovem ("Compositing"), ne číslem.
Ty se na roli koukáš přes department, report čte pozici. Kdyby report umel department pojmenovat, šlo by u těch čtyř lidí bez pozice aspoň napsat, do jakého departmentu patří, a rovnou by bylo vidět, komu to poslat k doplnění.
V datasetu "hodiny" je 16 tabulek a ŽÁDNÁ z nich nedrží názvy departmentů. Je tam jen spojovací tabulka working_hours_department_users s číselným department_id (22 různých hodnot). Tabulka s názvy se do BigQuery nemirroruje.
Report napíše "pozice nevyplněná" a číslo departmentu.
Doplnit do mirroru tabulku s názvy departmentů. Je to úprava datové pipeline, ne reportu.
Bereme je z HODIN, ne z BigQuery. V hodinách ty názvy máme u sebe, takže se na pipeline nečeká — dotáhne se to odtud.
OBCHVAT FUNGUJE · potřeba u bodu 8
U každého tasku vědět, jakého je typu (comp / dmp / matchmove / roto…).
Bez toho nejde odpovědět na otázku "jak je na tom dmp" nebo "kolik zbývá matchmove". A je to důvod, proč dlaždice z bodu 8 vůbec vznikla — odvozovala department odhadem z názvu tasku.
Sloupec typedcontext.type_name je PRÁZDNÝ u 22 826 z 23 275 tasků, tedy u 98,1 %. Změřeno 19. 8. 2026.
Typ dohledáváme přes číselník (tabulka "type", 52 řádků) — to funguje a report na tom dnes stojí. Ten starý odhad z názvu tasku je zrušený.
Nic nutného — máme funkční obchvat. Ale dokud je type_name prázdný, každý, kdo se na ten sloupec podívá, dostane nesmysl. Stálo by za to ho doplnit nebo z mirroru vyhodit, ať nemate.
Potřebujeme doplnit z ftracku do BigQuery. Bez toho zůstává jen ta objížďka přes lookup tabulku.
NELZE — data neexistují · potřeba u bodu 3
Umět rozdělit hodiny z hodin podle typu práce (kolik hodin šlo na comp, kolik na fx…).
Hodiny jsou jediný zdroj, který vidí i práci, co nepřistála na tasku, takže peníze se dělí jimi. Rozpad po typech by řekl, kam ty peníze šly.
Tabulka working_hours_whrecord má granularitu artist × projekt × budget. ŽÁDNÝ odkaz na task tam není. Ta informace v systému hodin neexistuje, takže ji nedostaneme ani lepším dotazem, ani doplněním mirroru.
Místo "hodiny po typu tasku" je v reportu panel HODINY PO POZICI (Compositor 637,48 d / 26 lidí, 3D Generalist 123,85 / 4, …). U karty je napsané, že to NENÍ totéž jako typ tasku, a proč.
Změna v samotném systému hodin — u zápisu hodin by musel jít vybrat task nebo aspoň typ práce. To je rozhodnutí o nástroji, ne o reportu.
Dopočítá to funkce. Do hodin se ten odkaz na task dostávat nebude.
VYŘEŠENO ručním zápisem · potřeba u bodů 5, 6
Celkový bid, na který byl projekt prodaný.
Spálenost se počítá proti bidu. Když je v ftracku jen část bidu, procento vyjde vyšší, než jaká je pravda.
Protože to není v ftracku. Nejsou tam všechny tasky a u některých není bid. Žádný dotaz nad mirrorem to nedokáže dopočítat — ta informace tam prostě není.
Zapisuje se ručně v záložce Breakdown (viz bod 5) a report ukazuje ftrack bid, master bid a rozdíl vedle sebe.
Buď se bidy doplní do ftracku, nebo zůstane ruční zápis. Ruční zápis je funkční řešení, ne provizorium.
Spočítá to funkce breakdown, dohromady a společně s ftrackem — tedy jeden výsledek z obou zdrojů, ne dvě čísla vedle sebe.
ČEKÁ NA PRODUKCI · potřeba u bodů 2, 3, 9
Vyplněnou pracovní pozici v hodinách u Wesama Moussy, Silvie Rákociové, Davida Teicherta a Arseniyho Kozlova.
Bez ní report neumí zařadit 50,6 dne práce na DRV. Je to jediná věc, která v bodu 3 ještě dělá rozdíl proti tvému číslu.
Tři z nich mají v hodinách vyplněný department, ale prázdnou pozici. Čtvrtý (Arseniy Kozlov) v hodinách není vůbec. Napříč studiem má department a nemá pozici 69 lidí.
Report je vypisuje jmenovitě jako "chybí pozice" a nikoho nevynechává ze součtů — jen je nezařadí. Schválně to nedopočítáváme (viz bod 3).
Doplnit pozici v hodinách u tří lidí, u jednoho založit záznam. Tím se to vyřeší samo, bez zásahu do reportu.
Řeší se v HODINÁCH — tam se ty pozice doplní.
ČEKÁ NA PRODUKCI · potřeba u bodu 3
Aby se každý ftrack projekt našel i v hodinách.
Spálenost se počítá jen za projekty, kde známe obě strany. U nespárovaných neumíme říct, co stály — a u "All projects" to systematicky snižuje procento.
Z 38 ftrack projektů se do hodin páruje 29. Nepáruje se 9, a čtyři z nich jsou reálné projekty:
v00032_wan ← 346 comp shotů, druhý největší projekt ve snapshotu v00052_vio v00082_pup v00123_hon
Zbytek je testovací (v9997_dev, v9999_IT_TEST, v9999_ars, c00000_tmp, y77777_hslib). Páruje se na název, takže u těch čtyř je projekt v hodinách buď založený jinak pojmenovaný, nebo tam není.
Karta spálenosti počítá jen ze spárovaných projektů a VYPISUJE, které vypadly a kolik bidu to představuje — aby nebylo vidět jen výsledné procento.
Dotaz na produkci: chybí ty čtyři projekty v hodinách, nebo se tam jmenují jinak?
Dát přístup Ondřejovi a udělat JEDEN JEDINÝ jednorázový sync do BigQuery ze starého ftracku. Není to nic, co by muselo běžet dál.
OBCHVAT FUNGUJE · potřeba u bodu 2
Roli člověka přímo z ftracku, ať se nemusí párovat dva systémy.
Párování ftrack ↔ hodiny podle jména a e-mailu je zdroj chyb — kdo se nespáruje, vypadne z rozdělení na artisty a overhead.
ftrack pracovní pozici NEMÁ — ani v mirroru, ani v živém API. Entita User takový atribut nemá; SecurityRole jsou oprávnění, ne pozice.
BambooHR by pozice měl, ale api_bamboo.employees.workEmail je prázdný na VŠECH 489 řádcích, takže se to nemá na co napojit — a jeho tituly ten seznam ani nereprodukují.
Role se berou z hodin a párují se na jméno/e-mail. Report vypisuje, u koho se párování nepovedlo, takže nikdo nezmizí.
Buď doplnit pozici do ftracku, nebo zprovoznit e-maily v BambooHR mirroru. Ani jedno není nutné — dnešní stav funguje, jen není samoopravný.
Hodiny. A do ftracku to budeme muset pushovat přes API — samo se to tam nedostane.
OBCHVAT FUNGUJE · potřeba u bodů 14, 16, 17
U každé publikované verze vědět, v jakém je stavu (odesláno, schváleno, retake).
Bez toho nejde spočítat "kolik záběrů bylo za týden schváleno" ani zkontrolovat, jestli má záběr zapomenutý stav.
Sloupec assetversion.status_name je PRÁZDNÝ u ~99 % řádků — u comp verzí 26 756 z 27 177. Kdo se na ten sloupec spolehne, dostane prázdno a bude si myslet, že žádná verze nikdy schválená nebyla.
Stav bereme z historie změn (assetversionstatuschange), která je kompletní. Funguje to, ale je to o jeden join složitější.
Doplnit ten sloupec, nebo ho z mirroru vyhodit, ať nemate.
Ten sloupec dropnout a věci, co v něm jsou, nechat tak, jak jsou. Nic se nepředělává.
OBCHVAT FUNGUJE · potřeba u bodu 14
typedcontext.status_name je prázdný u 223 z 225 comp tasků na DRV. Stav se musí brát přes status_id → tabulka status. Report to tak dělá, ale je to stejná past jako B8 a stojí za to ji vědět.
Neřešit — stejně jako B8.
OBCHVAT FUNGUJE · potřeba u bodů 5, 6, 11
Sloupec bid NENÍ nikdy prázdný — nevybidovaný task má nulu. Takže každá kontrola "chybí bid" postavená na prázdné hodnotě hlásí, že je všechno v pořádku. Musí se testovat "bid > 0", což report i nová kontrola dat dělají. Reálně: 6 projektů má tasky a ani jeden s bidem.
Neřešit.
RIZIKO · potřeba u bodu 11
V ftracku jsou "C00620_maybelline" (prázdná skořápka, 0 řádků) a "c00620_maybelline" (151 řádků, živý). Při párování do hodin spadnou na stejný klíč, takže hrozí, že se něco spočítá dvakrát. Zatím k tomu nedošlo, protože ta skořápka je prázdná — ale kdyby do ní někdo něco založil, stane se to. Řešení je smazat tu prázdnou v ftracku.
Smazat ten projekt, který je prázdný.
Markéto, potvrdíš, který z těch dvou je ten prázdný? Text výš říká, že to je ten bez řádků, ale mazat projekt naslepo nechceme.
ČEKÁ NA PRODUKCI · potřeba u bodů 3, 26, 27
Aby každý, kdo si na projekt zapsal čas v ftracku, měl v hodinách záznam a vyplněnou pracovní pozici.
Bez pozice ho report neumí zařadit mezi artisty ani mezi overhead, a bez záznamu v hodinách navíc neumíme říct, co jeho práce stála.
Wesam Moussa 32,0 dne odpracováno ← chybí pozice, 31 dnů na compu Silvia Rákociová 17,7 dne ← chybí pozice David Teichert 0,8 dne ← chybí pozice Arseniy Kozlov 0,1 dne ← v hodinách NENÍ vůbec
Dohromady 50,6 dne, které report neumí zařadit.
Doplnit pozici u tří lidí a jednoho v hodinách založit. Report to za ně dopočítat nemůže a schválně to nedělá — viz vysvětlení v bodu 3.
(Poznámka: dřív tu stálo, že mimo hodiny jsou tři lidi. Bylo to špatně — vysvětlení v bodu 26.)
Hodiny — čeká se na migraci. Do té doby se s tím nic dělat nedá.
NENÍ CHYBA, ale je potřeba to vědět · potřeba u bodu 11
V mirroru je dnes 41 projektů, minulé kolo jich bylo 38 — dnešním syncem přišly tři nové. Podobně narostly tasky (30 147), verze (75 644) a timelogy (236 009).
Není to chyba, ale znamená to, že stejné číslo se mezi dvěma dny může lišit a nemá smysl hledat v tom chybu. Když ti něco nesedí, první otázka je, jak starý snapshot vidíš — datum je na stránce pod filtry.
Je to správně, tohle není potřeba nijak měnit.
OTEVŘENÉ · týká se všeho
Aby se report po každém syncu BigQuery sám přepočítal.
BigQuery se syncuje samo (dnes 19. 8. v 15:36), ale náš přepočet musí někdo pustit ručně. Než se to udělá, report ukazuje starší čísla, i když v BigQuery už jsou nová. Dnes byl náš snapshot z 14:12, tedy o sync pozadu.
Plánovač u nás nainstalovaný není, takže to opravdu nikdo neudělá sám.
Zapnout plánovač na straně Supabase, ať se přepočet spustí po každém syncu. Do té doby platí: než začneš kontrolovat čísla, řekni nám, ať to přetáhneme.
Přidat cron. Když BigQuery syncuje každou hodinu, u nás v Supabase to bude běžet taky každou hodinu a půl, ať se to nepotká.
Zapnout až bude všechno ostatní opravené, a zeptat se Ondřeje, jestli to může zapnout.
Poznámka k pořadí: v Supabase teď rozšíření pg_cron nainstalované NENÍ, takže ho bude potřeba zapnout dřív, než ten cron může vzniknout.
Ftrack u každého stavu vede, jestli znamená Done / In Progress / Blocked / Not Started. Je to v BigQuery celou dobu (tabulka state) a my jsme si místo toho psali vlastní seznam hotových stavů — což je přesně to, co způsobilo chybu v bodu 14. Teď se čte ftrackův stav. Stálo by za to projít, jestli si někde nepíšeme vlastní seznam tam, kde už odpověď existuje.
nahoruVšechna čísla jsou z BigQuery, ne z reportu — schválně, aby to byla nezávislá kontrola. Projekt v00080_drv:
tasků celkem 1 403
bid celkem 455,70 dne <- tvoje číslo, potvrzeno
odpracováno celkem 478,33 dne = 105 % bidu
comp tasků pod "shots" 225, bid 232,45, odpracováno 314,06
záběrů pod větví "shots" 229 <- tvoje číslo, potvrzeno
z toho bez comp tasku 4 (007_log_2110/2230/2540/2650)
lidí s časem v ftracku 25 (477,86 dne)
z toho artisti 19 (420,6 dne)
z toho overhead 2 (6,7 dne)
z toho bez pozice 4 (50,6 dne)
lidí s hodinami v hodinách 39
hodin v hodinách celkem 820,26 dne
pozic v hodinách celkem 64 (25 artist / 39 overhead /
0 nezařazených)
medián artisty na projektu 13,5 dne (333 případů, p25 3,9)Kolo 2 feedbacku (body 11–18), měřeno 19. 8. 2026:
comp záběrů se stavem 225 = 186 hotových + 32 zrušených + 7 ostatních
z toho skutečně otevřených 6 (7 minus "Completed", který je hotový)
(tohle je comp podle JMÉNA tasku, tedy stav před bodem 24)
projektů v mirroru 38 (28 má comp tasky, 22 pod větví "shots")
projektů bez jediného tasku 7
projektů s tasky ale bez bidu 6
projektů mimo hodiny 9 (vč. v00032_wan a v00052_vio)
comp podíl na publikované práci 38,7 % (fx 6 255 verzí, slapcomp 5 199,
animation 1 086)
tempo DRV v okně před deadlinem 35,25 záběru/týden (8.6.–29.6.)Kolo 3 feedbacku (body 19–33), měřeno 19.–20. 8. 2026, comp podle ftrack TYPU, záběr určený RODIČEM tasku a počítáno PO ZÁBĚRECH:
comp tasků pod větví shots 255 z toho různých záběrů 225 stav po záběrech 225 = 188 hotových + 32 zrušených + 5 otevřených (záběr je hotový, když je hotový aspoň jeden jeho comp task — druhá varianta, "všechny comp tasky hotové", dává 177 / 32 / 17 a posunula by odpověď na bod 14 na sedmnáct otevřených, proto jsme ji nevzali) retaky po záběrech 150 / 35 / 24 / 12 / 4 = 225 z nich dodáno / ke klientovi 191 / 180 0 retaků a přesto dodáno 116 (bod 33) comp bid / spent 235,20 / 328,66 dne compositorů na projektu 15 s pozicí + 4 nezařaditelní týden 1. 6. 107 různých záběrů ve 524 publishech (4,9 verze/záběr)
Celkové součty jsou z 10. 8. 2026, rozpady lidí a záběrů z 18.–20. 8. 2026 už proti nasazené verzi. Dny, kdy se to měřilo dvakrát, vyšly stejně.
nahoru