Yazılım Ekiplerinde Rol Beklentileri: RACI ve DACI Çerçeveleri

Yazılım takımlarında rol belirsizliği kendini rol tartışması olarak değil, duran iş olarak gösterir. Gallup’un 2024 ABD işyeri araştırmasına göre çalışanların %46’sı kendisinden ne beklendiğini söyleyemiyor. Mühendisler bir kararın kime ait olduğunu bilmediğinde iş ya bir toplantıyı bekler ya da iki ayrı branch’te iki kez yazılır.

İki hafif çerçeve bu sorunun büyük kısmını kapatır. Tekrar eden akışlar için (API tasarımı, deployment, gereksinimler) RACI’yi, tek seferlik kararlar için (mimari, araç seçimi) DACI’yi kullanın. Başlangıç için varsayılan dar tutulmalı: en çok yeniden iş doğuran iki üç akışı seçin, kararı kimin verdiğini yazın, geri kalanı size bir bedel çıkarana kadar informal bırakın.

Rol Belirsizliğinin Maliyeti#

Yazılım takımları bu %46’lık tablonun kötü tarafında duruyor. Metodolojiler birkaç yılda bir değişiyor, uzaktan çalışma koridor sohbetini ortadan kaldırıyor, DevOps, Frontend, Backend, QA ve Product arasındaki sınırlar her yeniden yapılanmada kayıyor.

Bozulma genelde gürültülü olmuyor. İş, kimin onayının geçerli olduğu bilinmediği için review’da bekliyor ya da aynı problemi iki kişi paralel çözüyor. Retrospektifte bu bir iletişim sorunu olarak kaydediliyor, takım daha çok konuşmaya söz veriyor ve aynı şey bir sonraki çeyrekte tekrarlıyor.

”Herkes Developer” Yaklaşımının Bedeli#

Bir platform migrasyonu sırasında yönetim “artık hepimiz developer’ız” duyurusunu yaptı. Niyet makuldü: siloları yıkmak, işbirliğini teşvik etmek.

Ortaya çıkan tablo silolardan daha yavaştı. DevOps mühendisleri frontend kod yazmaya başladı, backend developer’lar hiç işletmedikleri altyapıyı devraldı, frontend developer’lar triyaj yapacak bağlamları olmadan production sorunlarını debug etti. Hiç kimse hiçbir şeyin sahibi olmadı, dolayısıyla herkes her şeyin sahibiydi.

Sorun insanlar değildi. Bir rolün nerede bitip diğerinin nerede başladığını kimse yazmamıştı. İşbirliği noktaları açık tutularak swim lane’lerin yeniden kurulması teslimatı yeniden hareketlendirmeye yetti.

Sessiz Handoff Başarısızlığı#

Bir senior engineer bir özellik geliştirmek için iki hafta harcadı: sağlam iş, iyi test edilmiş, deploy’a hazır. Aynı işin büyük kısmını bir junior developer farklı bir branch’te çoktan yazmıştı ve ikisinin de haberi yoktu.

Kaybedilen sprint bu tablonun ucuz tarafı. İki taraf arasındaki güven aşınır, junior developer durumu kendi işine verilmiş bir not gibi okur ve retrospektif kimin haber vermesi gerektiği tartışmasına döner.

Uzaktan Çalışmanın Büyüteç Etkisi#

Aynı ofiste oturan takımlarda rol belirsizliği omuz dürtmeyle çözülür: sahipliği anında netleştiren informal konuşmalarla. Uzaktan çalışma bu güvenlik ağını kaldırır; belirsiz ama yönetilebilir olan şey, kimsenin göremediği bir tıkanmaya dönüşür.

ABD, Hindistan ve Almanya’ya yayılmış bir takım bunu doğrudan yaşadı. Bir taraftaki hiyerarşik beklentiler, diğer tarafın tercih ettiği düz yapıyla çatıştı; üçüncü grup ise kararların birlikte alınmasını bekliyordu. Açık rol tanımı olmadan “Bu mimari değişikliği kim onaylıyor?” sorusu günlerce süren bir e-posta zincirine dönüştü.

