Notion, nebo Confluence: pružnost databází naráží na správu ve velkém

Notion se hodí, když tým potřebuje z dokumentů a databázových záznamů skládat vlastní pracovní postupy. Confluence má větší smysl, když je dokumentace pevně spojená s Jira a přístup k ní se musí řídit napříč odděleními. S rostoucím počtem lidí roste hodnota předvídatelné správy, ale samotná velikost týmu výběr neurčuje.

Rozhodující je, zda znalostní báze slouží hlavně jako proměnlivý přehled práce, nebo jako trvalý záznam rozhodnutí a provozních postupů. Do volby patří také cena přestavby existujícího obsahu: licence neřekne, kolik času zabere obnova práv, maker a vazeb na Jira po přesunu.

Databáze: co je jádrem práce

Notion dává největší prostor týmu, který vede požadavky, specifikace nebo rozhodnutí jako záznamy s vlastníkem, stavem a dalšími vlastnostmi. Nad stejnou sadou záznamů může vytvořit filtrované pohledy pro produkt, vývoj a provoz, aniž by pro každou skupinu udržoval samostatný seznam. Přehled funkcí Notionu uvádí vlastní vlastnosti a filtry, automatizace i jemnější oprávnění k databázovým záznamům v tarifu Business; ve stejném tarifu jsou také AI Meeting Notes a vyhledávání v připojených aplikacích.

Confluence má vlastní databáze, takže nejde o volbu mezi databází a její absencí. Jeho výchozí logikou jsou však prostory a stránky, do nichž se ukládají znalosti jednotlivých týmů. Pokud má specifikace zůstat dohledatelným dokumentem s jasným vlastníkem a databáze je jen doplňkem, tato struktura bývá snazší na správu. V Notionu je naopak potřeba určit, kdo smí měnit vlastnosti, pohledy a vazby mezi záznamy, jinak si různé týmy postupně vytvoří odlišné verze téhož procesu.

Jira: živý kontext, nebo synchronizovaná kopie

Confluence umí zobrazit informace z Jira přímo ve stránce. Dokumentace Smart Links popisuje vložení nástěnky, seznamu či časové osy Jira do dalších aplikací Atlassianu s aktuálními údaji; vložený pohled uvidí uživatelé, kteří mají přístup k příslušnému prostoru v Jira. To se hodí tam, kde se specifikace průběžně čte společně se stavem vývojové práce a tým nechce stav opisovat do dalšího systému.

Notion nabízí spravovanou synchronizaci Jira Cloud do propojených databází. Návod k propojení Jira stanoví tarif Business nebo Enterprise a uvádí, že synchronizované vlastnosti se mění v Jira, zatímco v Notionu jsou pouze pro čtení. Načtené položky lze v Notionu doplnit vlastními vlastnostmi a pohledy; tyto doplňky se zpět do Jira neposílají. Důležitá hranice vzniká při sdílení: přístup k importovaným údajům pak určují práva v Notionu a oprávnění každého čtenáře v Jira se samostatně nekontroluje. Před otevřením takové databáze širšímu týmu je proto nutné rozhodnout, které položky do synchronizace vůbec patří.

Oprávnění a historie při růstu týmu

U firemní wiki přibývají různí vlastníci obsahu, externí spolupracovníci i stránky určené jen části organizace. Tarify Confluence uvádějí databáze už v základní nabídce a pro Standard pokročilá oprávnění, hosty, funkce Rovo a úložiště 250 GB. Správa přes prostory a omezení jednotlivých stránek odpovídá týmu, který může přístup odvozovat od relativně stálých oddělení nebo služeb. Hosté přitom potřebují vymezený rozsah přístupu, nikoli automaticky stejné místo jako interní členové.

Notion pracuje s týmovými prostory, skupinami a sdílením stránek; jemnější oprávnění k databázovým záznamům jsou otázkou tarifu. To může vyhovovat projektům, jejichž členové se častěji mění, ale vyžaduje správce struktury a pravidel sdílení. Při výběru je také potřeba rozlišit aktuální stránku od její historie: možnost vrátit změny a délka uchování starších verzí se musí posuzovat podle konkrétního tarifu a požadavků na dohledatelnost. U provozního postupu může být starší znění stejně důležité jako poslední úprava.

