Psané narativy

Antonín Král

2025-07-24

Categories: leadership

Překlady: English 🇬🇧: Written Narratives

Jednou z klíčových rolí vedení firmy je dělat jasná rozhodnutí1 a odemknout rozhodování internal link na dalších úrovních organizace. Témata jsou často komplexní a k popisu problémového prostoru potřebují data a složité vztahy mezi nimi. Přesto mnoho vedoucích týmů používá k synchronizaci týmů a popisu problému prezentace2.

Než se zamračíte a půjdete dál, protože PowerPoint nikdy nepoužíváte – tento článek je v podstatě obhajobou toho, abychom více psali. Je to ještě relevantnější v době AI kódovacích agentů a nastupujícího spec-driven developmentu external link . Je to vlastně to samé; místo lidí instruujete AI agenta. Ale i tak je stále potřeba myslet, psát a myslet v psaní.

Pozor, spoiler: V tomto článku se snažím obhajovat větší přítomnost del(ší)ho psaného textu v organizacích. Netvrdím, že by lidé neměli mluvit nebo se osobně potkávat, právě naopak. Mým přesvědčením je, že psaní je myšlení3, což také znamená, že jsem vehementně proti vedení skrze prezentace. Jasné psaní je ještě důležitější v době, kdy se AI nástroje stávají součástí každodenního života.

Co je špatně na prezentaci?

Mnoho jednání, na kterých by mělo padnout nějaké závažné rozhodnutí4, začíná prezentací. Přednášející se snaží popsat problém, kontext, data, vztahy a možná řešení. Publikum se snaží přednášejícího sledovat, porozumět problému a rozhodnout se; přitom přednášejícího často přerušuje otázkami, komentáři nebo návrhy, čímž narušuje tok prezentace a někdy ji úplně vykolejí.

Formát prezentace

Velkou roli hraje forma prezentace. Mohou se lišit designem, ale všechny se skládají z krátkých bloků textu, odrážek a občasných diagramů. I návody typu “Jak přednést skvělou prezentaci” nabádají jít výrazně pod 50 slov na slide, s důrazem na vizuální podpoření primárně verbálního sdělení5. Někteří přednášející situaci vyřeší tím, že se vydají úplně opačným směrem a slidy standardně zaplácají textem. Prezentační formát nicméně téměř vždy sleduje velmi hierarchickou strukturu s jedinou cestou.

A protože přednášejícímu rychle dojde místo na slidu, je tlačen k tomu, aby všechny chybějící informace doplnil ústně. To nejen dává výrazně příliš nespravedlivou výhodu lepším přednášejícím6, ale také to zvyšuje kognitivní zatížení na straně publika. Úspěch prezentace tak bude záležet víc na úplně irelevantních faktorech než na samotném obsahu.

Jednou z velmi slavných událostí spojených s přehnaným používáním prezentací jako komunikačního nástroje byla havárie raketoplánu Columbia. Závěrečné vyšetřovací zprávy jsou volně dostupné a obsahují fascinující čtení o informačních tocích, v podstatě o hře na tichou poštu v rámci celé organizace7:

Jak se informace posouvá vzhůru hierarchií organizace, od lidí, kteří dělají analýzy, přes střední manažery až k nejvyššímu vedení, klíčová vysvětlení a podpůrné informace se odfiltrují. V tomto kontextu je snadné pochopit, jak si vysoký manažer může přečíst tento PowerPointový slide a neuvědomit si, že se týká situace ohrožující životy.

— Columbia Accident Investigation Board, Report volume 1 (2003), strana 191. Označováno také jako zpráva CAIB.

Podobný názor lze najít v navazující zprávě od Return to Flight Task Group:

