Teknik İşlerde Deadline Disiplini: Teslim Tarihi Takibi

Teknik İşlerde Deadline Disiplini: Teslim Tarihi Takibi

Teknik işlerde deadline kaçırma genellikle iki şekilde başlıyor.

Birincisi: deadline hiç konulmadı. "Yapacağız" dendi, ne zaman yazılmadı. Görev backlog'a girdi, haftalarca orada kaldı. Her sprint "önümüzdeki sprint'e" taşındı.

İkincisi: deadline konuldu ama kimse takip etmedi. Tarih geldi geçti, görev hâlâ açık. Kimse fark etmedi ya da fark etti ama söylemedi.

Her iki durumun da sonucu aynı: teknik borç birikti, müşteri beklentisi karşılanamadı, ekip "çok çalışıyoruz ama bir şey bitmiyor" hissine girdi.

Teknik Görevlerde Deadline Neden Komuyor?

Teknik görevlerde deadline disiplininin yerleşmemesinin arkasında yazılım geliştirmenin kendine özgü dinamikleri var.

Tahmin zor, taahhüt riskli. Geliştirici "ne kadar sürer?" sorusuna kesin cevap veremiyor çünkü gerçekten bilmiyor. Bilinmeyen değişkenler çok. Bu belirsizlik taahhütten kaçınmayı doğuruyor — deadline koymak yerine "bakacağım" deniyor.

Teknik borç sessiz büyüyor. Refactor, test coverage, güvenlik güncellemesi — bunların "acil" görünen müşteri talebi karşısında önceliği hep düşük kalıyor. Deadline olmadığı için her sprint erteleniyor. Bir baktınızda altı aylık teknik borç birikmiş.

"Bitti" tanımı belirsiz. Geliştirici "bitti" diyor ama review yok, test yok, deployment yok. Ürün ekibi "ne zaman canlıya çıkıyor?" diye soruyor. Geliştirici "bitti zaten" diyor. Bu kopukluk deadline'ın anlamını yitirmesine yol açıyor.

Bağımlılıklar görünmüyor. Bir görev bitmeden diğeri başlayamıyor ama bu zincir yazılı değil. Deadline kaçırıldığında zincirin geri kalanı da kayıyor ama bu etki geç fark ediliyor.

Alios'ta Teknik Deadline Sistemi

Alios'ta teknik deadline yönetimi üç katmanla çalışıyor: deadline alanı, durum akışı ve filtre alışkanlığı.

Deadline Alanı: Taahhüt Görünür Hale Geliyor

Her teknik görev node'una iki tarih giriliyor:

