Kuruluş ve takım yapısını nasıl tasarlarsınız?

Question

Accepted Answer

Kuruluş tasarımı, **birlikte değişen işlerin birlikte yaşaması için takım sınırlarını çizme** hakkındadır — hızlı hareket eden şeyler için takımlar arasındaki bağımlılıkları en aza indirmek. Yapı strateji ve sistemi takip etmeli, tersi değil.

## İlkeler

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Akış odaklı düşünme

Bir iş akışına sahip olan, uzun ömürlü akış yönelimli takımları tercih edin ve diğerlerinin bilişsel yükünü azaltan platform takımları tarafından desteklenen takımları tercih edin. Yapı işle savaşmaya başladığında yeniden düzenleyin — bir kaprice göre değil.

## Tuzaklar

- **İşlevsel silos** (bir "QA takımı," bir "frontend takımı") her özelliği birçok el değiştirmesine zorlar.
- **Conway Yasasını görmezden gelmek** ve mimarinin kuruluş şemasini yansıttığına şaşırmak.
- **Sürekli olarak yeniden düzenlemek**, bu da her seferinde güveni ve mülkiyeti sıfırlar.
- **Bulanık mülkiyet**, her şeyin "paylaşıldığı" ve bu nedenle kimse tarafından sahip olmadığı.

## Neden önemli

Yapı sessizce hızı belirler.

Kötü sınırlar sonsuz koordinasyon toplantıları ve bulanık sorumluluk yaratır; iyi olanlar takımların bağımsız olarak hareket etmesine izin verir.

Conway Yasası nedeniyle kuruluş tasarımı *aynı zamanda* mimari tasarımdır.

Takım sınırlarını yanlış alırsanız, hiçbir mühendislik kahramanlığı sistemi temiz yapmayacaktır.