Mühendislik Organizasyon Şeması: Ekipleri Sahip Oldukları Sistemlerle Eşleştirin

Çoğu organizasyon şeması tek bir soruyu yanıtlar: kim kime bağlı. Mühendislerin bu yanıta nadiren ihtiyacı olur. Bir olay sırasında, sorun çıkaran servisin hangi ekibe ait olduğunu ve nöbette kimin olduğunu bilmeleri gerekir. Bir tasarım incelemesinde, bir değişikliğin hangi ekiplere dokunduğunu ve bu ekiplerin nasıl birlikte çalıştığını bilmeleri gerekir. İsimlerden ve unvanlardan oluşan bir şema bunların hiçbirini yanıtlamaz.

Bu yazı, bu soruları yanıtlayan bir mühendislik organizasyon şeması oluşturuyor. Şema, insan tarafı için raporlama hatlarını koruyor ve mühendisliğin ihtiyaç duyduklarını ekliyor: ekip türü, sahip olunan sistemler, nöbet saatleri ve ekiplerin etkileşim biçimi. Ekipler için Team Topologies terimlerini kullanıyor ve neyin etiketleneceğiyle ve şemanın nasıl güncel tutulacağıyla bitiyor.

Bir mühendislik organizasyon şeması neleri göstermeli

Birkaç ekibi geçtiğinizde tek tek mühendisleri şemaya koymayın, her ekip lideri için bir kart gösterin. Altmış isimli bir şema telefon rehberidir; sekiz ekipli bir şema ise haritadır. İsimlere ihtiyaç duyulursa her ekibi kendi ekip listesine bağlayın.

Raporlama hatları hikâyenin tamamı değil

Mel Conway'in “How Do Committees Invent?” makalesi Nisan 1968'de Datamation'da yayımlandı. Conway, yasa hakkındaki kendi sayfasında tezini şöyle özetler: bir sistemi tasarlayan kuruluş, yapısı kendi iletişim yapısının kopyası olan bir tasarım üretir. Fred Brooks daha sonra buna Conway yasası adını verdi ve bu ad kalıcı oldu.

“İletişim” kelimesine dikkat edin. Organizasyon şeması raporlama hatlarını gösterir ve bunlar insanların iletişim kurma biçiminin yalnızca bir parçasıdır. Farklı direktörlere bağlı olup her gün konuşan iki ekip, sistemi yöneticileri arasındaki çizgiden daha fazla şekillendirir. Bu yüzden bu yazıdaki şema, ekiplerin yalnızca kime bağlı olduğunu değil, nasıl birlikte çalıştığını da yazıyor.

Yasa bir tasarım aracı olarak da işe yarar. İki servisin bağımsız kalması gerekiyorsa, onları her değişikliği koordine etmek zorunda olan ekiplere vermeyin. Conway'in makalesi bir sonuç daha ekler: ilk tasarım nadiren en iyisidir, bu yüzden kuruluşun tasarımla birlikte değişebilecek kadar esnek olması gerekir.

Ekip türleri ve etkileşim biçimleri

Matthew Skelton ve Manuel Pais'in Team Topologies yaklaşımı, ekiplere küçük ve ortak bir sözlük verir: dört ekip türü ve ekiplerin etkileşime girmesinin üç yolu.

Üç etkileşim biçimi:

• İş birliği (collaboration). İki ekip, bir API ya da bir uygulama gibi yeni bir şeyi keşfetmek için belirli bir süre yakın çalışır. Maliyetlidir, bu yüzden bir bitiş tarihi verin.
• Hizmet olarak X (X-as-a-Service). Bir ekip bir şey sağlar, diğeri onu az etkileşimle kullanır; dağıtım hattı buna bir örnektir.
• Kolaylaştırma (facilitating). Bir ekip diğerine yardım eder ve rehberlik eder; örneğin diğer ekip yeni bir test yaklaşımını benimserken.