Také jsme zaznamenali, že místo výstižných technických zpráv jsou rozhodnutí a jejich zdůvodnění často obsažena výhradně v grafech Microsoft PowerPoint® nebo v e-mailech. Zpráva CAIB (sv. I, str. 182 a 191) kritizovala používání PowerPointu jako inženýrského nástroje a i další profesní organizace zaznamenaly zvýšené používání tohoto prezentačního softwaru jako náhrady technických zpráv a jiné smysluplné dokumentace. PowerPoint (a podobné produkty jiných výrobců) má jako metoda pro poskytnutí opěrných bodů a prezentaci omezených dat sestaveným skupinám v inženýrské komunitě své místo; těmto prezentacím by však nikdy nemělo být dovoleno nahrazovat formální dokumentaci, ani ji doplňovat. [….] Zdá se, že mnoho mladých inženýrů nerozumí potřebě formálních inženýrských dokumentů, jako jsou zprávy, white papery nebo analýzy, ani neumí takové dokumenty připravit.

— Final Report of the Return to Flight Task Group (2005), strana 190.

Informační hustota a předčasná generalizace

Informační hustota slidu je poměrně nízká. Typická rychlost mluveného slova u prezentace nebo přednášky je 125 až 150 slov za minutu8. Naproti tomu průměrný dospělý čte při čtení s porozuměním rychlostí okolo 200 až 300 slov za minutu9. A dále, pokud je náš cílový počet slov na jednom slidu okolo 50 a typická technická zpráva má na jedné stránce 500 slov, máme desetinásobnou informační hustotu už jen na počtu slov. To se stane zjevným, když se prezentace vytiskne na papír. Jak upozornil Edward Tufte:

Rozlišení vytištěných prezentací je pozoruhodně nízké, blíží se demenci.

— Edward R. Tufte; The Cognitive Style of PowerPoint: Pitching Out Corrupts Within (2006), strana 26.

Malý prostor a používání odrážek v prezentacích vede k dalšímu problému – předčasné generalizaci, vágnosti. Analýza v Harvard Business Review10 označila seznamy odrážek za typicky příliš obecné, ponechávající klíčové vztahy nespecifikované.

Viděl jsem už tolikrát slidy volající po tom, aby řešení bylo “vysoce škálovatelné” nebo “vysoce dostupné”, bez jakýchkoli podrobností11.

Jak prezentace vylepšit

Pevně věřím, že u seriózních prezentací potřebujeme slidy nahradit psaným narativem. Zbytek článku probere několik možných stylů. I když se jejich struktura může mírně lišit, všechny těží z jednoduchého faktu, že se skládají z celých vět a odstavců.

Někdy je na místě kombinace psaného narativu a prezentace. Nejprve rozešlete psanou část a pak uspořádejte Q&A session podpořenou slidy, které publikum dostanou do obrazu.

Toto je jedna z těch jednoduchých, ale obtížných změn, takže potřebuje nejen podporu vedení, ale spíš přímý exekutivní příkaz12.

RFC (Request For Comments)

RFC znamená Request for Comments, tedy žádost o komentáře – praxe, která dodnes skrze IETF pohání klíčová technická rozhodnutí o internetu. Systém RFC vytvořil Steve Crocker v roce 1969 pro Network Working Group v ARPANETu, aby zachycoval poznámky. Přístup podobný RFC přijalo mnoho firem a open-source komunit13.

RFC slouží jako “živé dokumenty”, které popisují navrhované technické návrhy nebo plány a před implementací zvou zainteresované strany k revizi a zpětné vazbě. Základní účel RFC jde za rámec jednoduché dokumentace – představují prostředek pro asynchronní diskusi. To je klíčový stavební kámen spolupráce jakéhokoli distribuovaného týmu.

RFC by navíc nemělo být chápáno jako žádost o povolení, ale spíš jako “tady je to, kam chceme jít, neuniká nám něco?” (jak jsme probírali v Kdo rozhoduje? internal link ).

Struktura RFC

Vaším prvním RFC by měla být šablona RFC14. Jak bylo řečeno, RFC jsou živé dokumenty, takže se šablona může (a měla by se) měnit, ale mít odsouhlasenou šablonu je pro rozhýbání věcí zásadní.

