Kitap, Kültür ve Dil

Wei’yi Kuşatarak Zhao’yu Kurtarmak: Sorunun Olduğu Yerde Savaşmamak

“Wei’yi Kuşatarak Zhao’yu Kurtarmak”, 36 Strategem içindeki ikinci yaklaşımdır. Tarihî anlatı, sıkışan Zhao’ya doğrudan savaş alanında yardım etmek yerine Wei’nin merkezine yönelerek dengeyi değiştirmeyi anlatır. Bu notta strategemin tarihî bağlamını; proje yönetimi ve müşteri ilişkilerinde görünen sorunun arkasındaki asıl darboğazı arama fikriyle birlikte ele alıyorum.

Yayınlandı: 13 Mart 2024Güncellendi: 28 Ağustos 2026Strateji, Liderlik ve Kültür
İçindekiler

36 Strategem’in ikinci maddesi 圍魏救趙 (wéi Wèi jiù Zhào): “Wei’yi kuşatarak Zhao’yu kurtarmak.”

İfade ilk duyulduğunda ters geliyor. Zhao kuşatma altındaysa, onu kurtarmak için neden Wei’ye saldırılsın?

Savaşan Devletler dönemine ait anlatıda Wei ordusu Zhao’nun başkenti Handan’ı kuşatır. Zhao, Qi’den yardım ister. Qi ordusunun komutanı Tian Ji ve danışmanı Sun Bin, kuşatılmış şehre doğrudan gitmek yerine Wei’nin başkenti Daliang’a yönelir. Wei ordusu kendi başkentini korumak için geri dönmek zorunda kalır; dönüş yolunda Guiling’de Qi kuvvetleriyle karşılaşır ve yenilir. Zhao üzerindeki baskı da böylece kalkar.

Deyimin sonradan kazandığı anlam da bu hikâyeden gelir: Doğrudan karşı koyması çok güçlü olan bir hedef yerine, onu hareket etmeye zorlayan başka bir noktaya yönelmek.

Görünen sorun ile asıl darboğaz

Bu strategemi iş hayatında düşünürken “karşı tarafın zayıf noktasına saldırmak” fikrini doğrudan almak doğru değil. Benim için daha yararlı okuma şu: Sorunun en görünür olduğu yer, her zaman çözümün olduğu yer değildir.

Bir proje teslim tarihi sürekli kayıyorsa ilk tepki geliştirme ekibine daha fazla iş yüklemek olabilir. Fakat gecikmenin asıl nedeni, müşteriden haftalarca beklenen onaylar, belirsiz kabul kriterleri veya son dakikada değişen öncelikler olabilir.

Bu durumda doğrudan ekibe “daha hızlı ilerlemeliyiz” demek, Handan kuşatmasına cepheden saldırmaya benzer. Sorunun görünen yerine enerji harcanır; fakat sistemi kilitleyen nokta yerinde kalır.

Asıl hamle, teslim tarihini tartışmak değil; onay sürecini değiştirmek olabilir. Örneğin karar verecek kişileri baştan netleştirmek, her iş için kabul kriterlerini yazılı hâle getirmek veya haftalık kısa bir karar toplantısı planlamak. Projenin hızını artıran şey bazen daha çok çalışma değil, doğru yerdeki engeli kaldırmaktır.

Customer Success tarafında

Customer Success’te de benzer bir yanılgı yaşanabilir. Müşteri ürünü az kullanıyordur ve ilk çözüm olarak eğitim önerilir. Eğitim bazen doğru cevaptır; fakat her zaman değil.

Kullanımın düşük olmasının nedeni şunlardan biri olabilir:

  • Ürünü kullanması gereken kişilerin yetkisi yoktur.

  • Ekip değişmiştir ve kurulum bilgisi kaybolmuştur.

  • Ürün, müşterinin günlük iş akışındaki kritik noktaya bağlanmamıştır.

  • Müşteri tarafında karar veren kişi ile kullanan kişi farklıdır.

Bu yüzden “Daha çok eğitim verelim” demeden önce, sorunun üründe mi, süreçte mi, yetkide mi veya sahiplikte mi olduğunu anlamak gerekir. Bazen müşterinin ihtiyacı yeni bir özellik değil; yönetici onayı, doğru kullanıcı tanımı ya da mevcut sürecin yeniden kurulmasıdır.

Bu strategemin burada açtığı soru şu olabilir:

Müşterinin söylediği problemi çözmeye mi çalışıyorum, yoksa o problemi tekrar tekrar üreten koşulu mu anlamaya çalışıyorum?

Dikkat edilmesi gereken yer

Bu yaklaşım, sorunları dolaylı yoldan çözmeye çalışırken insanları devre dışı bırakmak anlamına gelmez. Özellikle müşteri, ekip veya başka bir paydaş doğrudan etkileniyorsa, kararın nedeni ve etkisi açık biçimde konuşulmalı.

Fakat bir problem karşısında hemen en görünür noktaya yüklenmek yerine, şu soruları sormak faydalı olabilir:

  1. Bu sorunu her hafta yeniden üreten koşul ne?

  2. Kararı kim veriyor; işi kim yapıyor; etkisini kim yaşıyor?

  3. En küçük değişiklikle hangi bağımlılığı azaltabiliriz?

  4. Bu sorunu çözmek için gerçekten daha çok kaynak mı gerekiyor, yoksa daha net bir karar mı?

Bende kalan

“Wei’yi kuşatarak Zhao’yu kurtarmak” bana, her sorunun doğrudan çözülemeyeceğini hatırlatıyor. Bazen sorunla savaşmak yerine, onu güçlü tutan yapıya bakmak gerekir.

Bu, insanları hedef almak değil; sistemdeki darboğazı görebilmekle ilgili. Proje yönetiminde de Customer Success’te de doğru soruyu sormak, çoğu zaman en çok görünen soruna hemen müdahale etmekten daha etkili olabilir.

Wei’yi Kuşatarak Zhao’yu Kurtarmak: Sorunun Kaynağını Bulmak