Riskli proje başlamadan: pre-mortem risk listesi
Altı başlıkta gruplanmış bir risk listesi elde edersin: her risk için neden oluştuğu, erken uyarı sinyali, sahibi ve başlamadan alınacak önlem yazılı.
Yeni bir projeye "evet" dedin. Herkes heyecanlı, takvim dolu, ilk toplantı ayarlandı. Ama içinden bir ses bu işin bir yerde tıkanacağını söylüyor; sadece nerede tıkanacağını henüz göremiyorsun. Sorunu üç ay sonra kriz olarak konuşmak yerine, daha ilk gün masaya koymak istiyorsun.
Rol: Deneyimli bir program yöneticisisin ve pre-mortem (ön-ölüm analizi) yöntemini uyguluyorsun.
Sana başlatmak üzere olduğum bir projenin özetini vereceğim. Senaryo şu: aradan zaman geçti, proje başarısız oldu. Geriye dönüp bu başarısızlığın NEDEN yaşandığını, hangi risklerin gerçeğe döndüğünü masaya koy.
Kurallar:
- Sadece aşağıya yapıştırdığım metindeki bilgiye dayan. Tahmin yürütme, bilgi uydurma, boşluğu senaryoyla doldurma.
- Bir riski değerlendirmek için gereken bilgi metinde yoksa, o maddeye "EKSIK:" yaz ve hangi bilginin gerektiğini tek cümlede belirt.
- Her riski şu beş alanla ver: (1) Risk nedir (2) Neden oluşur — metindeki hangi ipucundan çıkardın (3) Erken uyarı sinyali — bunu hangi belirtiden anlarız (4) Sahibi kim olmalı (5) Şimdi, başlamadan alınacak somut önlem.
- Riskleri şu altı başlıkta grupla: Kapsam, Kaynak ve bütçe, Zaman planı, Paydaş ve onay, Bağımlılıklar, İnsan ve ekip.
- Analizin sonunda en kritik 3 riski "KIRMIZI" olarak ayrı bir listede öne çıkar; kritiklik sırasına diz.
- Abartma, süslü dil kullanma. Kısa ve net madde yaz. İçeriği garantiye bağlayan iyimser cümle kurma.
Proje özeti:
"""
[BURAYA PROJE ÖZETİNİ YAPIŞTIR — amaç, kapsam, ekip, bütçe, süre/teslim tarihi, ana paydaşlar, dış bağımlılıklar. Ne kadar çok verirsen analiz o kadar isabetli olur.]
"""Altı başlıkta gruplanmış bir risk listesi elde edersin: her risk için neden oluştuğu, erken uyarı sinyali, sahibi ve başlamadan alınacak önlem yazılı. En kritik 3 risk ayrıca "KIRMIZI" olarak işaretli gelir; eksik bilgi verdiğin yerler "EKSIK:" notuyla açıkça belirtilir. Elindeki, ilk proje toplantısına koyabileceğin bir risk taslağı olur; yapıştırma birkaç dakika, gözden geçirip kendi bağlamınla düzeltmen 10-15 dakika sürer.
Riski proje battıktan sonra "ben söylemiştim" diye değil, daha ilk gün önlemiyle masaya koyan kişi, ekipte öngörülü ve güvenilir olarak hatırlanır.
Pre-mortem sadece verdiğin bilgi kadar iyidir; odadaki örtük politik gerilimleri, söylenmeyen anlaşmazlıkları AI bilemez, o riskleri sen ekleyeceksin. Bütçe rakamı, kişi adı gibi hassas veri yapıştıracaksan kurumun onayladığı AI aracını kullan.
Yeni proje: A firmasının müşteri portalını yenileyeceğiz. Eski portalı modern, mobil uyumlu bir arayüze taşımak istiyorlar. Ekip: 2 frontend, 1 backend, 1 tasarımcı (yarı zamanlı). Bütçe net değil, üst yönetim "makul tutun" dedi. Teslim 15 Kasım — satış ekibi o tarihte lansman istiyor. Ödeme entegrasyonu için X Bankası'nın API'sine bağımlıyız, dokümantasyonları eski. Hukuk KVKK onayı verecek ama henüz talep açmadık. Tasarımcı Aralık'ta 3 hafta izne çıkıyor. Eski portalın kodu belgesiz, yazan kişi işten ayrıldı. Paydaşlar: satış müdürü, operasyon birimi, bir de CFO ara ara bakıyor. Kapsamın tam listesi yok, "eski neyse yenisi de olsun ama daha iyi" gibi konuşuldu.
Kapsam
R1 — Taşınacak özellik seti belirsiz
- (1) Ne: Eski portaldaki bazı işlevler yeni arayüzde eksik kalıp lansmandan sonra fark edilebilir.
- (2) Neden: Özet "eski neyse yenisi de olsun ama daha iyi" diyor; taşınacak/çıkarılacak ekran listesi yok.
- (3) Erken uyarı: İlk demoda "şu ekran nerede?" sorularının çıkması.
- (4) Sahibi: Proje sahibi + satış müdürü.
- (5) Önlem: Başlamadan taşınacak ve çıkarılacak özelliklerin listesini yazılı onaylat.
Kaynak ve bütçe
R2 — Bütçe tanımsız
- (1) Ne: Bütçe belli olmadan iş büyüyüp ortada kaynak sıkışması yaşanabilir.
- (2) Neden: Özette "bütçe net değil, makul tutun" deniyor; rakam ve onay eşiği yok.
- (3) Erken uyarı: Ek lisans/dış kaynak ihtiyacında "kim onaylayacak?" belirsizliği.
- (4) Sahibi: CFO / proje sahibi.
- (5) Önlem: İlk toplantıda bir üst bütçe tavanı ve onay merciini yazılı netleştir.
- EKSIK: Onaylı bir bütçe rakamı ve harcama onay eşiği verilmemiş — riskin büyüklüğü ancak bu rakamla ölçülür.
Zaman planı
R3 — Sabit lansman tarihi baskısı
- (1) Ne: 15 Kasım kapsamdan bağımsız sabit; kapsam büyürse kalite ya da tarih feda edilir.
- (2) Neden: Tarih teknik tahminden değil, satış ekibinin lansman isteğinden geliyor.
- (3) Erken uyarı: İlk sprint hedeflerinin kayması.
- (4) Sahibi: Proje sahibi.
- (5) Önlem: Tarihi sabit alıp kapsamı "olmazsa olmaz / sonraya" diye ikiye böl, satışla yazılı mutabakat kur.
Paydaş ve onay
R4 — KVKK onayı henüz başlatılmadı
- (1) Ne: Hukuk onayı verecek ama talep açılmamış; onay gecikirse lansman kayar.
- (2) Neden: Özet "onay verecek ama henüz talep açmadık" diyor.
- (3) Erken uyarı: Hukuktan ilk dönüşte ek belge veya ek süre istenmesi.
- (4) Sahibi: Proje sahibi (hukuk irtibatı).
- (5) Önlem: Bu hafta KVKK talebini aç, tahmini onay süresini yazılı iste.
Bağımlılıklar
R5 — Dış ödeme API'sine bağımlılık
- (1) Ne: Ödeme entegrasyonu, kontrolümüz dışındaki bir bankanın API'sine bağlı ve dokümantasyonu eski.
- (2) Neden: Özet "X Bankası'nın API'sine bağımlıyız, dokümantasyonları eski" diyor.
- (3) Erken uyarı: Test ortamında beklenenden farklı yanıtlar veya yanıtsız uç noktalar.
- (4) Sahibi: Backend geliştirici.
- (5) Önlem: İlk hafta bir test entegrasyonu (spike) yap; bankadan güncel doküman ve teknik irtibat kişisi iste.
İnsan ve ekip
R6 — Belgesiz eski kod + tasarımcı izni
- (1) Ne: Eski portal kodu belgesiz ve yazan kişi ayrılmış; ayrıca tasarımcı Aralık'ta 3 hafta izinli.
- (2) Neden: Özet her iki durumu da açıkça belirtiyor; tasarımcı zaten yarı zamanlı.
- (3) Erken uyarı: Basit bir değişikliğin beklenenden uzun sürmesi; tasarım kararlarının izin döneminde tıkanması.
- (4) Sahibi: Teknik lider (kod) / proje sahibi (tasarım kapasitesi).
- (5) Önlem: İlk iki haftada eski koddaki kritik akışları haritala; tasarım işlerini izin öncesine yığ veya yedek çöz.
KIRMIZI — en kritik 3 risk
- R5 — Dış ödeme API bağımlılığı. Eski doküman + kontrol dışı taraf; ödeme çalışmazsa lansmanın anlamı kalmaz.
- R4 — KVKK onayı başlatılmadı. Yasal engel ve süresi bizde değil; en erken bugün tetiklenmeli.
- R3 — Sabit tarih + tanımsız kapsam. İkisi birlikte kalite riskini büyütür.
ÜRETİM: TEM 2026 · CLAUDE Bu kayıt eşlenmiş örnek girdi ve çıktı içerir. Model koşumu kanıtı yoktur — kendi verinle doğrulamadan karar girdisi yapma.
Rol: Deneyimli bir program yöneticisisin ve pre-mortem (ön-ölüm analizi) yöntemini uyguluyorsun.
Sana başlatmak üzere olduğum bir projenin özetini vereceğim. Senaryo şu: aradan zaman geçti, proje başarısız oldu. Geriye dönüp bu başarısızlığın NEDEN yaşandığını, hangi risklerin gerçeğe döndüğünü masaya koy.
Kurallar:
- Sadece aşağıya yapıştırdığım metindeki bilgiye dayan. Tahmin yürütme, bilgi uydurma, boşluğu senaryoyla doldurma.
- Bir riski değerlendirmek için gereken bilgi metinde yoksa, o maddeye "EKSIK:" yaz ve hangi bilginin gerektiğini tek cümlede belirt.
- Her riski şu beş alanla ver: (1) Risk nedir (2) Neden oluşur — metindeki hangi ipucundan çıkardın (3) Erken uyarı sinyali — bunu hangi belirtiden anlarız (4) Sahibi kim olmalı (5) Şimdi, başlamadan alınacak somut önlem.
- Riskleri şu altı başlıkta grupla: Kapsam, Kaynak ve bütçe, Zaman planı, Paydaş ve onay, Bağımlılıklar, İnsan ve ekip.
- Analizin sonunda en kritik 3 riski "KIRMIZI" olarak ayrı bir listede öne çıkar; kritiklik sırasına diz.
- Abartma, süslü dil kullanma. Kısa ve net madde yaz. İçeriği garantiye bağlayan iyimser cümle kurma.
Proje özeti:
"""
[BURAYA PROJE ÖZETİNİ YAPIŞTIR — amaç, kapsam, ekip, bütçe, süre/teslim tarihi, ana paydaşlar, dış bağımlılıklar. Ne kadar çok verirsen analiz o kadar isabetli olur.]
"""Yapıştırdığın veri tarayıcından çıkmaz — WhiteYaka'ya gönderilmez. Prompt panoya kopyalanır; açılan sohbete Ctrl/⌘ + V ile yapıştırırsın.
Bülten kaydı kapalı.
Bu sayfa e-posta adresi toplamaz ve liste kaydı başlatmaz. 160 hamlenin tamamı giriş yapmadan açık.