Teknik bir konuyu uzman olmayan birine nasıl anlatırsınız?

Teknik bir konuyu uzman olmayan birine anlatırken önce onun hangi soruya cevap aradığını öğrenin. Ardından işini etkileyen sonucu açıklayın, gerekli teknik kelimeleri somut anlamlarıyla tanıtın ve örneği dinleyenin bildiği bir görevden seçin. Sonunda “Anladınız mı?” demekle yetinmeyin; bilgiyi kendi işinde nasıl kullanacağını sorun. Sadeleştirmek, önemli ayrıntıyı silmek değil, gerekli bilgiyi karşı tarafın kullanabileceği hale getirmektir.

Siz sistemin bütün ayrıntısını biliyor olabilirsiniz. Dinleyen kişi ise yalnız raporun neden güncellenmediğini veya kendisinden hangi işlemin beklendiğini öğrenmek istiyor olabilir. Açıklama bu farktan başlamalı.

Gerçek bir kurum sade dili okuyucunun ihtiyacıyla tanımlıyor

ABD kamu hizmeti rehberi Digital.gov, sade dili herkes için aynı düzeye indirmek olarak görmüyor. Açıklamanın belirli okuyucunun bilgisine, ilgisine ve ihtiyacına uygun olmasını istiyor.

Bu yaklaşım ofiste önemli bir ayrımı gösterir. Uzman olmayan biri bilgisiz değildir; yalnız sizin uzmanlık alanınızdaki kelimeleri kullanmıyor olabilir. Finans yöneticisinin veri aktarım ayrıntısını bilmemesi, finansal kararı anlamadığı anlamına gelmez. Açıklamayı onun bildiği işle ilişkilendirmek gerekir.

İlk sorunuz “Bu konuda ne kadar bilginiz var?” olmak zorunda değil. “Bu bilgiyi hangi iş için kullanacaksınız?” daha doğal bir başlangıç olabilir. Bilgi vereceğiniz kişi bir işlem yapacaksa işlem adımları, karar verecekse seçenek ve etkiler daha önemli hale gelir.

Kelimeyi değil, ihtiyacı çevirmeye başlayın

Şöyle bir durum düşünün: Satış ekibindeki bir çalışma arkadaşınız ortak rapordaki yeni kayıtları göremiyor. Teknik açıklamanız ilk anda şöyle: “API entegrasyonunda senkronizasyon sorunu var; veri güncellemesi gerçekleşmedi.”

Bu cümle sizin için anlamlı, fakat dinleyen kişi ne olduğunu veya ne yapacağını çıkaramayabilir. Şöyle açıklayabilirsiniz: “Satış sistemindeki yeni kayıtlar rapora henüz aktarılmadı. Bu yüzden raporda eski bilgiler görünüyor. Aktarım sorununu kontrol ediyoruz. Güncel kayıtlar görünmeden bu rapordaki toplamı son durum olarak kullanmayın.”

Yeni açıklama önce görülen sorunu ve iş üzerindeki etkisini anlatıyor. Teknik ayrıntıyı bütünüyle silmiyor; bu aşamada gereken bilgiyi seçiyor. Dinleyen kişi neden eski kayıt gördüğünü ve hangi sınırla ilerleyeceğini anlayabiliyor.

Konu ayrıca teknik terim öğrenmeyi gerektiriyorsa kelimeyi ekleyebilirsiniz: “API, iki uygulamanın belirli kurallarla bilgi alışverişi yapmasını sağlayan arayüzdür. Buradaki sorun, bu bağlantı üzerinden yeni kayıtların rapora geçmemesi.” Böylece terim, anlaşılmayan ilk cümlenin merkezinde değil, somut sorunun açıklaması olarak yer alır.

Her teknik kelimeyi çıkarmak gerekmez

Digital.gov'un içerik erişilebilirliği rehberi, gerekli teknik terimleri geçtikleri yerde açıklamayı öneriyor. Özellikle kısaltmayı tek başına kullanmak yerine önce anlaşılır adını ve anlamını vermek önemli olabilir.

Dinleyen kişi daha sonra destek ekibine başvuracaksa doğru terimi bilmesi faydalıdır. Kelimeyi tamamen çıkarırsanız hangi sorunu anlatacağını bulamayabilir. Bunun yerine “Bu dosyadaki sürüm numarası, hangi güncellemenin kullanıldığını gösterir” gibi kısa açıklama ekleyebilirsiniz.

Terimin bütün akademik tanımını vermeniz gerekmez. Görev için anlamını açıklayın; tanımın sınırını koruyun. Bir benzetme kullanıyorsanız gerçek işle nasıl farklı olduğunu da düşünün. Örneğin bir veri kaynağını “kitaplık” diye anlatmak dosya yerini anlamaya yardımcı olabilir, fakat kayıtların otomatik güncellendiğini açıklamaz.

