/em:hard-call — Hiçbir seçeneği iyi olmayan kararlar için framework. Her opsiyon ağrılı olduğunda ve yapılandırılmış bir 10/10/10 analizi ile pişmanlık minimizasyonu gerektiğinde kullanın — örneğin, işten çıkarma ile down round arasında seçim yapmak ya da sevilen bir ürün serisini sonlandırmak gibi.
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/hard-call
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/hard-call/SKILL.md \
-o ~/.claude/skills/hard-call/SKILL.md Komut: /em:hard-call <decision>
Sizi saat 3'te uyandıran kararlar için. Bir kurucu ortağı işten çıkarmak. Ekibin %20'sini layoff etmek. Müşterilerin sevdiği bir ürünü öldürmek. Pivot yapmak. Kapanmak.
Bu kararların doğru bir cevabı yok. Sahip oldukları daha az yanlış bir cevaptır. Bu çerçeve bunu bulmanıza yardımcı olur.
Veriler belirsiz olduğu için değil. Çoğu zaman veriler açıktır. Zordurlar çünkü:
Zor bir karardan ne kadar uzun kaçınırsanız, durum genellikle o kadar kötüleşir. 6 ay önce %10 kesintiye ihtiyacı olan şirket şimdi %25 kesintiye ihtiyacı vardır. Ay 4'te gerçekleşmesi gereken kurucu ortak konuşması ay 14'te gerçekleşiyor.
Çoğu zor karar, geç alınan kararlardır.
En önemli soru ilk: bunu geri alabilir misiniz?
Geri döndürülemez kararlar için kesinlik çubuğu daha yüksektir. Harekete geçmeden önce daha fazla durum tespiti yapmalısınız. Yanılıyor olabileceğiniz için değil — onu geri alamayacağınız için.
Geri döndürülebilir bir kararı geri döndürülemez gibi ele alıyorsanız, ondan kaçınıyorsunuz.
Her seçenek hakkında üç soru sorun:
10 dakikalık his genellikle en az güvenilir rehberdir. 10 yıllık görünüş genellikle doğru çağrının gerçekte ne olduğunu netleştirir.
Çoğu zor karar, 10 yılda belirgin görünür. Soru, 10 dakikalık acıya katlanıp katlanamayacağınızdır.
Andy Grove'un stratejik kararlar için testi: "Yarın bizi değiştirilseydi ve yeni bir CEO gelseydi, ne yapardı?"
Taze bir bakış açısı, mevcut yola hiçbir duygusal yatırım yok, batık maliyet yok. Dışarıdan bakıldığında belirgin doğru çağrı nedir?
Cevap bir yabancıya açık ise, soru şu hale gelir: neden bunu henüz yapmadınız?
Her seçenek için, kimin etkilendiğini ve nasıl etkilendiğini haritalamalandırın:
| Paydaş | Seçenek A Etkisi | Seçenek B Etkisi | Onların Tepkisi |
|---|---|---|---|
| Etkilenen çalışanlar | |||
| Kalan ekip | |||
| Müşteriler | |||
| Yatırımcılar | |||
| Siz |
Bu, kimseyi incinme seçeneği bulma hakkında değil — öyle bir seçenek yok. Karar vermeden önce tam resmi anlamak hakkındadır.
Karar vermeden önce: duyuruyu yazın. Ekibe gönderilecek email, müşteriye gönderilecek mesaj, yapacağınız konuşma.
Bu duyuruyu yazamazsanız, bu kararı almaya hazır değilsiniz.
Bunu yazmak sizi ne yaptığınızın gerçeğiyle yüzleştirmeye zorlar. Ayrıca, akıl yürütmenizin inceleme altında tutulup tutulmadığını da ortaya çıkarır. "Bu değişikliği yapıyoruz çünkü..." — bu cümle doğru geliyor mu?
Zor kararlar, iletişim kötü ise neredeyse her zaman daha da zorlaşır. Karar kendisi önemli değil — nasıl yapıldığı çok önemlidir.
Her zor çağrı için planlamanız gereken şeyler:
../executive-mentor/references/hard_things.md)Tam çerçeve için bkz. ../executive-mentor/references/hard_things.md — Co-Founder Conflicts.
Önce yanıtlaması gereken kilit sorular:
Kural: Bunu 3 aydan fazla düşünüyorsanız, zaten cevabı biliyorsunuz. Soru ne olduğu değil, ne zaman olduğudur.
Kilit sorular:
Kural: Bir kez kesin, derin kesin, haysiyetle kesin. Belirsizlik açıklıktan daha kötüdür.
Kilit sorular:
Kural: Pivot'ler yeni fırsat kanıtı tarafından çekilmeli, mevcut yolun başarısızlığı tarafından itilmemelidir.
Kilit sorular:
Zor bir çağrıdan kaçındığınızı bilirsiniz eğer:
Gecikmenin maliyeti, karar maliyetinden neredeyse her zaman daha yüksektir.
Bekledikçe sorun bileşir. İşi yapamayan kurucu ortak daha derinden kök salar. Ölmesi gereken ürün hattı daha fazla kaynak tüketir. Layoff edilmesi gereken kişi etrafındaki insanları etkiler.
Çağrıyı yapın. Açık bir şekilde yapın. Haysiyetle yapın.
2 veya daha fazla bağımsız görevin paralel olarak yürütülebileceği ve aralarında state paylaşımı ya da sıralı bağımlılık olmadığı durumlarda kullanın.
Ayrı bir oturumda inceleme kontrol noktaları ile yürütülecek yazılı bir uygulama planınız olduğunda kullanın.
Mevcut oturumda bağımsız görevlerle uygulama planlarını yürütürken kullanın
Herhangi bir hata, test başarısızlığı veya beklenmeyen davranışla karşılaştığınızda, çözüm önerisi sunmadan önce kullanın.
Herhangi bir feature ya da bugfix uygulamaya başlamadan önce kullanın.
Yeni beceriler oluştururken, mevcut becerileri düzenlerken veya dağıtımdan önce becerileri doğrularken kullanın.