Framework 1: Yazılım Takımları İçin RACI Matrix#

RACI bürokrasi olmadan yapı sağlar:

• Responsible (Sorumlu): İşi kim yapar
• Accountable (Hesap verebilir): Final kararları kim verir (sadece bir kişi)
• Consulted (Danışılan): Kim input verir (iki yönlü iletişim)
• Informed (Bilgilendirilen): Sonuçları kimin bilmesi gerekir (tek yönlü)

Yazılıma Özgü Uygulamalar#

API Tasarımı:

interface APITasarimRolleri {
  responsible: "Backend Developer";
  accountable: "Tech Lead";
  consulted: ["Frontend Developer", "Product Manager"];
  informed: ["QA Takımı", "DevOps"];
}

Production Deployment:

interface DeploymentRolleri {
  responsible: "DevOps Engineer";
  accountable: "Tech Lead";
  consulted: ["Backend Developer"];
  informed: ["Product Manager", "QA Takımı", "Support"];
}

Özellik Gereksinimleri:

interface RequirementsRolleri {
  responsible: "Product Manager";
  accountable: "Product Owner";
  consulted: ["Tech Lead", "UX Designer"];
  informed: ["Development Takımı"];
}

Bir takım RACI’yi ana akışlarına uyguladı ve her akışı tek sayfada tuttu. Dikkate değer değişiklik prosedüreldi: eskiden lead’ler arasında dolaşan sorular doğrudan matriste accountable olarak yazan kişiye gitti.

Framework 2: Karmaşık Kararlar İçin DACI#

Mimari kararlar, araç seçimi ve süreç değişiklikleri için DACI daha iyi çalışır:

• Driver: Karar verme sürecini kolaylaştırır
• Approver: Final söz (deadlock’tan kaçınmak için tek kişi)
• Contributors: Uzmanlık ve tavsiyeler sağlar
• Informed: Sonucu bilmesi gerekenler

DACI’yi Mimari Kararlara Uygulamak#

Bir fintech startup bir yıldan kısa sürede birkaç mühendisten birkaç düzine mühendise büyüdü. Karar alma kilitlendi: herkes fikir vermek istiyordu, kimsenin yetkisi yoktu.

Tüm mimari kararlar için DACI’yi devreye aldılar:

interface MimariKarar {
  driver: "Senior Architect"; // Tartışmayı kolaylaştırır
  approver: "Tech Lead"; // Final karar
  contributors: [
    "Backend Lead",
    "Frontend Lead",
    "DevOps Lead",
    "Security Engineer"
  ];
  informed: ["Tüm Mühendisler", "Product Takımı"];
}

Asıl işi gören parça tek approver’dı. Adı yazılı bir approver, açık uçlu tartışmayı bir son tarihe bağlar: contributor’lar karar toplantısına kadar görüşünü sunar, sonrasında karar yeniden açılmaz, kayda geçer.

Net Sınırların Özerkliğe Katkısı#

Paradoksal gerçek: net sınırlar özerkliği artırır.

Bir frontend developer sorumluluğunun nerede bittiğini ve backend’in nerede başladığını tam olarak bildiğinde, sürekli kontrol etmeden güvenle karar verebilir. Sınırlar bulanık olduğunda, herkes her şeyi kontrol eder, darboğazlar ve hayal kırıklığı yaratır.

Frontend/Backend/DevOps Sınırları#

API Contract Sahipliği#

Backend sahip: Contract tanımı, data validasyon, error kodları Frontend sağlar: Input gereksinimleri, use case’ler, UX kısıtları DevOps sağlar: Performans monitoring, ölçekleme yetenekleri

Data Validasyon#

Backend handle eder: Server-side validasyon, business kuralları, güvenlik Frontend handle eder: Kullanıcı deneyimi, input formatlama, anında feedback Paylaşılan sorumluluk: Error mesajlaşma (backend tanımlar, frontend görüntüler)

Performans#

Backend optimize eder: Query performans, data işleme, caching Frontend optimize eder: Rendering, bundle size, lazy loading DevOps sağlar: Altyapı, CDN, monitoring araçları

Production Sorunları#

