AI Paralel İşlerde Bağımlılık Yönetimi: Blokajı Erken Gör

AI Paralel İşlerde Bağımlılık Yönetimi: Blokajı Erken Gör

AI araçlarıyla geliştirme hızlandığında ekip doğal olarak daha fazla şeyi paralel yürütmeye başlıyor. Backend API yazılırken frontend component'leri hazırlanıyor, QA test senaryoları yazılıyor, dokümantasyon oluşturuluyor. Hepsi aynı anda, hepsi birbirine bağlı.

Paralel iş verimliliği artırıyor. Ama beraberinde görünmez bir risk getiriyor: bağımlılıklar.

Frontend API'yi bekliyor. API üçüncü parti servis onayını bekliyor. Onay süreci belirsiz. Bu zincir hiçbir yerde yazılı değilse Cuma günü "bu bitmedi" sürprizi geliyor. Oysa Pazartesi görülseydi dört gün kurtarma penceresi açılırdı.

AI Paralel İşi Neden Bağımlılıkları Görünmez Kılıyor?

Geleneksel geliştirmede sıralı çalışma bağımlılıkları doğal olarak görünür tutuyordu. A bitmeden B başlamıyordu çünkü B'yi yazmak için zaman gerekiyordu. Bekleme sürecin içine gömülüydü.

AI bu yapıyı değiştirdi. Şimdi B, A bitmeden başlayabiliyor — AI hızla bir şeyler üretiyor, geliştirici ilerliyor. Ama B gerçekten tamamlanmak için hâlâ A'yı bekliyor. Fark şu: bu bekleme artık görünmüyor çünkü B "In Progress" etiketiyle aktifmiş gibi görünüyor.

Sahte ilerleme: Birden fazla görev aynı anda "In Progress" durumunda. Görünürde her şey yürüyor. Aslında birkaçı bloke, bekleme gizlenmiş.

Bağımlılık notu yok: Sprint planlamasında "A bitmeden B başlayamaz" söylendi ama yazılmadı. Hafta içinde kim neyi beklediği belirsizleşiyor.

Erken bildirim maliyetli hissettiriyor: "Bloke oldum" demek hâlâ zayıflık gibi algılanıyor. Geliştirici beklerken başka şeyle ilgileniyor, blokajı bildirmiyor. Ekip lideri hafta sonunda öğreniyor.

Alios'ta WAITING Durumu

Alios'ta bağımlılık yönetiminin merkezinde WAITING durumu var. Standart dört duruma eklenen bu durum "aktif çalışılmıyor, bir şey bekleniyor" anlamına geliyor.

🔄 IN PROGRESS → aktif çalışılıyor
⏳ WAITING     → dışarıdan girdi bekleniyor, ilerlenemiyor
👀 REVIEW      → tamamlandı, onay bekleniyor
✅ DONE        → kapatıldı

WAITING ile REVIEW arasındaki fark kritik. REVIEW'da iş tamamlandı, başkasının değerlendirmesi bekleniyor. WAITING'de iş yarım, devam etmek için dışarıdan bir girdi gerekiyor.

Bu ayrım olmadan blokaj gizleniyor. WAITING durumu blokajı yüzeye çıkarıyor.

WAITING Node'una Geçerken: Blokaj Notu Formatı

Görev WAITING'e geçtiğinde standart bir format dolduruluyor. "Bekliyorum" tek satırı yeterli değil — çözüm için gereken bilginin tamamı node'a yazılıyor.

⏳ WAITING — [Tarih / Saat]

