Sunum inşası: yönetici anlatısı vs teknik derinlemesine

Zihinsel model

M13-M14’te bir migrasyon programının içeriğini (roadmap, maliyet, governance, risk) kurdun; önceki derste bu içeriğe gelecek itirazları hazırladın. Bu ders, aynı içeriği kime, hangi sırayla anlatacağını, yani sunumun kendi mimarisini kuruyor.

İki anlatı, iki farklı amaç

Yönetici anlatısı (~20 slayt, risk/maliyet/takvim), bir karar almak için var: yönetim kurulu veya üst yönetim, bu sunumun sonunda bir bütçe onayı veya bir yön kararı vermeli. Bu yüzden bu anlatı sonuçla başlar: “PQC migrasyonuna şu üç ufukta, şu aralıkta bir maliyetle geçiyoruz, önerimiz şu” (M13). Detaylar (hangi algoritma, hangi mekanizma) sadece bir karar vericinin güvenini kurmak için gereken minimum düzeyde var, “neden şimdi” ve “ne kadara” sorularının cevabı öncelik alıyor.

Teknik derinlemesine anlatı (~45 dakika, mekanizma/bağımlılık), bir uygulamayı doğrulamak veya eleştirmek için var: bir mimar veya güvenlik mühendisi, bu sunumun sonunda “bu plan teknik olarak sağlam mı” sorusuna kendi uzmanlığıyla cevap verebilmeli. Bu anlatı gerekçeyle başlar: neden hybrid (M6), hangi mekanizma (M2-M4’ün matematiği), hangi bağımlılıklar (M13’ün bağımlılık grafiği), hangi implementasyon riskleri (M14’ün KyberSlash dersi). Bir mimar için “bize güvenin, güvenli” cümlesi ikna edici değil, tam tersine bir kırmızı bayrak (önceki derste gördüğün “quantum snake oil” kırmızı bayraklarıyla aynı aile): mimar, iddiayı kendisi doğrulayabileceği kadar detay istiyor.

Hangi içerik hangi anlatıya ait

Kural basit: bir bilginin karar üzerindeki etkisi mi, yoksa doğruluğunun kanıtı mı olduğunu sor. “3 yıllık migrasyon, X-Y aralığında maliyet” kararı etkiliyor, yönetici anlatısına ait. “Bu maliyet aralığı hangi varsayımlara dayanıyor, her biri nasıl doğrulanabilir” (M13’ün maliyet metodolojisi) doğruluğun kanıtı, teknik anlatıya ait. Bazı içerikler ikisine de ait ama farklı derinlikte: “hybrid KEX kullanıyoruz” yönetici anlatısında bir cümle, teknik anlatıda M6’nın downgrade/karmaşıklık riskini içeren bir bölüm.

Sıralama da farklı: yönetici anlatısı sonuç → gerekçe özeti → sonraki adım sırasını izler (bir karar vericinin dikkat süresi kısa, en önemli bilgiyi en başta ister); teknik anlatı problem → mekanizma → bağımlılıklar → riskler → doğrulama yöntemi sırasını izler (bir mimarın güveni, gerekçenin adım adım takip edilebilir olmasından gelir, sonuçtan değil).

Somut bir örnek: iki anlatının iskeleti

Soyut kuralın nasıl göründüğünü görmek için, kısa bir örnek. Yönetici anlatısının (~20 slayt) başlık akışı şöyle olabilir: (1) özet/öneri, (2) neden şimdi (Mosca/HNDL, M1), (3-4) üç ufuklu roadmap (M13), (5-6) maliyet aralığı ve varsayımlar (M13), (7-8) risk manzarası (M10/M14’ten en kritik 2-3 bulgu, detay değil sonuç), (9) governance/RACI özeti (M13), (10) itiraz/risk karşılama (bir önceki ders), (11) sonraki adım ve onay talebi, kalan slaytlar ek/yedek (appendix) olarak, sorulursa açılacak.

Teknik derinlemesine anlatının (~45 dakika) akışı farklı: (1) problem tanımı (kuantum tehdidi, M1-M2’nin matematiği), (2) algoritma seçimi ve gerekçesi (M3-M5), (3) mimari karar: hybrid/pure (M6, mekanizma dahil), (4) protokol/sertifika etkisi (M7-M8), (5) HSM/anahtar yönetimi (M9), (6) ödeme yüzeyleri varsa (M10), (7) keşif/CBOM/crypto-agility (M12), (8) bağımlılık grafiği ve roadmap detayı (M13), (9) bilinen riskler: HAWK/Simon 2026/side-channel (M14), (10) doğrulama yöntemi: her iddianın nasıl kontrol edilebileceği.