Začněte Popisem problému. RFC navazuje na vaši strategii internal link a realizuje ji, takže začněte diagnózou (proč vůbec toto RFC píšete). Hned si vyžádejte komentáře. Viděl jsem, že “co je problém” je náročné, ještě víc než samotné řešení. Poskytněte dostatek Pozadí a kontextu, aby kdokoli nový k dokumentu měl dostatečný kontext k porozumění tomu, proč je změna nutná. Mělo by odkazovat na předchozí RFC, diskuse, tickety a relevantní dokumentaci, aby se zabránilo opakování a zároveň bylo zajištěno úplné porozumění.

Zavržené nápady – místo mazání zamítnutých hypotéz15 by RFC mělo dokumentovat, proč byly určité nápady zavrženy. To zabrání budoucím týmům jít stejnou cestou a spadnout do známých pastí. Nemluvě o tom, že za půl roku si ani sami autoři nebudou pamatovat, co všechno se zvažovalo (a nepotřebuje být znovu zvažováno a diskutováno).

A nakonec Přehled návrhu. Jasné (vysokoúrovňové) vyjádření navrhovaného řešení, které nastiňuje “jak” na vysoké úrovni a detailní implementaci ponechává následujícím sekcím. Následováno Detaily implementace. Sekce popisující hrubé změny API16, změny UI a přehled zasažených subsystémů.

Jazyk

Může to působit divně a příliš formálně, ale vyplatí se podívat na RFC 2119 external link , které ustavilo konkrétní pojmy a jejich význam. Například “MUST” (musí), “SHOULD” (mělo by) a “MAY” (může) pro označení úrovní povinnosti implementace, přičemž každý pojem nese specifický význam, který se mění podle úrovně autority dokumentu. Tato standardizace zajišťuje, že technické požadavky jsou napříč týmy interpretovány konzistentně. Také velmi pomáhá společný slovník běžně používaných pojmů a jejich významů.

Protože mnoho z nás nejsou rodilí mluvčí angličtiny, doporučil bych Technical Writing and Professional Communication: For Nonnative Speakers of English od Thomase N. Huckina a Leslie A. Olsena.

Životní cyklus RFC

Neexistuje univerzální řešení, ale typicky by RFC prošlo několika fázemi:

flowchart LR
  D(Návrh) --> PR(Revize problému) --> SR(Revize řešení) --> I(Implementace) --> M(Údržba) --> S(Ukončení)

Přičemž Údržba a Ukončení bývají často opomíjeny. Je ale důležité nenechávat stará RFC přežívat.

Šablony RFC

PRD (Product Requirements Document)

Co je PRD?

Product Requirements Document (dokument produktových požadavků) slouží jako plán, který popisuje funkční a nefunkční požadavky produktu, včetně jeho účelu, vlastností, funkčnosti a chování. Měl by být schopen odpovědět na otázky Proč a Co. PRD by mělo sloužit jako most mezi vývojáři, designéry a zainteresovanými stranami okolo společné vize a zároveň definovat hranice projektu, aby se zabránilo scope creepu.

PRD se výrazně překrývá s RFC nebo ADR, jen má jiný účel, a tedy i mírně odlišnou strukturu. Myšlenka využití psaní a sbírání zpětné vazby je stejná.

Struktura PRD

Hlavním cílem PRD je sjednotit všechny zapojené strany. To se odráží i v jeho struktuře; tři hlavní sekce jsou – Sjednocení na problému, Sjednocení na řešení, Sjednocení na (plánu) uvedení. Vzhledem k tomu, že PRD by měli číst lidé napříč organizací, může být u komplexnějších PRD dobré začít Souhrnem pro vedení17.

