Mühendislik RFC (Yorum Talebi) süreçleri neden 4 aylık anlamsız tartışma felçlerine dönüşür; süre sınırlandırılmış RFC döngüleri ve 'Katılmıyorum Ama Bağlanıyorum' ilkesi mimari hızı nasıl açar?

Büyüyen teknoloji şirketlerinde büyük mimari kararları (gRPC'ye geçiş, dağıtık kuyruk seçimi, veritabanı bölümleme) değerlendirmek için **Yorum Talebi (RFC - Request for Comments)** süreci şarttır. Ancak sıkı kurallar olmazsa RFC'ler **Analiz Felcine ve Bisiklet Parkı Sendromuna (Bike-Shedding)** dönüşür: 40 mühendis tek bir JSON alanının adını veya Go mu Rust mı kullanılacağını Google Docs üzerinde 300 yorumla 4 ay boyunca tartışırken canlıya tek satır kod çıkamaz. Başarılı organizasyonlar **Süre Sınırlandırılmış RFC Yönetişimi** uygular: (1) **Standart 1-2 Sayfalık Markdown Şablonu**: **Problem Tanımı**, **Hedef Olmayanlar (Non-Goals)**, **Önerilen Mimari**, **Değerlendirilen Alternatifler** ve **Elenen Yaklaşımlar**. (2) **Katı 2 Haftalık İnceleme Süresi**: RFC Pazartesi açılır ve tam 14 takvim günü sonra kapanır. (3) **Tek Karar Verici (DRI - Directly Responsible Individual)**: Nihai kararı Baş Mimar veya Teknik Lider verir. (4) **Amazon'un 'Katılmıyorum Ama Bağlanıyorum' (Disagree and Commit) İlkesi**: Karar verildikten sonra herkes kararın arkasında kenetlenir; sinsi itirazlar kesinlikle yasaklanır.

Teknik Yönetişim: Yorum Talebi (RFC) Yaşam Döngüsü ve Uzlaşma ile Hız Arasındaki Süre Sınırı Dengesi

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Büyüyen teknoloji şirketlerinde büyük mimari kararları (gRPC'ye geçiş, dağıtık kuyruk seçimi, veritabanı bölümleme) değerlendirmek için Yorum Talebi (RFC - Request for Comments) süreci şarttır. Ancak sıkı kurallar olmazsa RFC'ler Analiz Felcine ve Bisiklet Parkı Sendromuna (Bike-Shedding) dönüşür: 40 mühendis tek bir JSON alanının adını veya Go mu Rust mı kullanılacağını Google Docs üzerinde 300 yorumla 4 ay boyunca tartışırken canlıya tek satır kod çıkamaz. Başarılı organizasyonlar Süre Sınırlandırılmış RFC Yönetişimi uygular:

Standart 1-2 Sayfalık Markdown Şablonu: Problem Tanımı, Hedef Olmayanlar (Non-Goals), Önerilen Mimari, Değerlendirilen Alternatifler ve Elenen Yaklaşımlar.

Katı 2 Haftalık İnceleme Süresi: RFC Pazartesi açılır ve tam 14 takvim günü sonra kapanır.

Tek Karar Verici (DRI - Directly Responsible Individual): Nihai kararı Baş Mimar veya Teknik Lider verir.

Amazon'un 'Katılmıyorum Ama Bağlanıyorum' (Disagree and Commit) İlkesi: Karar verildikten sonra herkes kararın arkasında kenetlenir; sinsi itirazlar kesinlikle yasaklanır.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

RFC yaşam döngüsü yönetişimi Git üzerinde 4 standart aşamayla işler:

▸Aşama: Taslak: Yazar docs/rfc/rfc-042-olay-gudumlu-odeme.md dosyasını DRAFT statüsünde açar ve 2 kıdemli arkadaşından erken geri bildirim alır.

▸Aşama: Açık İnceleme (14 Gün): Yazar bir Pull Request açar ve #mimari-tartisma kanalına duyurur; tüm takım GitHub yorumlarında alternatifleri tartışır.

▸Aşama: DRI Hakemliği: İki rakip fikir arasında tıkanma yaşanırsa, Sorumlu Lider (DRI) 30 dakikalık bir toplantı yaparak nihai rotayı seçer.

▸Aşama: Karar ve Arşivleme: RFC ACCEPTED (Kabul), REJECTED (Reddedildi) veya SUPERSEDED durumuna alınıp birleştirilir ve kalıcı hafıza için ADR'a dönüştürülür.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Büyük teknik dönüşümler, yeni framework seçimleri, takımlar arası API sözleşmeleri, bulut altyapı yenilemeleri ve kimlik doğrulama mimarisi değişiklikleri.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Bir RFC'nin 6 ay boyunca karara bağlanmadan açık kalması ve bu sırada takımların gizlice kendi bildiklerini okuması
✓
karara katılmayanların kabul edilmiş bir mimariyi uygulamayı reddederek projeyi sabote etmesi

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
Google Docs üzerinde 450 çözülmemiş yoruma sahip sahipsiz RFC'ler
✓
takımların mimari uzlaşma beklerken teslimat yapamaması
✓
tartışmalı teknik kararların Slack'te en çok bağıranın isteğine göre verilmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Tüm RFC'lere 14 günlük katı süre sınırı koyun
✓
her öneri için tek bir Nihai Karar Verici (DRI) atayın
✓
tüm Staff+ mühendislere 'Katılmıyorum Ama Bağlanıyorum' ilkesini aşılayın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Süre sınırlı RFC'ler fikir çeşitliliği ile hızlı karar alma hızını dengeler; ancak herkesin aynı fikirde olmadığı durumlarda popüler olmayan nihai kararları alabilecek güçlü bir mimari liderlik gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir e-ticaret platformu iç servis iletişiminde REST'ten GraphQL'e mi yoksa gRPC'ye mi geçileceğini 5 ay boyunca tartıştı. 60 mühendis Slack'te kamplara bölündü ve geliştirme hızı %40 düştü. Baş Mimar devreye girdi ve Süre Sınırlı RFC modelini başlattı:

Bir Staff SRE'yi tek karar verici (DRI) atadı,

Somut performans testlerini sunmaları için takıma 10 gün süre verdi, ve

45 dakikalık bir karar paneli düzenleyerek iç servisler için gRPC, mobil için GraphQL hibrit modelini seçti. 'Katılmıyorum Ama Bağlanıyorum' ilkesi işletildi, tüm takımlar kararın arkasında birleşti ve dönüşüm sıfır sürtünmeyle 6 haftada tamamlandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Katı bir süre sınırı olmayan ucu açık bir RFC (Yorum Talebi) sürecinin arkasındaki en büyük tehlike nedir?

Analiz Felci ve Bisiklet Parkı Sendromu: Mühendislerin aylarca önemsiz detaylar üzerine sonu gelmeyen teorik tartışmalara boğulması; bu durumun mimari ivmeyi ve yazılım teslimat hızını tamamen felç etmesidir.

Teknik mimaride Amazon'un 'Katılmıyorum Ama Bağlanıyorum' (Disagree and Commit) liderlik ilkesi ne anlama gelir?

Mühendisler karar aşamasında fikirleri kıyasıya tartışmaya ve itiraz etmeye teşvik edilir; ancak Nihai Karar Verici (DRI) kararı verdikten sonra, herkes seçilen çözümün arkasında %100 kenetlenir ve sinsi iç dirençler tamamen biter.

Teknik Yönetişim: Yorum Talebi (RFC) Yaşam Döngüsü ve Uzlaşma ile Hız Arasındaki Süre Sınırı Dengesi — Sıkça Sorulan Sorular

Bir RFC sürecinde Doğrudan Sorumlu Kişinin (DRI) rolü nedir?

Tartışmayı yöneten, geri bildirimleri toparlayan, fikir ayrılıklarında nihai bağlayıcı kararı verme yetkisine sahip olan ve uygulamanın hayata geçirilmesini sağlayan tek yetkili liderdir.

İyi yazılmış bir RFC belgesinde 'Hedef Olmayanlar' (Non-Goals) bölümü ne işe yarar?

Önerilen mimarinin bilinçli olarak neleri çözmeyeceğini açıkça belirten sınır listesidir; kapsamın gereksiz yere büyümesini (scope creep) ve konu dışı tartışmaları en baştan engeller.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
RFC'ler mimari önerileri toplar; süreyi kesinlikle 14 takvim günüyle sınırlandırın.
▸
Tıkanıklıkları çözmek için tek bir Doğrudan Sorumlu Lider (DRI) atayın.
▸
'Katılmıyorum Ama Bağlanıyorum' ilkesini işletin: Karardan sonra herkes tam destek verir.
▸
Kabul edilen RFC'leri Git üzerinde versiyonlanan Mimari Karar Kayıtlarına (ADR) dönüştürün.

Yaygın Yanılgılar

✗
Yanılgı: Bir RFC'nin şirketteki tüm mühendislerin %100 oybirliğiyle onaylanması gerekir (Gerçek: Tam oybirliği imkansızdır; RFC fikirleri toplar, kararı DRI verir).
✗
Yanılgı: RFC'ler sadece yıllar sürecek dev projeler içindir (Gerçek: Birden fazla takımı etkileyen veya yeni bir teknoloji getiren her değişiklik hafif bir RFC gerektirir).

Karar Kılavuzu & Önceliklendirme

Geniş teknik katılımı sağlarken mimari geliştirme hızından taviz vermemek için tek yetkili liderlere (DRI) ve 'Katılmıyorum Ama Bağlanıyorum' ilkesine sahip 14 günlük süre sınırlı RFC modelini uygulayın.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]The Rust RFC Process: Open Collaborative Decision Making at Scale— Rust Programming Language Foundation