Team Topologies sitesinin kendisinden bir uyarı: Site, yaklaşımın yeni bir organizasyon şeması tasarlama yöntemi olmadığını söyler. Yaklaşım, işin ekipler arasında nasıl aktığını anlatır. Sözlüğünü şemanızda etiket olarak kullanın, her raporlama hattını yeniden çizmek için bir gerekçe olarak değil.

Sahipliği tek bir yerde tutun

Yalnızca bir diyagramda yazan sahiplik bilgisi eskir. Doğruluk kaynağını mühendislerin zaten baktığı yerde tutun ve şemanın bunu ekip düzeyinde yansıtmasını sağlayın.

Backstage gibi bir servis kataloğunda her bileşen bir sahip belirtmek zorundadır: katalog tanımlayıcı biçiminde spec.owner zorunlu bir alandır ve sahip tek bir varlıktır, genellikle bir ekip. Bir depoda ise CODEOWNERS dosyası yolları, onlardan sorumlu kişilere ya da ekiplere eşler ve taslak olmayan bir pull request onların kodunu değiştirdiğinde GitHub kod sahiplerinden otomatik olarak inceleme ister.

Şema ile katalog çelişiyorsa genellikle katalog haklıdır ve şemanın incelemesi gecikmiştir.

Örnek: bir çevrimiçi mağazada mühendislik

Bir çevrimiçi mağazanın mühendislik bölümünde bir VP ve iki direktör var. Product Engineering üç ekip yönetiyor: ikisi de akış odaklı olan Checkout ve Search ile ödeme işlemlerinin ve dolandırıcılık puanlamasının sahibi olan karmaşık alt sistem ekibi Payments. Platform Engineering ise CI/CD'nin, Kubernetes kümelerinin ve gözlemlenebilirlik yığınının sahibi olan Platform ekibini ve lider rolü hâlâ açık olan Developer Experience ekibini yönetiyor.

Bu çeyrekte iki etkileşim aktif. Payments ve Checkout, Q2 sonuna kadar 3-D Secure üzerinde iş birliği yapıyor. Developer Experience ise Checkout'un sözleşme testlerine geçişini kolaylaştırıyor.

Nasıl okunur:

• Yukarıdan aşağı, raporlama hatları. VP, iki direktör ve beş ekip lideri. Çizgiler yalnızca kimin kime bağlı olduğunu gösterir.
• Kart rengi, ekip türü. Akış odaklı ekipler kehribar, karmaşık alt sistem gül, platform mavi, destekleyici ekip mor. Ekip düzeyinin üstündeki yöneticiler gri kalır.
• Her ekibin altında, mühendislik görünümü. Ekibin sahip olduğu servisler, nöbet saatleri ve diğer ekiplerle güncel etkileşimi.
• Kesikli kart açık bir pozisyondur. Developer Experience'ın henüz bir lideri yok ve şema bu boşluğu gizlemek yerine açıkça gösteriyor.

Neler etiketlenmeli

• Ekip adları, insanların söylediği şekliyle. Olay kanalında “Checkout” deniyorsa şemada da Checkout yazar.
• Sahip olunan sistemler, katalogda, panolarda ve alarmlarda kullanılan adlarla.
• Nöbet saatleri ve olayın nereye yükseltileceği.
• Etkileşim biçimi ve bir bitiş tarihi, her iş birliği için.
• Noktalı çizgi ilişkiler; örneğin güvenlik ekibine bağlı olup her gün Payments ile çalışan bir güvenlik mühendisi.
• Konum ya da saat dilimi, ekipler birden fazlasına yayılıyorsa.
• Son inceleme tarihi, şemanın kendisinde.

Sık yapılan hatalar

