Syntéza napříč oblastmi zaměřená na otázku, která je pro převzatelnost systému zásadní: jak snadno lze systém předat někomu jinému a jak velká je závislost na konkrétních lidech (bus factor). Právě tohle je jádro celého auditu.

Jak to čteme

Předatelnost neměříme dojmem, ale konkrétními atributy: je znalost zapsaná (a strojově čitelná), rozjede nový vývojář projekt sám, je infrastruktura reprodukovatelná z kódu, a nezávisí běh na tom, „co ví jen Honza".

🎯 Skóre předatelnosti (ukázka na tfpl)

Faktor	Stav	Důkaz
Znalost zapsaná a strojově čitelná	🟢	AGENTS.md, CODEBASE.md, dokumentace jako součást repa
Onboarding nového vývojáře	🟢	návod na lokální spuštění u všech aplikací, .env.example, „na jeden příkaz"
Reprodukovatelnost prostředí	🟢	infrastruktura jako kód (Terraform + Kustomize)
Nezávislost běhu na jednotlivci	🟢	generovaný API klient, sdílené balíčky, konvence vynucené CI
Evidence technického dluhu	🟢	dedikovaný prioritizovaný dokument, ne „v hlavách"
Řízení tajemství při předání	🟠	commitnutá tajemství komplikují čisté předání (viz Bezpečnost)

Verdikt (ukázka): systém tfpl je dobře předatelný a závislost na konkrétních lidech je nízká — znalosti jsou zachycené v repozitáři, prostředí je reprodukovatelné a konvence jsou vynucené automaticky. Hlavní tření při předání by způsobila jen tajemství ve verzování.

🔑 Proč je to pro vás klíčové

U vlastního (custom) softwarového řešení drženého malým týmem je největším rizikem, že kritická znalost žije jen v hlavách lidí, kteří systém léta udržují. Audit tuto závislost pojmenuje konkrétně:

• Co je zdokumentované vs. co existuje jen jako „tacit knowledge".
• Kolik lidí je nezbytných k rozjetí, nasazení a opravě systému (bus factor).
• Které části by po odchodu klíčového člověka nebyl schopen převzít nikdo jiný.
• Jaké kroky závislost sníží (dokumentace, konvence, IaC, automatizace).

📌 Tohle je přímá odpověď na klíčovou otázku: jak velký je vendor lock na současných programátorech a co s ním.

🛠️ Jak závislost snižujeme

Výstupem auditu není jen konstatování, ale i konkrétní plán snížení závislosti — navazuje na standard TechFides „Dlouhodobá udržitelnost projektu" (registr rizik, evidence technického dluhu, roadmapa). Prioritizované kroky viz Rizika, technický dluh a roadmapa nápravy.

ℹ️ V ostré verzi tuto sekci doplníme o konkrétní bus-factor analýzu na základě přístupu ke kódu a rozhovorů s týmem.