Uzman, karma ve konuya yabancı dinleyiciler için teknik ayrıntıları seçme; açıklamayı katmanlandırma ve doğruluğu koruyarak sadeleştirme rehberi.
Bir sistemi anlatmaya başladığınızı düşünün. İlk cümle gayet açık. Sonra bir kavramı açıklamak için başka bir kavrama, onu açıklamak için de küçük bir teknik ayrıntıya giriyorsunuz. Bir süre sonra siz bile “Ben buraya nereden geldim?” diye düşünüyorsunuz. Konuyu iyi bilince, anlatılmaya değer pek çok şey oluyor.
Teknik bir konuyu sade anlatmak için önce dinleyicinin neyi anlaması veya yapması gerektiğini belirlemek işe yarar. Sonra açıklamayı adım adım derinleştirebilirsiniz: ana fikir, işleyiş, gerektiğinde açılacak ayrıntılar. Bunu yaparken sonucu değiştiren koşulları, sınırları ve belirsizlikleri de açıkça söylemeniz gerekir.
Karşınızdaki kişi neyi merak ediyor?
Bir müşteri toplantısında, mühendislik ekibinin karşısında veya büyük bir sahnede aynı ürünü anlatabilirsiniz. Her seferinde biraz farklı bir hazırlık gerekir. Üstelik dinleyicinin ne bildiğini yalnızca unvanına bakarak anlamak güçtür. Bir yazılım uzmanı sizin altyapınızı tanımayabilir; teknik unvanı olmayan bir müşteri ise ürünün sınırlarını sizden daha çok deneyimlemiş olabilir.
Hazırlıkta şu dört soruya yer açın:
- Bu kişiler konu hakkında neleri zaten biliyor?
- Hangi soruya cevap bulmak için buradalar?
- Anlatımdan sonra neyi açıklayabilmeli veya yapabilmeliler?
- Yanlış anlaşılırsa hangi karar ya da uygulama etkilenir?
Google’ın teknik yazımda hedef kitle rehberi de kişinin rolüyle birlikte konuya yakınlığını ve mevcut bilgisini değerlendirmeyi önerir. Bunun için uzun bir araştırma yapmanız şart değil. Toplantıdan önce “Temel işleyişe mi bakalım, entegrasyona mı, yoksa zorlandığınız durumlara mı?” diye sorabilirsiniz.
Uzmanlık ve ilgi her zaman aynı yere çıkmıyor
Uzman bir grubun karşısındaysanız ortak kavramları kısa geçip yöntemlere, varsayımlara ve istisnalara zaman ayırabilirsiniz. Konuya yeni başlayanlarla somut bir kullanım üzerinden ilerlemek daha uygun olabilir. Karma bir grupta ise önce herkesin izleyebileceği bir çerçeve kurup teknik ayrıntıyı nerede açacağınızı söyleyin.
Bir nokta daha var: Konuyu çok iyi bilen kişi her ayrıntıyı duymak istemeyebilir. Belki o gün yalnızca bakım yükünü değerlendirmek için oradadır. Konuya yeni başlayan biri de sistemi kuracağı için bütün adımlara ihtiyaç duyabilir. “Ne kadar biliyor?” sorusunun yanına “Bugün neye ihtiyacı var?” sorusunu ekleyin.
Slaytlardan önce bir cümle yazın
“Bu anlatımın sonunda dinleyici…” Cümleyi nasıl tamamlarsınız? “Ürünümüzü tanıyacak” biraz geniş kalıyor. “Hangi işlerin arka planda yürütülebileceğini ayırt edecek” dediğinizde hazırlığınızın yönü belirginleşmeye başlıyor.
Bunun gerçekleşmesi için ne gerekir? Küçük bir hazırlık sırası işinizi kolaylaştırabilir:
- Sunumun cevaplayacağı ana soruyu yazın.
- Cevabınızı tek cümlede söylemeyi deneyin.
- Bu cevabı taşıyan iki veya üç ana nokta seçin.
- Her noktanın yanına örneğini, kanıtını ve gerekli koşulları ekleyin.
- Hangi ayrıntıyı konuşacağınızı, hangisini sorulara veya ek dokümana bırakacağınızı belirleyin.
Örneğin “Yeni rapor sistemini tanıtmak” için hazırlandığınızda bütün özellikleri anlatmak isteyebilirsiniz. “Kullanıcıya ne zaman ‘rapor hazır’ diyebiliriz?” sorusuyla başladığınızda ise durumlar, bekleme süresi ve hata davranışı öne çıkar.
Kapsamı dinleyiciyle de paylaşın: “Bugün kullanıcı akışını ve hata durumlarını konuşacağız; kurulum adımları ek dokümanda.” Böylece kurulum ayrıntısını bekleyen kişi de aradığının nerede olduğunu bilir. Yönetim toplantılarında karar ve veri anlatımının genel çerçevesini yöneticilere yönelik sunum rehberinde ayrıca ele aldık.
Aynı konuyu üç farklı derinlikte anlatmayı deneyin
Elinizde otuz saniyelik, iki dakikalık ve daha ayrıntılı bir açıklama olsun. Bu süreleri prova için kullanabilirsiniz; kronometreye yetişmek için konuşmanızı hızlandırmanız gerekmiyor.
Yaklaşık 30 saniye: konu, amaç ve önemli bir sınır
Şöyle bir açıklama düşünün: “Rapor talebi alındığında ekranı uzun süre bekletmek yerine raporu arka planda hazırlamayı öneriyoruz. Kullanıcı talebinin durumunu görebilecek. Talebin alınması, raporun tamamlandığı anlamına gelmeyecek.”
Burada dinleyici öneriyi ve ne işe yarayacağını duyuyor. Aynı zamanda yanlış anlaşılabilecek bir nokta en baştan açıklanıyor.
Yaklaşık iki dakika: işleyişi biraz açın
Şimdi talebin nasıl kaydedildiğini, işlendiğini ve sonucun nasıl görüntülendiğini ekleyebilirsiniz. İş başarısız olursa kullanıcının ne göreceğini de anlatın. Bu aşamada her bileşenin iç yapısını açıklamak zorunda değilsiniz; bir talebin başına neler geldiğini takip etmek yeterli olabilir.
Daha derin açıklama: koşullar ve teknik kararlar
Tekrar deneme politikası, kapasite, yetkilendirme, veri saklama, izleme ve test yöntemi burada açılabilir. Mimari incelemede sunumun büyük kısmını bunlara ayırabilirsiniz. Kısa bir ürün tanıtımında ise sorulara veya ek dokümana bırakmanız uygun olabilir.
Yalnız, üç anlatımda da söylediğiniz şey aynı kalmalı. İlkinde “anında hazır” dediğiniz raporun sonradan kuyrukta beklediği ortaya çıkıyorsa, ilk cümleyi yeniden düşünmek gerekir.
Bir ayrıntıyı çıkarmadan önce sorun: ne değişir?
Teknik sunum hazırlarken bazı ayrıntıları çıkarmak zor gelebilir. Onları öğrenmek, geliştirmek veya çözmek için epey uğraşmış olabilirsiniz. Yine de dinleyicinin o günkü ihtiyacına bakmak işinizi kolaylaştırır: “Bunu anlatmazsam yanlış bir sonuca ulaşabilir mi?”
Cevap evetse ayrıntıya ana anlatımda yer verin veya açıkça işaret edin. Özellikle şu bilgiler kaybolmasın:
- Önerinin hangi koşullarda geçerli olduğu
- Güvenlik, veri kaybı, maliyet ve kullanım açısından önemli sınırlar
- Ölçümün nasıl yapıldığı ve neleri kapsamadığı
- Henüz doğrulanmamış varsayımlar
- Bir seçeneği tercih ederken nelerden vazgeçildiği
Bir bileşenin sürüm numarası, belirli bir uyumluluk sorununu açıklarken çok önemlidir. Genel işleyişi konuşurken aynı bilgiye ihtiyaç olmayabilir.
“Daha hızlı” dediğinizde de bir an durun. İlk yanıt mı hızlanıyor, işin tamamlanması mı? Yoğunluk altında bekleme mi azalıyor? Test ortamındaki sonucu canlı kullanımın garantisi gibi sunmayın. Henüz ölçmediyseniz “Azalmasını bekliyoruz; pilotta ölçeceğiz” demek yeterince açık bir cümledir.
Teknik kelimelere küçük bir açıklama eşlik etsin
“Asenkron” yerine “eşzamansız” dediniz. Peki dinleyicinin zihninde bir şey canlandı mı? Bazen kelimeyi çevirmek yetmez; olanı anlatmak gerekir: “İş arka planda devam ediyor. Kullanıcı tamamlanmasını aynı ekranda beklemek zorunda kalmıyor.”
Terime daha sonra ihtiyaç duyacaksanız adını da söyleyin. Google’ın jargon kullanım rehberi, gerekli terimleri ilk kullanımda açıklamayı önerir. Sonrasında aynı kavram için aynı adı kullanmak, dinleyiciyi “Acaba şimdi başka bir şeyden mi söz ediyor?” diye düşündürmez.
Benzetmeler de yardımcı olabilir, ama sınırlarını söylemek kaydıyla. İş kuyruğunu sıra numarası alınan bir hizmet noktasına benzettiniz diyelim. Ardından şunu ekleyebilirsiniz: “Bu benzetme bekleyen işleri anlatıyor. Bizim sistemde işler farklı önceliklerle işlenebilir; tamamlanma sırası değişebilir.”
Benzetmeyi düzeltmek, konunun kendisini anlatmaktan uzun sürmeye başladıysa küçük bir süreç çizimine geçebilirsiniz.
Bir teknik açıklamayı birlikte açalım
Aşağıdaki rapor sistemi kurmaca bir öğretici örnektir. Gerçek bir ürünün özelliklerini veya ölçülmüş performansını anlatmıyor.
İlk hali
“Rapor üretimini asenkron worker’lara taşıyıp kuyruk üzerinden yürüteceğiz. Retry ve idempotency mekanizmaları olacak. Böylece kullanıcı tarafındaki bekleme problemini çözeceğiz.”
Bazı uzmanlar bu paragrafı rahatlıkla takip edebilir. Yine de sorular kalıyor: Hangi bekleme değişecek? Kullanıcı ne görecek? Son cümlede söylenen sonuç ölçüldü mü?
Biraz açılmış hali
“Önerdiğimiz tasarımda kullanıcı rapor istediğinde talebin alındığını görecek. Raporu hazırlayan işlem arka planda çalışacak; kullanıcı durumu daha sonra kontrol edebilecek. Böylece ekranın rapor bitene kadar açık kalmasına gerek olmayacak.
Bu tasarım tek başına raporun daha kısa sürede hazırlanacağını garanti etmiyor. Yoğunluk varsa iş bekleyebilir. İş başarısız olursa kullanıcıya ‘rapor hazır’ göstermeyeceğiz. Geçici hatalarda belirlediğimiz sınırlar içinde yeniden deneyeceğiz. Aynı talebin yeniden işlenmesi halinde mükerrer sonuç oluşmaması için ayrıca kontrol tasarlayacağız.”
Uzmanlarla buradan devam edebilirsiniz
“Yeniden denemenin sınırı nedir?”, “Mükerrer talep nasıl tanınacak?”, “Hangi hata kalıcı sayılacak?” Tasarım kararları ve testler bu sorulara cevap vermeli. Bir mekanizmanın adını söylemek, her hata durumunu çözdüğünü göstermeye yetmez.
Açıklamada artık kullanıcı da var: Ne görüyor, neyi bekliyor, hata olduğunda ne yapıyor? Teknik konuyu insanın deneyimiyle buluşturmak için bazen bu soruları takip etmek yeterli oluyor.
Şemayı, o anda konuştuğunuz soru için çizin
Bütün mimariyi tek slayta sığdırmak cazip gelebilir. Rapor örneğinde önce “talep alındı”, “hazırlanıyor”, “hazır” ve “başarısız” durumlarını gösterip ardından ihtiyaç duyulan bileşenleri açmayı deneyin.
Slaytın başlığı da anlattığınız fikri söylesin: “Talep kabulü ile raporun tamamlanması ayrı durumlar.” Okların neyi gösterdiğini yazın. Durumları renklerin yanında adlarıyla da belirtin. Büyük bir salonda sunacaksanız arka sıraya geçip bakın; bilgisayarınızda rahatça okuduğunuz etiketler oradan da okunuyor mu?
Grafiklerde ölçüm birimini, zaman aralığını, veri kapsamını ve kaynağını gösterin. Ortalama değer, önemli yavaşlıkları gizliyor olabilir mi? Varsayımsal grafiğe “örnek veri” yazdınız mı? Genel slayt akışını kurarken etkili sunum teknikleri rehberinden de yararlanabilirsiniz.
Sorular gelince ve siz ayrıntıya dalınca
Karşınızdaki kişi ürünü sizden daha çok kullanmış olabilir. “Sizin kullanımınızda hangi koşul belirleyici?” diye sorarak deneyimini konuşmaya katabilirsiniz. Cevap verirken bildiğiniz kısmı, bunun geçerli olduğu koşulu ve emin olmadığınız noktayı ayırın.
Bir düzeltme gelirse hangi duruma ait olduğunu anlamaya çalışın: “Bu davranışı hangi sürümde veya yapılandırmada görüyorsunuz?” Belki farklı koşullardan söz ediyorsunuzdur. Bilginiz yanlışsa ilgili cümleyi düzeltin; bilmiyorsanız tahmininizi kesin bir bilgi gibi sunmayın.
Ayrıntılı bir soru ortak kararı değiştirmiyorsa kısa cevabı verip devamını planlayabilirsiniz: “Kısa cevap şu… Yapılandırma ayrıntısını soru-cevapta açalım; şimdi kullanıcı akışına dönüyorum.” Soruyu not edin ve geri dönün. Kararı etkileyecek bir güvenlik veya doğruluk sorusunu ise akış bozulmasın diye ertelemeyin.
Bazen soran olmadan da ayrıntıya dalıyoruz. Başlangıçtaki “Buraya nereden geldim?” anına dönersek, çıkmak için üç küçük cümle hazırlayabilirsiniz:
- “Burada uygulama ayrıntısına girdim.”
- “Bu ayrıntının ana konumuz açısından önemi şu…”
- “Şimdi hata olduğunda kullanıcının ne göreceğine bakalım.”
Bu geçişleri notlarınıza yazın. Konu başlıklarını bilmek kadar, birinden diğerine nasıl döneceğinizi denemek de işe yarar.
Prova yaparken “Anlaşıldı mı?” sorusunu biraz açın
Mümkünse bir alan uzmanı ve konuya daha uzak bir kişiyle prova yapın. Uzmandan doğruluğa ve eksik koşullara, diğer kişiden anlatımı nerede takip edemediğine bakmasını isteyin.
Şu noktalara “belirsiz”, “kısmen açık” veya “açık” değerlendirmesi verebilirler:
- Ana soru ve sonuç anlaşılıyor mu?
- Terimler ihtiyaç duyulmadan önce açıklanıyor mu?
- Sonucu değiştiren sınırlar görünür mü?
- Örnek ve görsel aynı açıklamayı destekliyor mu?
- Ayrıntıdan ana fikre dönüş izlenebiliyor mu?
Sonra “Bu sistem ne yapıyor, neyi garanti etmiyor?” diye sorun. Dinleyicinin kendi cümleleri, hangi kısmı yeniden ele alacağınızı gösterebilir. Her şeyi aynı provada düzeltmeye çalışmanız gerekmiyor. Bir noktayı değiştirin, yeniden anlatın. Bu işin biraz da kilometre tarafı var; anlattıkça, dinledikçe ve yeniden denedikçe kendi yolunuzu bulabilirsiniz.
Ekibinizin kendi teknik konuları üzerinde uygulamalı çalışmak isterseniz kurumsal iletişim eğitimi seçeneklerini inceleyebilirsiniz.
Sık sorulan sorular
Teknik sunumda bütün ayrıntıları anlatmak gerekir mi?
Dinleyicinin amacını karşılayan ayrıntıları anlatın. Çıkarıldığında yanlış karar doğuracak koşulları koruyun. Diğer ayrıntıları bulunabilir bir ek dokümana veya soru-cevap bölümüne taşıyın.
Dinleyici konuyu benden iyi biliyorsa nasıl sunum yapmalıyım?
Önce neyi bildiğini ve neyi merak ettiğini anlayın. Kullanım bağlamına ve açık sorulara odaklanıp iddialarınızı kanıtlarıyla sunun. Bilmediğiniz bir noktayı kabul ederek doğrulamanız gayet mümkündür; her soruya o anda cevap yetiştirmeniz gerekmez.
Uzmanlarla konuya yabancı kişiler aynı salondaysa ne yapmalıyım?
Ortak soruyla başlayın. Ana açıklamanın ardından hangi teknik ayrıntıları açacağınızı söyleyin. Bir ayrıntıya girmeden önce bunun hangi soruyu yanıtladığını belirtin; çıkarken sonucu herkesin takip edebileceği biçimde özetleyin.
Her teknik konuya hikâye eklemek zorunda mıyım?
Hayır. Kısa bir kullanım senaryosu, karşılaştırma veya süreç çizimi yeterli olabilir. Örnek kullanıyorsanız gerçek mi, varsayımsal mı olduğunu belirtin; hikâyeye uysun diye sistemin sınırlarını değiştirmeyin.
Ayrıntıya girince söyleyeceğimi unutursam nasıl toparlarım?
Son anlattığınız ayrıntının ana soruyla bağını tek cümlede kurun. Ardından notunuzdaki bir sonraki başlığa geçin. Açık kalan teknik kısmı kaydedip uygun bölümde tamamlayın.