Holakrasi'den Team Topologies'e: Gerçek Otonomi için Teknik Takımların Tasarımı

"Otonomi"yi yapı olmadan vermek, organizasyonel borcu daha hızlı birikirmek demek. Birkaç yıl önce matriks, proje-modundan ürün-moduna; akışa-hizalanmış (stream-aligned) takımlara geçtik. Hız arttı ama defekt, mükerrer iş ve takım arası sürtünme de fırladı. Çözüm ne daha fazla özgürlük ne de daha fazla süreçti; daha iyi sınırlar ve net karar haklarıydı.

Bu yazı Holakrasi, Spotify modeli ve Team Topologies'den seçerek neleri aldığımızı ve otonominin kaosa dönüşmesini engelleyen korumaları özetliyor.

Mühendislikte Otonomi Gerçekte Ne Demek?#

Karar hakları: Takım tek başına neye karar verebilir, nerede onay/öneri gerekir?
Net domain sahipliği: Bir takım bir problem alanını uçtan uca sahiplenir—yol haritası, kod, altyapı, on-call, maliyet.
İnce ve güvenilir arayüzler: Takımlar toplantılarla değil versiyonlanmış API'ler, event'ler ve kontratlarla etkileşir.
Çıktı odaklılık: Takımlar bilet kotasına değil sonuçlara ve SLO'lara taahhüt eder.

Modellerden Nasıl Yararlandık#

Holakrasi (seçerek benimseme)#

Aldıklarımız: Rol tüzükleri (amaç, sorumluluklar, domainler) ve kısa "taktik" toplantılar.
Almadıklarımız: Tam yönetişim törenleri ve anayasa—hızlı ürün organizasyonu için ağır.
Dikkat: Rol çoğalması ve muğlaklık. Canlı rol kataloğu tutun, her ay işe yaramayan rolleri kapatın.

Spotify Modeli (dil ve topluluklar)#

Aldıklarımız: Squad'lar (çapraz fonksiyonel) ve guild'ler (ilgi toplulukları). Chapter'lar, gerçekten ortak zanaat standartları varsa.
Almadıklarımız: Org şemasını kopyalamak. Spotify bile bunun bir fotoğraf karesi olduğunu, plan olmadığını söyledi.
Dikkat: Chapter lead'lerin gölge yöneticiye dönüşmesi. Performans yönetimi squad liderinde kalsın.

Team Topologies (iskelet)#

Aldıklarımız: Dört takım tipi ve üç etkileşim modu:
- Stream-aligned, Platform, Enabling, Complicated-Subsystem
- Collaboration, X-as-a-Service, Facilitating
Neden işe yarıyor: Conway Yasası ile örgüt tasarımını hizalar, bağımlılıkları görünür kılar. İstediğiniz takım sınırlarına göre mimariyi şekillendirmek için ters Conway manevrası ile eşleyin.
Dikkat: Platform takımları ürün takımı gibi davranmalı; SLA'lar ve "paved road" yayınlamalı; bilet fabrikası ya da bekçi olmamalı.

Otonomiyi Güvenli Kılan Korumalar#

Sahiplik haritası: Her domain, servis ve yetenek tek bir takıma net atanır. Ortak velayet yok.
SLO ve hata bütçeleri: Güvenilirliğin sahibi takımlar; hata bütçelerini liderlik korur.
Değişim taksonomisi: 2-yönlü kapılar tavsiye gerektirir; 1-yönlü kapılar etkilenen sahiplerden onay ister.
Karar kayıtları (ADR): Hafif, aranabilir; PR'lara linkli.
Paved road: CI, deploy, gözlemlenebilirlik, kimlik vb. için görüş sahibi varsayılanlar. Olgunluk seviyeleri ve kaldırma takvimi yayınlayın.
Etkileşim kontratları: Her çapraz bağımlılık için hedef etkileşim modu ve beklentiler yazılı.
Metrikler: DORA (lead time, deploy sıklığı, MTTR, değişim hata oranı), takım sağlığı, platform NPS.

Geçiş Oyun Kitabı (12–24 Hafta)#