Bu iki iskelet, P4 (capstone) projesinin kendi kabul kriterine doğrudan bağlanıyor: yönetici sunumu, 5 dakikalık bir soru-cevabı savunabilecek şekilde çerçevelenmeli, hiçbir slaytta kaynaksız bir iddia olmamalı (her rakam bir ProvenanceBadge’e karşılık gelmeli); teknik derinlemesine anlatı, hostile bir mimarın sorabileceği en az üç takip sorusunu (örneğin: “hybrid neden gerekli,” “HSM’iniz gerçekten sertifikalı mı,” “implementasyon riski nasıl test edildi”) sunumun içinde, sorulmadan önce yanıtlamış olmalı.

Karışıklığın somut maliyeti

Bu iki anlatıyı karıştırmanın gerçek bir maliyeti var: yönetici anlatısına bir CA/Browser Forum ballot numarası veya bir FIPS bölüm numarası sokmak, kararı geciktiren bir dikkat dağınıklığı yaratıyor (toplantı “bu ballot ne demek” sorusuna kilitleniyor, asıl karar sorusundan uzaklaşıyor). Tersine, teknik anlatıda “yönetim kurulu bunu onayladı, bu yüzden güvenli” demek, bir mimarın sorması gereken soruyu (bu plan teknik olarak neden sağlam) hiç cevaplamıyor, sadece otorite argümanına (M13’ün “quantum snake oil” derste gördüğün kırmızı bayraklardan biri, “NIST seçti” ile “sertifikalı” karışıklığına benzer bir mantık hatası) başvuruyor. Her iki anlatının kendi doğru sırasında, doğru dinleyiciye sunulması, bir sonraki derste (mock workshop) test edeceğin becerinin temeli.

Numbers to know

İki anlatı, iki farklı amaç: yönetici anlatısı (risk/maliyet/takvim, ~20 slayt, bir KARAR almak için) karar vericiye hitap eder, sonuçla başlar; teknik derinlemesine anlatı (mekanizma/bağımlılık, ~45 dakika, bir UYGULAMAYI doğrulamak için) mimara/mühendise hitap eder, gerekçeyle başlar

Aynı içerik, ters sırayla anlatılırsa başarısız olur: yönetici anlatısında bir CA/Browser Forum ballot numarasıyla başlamak dikkat kaybettirir; teknik anlatıda 'bize güvenin, güvenli' demek mimarı ikna etmez, aksine güvensizlik yaratır

Lab: Kendi P4 sunumun için iki anlatıyı ayır

[not run] Bu bir sunum planlama alıştırması, çalıştırılabilir bir komut değil

shell

# M9-M14'te öğrendiğin içerikten bir liste çıkar: her madde için, bu 'yönetici anlatısına mı, teknik anlatıya mı, ikisine de mi' ait diye işaretle. İkisine de aitse, hangi seviyede (özet mi detay mı) her ikisinde de nasıl görüneceğini yaz

Recorded output

İki ayrı liste: yönetici anlatısı için ~20 madde (her biri bir slaytın özü), teknik anlatı için daha uzun bir liste (mekanizma detaylarıyla)

At the table

How to say this in a bank meeting.

To an executive

İki farklı toplantıda aynı sunumu kullanmak, ya yönetim kurulunu sıkar ya da mimarı ikna edemez. Bu ders, aynı gerçekleri, iki farklı dinleyiciye, iki farklı yapıda anlatmayı öğretiyor.

To an architect

Teknik derinlemesine anlatı, yönetici anlatısının 'özetlenmiş' hali değil, farklı bir amaca hizmet ediyor: yönetici anlatısı bir kararı onaylatmak için, teknik anlatı bir uygulamayı doğrulamak/eleştirmek için var. Bu yüzden teknik anlatı, yönetici anlatısının atladığı bağımlılıkları (M13'ün bağımlılık grafiği gibi) ve mekanizmaları (M6'nın hybrid KEX mekanizması gibi) içermeli.

Objection

“"İki ayrı sunum hazırlamak zaman kaybı değil mi, tek bir kapsamlı sunum herkese yetmez mi?"”

Answer

Tek bir sunum, ya yönetim kurulunu teknik detayla boğar (ve kararı geciktirir) ya da mimarı yeterince derine inmediği için ikna edemez (ve implementasyonda güven kaybına yol açar). İki ayrı yapı, aynı araştırmayı iki kere yapmak değil, aynı araştırmayı iki farklı sırayla ve derinlikte sunmak.

Project linkP4 (capstone) sunumunun doğrudan yapısal iskeleti: bu dersteki iki-anlatı ayrımı, capstone'un teslim edilecek iki ayrı belgesinin (yönetici özeti + teknik ek) şablonu.