V sekci Sjednocení na problému popíšeme daný problém v několika větách: proč by to firmu mělo zajímat, proč to zajímá zákazníky? Poskytněte důkazy podporující tato tvrzení. Měli bychom být schopni požadavky svázat s Uživatelskými příběhy a personami, které detailně popisují cílové uživatele18, včetně konkrétních scénářů ilustrujících interakci s produktem. Vypíšeme Cíle (krátce), ukazující nezbytné chování produktu, s konkrétními měřitelnými (== metriky) i neměřitelnými (== pocity) cíli. Zahrňte také seznam Ne-cílů; podobně jako u strategií a RFC je vypsání toho, co se nebude řešit, velmi cenné. Vysvětlete, proč jsou to ne-cíle.

Mít tuto sekci sepsanou je skvělý moment k vyžádání komentářů, aby se ověřilo, že porozumění problému je společné.

Sjednocení na řešení je o definování perimetru řešení. PRD/produktový manažer je ideálně ten, kdo má pod kontrolou rozsah, a ostatní ho nemusí vymýšlet. Vypište klíčové vlastnosti, které řešení postaví. Opět mějte jasno v rozsahu jednotlivých vlastností, aby se týmy mohly soustředit na dodávku. Odkazujte na detailní popisy, RFC apod. Pokryjte běžné hraniční případy. Ukažte klíčové toky, ideálně to, jak bude pro uživatele vypadat zkušenost od začátku do konce. Zahrňte i další části produktu (v menší podrobnosti), abyste vyzdvihli kontext daného PRD/funkce.

Plán uvedení není potřeba u menších projektů, ale u větších iniciativ by měl být zahrnut. Potřebujeme pilotní nebo beta verzi? Pokud ano, jaká budou kritéria pro posun do další fáze19?

Checklist interakcí

Dobrou praxí, zvlášť ve větších organizacích, je mít provozní checklist, který pokrývá potenciál pro nekaždodenní interakce s dalšími odděleními. Příklad takového checklistu:

Otázka Oddělení Příklad akce
Potřebujeme nové/konkrétní insighty? Data Science / Analytika Spolupracovat s osobou na určení, co a jak je potřeba logovat pro takový report.
Mělo by to dopad na sales enablement? Sales Spolupracovat s osobou.
Ovlivňuje to naše současné marketingové sdělení? Může to ovlivnit naše budoucí sdělení? Marketing Spolupracovat s osobou.
Ovlivňuje to nějaké společné KPI? Zasažená oddělení Spolupracovat s osobou na úpravě cílů.
Potřebujeme aktualizovat školicí nebo podpůrné materiály? Customer Success / Podpora Spolupracovat s osobou na aktualizacích.
Potřebujeme GTM plán? Produktový marketing Spolupracovat s osobou v předstihu, protože to může zabrat hodně času.
Ovlivňuje to nějaké channel partnery? Channel Spolupracovat s osobou na plánu rolloutu.
Je na tom něco rizikového (např. nový vektor útoku/reputační riziko, GDPR, SOC2 apod.)? Riziko / Compliance Spolupracovat s osobou.
Nějaké potenciální právní důsledky? Právní Spolupracovat s osobou.

Životní cyklus PRD

Jako obvykle prochází PRD několika fázemi:

flowchart LR
  D(Návrh) --> PR(Revize problému) --> SR(Revize řešení) --> LR(Revize uvedení) --> L(Uvedeno) --> M(Údržba) --> S(Ukončení)

Každá fáze může (a měla by) přinést změny a aktualizace. Ideálně jsou zachyceny v nějakém verzovacím systému. Ale i když ho máte, může být přínosné vést manuální changelog sekci, která vyzdvihne klíčové změny pro lidi, kteří to nesledují zblízka. Changelog nemusí být detailní; jde skutečně o to pobídnout čtenáře, aby si znovu přečetl sekce, které už možná v minulosti přečetl.

Šablony PRD

Odkazy na dobré PRD šablony a další zdroje:

Kultura psaní na prvním místě a psané narativy v praxi

