PR Review Darboğazı: Onay Bekleyen İşleri Görünür Kıl

PR Review Darboğazı: Onay Bekleyen İşleri Görünür Kıl

Geliştirici görevi bitirdi, PR açtı. Şimdi bekliyor. Bir gün geçti, iki gün geçti. Review gelmedi. Geliştirici başka bir göreve geçti. Review nihayet geldi ama geliştirici artık o context'te değil. Düzeltmeleri yapmak için context switch gerekiyor, zaman kayboluyor.

PR review darboğazı startup'larda en yaygın ama en az görünür gecikme kaynağı. Kimse kasıtlı olarak review'u geciktirmiyor. Ama herkes kendi işine odaklandığında review bekleyen PR'lar listede kaybolup gidiyor.

PR Bekleme Neden Görünmez?

Review bekleyen PR'ın sisteme yansımamasının üç sebebi var.

Görev "bitti" sayılıyor. Geliştirici PR açtı, kendi listesinde görevi "tamamladı" olarak işaretledi. Ama iş aslında bitmedi — review ve merge bekliyor. Bu ara durum hiçbir yerde görünmüyor.

Review sorumluluğu belirsiz. "Takım review yapacak" deniyor ama takımda herkes kendi işiyle meşgul. Kimin review'u alacağı yazılı değil. Herkes bir başkasının baktığını sanıyor.

Bekleme süresi ölçülmüyor. PR kaç gündür bekliyor? Bu bilgi GitHub'da var ama ekibin çalışma sisteminde görünmüyor. Bir hafta bekleyen PR ile dün açılan PR aynı listede duruyor.

Alios'ta WAITING ve REVIEW Durumları

Alios'ta PR review darboğazını görünür kılmak için standart durum akışına iki durum ekleniyor: WAITING ve REVIEW.

🔄 In Progress → geliştirici aktif çalışıyor
⏳ Waiting → PR açıldı, review atandı, bekleniyor
👀 Review → reviewer aktif inceliyor
🔵 Fix Requested → değişiklik istendi, geliştirici düzeltiyor
✅ Done → merge edildi, görev tamamlandı

Her PR açıldığında görev node'u otomatik olarak "Waiting" durumuna geçiyor ve reviewer atanıyor. Bu iki adım PR'ın sisteme girmesini sağlıyor.

WAITING Node'una Geçerken Eklenenler

⏳ PR AÇILDI — [Tarih / Saat]

PR linki: [GitHub / GitLab URL]
Branch: [Branch adı]
Reviewer: [Atanan kişi]
Review deadline: [Beklenen tarih — SLA'ya göre]

Değişiklik özeti:
[Ne değişti, neden — 2-3 cümle]
[Test edilmesi gereken senaryolar]

Özel dikkat gerektiren:
[Varsa risk, bağımlılık veya reviewer'ın bilmesi gereken]

REVIEW Node'una Geçerken Eklenenler

👀 REVIEW BAŞLADI — [Tarih / Saat]
Reviewer: [İsim]
Tahmini tamamlanma: [Saat veya tarih]

Bu geçiş reviewer'ın PR'ı gördüğünü ve aktif baktığını gösteriyor. "Kimse bakmadı mı?" sorusu ortadan kalkıyor.

Ekip İçi Review SLA

SLA (Service Level Agreement) kurumsal bir kavram gibi görünüyor ama küçük ekipler için de değerli. "PR'lar ne kadar sürede review edilmeli?" sorusunun cevabı yazılı olduğunda beklenti yönetimi mümkün hale geliyor.

Küçük teknik ekip için örnek SLA:

📋 PR REVIEW SLA — [Ekip Adı]

Kritik (hotfix, production bug):
→ Review başlangıcı: 2 saat içinde
→ Review tamamlanma: Aynı gün

Yüksek öncelik (aktif sprint görevi):
→ Review başlangıcı: İş günü içinde
→ Review tamamlanma: 24 saat

Normal (feature, iyileştirme):
→ Review başlangıcı: 24 saat içinde
→ Review tamamlanma: 48 saat

Küçük (dokümantasyon, minor fix):
→ Review başlangıcı: 48 saat içinde
→ Review tamamlanma: 72 saat

Bu SLA Alios'ta "Review SLA" node'u olarak kayıt altına alınıyor. Her PR açılırken öncelik seviyesine göre review deadline hesaplanıyor ve node'a yazılıyor.

SLA aşıldığında ne olur? Waiting node'undaki deadline geçmiş ama hâlâ açık — bu sinyal otomatik olarak görünür hale geliyor. Pazartesi sabahı "SLA aşılan PR'lar" filtresi çalıştırılıyor.

Pazartesi Sabahı PR Review Taraması

⏱️ 10 DAKİKA

- [ ] "Waiting" durumundaki node'lar listelendi
      Kaç gündür bekliyor?
      SLA aşıldı mı?

- [ ] "Review" durumunda 24 saatten uzun süre olanlar
      Reviewer bloke mu, yardım gerekiyor mu?

- [ ] "Fix Requested" durumunda 48 saatten uzun süre olanlar
      Geliştirici düzeltmeleri yapmadı mı, neden?

- [ ] Bu hafta merge edilmesi gereken PR'lar belirlendi

Review Kalitesi İçin Node Açıklaması

Review sadece "onaylandı / reddedildi" değil. Review sırasında öğrenilen şeyler node açıklamasına işlendiğinde ekip hafızası oluşuyor.

👀 REVIEW NOTU — [Tarih]
Reviewer: [İsim]
Sonuç: [ ] Onaylandı [ ] Değişiklik istendi

Olumlu:
[Ne iyi yazılmıştı — 1-2 madde]

Geliştirilecek:
[Neyin değiştirilmesi istendi — spesifik]

Öğrenme notu:
[Bu PR'dan ekibin öğrenebileceği bir şey var mı]

Bu not bir sonraki benzer görevde referans alınabiliyor. Aynı yorum tekrar tekrar verilmiyor.

Son Düşünce

PR review darboğazı önlenemez değil. Ama görünür kılınmazsa yönetilemiyor.

Alios'ta WAITING ve REVIEW durumları, reviewer ataması ve SLA takibi bu görünürlüğü kuruyor. "Bu PR ne zaman merge olacak?" sorusu node'a bakılarak cevaplanıyor. Review gecikmeleri haftalık taramada yakalanıyor.

Geliştirici PR açıp beklemiyor — beklediği görünüyor ve takip ediliyor.