• Ekipsiz insanlar. İsimlerden oluşan bir ağaç, bir şey bozulduğunda kimseye nereye gideceğini söylemez.
• Kimsenin sahip olmadığı sistemler. Bir servis hiçbir ekibin altında görünmüyorsa asıl bulgu budur. Bir sonraki olay bunu sizin yerinize yapmadan önce servisi bir ekibe atayın.
• Paylaşılan sahiplik. İki sahip genellikle hiç sahip olmaması demektir. Backstage'in tek bir sahip istemesinin bir nedeni var.
• Sonu olmayan iş birliği. İş birliği belirli bir süre içindir. Hiç bitmeyen bir iş birliği çoğu zaman iki ekip arasındaki sınırın yanlış yerde olduğunu gösterir.
• Aşırı yüklenmiş ekipler. Bir düzine servisin ve iki nöbet rotasyonunun sahibi olan bir ekip hepsinde yavaş kalır. Team Topologies, bir ekibin bilişsel yükünü tasarımda gözetilmesi gereken bir sınır olarak ele alır; şema da bu yükü görünür kılar.
• Kimsenin güncellemediği bir şema. Her yeniden yapılanmada ve her yeni serviste güncelleyin, belirli aralıklarla da gözden geçirin.

Organizasyon şeması kimin neye sahip olduğunu gösterir; sistemlerin birbirine nasıl oturduğunu göstermez. Bunun için bir C4 modeli diyagramı ya da bir mikroservis mimarisi diyagramı çizin ve ikisini de eskimeyen mimari diyagramlar yazısında anlatıldığı gibi güncel tutun.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun ya da organizasyon şeması şablonundan başlayın.
2. Organizasyon şeması paketinden VP için bir Çalışan kartı ekleyin; ad, unvan, departman ve konumu doldurun.
3. Artı tutamaklarıyla kişi ekleyin: bağlı çalışan için alttaki, eş düzey için yandaki, yönetici için üstteki tutamağı kullanın. Şema kendini yukarıdan aşağı yerleştirir.
4. İşe alım yaptığınız her rol için bir Açık pozisyon kartı ekleyin.
5. Her ekip liderinin kart rengini ekip türüne göre ayarlayın, ekip düzeyinin üstündeki yöneticileri gri bırakın.
6. Her ekip liderinin altına Temel paketinden, ekip türünü, sahip olduğu sistemleri, nöbet saatlerini ve güncel etkileşim biçimini yazan bir Metin ekleyin.

Örnek 8 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Metin bu sınıra sayılmıyor. Organizasyon şeması oluşturucu sayfası paylaşma ve dışa aktarmayı anlatıyor.

SSS

Bir mühendislik organizasyon şeması her mühendisi göstermeli mi? Birkaç ekip için evet. Bundan büyük yapılarda ekipleri ve liderlerini gösterin, her ekibi kendi listesine bağlayın. Şema okunabilir kalır ve daha seyrek değişir.

Noktalı çizgiyle bağlı bir yöneticiyi nasıl gösteririm? İkinci yöneticiden kesikli bir çizgi çizin ve düz çizgiyi performans değerlendirmelerini yürüten yöneticiye ayırın. Archboard'da ikinci bir yöneticiden gelen bağlantı noktalı çizgiye dönüşür ve yerleşim ilk yöneticiye göre kalır.

Organizasyon şeması ile ekip topolojisi arasındaki fark nedir? Organizasyon şeması raporlama hatlarını gösterir. Ekip topolojisi ise ekip türlerini ve ekiplerin nasıl etkileşime girdiğini gösterir. İkisini de çizin ya da örnekteki gibi organizasyon şemasına etkileşimleri not edin.

Servis sahipliği nerede tutulmalı? Araçların ve insanların bulabileceği bir servis kataloğunda ya da CODEOWNERS dosyalarında. Organizasyon şeması bunu ekip düzeyinde yansıtır.

Bir mühendislik organizasyon şeması ne sıklıkla güncellenmeli? Her yeniden yapılanmada, her yeni ekipte ya da yeni serviste ve buna ek olarak, örneğin aylık, düzenli bir incelemede. Son inceleme tarihini şemanın üzerine yazın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.