Teknik Konuyu İş Sonucuna Çevirme ve Sunum

İlk derste Arven görüşmesinin amaç, karar, dinleme ve teyit sözleşmesini kurdun. Bu derste teknik konuyu farklı rollere anlatırken aynı gerçeği koruyacaksın. İyi teknik sunum bir ürün katalog gezisi değildir. Müşteri sorusunu, teknik mekanizmayı, gözlenebilir iş etkisini ve kanıt sınırını bir araya getirir. Örneğin 'iki site replikasyonu' BT liderine veri tutarlılığı ve failover topolojisi, CFO'ya kesinti etkisi, operasyon ekibine test ve runbook sorusu olarak görünür. Her rol için farklı ilk cümleyi seçebilirsin, fakat RPO hedefi ve test durumu değişmez. Konuşmacı 'kanıtlandı' ile 'planlandı' sözcüklerini karıştırmaz. Arven için 30 dakika RPO tasarım hedefi varsa ama site kaybı tatbikatı yapılmadıysa slayt ve sözlü yanıt bunu açık söyler. Digital.gov okuyucu/dinleyici odaklı yazım rehberi farklı kitlelerin farklı sorularını ayırmayı önerir. Bu ilkeden yararlanıyoruz; teknik kabul ve satın alma şartları yine müşterinin belgelerinde belirlenir. Yaklaşık 29 dakika anlatı, 28 dakika uygulama, 12 dakika kontrol önerilir.

Teknik olguyu iş sonucuna çevirirken dört halkayı sırala: durum, mekanizma, ölçülebilir sonuç, sınır. 'ERP olay kuyruğu ve yeniden deneme' mekanizmadır; 'siparişin kullanılabilir hale gelme gecikmesi' iş sonucudur. POC 100 kayıt için 4,8 dakika gösteriyorsa bu gözlemdir; 1 milyon kayıt için 15 dakika hedefi hâlâ test edilecektir. 'Daha hızlı' gibi göreli sıfat için baseline gerekir. Üretici datasheet'i bir kabiliyet sağlar ama Arven'in veri modeli ve operasyon koşulunda sonucu ispatlamaz. Her sunum parçasında kaynak ID ve tarih/sürüm bulunsun; konuşmacı notları ayrıntıyı taşıyabilir ama kritik koşul yalnız notta kalmamalıdır. İş sahibi için ölçü kullanıcı etkisidir; mimar için ölçü gecikme, IOPS veya failover zamanı olabilir. Aynı metrikler farklı karar sorularına bağlansa da formül ve veri kaynağı tutarlı kalır. Terim ilk geçtiğinde kısaca açıklanır, sonra gerekirse teknik derinlik açılır.

Teknik sunum üç derinlikte hazırlanır: 30 saniyelik sonuç, iki dakikalık neden ve gerektiğinde beş dakikalık kanıt/alternatif. İlk katman müşterinin iş sorusunu yanıtlar. İkinci katman mimarinin neden bu sonucu hedeflediğini söyler. Üçüncü katman topoloji, test, BoM/lisans ve risk belgelerine iner. Bu katmanlar arasında 'isterseniz ayrıntıyı açayım' diye dinleyici izni al; bir sorunun cevabı üçüncü katmandaysa sürekli ilk katmanda kalma. CFO maliyet duyarlılığını soruyorsa lisans entitlement tablosuna geçilebilir; BT lideri veri yerleşimini soruyorsa akış diyagramındaki bölge ve kopyaları aç. Digital.gov sade dil rehberi ana noktayı önce vermeyi ve ardından gerekliyse arka plan eklemeyi önerir. Teknik kesinlik bu düzenle korunur. Birinci katmanı basitleştirmek için yanlış benzetme kullanma. 'Sistem asla kesilmez' yerine hangi failure domain, test ve bakım senaryosunda hizmetin sürdüğünü söyle.

Diyagram ve demo sunum akışının hizmetindedir. Önce hangi soruyu yanıtladığını söyle, sonra görselde yalnız ilgili veri yolunu vurgula, ardından kanıtı ve sınırı özetle. Tüm HLD'yi küçük puntoda tek slayta sığdırmak dinleyicinin kararı kolaylaştırmaz. Arven ERP akışında olay kaynağı, adaptör, kuyruk, hedef ERP ve hata geri dönüşü yeterli ilk görünüm olabilir. Derin katmanda kimlik, ağ sınırı, izleme ve yeniden deneme gösterilir. Demo canlı ortamda çalışmazsa sessizce 'böyle olması gerekiyordu' denmez; önceden hazırlanmış doğrulanmış kayıt veya test raporu kullanılır ve bunun canlı gözlem değil geçmiş kanıt olduğu açıklanır. CDC'nin Clear Communication Index'i sağlık içeriğinin hedef kitle ve ana mesajına bakar; bunu Arven için şablon gibi puanlamayız. Ancak sunum provasındaki yararlı soru şudur: farklı rol, gösterilen görselden hangi ana mesajı çıkarıyor? Yanlış çıkarıyorsa görsel veya anlatım değişir.

