Deadline Disiplini: Startup'ta Teslim Tarihlerini Yönetmek

Deadline Disiplini: Startup'ta Teslim Tarihlerini Yönetmek

"Bu hafta biter" cümlesi bir deadline değil. Bir niyet.

Startup'larda en sık kaçırılan deadline'lar yazılmamış olanlardır. Toplantıda "bu haftaya yetiştirelim" deniyor, kimse tarihi bir yere yazmıyor, hafta biterken "bu nerede kaldı?" sorusu geliyor. Cevap genellikle "aklımdan çıkmış" ya da "başka şeyler çıktı" oluyor.

Bu bir disiplin sorunu değil. Sistem sorunu.

Deadline'sız İşler Neden Sürünür?

Tarihi olmayan görevin bitmesi için dışsal bir baskı yok. İnsan beyni son teslim tarihi olmayan işi otomatik olarak düşük önceliğe atıyor — bilinçli bir karar olmadan. Önce tarihli işler yapılıyor, tarihi olmayan iş sürekli erteleniyor.

Bunun yanında startup'larda her gün yeni aciller çıkıyor. Deadline'sız görev, yeni gelen acil işin her seferinde arkasına geçiyor. Bir baktınız, üç haftadır "yapılacak" listesinde duruyor.

Bir de "yakında" tuzağı var. "Yakında yaparım" zihinsel olarak konforlu ama operasyonel olarak işlevsiz. Tarih olmadan öncelik belirlenemiyor, planlama yapılamıyor, takip edilemiyor.

Sonuç: deadline'sız görev listesi zamanla bir bataklığa dönüşüyor. Her hafta büyüyor, hiçbir şey kapanmıyor, ekip "çok iş var ama hiçbir şey bitmiyor" hissine giriyor.

Alios'ta Deadline ve Durum Akışı

Alios'ta startup deadline yönetimi iki bileşenin birlikte çalışmasıyla kuruluyor: deadline alanı ve durum akışı.

Deadline alanı her node'a tarih girmek için var. Basit ama kritik. Tarih girildiğinde görev öncelik kuyruğuna giriyor, filtrelerle listelenebiliyor, "bu hafta bitmesi gerekenler" görünür hale geliyor.

Durum akışı ise görevin nerede olduğunu gösteriyor. Her görev şu beş durumdan birinde yaşıyor:

📥 Yapılacak → görev tanımlandı, henüz başlanmadı
🔄 Devam ediyor → aktif olarak çalışılıyor
⏸ Beklemede → dış bağımlılık var, ilerlenemiyor
✅ Tamamlandı → çıktı teslim edildi, node kapatıldı
❌ İptal edildi → geçerliliğini yitirdi, kapatıldı

Bu iki bileşen birleştiğinde güçlü bir kontrol noktası oluşuyor: "deadline'ı bu hafta olan ve hâlâ devam eden node'lar" filtresi çalıştırıldığında risk altındaki görevler anında görünüyor.

Örnek: İki Haftalık Sprint Planı

Alios'ta deadline disiplinini sprint yapısıyla uygulamak için aşağıdaki yapı kullanılabilir.

Sprint Başlangıcı — Pazartesi (20 dakika)

📁 SPRINT [Numara] — [Başlangıç] → [Bitiş]

🔴 KRİTİK — Bu sprint mutlaka bitmeli
├── [ ] [Görev] — Sorumlu: [İsim] — Deadline: [Gün/Tarih]
├── [ ] [Görev] — Sorumlu: [İsim] — Deadline: [Gün/Tarih]
└── [ ] [Görev] — Sorumlu: [İsim] — Deadline: [Gün/Tarih]

🟠 YÜKSEK — Bu sprint bitmesi bekleniyor
├── [ ] [Görev] — Sorumlu: [İsim] — Deadline: [Gün/Tarih]
└── [ ] [Görev] — Sorumlu: [İsim] — Deadline: [Gün/Tarih]

🟡 ORTA — Zaman kalırsa
└── [ ] [Görev] — Sorumlu: [İsim] — Deadline: Sonraki sprint