interface IncidentSahiplik {
  infrastructure: "DevOps handle eder (serverlar, network, platform)";
  application: "Developerlar handle eder (buglar, logic hataları)";
  data: "Backend handle eder (corruption, bütünlük)";
  ui: "Frontend handle eder (rendering, client hataları)";

  escalation: {
    unclear: "DevOps triyaj yapar, uygun takıma yönlendirir";
    complex: "Tüm ilgili takımlarla ortak war room";
  };
}

Product Manager/Engineering İşbirliği#

PM ile mühendislik arasındaki sınır her zaman bulanıktır. Net karar hakları bu sürtünmeyi tekrar etmekten çıkarır:

Özellik Önceliklendirme:

• PM karar verir: Ne ve ne zaman
• Engineering karar verir: Nasıl ve çaba tahmini
• Ortak karar: Teknik kısıtlar mümkün olanı etkilediğinde

Teknik Borç:

• Engineering karar verir: Teknik yaklaşım
• PM karar verir: Business impact toleransı
• Ortak tartışma: Özelliklere göre öncelik

Scope Değişiklikleri:

• PM yapabilir: Sprint içinde scope ayarlama
• Engineering sahip: Teknik fizibilite veto yetkisi
• Onay gerektirir: Timeline’ı etkileyen scope değişiklikleri

Release Kararları:

• PM sahip: Pazar zamanlaması, müşteri iletişimi
• Engineering sahip: Teknik hazırlık, kalite kriterleri
• Ortak onay: Go/no-go kararı

Bunu bir kez yazmak, takım el kitabında bir karar matrisi olarak tutmak, tekrar eden sürtünmenin çoğunu ortadan kaldırır. Tartışma kimin karar verdiği olmaktan çıkar, kararın ne olması gerektiğine döner.

Rol Etkinliği Ölçümü#

Küçük bir gösterge kümesi yeterli:

interface RolNetligiMetrikleri {
  birincil: {
    netlikIndeksi: number; // Anket skoru, hedef >85%
    kararHizi: number; // Problemden çözüme kadar günler
    catismaZamani: number; // Rol çatışmalarını çözme günleri, hedef <2
    handoffBasarisi: number; // Sorunsuz handoff yüzdesi
  };

  ikincil: {
    memnuniyet: number; // Çalışan memnuniyet skorları
    velocity: number; // Sprint başına story point
    kalite: number; // Defect oranları
    eldeTutma: number; // Özellikle senior mühendisler
  };
}

Hiçbir şeyi değiştirmeden önce bir başlangıç ölçümü alın. Başlangıç değeri olmadan, rollout sonrası ilk anket framework’ün işe yarayıp yaramadığını değil, takımın yalnızca daha sakin bir çeyrek geçirip geçirmediğini gösterir. Önce karar hızı ve çatışma çözüm süresi hareket eder; memnuniyet ve elde tutma bunların en az bir çeyrek gerisinden gelir, bu yüzden erken verilen hüküm işleyen bir framework’ü başarısız gösterir.

Yaygın Tuzaklar#

Aşırı Dokümantasyon Tuzağı#

Kimsenin okumadığı 50 sayfalık rol dokümanları yazmak. Görev listelerine değil, karar sınırlarına ve iletişim beklentilerine odaklanın.

Kötü:

Frontend Developer:
- React componentleri yaz
- CSS stilleri oluştur
- API çağrıları implement et
- [100 task daha]

İyi:

interface FrontendKararlari {
  tekBasinaKararVerebilir: [
    "Feature'lar içinde component mimarisi",
    "CSS implementation yaklaşımı",
    "State management kalıpları"
  ];

  danismalidir: [
    "Paylaşılan componentlerde breaking değişiklikler",
    "Yeni bağımlılıklar veya framework'ler",
    "API contract değişiklikleri"
  ];

  onayAlmalidir: [
    "Major mimari değişiklikler",
    "Build pipeline modifikasyonları"
  ];
}

“Ayarla ve Unut” Hatası#

Roller evrimleşir. Framework’ler onlarla evrimleşmeli. Üç ayda bir review planla.

Kültürel Duyarsızlık#