Rozhodovací matice pro 10, 50 a 200 lidí

Jde o modelové velikosti, nikoli o limity služeb. Každý řádek vyjadřuje, která vlastnost obvykle začne rozhodovat, pokud tým používá nástroj jako interní znalostní bázi.

• 10 uživatelů: Notion usnadňuje rychlou úpravu databází, pohledů a stránek jednou skupinou. Pokud stejná skupina už vede vývoj v Jira a ukládá především technické postupy, Confluence může být přehlednější i při malém počtu lidí. Prvním kritériem je tedy podoba práce, ne počet licencí.
• 50 uživatelů: Více týmů potřebuje sdílené informace, ale často i vlastní editory a různé čtenáře. Notion obstojí, když mají propojené databáze určeného správce a jasná pravidla pro vlastnosti i sdílení. Confluence nabývá na hodnotě, pokud se dokumentace dobře dělí do prostorů a technické stránky pravidelně odkazují na aktuální práci v Jira.
• 200 uživatelů: Rozhoduje schopnost držet vlastnictví, přístup a životní cyklus obsahu bez množství ručních výjimek. V organizaci postavené na Jira tím získává Confluence silný argument. Notion zůstává možností, ale databázové schéma, týmové prostory a práva k synchronizovaným údajům už potřebují vědomou správu; pružnost sama pořádek nevytvoří.

Rozpočet licence a práce kolem ní

U české firmy má srovnání cen smysl jen při stejném počtu placených členů, stejné délce fakturace a stejné měně. Je třeba započítat tarif, který skutečně obsahuje požadovaná oprávnění a integrace, případné další produkty Atlassianu i doplňky. Měsíční cena za uživatele nevystihne čas, který správci stráví údržbou pracovního prostoru nebo ručním přepisováním stavu mezi dokumentací a Jira.

Pokud stačí statické stránky a odkazy, placená synchronizace přidává málo. Jestliže však produktový tým potřebuje v Notionu filtrovat pracovní položky z Jira spolu se svými specifikacemi, musí do rozpočtu zahrnout odpovídající tarif a správu přístupu k importovaným datům. U Confluence zase stojí za posouzení, zda rozsah požadované administrace odpovídá zvolenému plánu. Rozpočtová položka má vždy vycházet z konkrétní funkce, kterou tým použije.

Migrace: stránky se přenesou snáz než jejich pravidla

Při přesunu z Confluence do Notionu se mohou přenést stránky, jejich hierarchie, základní formátování a přílohy. Návod k importu z Confluence současně uvádí, že oprávnění a historie stránek se neimportují, většina maker a doplňků ztrácí původní podobu a složité tabulky se mohou zhoršit. Importované stránky přistávají jako soukromé pro uživatele, který je přenesl. Samotné dokončení importu proto ještě neznamená, že novou wiki mohou bezpečně používat původní skupiny čtenářů.

Práci je užitečné rozdělit na mapování skupin a omezení, přestavbu databázových vlastností, náhradu maker, kontrolu příloh a opravu vazeb na Jira. Pokud byly na stránkách vložené živé přehledy Jira, jejich náhrada může znamenat jiné rozvržení dokumentu nebo nové synchronizované databáze. U importu se mohou narušit i náhledy odkazů na Jira, pokud propojení nebylo předem autorizováno. Tyto úkoly mají jiné vlastníky než prostý export stránek a mohou převážit rozdíl v předplatném.

Reprezentativní vzorek běžné stránky, omezené stránky a specifikace navázané na Jira ukáže, co se v dané organizaci musí obnovit ručně. Výsledek takového převodu poskytne podklad pro odhad hodin správců a vlastníků obsahu. Teprve s tímto nákladem je možné rozhodnout, zda pružnější databázová práce vyváží změnu zavedené správy dokumentace.

Přečtěte si také:

• AI agent, nebo RPA: flexibilita prohrává tam, kde rozhoduje rychlost
• Midjourney, nebo Firefly: kvalita obrazu naráží na licenci a workflow
• CapCut, nebo Descript: střih podle klipů proti střihu podle slov