Několik prominentních technologických firem přijalo přístup “psaní na prvním místě”, protože rozpoznalo hodnotu jasné písemné komunikace pro rozhodování a sdílení znalostí. Mezi významné příklady patří Amazon, Basecamp, GitLab, Stripe a Automattic.

Než se ponoříme do konkrétních firemních příkladů, vyplatí se začít u Edwarda Tufteho external link – průkopníka informačního designu a jednoho z nejranějších a nejvlivnějších kritiků prezentačního formátu a softwaru20.

Amazonské šestistránkové narativy

Amazon je snad nejslavnějším příkladem kultury psaní na prvním místě. Jeff Bezos zakázal PowerPointové prezentace na výkonných jednáních a nahradil je šestistránkovými narativními dokumenty. Tyto dokumenty začínají souhrnem pro vedení a sledují jasnou strukturu, která autory nutí o svých návrzích hluboce přemýšlet. Prvních 20-30 minut každé schůzky se stráví v tichu, kdy si přítomní dokument čtou, což zajistí, že všichni mají před začátkem diskuse stejný kontext.

Bezos věří, že šestistránkový dokument je dost dlouhý na to, aby detailně pokryl komplexní témata, ale dost krátký na to, aby udržel soustředění a jasnost. Tento přístup se stal pro amazonskou kulturu tak zásadním, že je často uváděn jako klíčový faktor jejich schopnosti dělat vysoce kvalitní rozhodnutí ve velkém měřítku.

37signals

Basecamp/37signals postavil celou svou firemní kulturu na písemné komunikaci external link . Jejich přístup zdůrazňuje dlouhou formu psaní skrze nástroje jako jejich vlastní produkt Basecamp a e-mailovou platformu HEY. Jason Fried a David Heinemeier Hansson, zakladatelé firmy, konzistentně obhajují psaní jako nadřazenou formu komunikace, zejména pro distribuované týmy.

Zásadní rozhodnutí, produktové strategie a dokonce i firemní oznámení se typicky sdílejí jako detailní psané dokumenty, nikoli jako prezentace nebo schůzky. Tento přístup umožňuje asynchronní práci a promyšlené odpovědi, což je pro jejich globálně distribuovaný tým klíčové.

Veřejný handbook GitLabu

GitLab posouvá transparentnost a písemnou komunikaci na další úroveň svým veřejně dostupným handbookem – rozsáhlou sbírkou dokumentace, která popisuje vše od firemních hodnot po konkrétní postupy. Tento přístup “handbook na prvním místě” znamená, že jakékoli významné rozhodnutí nebo proces musí být před zavedením zdokumentováno písemně.