Her görevin deadline'ı sprint bitiş tarihinden önce. Kritik görevlerin deadline'ı sprint ortasına denk geliyor — böylece gecikme erken fark ediliyor.

Sprint Ortası — Çarşamba (10 dakika)

✅ Kontrol soruları:

Kritik görevlerden tamamlanan var mı? → Kapat
Kritik görevlerden tıkanan var mı? → Açıklamaya yaz, çözüm üret
Yeni gelen iş sprint'e mi giriyor, backlog'a mı? → Karar ver
Deadline'ı bu haftadan önce olan ama "Yapılacak" durmunda olan? → Alarm

Sprint ortası kontrol küçük bir alışkanlık ama kritik. Bu noktada fark edilen gecikme hâlâ kurtarılabilir. Sprint sonunda fark edilen çoğunlukla kurtarılamıyor.

Sprint Kapanışı — Son Cuma (15 dakika)

✅ Tamamlanan node'lar kapatıldı mı?
✅ Tamamlanamayan node'lar neden kapanmadı → açıklamaya yazıldı mı?
✅ Bir sonraki sprint'e taşınan görevler belirlendi mi?
✅ Backlog'dan bir sonraki sprint'e ne alınacak kararlaştırıldı mı?
✅ Sprint özeti node açıklamasına işlendi mi?

Sprint kapanışında tamamlanamayan görev için iki soru sorulmalı: deadline neden kaçırıldı ve bir sonraki sprint'te ne değişecek? Bu soruların cevabı node açıklamasına yazılırsa aynı hata tekrarlanmıyor.

Deadline Kaçırılınca Ne Olmalı?

Deadline kaçırmak olacak. Önemli olan nasıl ele alındığı.

Alios'ta deadline geçmiş ama hâlâ açık node'lar otomatik olarak dikkat çekiyor. Bu noktada yapılacaklar net:

Neden kaçırıldı? Bağımlılık mı vardı, kapsam mı genişledi, öncelik mi değişti, tahmin mi yanlıştı? Açıklamaya yazılıyor.

Yeni deadline nedir? "Yakında" değil, yeni bir tarih. Tarihsiz uzatma gecikmeyi geciktirmek.

Kapsam değişmeli mi? Bazen deadline kaçırılıyor çünkü görev çok büyük. O zaman görev ikiye bölünüyor — biri bu sprint'te, diğeri sonrakinde.

Bir daha olmaması için ne değişecek? Aynı sebep tekrar görünüyorsa sistemsel bir sorun var demektir.

Deadline Kültürü: Araçtan Önce Anlaşma

Startup deadline yönetimi araçla başlamıyor. Ekibin şu üç konuda anlaşmasıyla başlıyor:

Deadline gerçek: "Bu haftaya yetiştirelim" cümlesi toplantı bitmeden node'a tarih olarak giriyor. Sözlü deadline sistemde yok.

Deadline değişebilir ama sormadan değişmez: Deadline ötelenmesi olabilir. Ama sorumlu kişi ötelemeden önce ilgili kişilere haber veriyor, yeni tarih node'a yazılıyor.

Tamamlanmadan "bitti" denmez: "Neredeyse bitti", "son rötuşlar kalıyor", "yarın göndereceğim" tamamlanmış değil. Node ancak çıktı teslim edildiğinde kapatılıyor.

Bu üç anlaşma oturduğunda Alios'taki deadline takibi çalışmaya başlıyor. Araç anlaşmayı görünür ve takip edilebilir kılıyor — ama anlaşmanın yerini tutmuyor.

Son Düşünce

Startup deadline yönetimi karmaşık bir sistem gerektirmiyor. Gerektirdiği şey basit: her görevin bir tarihi olsun, o tarih görünür olsun, tarih geçince hesap sorulsun.

Alios'ta deadline alanı ve durum akışı bu üç ihtiyacı karşılıyor. Sprint yapısıyla birleştiğinde hem planlama hem takip hem de kapanış disiplini aynı sistemde yaşıyor.

"Bu hafta biter" niyet olmaktan çıkıyor. Sisteme giren bir taahhüde dönüşüyor.