Ne bekleniyor:
[Spesifik — "API bilgisi" değil,
"Payment servis sandbox API key'i ve
webhook endpoint listesi"]

Kimden bekleniyor:
[İsim veya ekip — iç kaynak mı, dış mı]

Ne zaman gelmesi bekleniyor:
[Tarih — bilinmiyorsa "belirsiz, takip edilecek"]

Bu görevin deadline'ı:
[Tarih — bekleme N günü geçerse sprint
hedefine etkisi ne olur]

Alternatif var mı:
[ ] Evet — [Mock data kullanılabilir /
            Başka modülden ilerlenebilir]
[ ] Hayır — tamamen bloke, zincir duruyor

Takip aksiyonu:
[Kim, ne zaman, nasıl takip edecek —
"Zeynep'e bugün Slack'ten yazılacak,
yarına kadar cevap gelmezse eskalasyon"]

Bu format beş soruyu yanıtlıyor: ne bekleniyor, kimden, ne zamana kadar, alternatif var mı, şimdi ne yapılıyor. Bu beş sorunun cevabı node'da yazıyorsa ekip lideri müdahale edebiliyor.

5 Tipik Blokaj ve Çözüm Aksiyonu

AI destekli paralel geliştirmede en sık karşılaşılan beş blokaj türü ve her biri için Alios'ta uygulanacak çözüm aksiyonu:

Blokaj 1 — Dış API veya Servis Onayı

⏳ WAITING — Stripe Sandbox Erişimi

Ne bekleniyor: Stripe sandbox API key'i ve
webhook test endpoint'leri
Kimden: Stripe developer portalı — onay süreci
Ne zaman: 1-3 iş günü (belirsiz)
Deadline etkisi: API Çarşamba'ya kadar gelmezse
ödeme entegrasyonu Perşembe'ye taşınacak,
QA Cuma'ya yetişmeyebilir

Alternatif: Evet — Stripe'ın test mock'ları ile
temel flow yazılabilir, gerçek key gelince
entegrasyon tamamlanır

Takip aksiyonu:
- Bugün: Stripe portal'da başvuru durumu kontrol edildi
- Yarın sabah: Güncelleme yok ise Stripe support'a yazılacak
- Çarşamba öğlen: Hâlâ yoksa mock ile ilerleme kararı alınacak

Blokaj 2 — İç Ekip Bağımlılığı

⏳ WAITING — Backend API Hazır Değil

Ne bekleniyor: /api/payments/history endpoint'i —
response formatı ve pagination yapısı
Kimden: Ali (backend) — kendi sprint görevi içinde
Ne zaman: Salı EOD (Ali'nin deadline'ı)
Deadline etkisi: API Çarşamba sabahına kadar
gelmezse frontend Perşembe'ye taşınır

Alternatif: Evet — Ali'nin paylaştığı taslak
response formatına göre mock data ile
component yazımına başlanabilir

Takip aksiyonu:
- Bugün: Ali ile hızlı senkron — response formatı
  taslak olarak şimdi paylaşılabilir mi?
- Salı 17:00: API hazır mı kontrol edilecek
- Hazır değilse: mock ile devam kararı alınacak

Blokaj 3 — Tasarım veya İçerik Onayı

⏳ WAITING — Tasarım Onayı

Ne bekleniyor: Ödeme geçmişi sayfası Figma onayı —
mobile görünüm ve boş state tasarımı
Kimden: Zeynep (tasarım) — review listesinde
Ne zaman: Pazartesi EOD talep edildi, yanıt yok
Deadline etkisi: Onay Salı öğlene kadar gelmezse
frontend tamamlanamaz, Perşembe deadline
risk altında

Alternatif: Kısmen — masaüstü görünüm
onaylandı, mobil ve boş state beklenebilir
ama teslim edilemez sayılır

Takip aksiyonu:
- Bugün: Zeynep'e Slack'te hatırlatma — spesifik
  olarak mobil ve boş state onayı isteniyor
- Salı sabahı: Yanıt yok ise doğrudan toplantı
  talebi — 15 dakika yeterli
- Onay gelmezse: mevcut tasarımla ilerlenip
  sonra revize edilecek, bu karar kayıt altına alınacak

Blokaj 4 — Teknik Belirsizlik

⏳ WAITING — Mimari Karar Bekleniyor

Ne bekleniyor: WebSocket mi SSE mi? — real-time
özellik için mimari seçim yapılmadı
Kimden: CTO veya teknik lead — karar alacak kişi
Ne zaman: Bugün toplantıda gündeme alınacak
Deadline etkisi: Karar bugün alınmazsa
implementasyon Çarşamba'ya erteleniyor,
sprint hedefi risk altına giriyor

Alternatif: Hayır — mimari karar olmadan
implementasyon başlanamaz, yanlış seçim
tüm kodu değiştirtirir

Takip aksiyonu:
- Bugün öğlen toplantısına gündem maddesi eklendi
- Karar bugün alınacak, ADR node'u açılacak
- Karar alınmazsa: yarın sabah async karar süreci —
  Ali ve CTO seçenekleri node'a yazacak, EOD'ye kadar karar

Blokaj 5 — Dış Ekip veya Ajans Gecikmesi

⏳ WAITING — Ajans Teslimi Gecikmesi

Ne bekleniyor: Landing page HTML/CSS çıktısı —
ajans 3 gün önce "yarın teslim" demişti
Kimden: XYZ Ajans — dış tedarikçi
Ne zaman: 3 gün önce söz verildi, hâlâ gelmedi
Deadline etkisi: Teslim bugün gelmezse
entegrasyon ve test Cuma'ya sığmaz,
sprint 15'e taşınması gerekebilir

Alternatif: Kısmen — mevcut taslakla entegrasyon
başlanabilir ama final teslim olmadan canlıya çıkılamaz

Takip aksiyonu:
- Bugün sabah: Ajansa e-posta + telefon —
  "Bugün öğlene kadar teslim edilmezse sözleşme
  geç teslim hükmü devreye giriyor" net mesaj
- Öğlen: Teslim yoksa proje yöneticisi devreye giriyor
- 17:00: Hâlâ yoksa sprint 15'e taşıma kararı
  alınıyor ve müşteri bilgilendiriliyor

Haftalık Risk Kontrol Rutini

WAITING node'larını açmak yeterli değil — düzenli kontrol edilmezse statik kayıt olarak kalıyor. Haftada iki kez, toplam 20 dakika:

📋 PAZARTESİ SABAHI — 10 DAKİKA

1. WAITING node'ları listele
   → Kaç tane var?
   → Her biri için: "Ne zaman bekleniyor?"
     sorusu yanıtlandı mı?
   → Geçen haftadan devir eden var mı?
     Neden hâlâ açık?

2. Bu haftaki deadline'lı görevlerin
   bağımlılıklarını kontrol et
   → Bağımlılık tamamlandı mı?
   → Tamamlanmadıysa: deadline risk altında mı?
   → Risk varsa: bugün aksiyon alınacak mı?

3. Yeni paralel iş başladıysa bağımlılık
   var mı kontrol et
   → Sprint'e yeni giren her görevin
     bağımlılığı node'a yazıldı mı?

─────────────────────────────

📋 ÇARŞAMBA ÖĞLENI — 10 DAKİKA

1. Pazartesi WAITING node'ları çözüldü mü?
   → Çözüldüyse: IN PROGRESS'e geçti mi?
   → Çözülmediyse: WAITING süresi kaç gün?

   WAITING yaşlanma skalası:
   1 gün  → Normal, takip ediliyor
   2 gün  → Aktif takip — bugün çözüm adımı atılmalı
   3 gün  → Eskalasyon — üst yönetime veya
             doğrudan ilgili kişiye iletiliyor
   5 gün+ → Sprint hedefi tehlikede —
             alternatif plan bugün netleşiyor

2. Zincir kayması var mı?
   → Bir görevin gecikmesi sonraki
     görevlerin deadline'ını etkiliyor mu?
   → Etkiliyorsa: o node'ların deadline'ı güncellendi mi?

3. Cuma'ya yetişmeyecek bir şey
   şimdi görünüyor mu?
   → Görünüyorsa: bugün karar alınıyor —
     kapsam daralıyor mu, sprint'e taşınıyor mu,
     ek kaynak devreye giriyor mu?

Çarşamba kontrolünün değeri şurada: Cuma'da "bu bitmedi" demek yerine Çarşamba'da "bu yetişmeyebilir" demek iki günlük müdahale penceresi açıyor. Bu pencerede blokaj çözülüyor, kapsam daraltılıyor veya bilinçli taşıma kararı alınıyor.

Blokaj Bildirimi Kültürü

Sistem ne kadar iyi kurulursa kurulsun, blokaj bildirmek normalleşmezse WAITING durumu kullanılmıyor.

Üç kural bu kültürü kuruyor. Birincisi: blokaj bildirmek bilgi paylaşmaktır, başarısızlık değil. "Bloke oldum" demek "yapamıyorum" değil, "zincirin bu halkası için şu girdiye ihtiyaç var" demektir. İkincisi: WAITING'e geçmek için izin gerekmez — geliştirici node'u kendisi güncelliyor, onay beklemiyor. Üçüncüsü: geç bildirilen blokaj yargılanmaz, çözüme odaklanılır. "Neden daha önce söylemedin?" sorusu bir dahaki seferinde erken söylemeyi engelliyor.

Son Düşünce

AI paralel işi artırıyor. Paralel iş bağımlılık sayısını artırıyor. Bağımlılıklar yönetilmezse hız kazanç değil risk kaynağına dönüşüyor.

Alios'ta WAITING durumu, blokaj notu formatı ve haftalık risk rutini bu riski görünür kılıyor. Blokaj Cuma sürprizi olmaktan çıkıyor — Pazartesi görünüyor, Çarşamba çözülüyor, Cuma sprint kapanıyor.

Domino zinciri yıkılmadan önce ilk taşı tutmak mümkün. Ama yalnızca o taşın sallandığını görebiliyorsan.