Batı merkezli framework’leri adaptasyon olmadan global takımlara uygulamak. Global bir SaaS şirketi bölge başına yetki beklentilerini açıkça eşleyerek bunu çözdü:

interface KulturelAdaptasyon {
  US: "İşbirlikçi karar verme, meydan okuma teşvik edilir";
  Germany: "Veriye dayalı kararlar, formal dokümantasyon";
  India: "Hiyerarşiye saygı, gerektiğinde eskalasyon";

  paylasilan_prensip: "Her rol için net karar hakları";
}

Bunu işler kılan şey paylaşılan prensip. Her rol her yerde açık karar haklarını korur; bölgeye göre değişen tek şey eskalasyon ve itiraz üslubudur.

Senior Mühendislerin Direnci#

Deneyimli developer’lar formal rol tanımını çoğu zaman micromanagement olarak okur. Tutan çerçeveleme karar yetkisi: doküman, neyi kendi başına çözebileceğini söylemek için vardır ve bu çalışmadan sonra kendi başına çözebileceğin şeylerin listesi öncekinden uzun olmalıdır.

Temel Dersler#

Rollout’lar tahmin edilebilir biçimlerde tökezler. Takımın gerçekte nasıl iletişim kurduğu haritalanmadan doküman yazılır. Framework, akışın içinde yaşayan mühendislere sorulmadan yukarıdan gelir. Pilot atlanır ve tüm organizasyon aynı anda devreye alınır.

İşe yarayanlar:

• Önce gerçek davranışı haritalayın. Pratikte netliğin nerede bozulduğunu görün.
• IC’leri framework tasarımına dahil edin. Sürtünme noktalarını bilirler.
• Gönüllülerle küçük başlayın. Benimsenme tartışmasını onların sonuçları taşısın.
• Karar haklarına odaklanın. Matris, kimin neye karar verebileceğini yanıtlar.
• Düzenli olarak gözden geçirin. Roller kayar ve bayatlamış bir matris dikkate alınmaz.

RACI ve DACI, bir akış iki veya daha fazla rolü kestiğinde ve birden fazla kez tıkandığında kendini amorti eder. Aynı kanalda oturan ve tek bir servise sahip dört kişilik bir takımda matris fazladan tören olur: informal handoff daha hızlıdır ve konuyu yeniden açmanın vakti takım bölündüğünde ya da dağıtık çalışmaya geçtiğinde gelir. Son dönemde en çok yeniden iş doğuran akışı seçin, sorumluluğun kimde olduğunu yazın, gerisini size bir bedel çıkarana kadar olduğu gibi bırakın.

Kaynaklar#

• Çalışan Bağlılığı 10 Yılın En Düşüğüne Düştü - Gallup (yeni sekmede açılır) - Gallup’un 2024 ABD işyeri araştırması; çalışanların %46’sı işte kendisinden ne beklendiği konusunda net değil.
• DORA Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - Beklenti netliğini elit ve düşük performanslı mühendislik ekipleri arasındaki kilit fark olarak ortaya koyan yıllık araştırma.
• Roller, Sorumluluklar ve Kaynaklar - PMI (yeni sekmede açılır) - Çapraz fonksiyonlu ekiplerde rol ve karar yetkisini netleştirmek için PMI’ın temel RACI çerçevesi.
• Hofstede’nin Ulusal Kültür Boyutları - Hofstede Insights (yeni sekmede açılır) - Otorite ve hiyerarşi beklentilerinin ABD, Almanya, Hindistan gibi bölgelere göre nasıl farklılaştığını açıklayan kültürel boyutlar modeli.
• Psikolojik Güvenlik Nedir? - Harvard Business Review (yeni sekmede açılır) - Amy Edmondson; belirsiz beklentilerin korkmadan dile getirilebildiği ortam olarak psikolojik güvenlik - rol netliği sürecinin etkinleştiricisi.
• Üretken Örgütsel Kültür - DORA (yeni sekmede açılır) - Westrum tipolojisi; üretken kültürler rol beklentisi sürtünmesini azaltan açık karar hakları ve bilgi akışı sağlar.