Handbook slouží více účelům: je jediným zdrojem pravdy o provozu firmy, vynucuje jasné myšlení o procesech a rozhodnutích a umožňuje jejich plně distribuovanému týmu efektivně pracovat napříč časovými zónami. Veřejná povaha handbooku také slouží jako silný nástroj pro nábor a onboarding, protože dává potenciálním zaměstnancům bezprecedentní vhled do toho, jak firma funguje.

  1. Doufejme, že ta správná. Často je jakékoli rozhodnutí lepší než žádné rozhodnutí a ztracený směr pro zbytek týmu/firmy. ↩︎

  2. Chci říct, můžu tady vinit PowerPoint, ale o to nejde. PowerPoint je jen jedním z mnoha nástrojů na tvorbu prezentací. ↩︎

  3. Typickým představitelem této myšlenky je David McCullough, který prohlásil: “Writing is thinking. To write well is to think clearly. That’s why it’s so hard” (Psaní je myšlení. Psát dobře znamená myslet jasně. Právě proto je to tak těžké). Ale rozhodně není sám. George Orwell, Paul Graham, Stephen King, Walter Ong a mnoho dalších vyjádřili podobný názor. ↩︎

  4. Dobrým výchozím bodem je mít vlastně jasno ne v možném dopadu rozhodnutí, ale spíš v tom, jak těžké by bylo vrátit se zpátky. Čím obtížnější je rozhodnutí zvrátit, tím více času a úsilí by mělo být věnováno porozumění problému. Přesto se lidé často zapletou do bikeshedding external link a tráví čas diskusí o trivialitách. ↩︎

  5. Přičemž jim uniká fakt, že prezentace není jejich TED talk. ↩︎

  6. nebo hezčí grafice, nebo denní době, nebo … chápete pointu. ↩︎

  7. V angličtině “telephone game”, někdy také “Chinese whispers”. My tomu v češtině říkáme tichá pošta. ↩︎

  8. Nepodařilo se mi najít žádné vědecké důkazy, ale mám tendenci sledovat přednášky na YouTube zrychleně někde mezi 1,6 až 2,4x. ↩︎

  9. Aurélie Calabrèse, et.al.; Baseline MNREAD Measures for Normally Sighted Subjects From Childhood to Old Age; https://pubmed.ncbi.nlm.nih.gov/27442222/ external link  ↩︎

  10. Gordon Shaw, Robert Brown a Philip Bromiley; Strategic Stories: How 3M Is Rewriting Business Planning, Harvard Business Review (1998). Dostupné online na https://hbr.org/1998/05/strategic-stories-how-3m-is-rewriting-business-planning external link . ↩︎

  11. Jako třeba definice “škálovatelnosti” – hledáme propustnost, latenci? Ideálně s definovanými vyhodnocovacími metrikami a jejich cíli. ↩︎

  12. Například: “Od nynějška očekáváme RFC pro cokoli většího než 2 člověkotýdny práce” a “Tickety bez popisu už nejsou akceptovatelné”. ↩︎

  13. Například Python Enhancement Proposals (PEPs) external link ). ↩︎

  14. RFC 007: Povolení dokumentovat

    Odrážky chladně blýskaly ve světle zasedací místnosti. “Očekávám, že zemřete, pane Binde,” zasyčel PowerPointový zloduch a vypálil laserovým ukazovátkem na projektor. Ale Bindův šestistránkový narativ obsahoval skrytý… ↩︎

  15. Náš slavný Jára Cimrman external link je skutečným mistrem slepých uliček. Málem vyhrál titul “Největší Čech”, ale byl vyřazen jako fiktivní osoba. ↩︎

  16. API nemusí být omezeno na veřejná API, jako REST, JSONAPI, GraphQL apod. Ale i na rozhraní v kódu. ↩︎

  17. Co skutečně zarezonovalo, nebyl standardní souhrn pro vedení, ale spíš “falešná” tisková zpráva. Protože “prodávat” zákazníkovi je hodně podobné prodávání managementu. Myšlenka přišla z amazonského Working Backwards external link . ↩︎

  18. Pokud máte problém definovat cílového uživatele, vraťte se ke své definici Ideal Customer Profile (ICP). Vágní (aka prodávat všem) definice ICP je často příčinou neschopnosti jasně definovat persony při navrhování funkcí. ↩︎

  19. Mám flashbacky nekonečných diskusí, jestli můžeme přejít do Early Access, když máme ještě reporty chyb od beta zákazníků. Stanovte to na začátku, kdy lidé ještě nejsou v obranném režimu. ↩︎

  20. The Cognitive Style of Powerpoint: Pitching Out Corrupts Within external link  ↩︎

Author's bio

Ing. Antonín Král, Ph.D.

Citace

Pro uvedení zdroje prosím citujte toto dílo takto

Antonín Král (2025). Psané narativy. bobek.cz. https://www.bobek.cz/cs/psan%C3%A9-narativy/

BibTeX citation

@misc{
  title = "Psané narativy",
  author = "Antonín Král",
  year = "2025",
  journal = "bobek.cz",
  note = "https://www.bobek.cz/cs/psan%C3%A9-narativy/"
}