Değer akışlarını haritalayın, 3–5 akışa-hizalanmış aday takım ilan edin; sahip oldukları sonuçları isimlendirin.
Mevcut bağımlılık grafiğini çizin; bekleme, yeniden iş, belirsiz sahiplik sıcak noktalarını işaretleyin.
Etkileşim modlarını tanımlayın; "toplantıyla koordinasyon"u öldürün.
Bir enabling takım kurun (8–12 hafta) test, gözlemlenebilirlik ve trunk-based development koçluğu için.
Platform = ürün: CI/CD, logging, auth, deney için golden path RFC yayınlayın.
Servis sınırları: Repoları ve runtime sahipliğini takımlara hizalayın. Kod, on-call ve bütçeyi eş konumlayın.
Kadans: Haftalık taktik (squad), iki haftada bir guild, aylık mimari forum, üç aylık iş gözden geçirme.
Ölçün: DORA + incident + merge süresi baz çizgisi; 6/12/24. haftalarda tekrar ölçün.

Kaçınılacak Anti-Pattern'ler#

Otonomi tiyatrosu: Takımlar backlog'a sahip ama deploy, kadro veya roadmap değiştiremiyor.
Platform polisi: Sert kapılar, paved road yerine. Yaratıcı bypass'lara hazır olun.
Gölge yönetim: Chapter'lar hiyerarşiyi geri getiriyor.
Matriks sızıntısı: Çift raporlama = belirsiz kararlar. Akış başına tek iplikli lideri tercih edin.
Araç > sonuç: Karar hakları ve sınırlar değişmeden yeni törenler/araçlar.

Çalışan Şablonlar#

Takım Tüzüğü (kopyala-yapıştır)#

Amaç: Takım neden var? Müşteri kim?
Sonuçlar (12 ay): 3–5 ölçülebilir sonuç ve öncül göstergeler.
Kapsam & sınırlar: Neler dahil/dahil değil? Hangi servisler ve domainler?
Karar hakları: Tek başımıza neye karar veririz? Ne öneri/onay ister?
Arayüzler: Sahiplendiğimiz API/event'ler; SLA/SLO'lar.
İşletim modeli: Kadans, on-call, incident, release süreci.
Metrikler: DORA, SLO, müşteri memnuniyeti, maliyet sınırları (ör. $/1000 istek).

Etkileşim Modu Kontrol Listesi#

Collaboration: Süre kutulu mu? Çıkış kriterleri net mi? Tek sahip var mı?
X-as-a-Service: SLO'lar yayınlı mı? Runbook? Backlog girişi ve görünürlük?
Facilitating: Koçluk hedefleri, yetenek transfer planı, bitiş tarihi?

Hafif Karar Akışı#

Küçük, geri döndürülebilir: Takım karar verir; ADR yazar.
Çapraz takım, geri döndürülebilir: Etkilenen sahiplerden tavsiye al; gerekçeli itiraz yoksa ilerle.
Geri döndürülemez/yüksek etki: Sahip liderlerden onay; risk ve geri alma planı yazılı.

Tasarımı ikame etmeyen ama yardım eden araçlar#

ADR repo + şablonlar ve arama.
Paved road skor kartları takım bazında.
Golden path iskeletleri (gözlemlenebilirlik ve auth gömülü).
Org bağımlılık haritası wiki'de; üç ayda bir gözden geçirme.

SSS: Otonomiyi Ne Zaman Zorlamamalı?#

Ürün/pazar uyumu belirsizse: Daha sıkı hizalama, daha az takım.
Güvenlik/düzenleyici kritik alanlarda: Daha fazla onay ve izlenebilirlik.
Çok küçük organizasyonlarda (<15 mühendis): Yapı icat etmeyin; güçlü varsayılanlar ve net sahiplik yeter.

Özet#

Törenlerden değil, değer akışları ve sınırlardan başlayın.
Omurgayı Team Topologies ile kurun; Holakrasi ve Spotify'dan minimal alın.
Platformu ürün gibi yönetin; enabling takımı erken kurun.
Yazın: tüzükler, SLO'lar, ADR'ler, etkileşim modları.
Sonuçları ölçün; yapıyı ona göre ayarlayın.