Sunum bittikten sonra yalnız 'soru var mı?' demek ortak anlayışı test etmez. Bir karar cümlesi sor: 'Bugün hangi sonucu ve hangi açık koşulla onaylayacağımız net mi?' veya 'ERP testinde kabul eşiğini nasıl özetlersiniz?' Bu, müşteriyi sınamak değil, senin açıklamanın nasıl duyulduğunu görmektir. Dinleyici 'üretimde 15 dakika garanti' diye tekrar ederse, POC sınırını ve yük testini anında düzelt. Özellikle teknik kısaltmalar farklı ekiplerde başka anlama gelebilir. CDC'nin açıklık kontrolünde ana mesaj ve eylemin hedef kitlece anlaşılması sorgulanır; burada aynı fikri sözlü teyide uyarlıyoruz. Bir örnek senaryo kullanmak soyut mimariyi açıklar ama tek örneği evrensel sonuç gibi göstermemelidir. İyi test, dinleyicinin karar, kanıt ve açık koşulu kendi sözcükleriyle doğru özetleyebilmesidir. Yanlış anlaşılma ortaya çıkarsa slayt, teklif metni veya meeting note düzeltilir.

Soru sırasında önce hangi kısmın sorulduğunu ayır. 'Güvenli mi?' veri şifreleme, erişim, lokasyon, olay müdahalesi veya sözleşme sorusu olabilir. 'Hangi riskinizi kastediyorsunuz?' diye sor. Sonra bilinen gerçeği, ilgili kanıtı ve sınırı açıkla. Cevap bilinmiyorsa owner ve geri dönüş tarihiyle kayıt aç. Aynı soru iki rolden geliyorsa yanıtı iki farklı iş etkisiyle ifade et ama teknik gerçek değişmesin. Ekran paylaşımında küçük yazılı slaytı okumak yerine soruyla ilgili bölümü büyüt veya metin özetini ver. Microsoft erişilebilir PowerPoint rehberi benzersiz başlık ve mantıklı okuma sırasını önerir; bu, toplantı sonrası dosyada da teknik argümanı takip etmeyi kolaylaştırır. İtirazı hızla 'müşteri anlamıyor' diye etiketleme; bir sonraki derste bilgi eksiği, farklı değerlendirme ölçütü, gerçek gap ve değişim riskini ayrı teşhis edeceğiz.

Teknik sunumun kapanışında tüm detayları yeniden anlatma. Müşteri hedefini, önerilen yöntemi, doğrulanmış kanıtı, açık koşulu ve istenen kararı beş cümlede toparla. Arven için örnek: sipariş görünme süresi hedefi 15 dakika; adaptör/kuyruk yaklaşımı öneriliyor; 100 kayıt POC'u 4,8 dakika gösterdi; üretim hacmi ve 7/24 servis eki açık; bugün ölçek testinin veri/bütçe/kabul planını onaylayın. Bu cümlelerde 7/24 destek eksikse hangi toplantıda çözüleceği de yazılır. Karar yetkilisi yoksa onay varmış gibi davranma. Açık teknik sorular için kaynak ID, owner, son tarih ve etkilenen teklif/POC kararı kaydedilir. Teknik sunum iş bitişi değildir; iyi bir sonraki adım oluşturur. Dinleyici farklı yorumladıysa önce tanımı düzelt, sonra takip oluştur. Kurum dışına follow-up gönderimi yalnız yetkili kanal ve organizasyon süreciyle yapılır; bu eğitim kaydı dış mesaj yetkisi vermez.

Sunum sonrası 'fiyat pahalı', 'riskli', 'vendor'a bağımlıyız' gibi itirazlar gelebilir. Şimdilik bunları hemen çürütmeye çalışma; önce hangi karar ölçütüne dayandığını ve hangi kanıtın eksik olduğunu sor. 'Pahalı' üç yıllık TCO farkı, nakit çıkış zamanı veya belirsiz lisans hakkı olabilir. 'Riskli' veri yerleşimi, operasyon kabiliyeti, teknik performans veya sözleşme olabilir. Doğru sınıflandırma üçüncü dersin konusu olacak. Bu dersten çıkarken itirazı soru defterine kaynaklı, rol bazlı ve açık karar etkisiyle kaydetmeyi öğren. Eğer müşteri talep etmediği bir özelliği sunumda uzun uzun anlattıysan geri bildirimden bunu çıkar; gelecek görüşmenin zamanını müşterinin gerçek sorusuna ayır. Kapanışın başarılı olup olmadığı alkışla değil, aynı gerçeğin anlaşıldığını ve sonraki karar adımının sahibini gösteren notla anlaşılır.