Başlangıç tarihi: [Görevin başladığı gün]
Deadline: [Teslim veya review'a hazır olması gereken gün]

Deadline girerken "kesin biteceğim" değil, "bu tarihe kadar review'a hazır olacak" taahhüdü veriliyor. Fark önemli: review ve deployment ayrı aşamalar, her birinin kendi tarihi olabilir.

Tarihi olmayan görev sprint'e alınmıyor. Bu kural uygulandığında backlog gerçek tahminlerle doluyor, sprint kapasitesi gerçekçi oluyor.

Durum Akışı: "Bitti" Net Tanımlanıyor

Teknik görev için altı durum:

📥 Backlog → sprint'e henüz alınmadı
🔄 In Progress → aktif geliştirme
👀 Review → PR açık, inceleme bekleniyor
🧪 Test → staging'de QA veya manuel test
✅ Done → kabul kriterleri karşılandı, canlıya alındı
⏸ Bloke → dış bağımlılık, ilerlenemiyor

Her durum geçişinde açıklamaya kısa not:

In Progress → Review geçişinde:
"PR #47 açıldı. [Staging linki]. Test edilecek
senaryolar açıklamada."

Review → Test geçişinde:
"Code review tamamlandı. [İsim] onayladı.
Staging'e deploy edildi."

Test → Done geçişinde:
"Tüm kabul kriterleri karşılandı. [İsim] onayladı.
Canlıya alındı: [Tarih/Saat]."

Bu notlar "bitti mi?" sorusunu ortadan kaldırıyor. Cevap node'da yazıyor.

Filtre Alışkanlığı: Deadline Takibi Otomatikleşiyor

Haftada iki kez filtre çalıştırmak deadline takibini sistematik hale getiriyor:

Pazartesi filtresi:
"Bu hafta deadline'ı olan tüm node'lar"
→ Kaç görev var, hepsi In Progress'te mi?
→ Bloke olan var mı, çözüm var mı?

Çarşamba filtresi:
"In Progress + deadline bu hafta"
→ Hâlâ ilerleyenler var mı?
→ Review'a geçmesi gereken ama geçmeyen var mı?
→ Cuma'ya yetişemeyecek olan şimdiden görünüyor mu?

Çarşamba filtresi kritik. Cuma'da "bu bitmedi" demek yerine Çarşamba'da "bu yetişmeyebilir" demek iki günlük kurtarma penceresi açıyor.

Örnek: 2 Haftalık Teknik Plan

📁 SPRINT 8 — 17-28 Mart
Sprint hedefi: Ödeme modülü iyileştirmeleri canlıya,
kullanıcı profil güncellemesi review'a hazır.

📅 BİRİNCİ HAFTA — 17-21 Mart

Pazartesi 17:
- [ ] Stripe webhook entegrasyonu
      Sorumlu: Ali — Deadline: Çarşamba 19
      Durum: In Progress
      Tahmini efor: Orta (2 gün)

- [ ] Ödeme geçmişi API'si
      Sorumlu: Mehmet — Deadline: Perşembe 20
      Durum: In Progress
      Tahmini efor: Orta (2 gün)

- [ ] Profil fotoğraf yükleme
      Sorumlu: Zeynep — Deadline: Cuma 21 (Review'a hazır)
      Durum: In Progress
      Tahmini efor: Büyük (4 gün)

Çarşamba 19 kontrol:
- Ali: Webhook In Progress → Review geçti ✅
- Mehmet: API %60, Perşembe'ye yetişir ✅
- Zeynep: Upload çalışıyor, kırpma devam ediyor —
  Cuma review'a yetişebilir ama risk var ⚠️

Cuma 21 kapanış:
- Webhook → Done ✅ (canlıya alındı)
- Ödeme geçmişi API → Review ✅ (PR açıldı)
- Profil fotoğraf → In Progress ⏳
  Neden: Kırpma arayüzü beklendenden uzun sürdü
  Yeni deadline: Salı 25

📅 İKİNCİ HAFTA — 24-28 Mart

Pazartesi 24:
- [ ] Profil fotoğraf yükleme (devir)
      Sorumlu: Zeynep — Deadline: Salı 25
      Durum: In Progress → Review hedefi: Salı öğlen

- [ ] Ödeme geçmişi frontend entegrasyonu
      Sorumlu: Mehmet — Deadline: Çarşamba 26
      Durum: In Progress (API Review'dan geçti)

- [ ] Hata mesajları iyileştirmesi
      Sorumlu: Ali — Deadline: Perşembe 27
      Durum: In Progress
      Tahmini efor: Küçük (1 gün)

- [ ] Sprint kapanış QA
      Sorumlu: Zeynep — Deadline: Cuma 28
      Durum: Backlog → Test'e geçiş koşulu:
      Tüm görevler Review'ı geçince

Çarşamba 26 kontrol:
- Zeynep: Profil fotoğraf → Done ✅
- Mehmet: Frontend entegrasyonu Review'da ✅
- Ali: Hata mesajları In Progress, Perşembe'ye yetişir ✅

Cuma 28 kapanış:
- Profil fotoğraf yükleme → Done ✅
- Ödeme geçmişi frontend → Done ✅
- Hata mesajları → Done ✅
- Sprint QA → Done ✅

Sprint tamamlanma oranı: 4/4 planlanan → 4 Done ✅
Devir: 0 node

Kontrol Listesi: Teknik Deadline Disiplini

Günlük, haftalık ve sprint bazında uygulanacak kontroller:

Günlük (5 dakika)

- [ ] Bugün deadline'ı olan node var mı?
      → Varsa durum ne, risk var mı?
- [ ] Dünden devir eden "In Progress" node var mı?
      → Neden bitmedi, bugün bitecek mi?
- [ ] Yeni blokaj çıktı mı?
      → Node "Bloke" durumuna geçirildi mi?

Haftalık (15 dakika — Pazartesi)

- [ ] Bu hafta deadline'ı olan tüm node'lar listelendi
- [ ] Her node'un durumu gözden geçirildi
- [ ] Bloke node'ların çözüm yolu belirlendi
- [ ] Sprint kapasitesi gerçekçi mi kontrol edildi
      (çok fazla "Kritik" varsa öncelik çatışması var)
- [ ] Geçen haftadan devir eden node'ların yeni
      deadline'ı güncellendi

Sprint Kapanışı (20 dakika — Cuma)

- [ ] "In Progress" veya "Review" node kalmadı
      (kalan varsa sebep yazıldı, yeni deadline atandı)
- [ ] Tüm Done node'lar kabul kriterlerini karşıladı
- [ ] Deadline kaçırılan node'lar için postmortem notu:
      neden kaçırıldı, bir dahaki sprint'te ne değişecek
- [ ] Tamamlanma oranı kaydedildi
- [ ] Bir sonraki sprint backlog ön seçimi yapıldı

Deadline Kaçırılınca: Postmortem Notu

Deadline kaçırıldığında suçlamak değil, öğrenmek. Her kaçırılan deadline için node açıklamasına üç satır ekleniyor:

⚠️ DEADLINE KAÇIRILDI — [Tarih]

Orijinal deadline: [Tarih]
Gerçekleşen teslim: [Tarih]
Sebep: [Tahmin hatası / Bağımlılık / Kapsam değişikliği /
        Teknik engel / Kaynak eksikliği]
Bir dahaki sprint'te ne değişecek: [1 madde]

Bu not iki haftada bir gözden geçirildiğinde pattern'lar görünmeye başlıyor. Aynı sebep tekrar tekrar çıkıyorsa sistematik sorun var demektir — o sorun adreslenebilir.

Son Düşünce

Teknik deadline yönetimi "daha sıkı çalışmak" değil. Taahhütleri görünür kılmak, durumları net tanımlamak ve kaçırmaları öğrenme fırsatına dönüştürmek.

Alios'ta deadline alanı, altı aşamalı durum akışı ve haftalık filtre alışkanlığı bu üç ihtiyacı karşılıyor. "Bu ne zaman biter?" sorusu artık toplantıda değil, node'da cevaplanıyor.

Sprint sonu sürpriz olmuyor. Cuma öğleden sonra "bu bitmedi" yerine "bu Done" deniyor.