Teknik konuyu grafikte gösteriyorsanız hangi grafik türünün ne zaman kullanılacağını anlatan rehber işin sorusuna uygun gösterimi seçmenize yardımcı olur. Karmaşık görünmesi, grafiğin daha doğru veya faydalı olduğu anlamına gelmez.

Sadeleştirirken önemli sınırı kaybetmeyin

“Sistem çalışmıyor” cümlesi kısa olabilir, ama bütün sistemin kapalı olduğu izlenimini oluşturabilir. Sorun yalnız rapor aktarımındaysa bunu söyleyin. “Satış kaydı alınabiliyor; yeni kayıtların rapora geçmesi henüz doğrulanmadı” daha doğru bir açıklamadır.

Aynı dikkat kesinlikte de gerekir. Sorunun nedeni henüz bulunmadıysa “Bağlantı kopmuş” diyerek nedeni seçmeyin. “Yeni kayıtların geçmediğini görüyoruz; nedeni kontrol ediliyor” diyebilirsiniz. Teknik konuyu basit anlatmak, bilmediğiniz kısmı biliniyormuş gibi sunma izni değildir.

Bu örnekte alıcının karar için ihtiyaç duyduğu bilgiyi üç parçaya ayırabilirsiniz: Ne görüyoruz, hangi işi etkiliyor, şimdi ne yapılmalı? Bu bir sunum şablonu değil; çalışma ihtiyacını kontrol eden sorulardır. Görevi netleştirme yazısı, dinleyenin gerçekten hangi sonucu beklediğini öğrenmeye yardımcı olur.

Aynı açıklamayı farklı alıcılara aynen göndermek zorunda değilsiniz. Raporu kullanan kişi kapsam sınırını, aktarımı düzelten kişi ise ilgili teknik bulguyu bilmek isteyebilir. Gerçek bilgiyi değiştirmeden ayrıntı düzeyini uyarlayın. Ortak konuşmada herkesin ihtiyaç duyduğu kısa açıklamayı verip uzmanlık ayrıntısını uygun ayrı bölümde açabilirsiniz. Böylece bir grup için gereken teknik bilgi, diğer grubun temel sorusunu görünmez bırakmaz.

Açıklamanızı küçük bir uygulamayla sınayın

Sık kullandığınız teknik bir cümleyi seçin. Şu alanları doldurun:

Tabloyu konuşmada aynen okumanız gerekmez. Açıklamayı hazırlarken hangi ayrıntının işe yaradığını görmenizi sağlar. Dinleyenin yapacağı işlem değişmediyse gereksiz teknik geçmişi çıkarabilirsiniz.

Sonra “Bir sonraki adımınız ne olacak?” diye sorun. Cevap, açıklamanızdaki önemli sınırı kaçırıyorsa farklı bir örnekle yeniden anlatın. Karşı tarafın anlamamasını kişisel eksik saymayın; açıklama henüz görevle yeterince bağlanmamış olabilir.

Yazılı açıklamada kısa başlık, ilgili örnek ve gereken bağlantı yeterli olabilir. Profesyonel e-posta rehberi, okuyucunun beklenen adımı kolay bulmasına yardımcı olur. Teknik sözlük eklemek, mesajın içinde gerekli açıklamayı yapmanın yerine geçmez.

İşinizde bildiklerinizi farklı kişilere daha açık anlatmak için kariyer gelişim kursunun programını inceleyebilirsiniz. En sık hangi teknik konuda anlaşılmakta zorlandığınızı belirleyerek programı değerlendirin.

Sık sorulan sorular

Teknik kelimeleri tamamen çıkarmalı mıyım?

Hayır. Gerekli terimi kısa ve somut biçimde açıklayın. Dinleyenin daha sonra doğru soruyu sorması için kelimeyi bilmesi faydalı olabilir. Gereksiz jargon ile işe yarayan terimi ayırın.

Benzetme kullanmak her zaman faydalı mı?

Her zaman değil. Tanıdık bir örnek anlamayı kolaylaştırabilir; fakat gerçek konuyu yanlış anlatmamalı. Benzetmenin nerede yetersiz kaldığını düşünün. Gerekliyse sınırı kısa biçimde belirtin.

Anladınız mı diye sormak neden yeterli olmayabilir?

Karşı taraf kibarca evet diyebilir, fakat uygulamada farklı anlamış olabilir. Bilgiyi hangi işte nasıl kullanacağını sormak daha somut kontrol sağlar. Soruyu bir sınav gibi değil, açıklamanızın yeterliliği olarak kurun.

Ayrıntılar uzunsa ne yapmalıyım?

İş için gerekli açıklamayı ana metinde tutun, ek ayrıntıyı uygun bağlantıyla verin. E-posta yazım rehberi, okuyucunun amaç ve adımı ayırmasını kolaylaştırır. Önemli kullanım sınırını ek dosyada gizlemeyin.