Bir hekimin veya acil tıp çalışanının meslek hayatı boyunca yapacağı en zor, en ağır ve boğazı en çok düğümleyen görev nedir biliyor musunuz?
Bir ameliyatı yapmak değil; bir kalbe masaj yapmak da değil.

En zor görev; o ameliyathanenin veya acil odasının kapısını açıp, koridorda umutla bekleyen bir anneye, bir eşe ya da bir evlada bakıp şu cümleyi kurmaktır:
"Elimizden gelen her şeyi yaptık ama maalesef onu kaybettik."

O an o koridorda yapılacak en ufak bir iletişimsizlik, yanlış seçilmiş tek bir kelime veya gösterilecek soğuk bir kibir; insanların hayat boyu unutamayacağı devasa bir travmaya ve öfke patlamasına yol açabilir.

İşte bu yüzden modern tıp, kötü haber vermeyi hekimlerin anlık duygusal reflekslerine bırakmamıştır. Onkolojide ve acil tıpta dünya çapında kabul görmüş katı bir iletişim protokolü uygulanır: SPIKES Protokolü.

Robert Buckman ve Walter Baile tarafından geliştirilen bu protokol, en karanlık kriz anında bile iletişimin nasıl bir cerrahi zarafetle yürütülmesi gerektiğini 6 adımda emreder:

S (Setting up): Doğru ortamı hazırla. Koridorda ayaküstü konuşma; sakin bir odaya geç, göz teması kur, telefonu sessize al.
P (Perception): Karşı tarafın algısını ölç. "Şu ana kadar hastanın durumuyla ilgili size neler söylendi?"
I (Invitation): Detay sınırını çiz. Bilgiyi ne kadar duymak istiyorlar?
K (Knowledge): Kötü haberi doğrudan, dolambaçsız ve jargonsuz ver. Tıbbi Latince terimlerin arkasına saklanma.
E (Empathy): Duyguları kabul et ve alan aç. Sessiz kal, öfkeye ya da gözyaşlarına şefkatle eşlik et.
S (Strategy & Summary): Bundan sonraki net yol haritasını çiz. "Şimdi atacağımız adımlar şunlar..."

Peki, şimdi bu yüksek duygusal zekayı ve kriz disiplinini alın; yazılım dünyasında sistemlerin çöktüğü, veritabanlarının silindiği o kanlı kriz günlerinin tam ortasına yerleştirin.

"Teknik Bir Aksaklık Yaşanıyor" Yalanı

Bir teknoloji şirketinde production sunucusu çöktüğünde veya büyük bir veri sızıntısı yaşandığında sergilenen kurumsal iletişim performansı genellikle tam bir sefalettir.

Sistem patlamıştır; e-ticaret sitesi çalışmıyordur, kullanıcılar ödeme yapamıyordur.
Yönetim panik içindedir, müşteriler Twitter'da öfkeyle yazıyordur.

Peki mühendislik ekibi veya kurumsal iletişim ne yapar?
Ya kapıları kilitleyip saatlerce hiçbir açıklama yapmazlar (ölüm sessizliği), ya da kullanıcıların zekasıyla alay eden o meşhur kalıp cümleyi sosyal medyaya yapıştırırlar:
"Sistemlerimizde planlı bir bakım çalışması / teknik bir aksaklık yaşanmaktadır. Anlayışınız için teşekkür ederiz."

Müşteri bilir ki o bakım planlı değildir. Müşteri parasının nerede olduğunu, siparişinin akıbetini ve ne zaman düzeleceğini öğrenmek istiyordur. Karşısında şeffaf bir insan bulamayınca da öfkesi çığ gibi büyür; markaya olan güven sıfırlanır.

Kriz anında iletişimi yönetemeyen bir ekip; kodu düzeltseler bile şirketin itibarını mezara gömer.

SPIKES Protokolü ile Kriz İletişimi

Bir yazılım krizinde müşterinize, şirketinizin CEO'suna veya yatırımcılarınıza durumu izah etmek zorundaysanız; tıptaki SPIKES protokolünü klavyenizin başına taşımak zorundasınız:

1. Setting Up (Kriz Masasını Kur)

Gürültüyü kesin. Yüz farklı Slack kanalında dedikodu dönmesine izin vermeyin. Hemen tek bir resmi kriz kanalı (#incident-2026-payment) açın. Bir Incident Commander (Kriz Lideri) ve iletişimi dışarıya aktaracak tek bir İletişim Sorumlusu (Scribe) belirleyin.

2. Perception (Karşı Taraf Neyi Görüyor?)

Müşterinin veya üst yönetimin krizden ne kadar haberdar olduğunu ölçün. Yöneticiniz sadece Twitter'daki 3 şikayeti mi gördü, yoksa cironun durduğunu biliyor mu? İletişime onların bulunduğu gerçeklik zemininden başlayın.

3. Knowledge (Jargonsuz, Çıplak Gerçek)

Yöneticinize veya müşterinize "PostgreSQL WAL dosyalarındaki I/O darboğazı yüzünden connection pool tükendi" demeyin. Bu, bir hasta yakınına "Miyokard enfarktüsü sonrası ventriküler disfonksiyon gelişti" demekle aynı şeydir; sadece kafa karıştırır ve güvensizlik yaratır.
Net konuşun:
"Ödeme servisimiz saat 14:15 itibarıyla yanıt vermeyi durdurdu. Şu an hiçbir kullanıcımızdan tahsilat yapamıyoruz ve yeni sipariş alamıyoruz."

4. Empathy (Acıyı ve Etkiyi Paylaş)

Karşı tarafın stresini ve kaybını kabul edin:
"Bu kesintinin şirketimizin bugünkü cirosunu ve Black Friday kampanyasını ne kadar kritik bir şekilde etkilediğinin tamamen farkındayız. Yaşattığımız aksaklık için ekibim adına samimiyetle özür dilerim."

5. Strategy & Summary (Yol Haritası ve Zaman Sınırı)

İşte krizdeki paniği söndüren ve güveni yeniden inşa eden en hayati adım:

"Şu an sorunun son deploy edilen koddan kaynaklandığını tespit ettik."
"Geri alma (rollback) sürecini başlattık."
"Tahmini toparlanma süremiz 25 dakikadır."
"Bir sonraki durum güncellemesini saat tam 14:45'te, sorun çözülmüş olsa da olmasa da bu kanaldan paylaşacağım."

Şeffaflık Güven İnşa Eder

İnsanlar krizlerden korkmazlar; insanlar bilinmezlikten ve yalandan korkarlar.

Bir cerrah gözlerinizin içine bakıp dürüstçe "Durum çok kritik ama şu an ameliyathanede her şeyi kontrol altına almaya çalışıyoruz, 20 dakika sonra tekrar bilgi vereceğim" dediğinde içinizdeki o dehşet dalgası sakinleşir. O hekime güvenirsiniz.

Yazılımda da müşterileriniz ve yöneticileriniz kusursuz bir sistem beklemez; çünkü onlar da teknolojinin kırılabileceğini bilirler.
Onların tek beklentisi; kriz anında yalan söylemeyen, teknik jargona sığınmayan, sorumluluktan kaçmayan ve soğukkanlılıkla krizi yönetebilen olgun profesyonellerle çalışmaktır.

Kriz anında panik bulaşıcıdır.
Ama şeffaf, dürüst ve yapılandırılmış bir iletişim; en büyük felaketleri bile sarsılmaz bir sadakate dönüştürebilir.

Kriz Yönetimi

Hastaya "Kötü Haber Verme" Protokolü (SPIKES) ve Müşteriye/Yönetime Prod Çöküşü Açıklamak