Ana sayfa → Ekip Yönetimi
Ekip Büyürken: 5 Kişi ile 15 Kişi Aynı İş Değil
Ekip büyüdükçe iş hızlanmıyor, toplantılar uzuyor. Kimse tembelleşmedi, kimse beceriksizleşmedi — sadece aynı yöntemle üç katı insanı çalıştırmaya çalışıyorsun. Beş kişide işe yarayan her şey on beş kişide bozuluyor.
- Sorun kişi sayısı değil, ikili ilişki sayısı. 5 kişide 10 yol, 15 kişide 105.
- Bölme kararı bir mimari karardır. Conway: sistem, ekiplerin sınırlarına oturur.
- Bölmeyi kişilere göre değil, işe göre yap. “Kim kiminle iyi anlaşıyor” kötü bir ölçüt.
- Erken bölmek de pahalı. İki ekip, iki nöbet, iki backlog demek.
Katlanarak artan tek şey: iletişim
Ekip iki katına çıkınca iş de iki katına çıkmıyor; çünkü büyüyen tek şey kişi sayısı değil, kimin kimle konuşması gerektiği:
| Kişi | İkili iletişim yolu | Pratikte |
|---|---|---|
| 5 | 10 | Herkes her şeyi biliyor, ayakta toplantı 8 dakika |
| 8 | 28 | Bilgi hâlâ akıyor ama tekrarlanması gerekiyor |
| 12 | 66 | Toplantıda insanlar telefona bakıyor |
| 15 | 105 | “Bunu bilmiyordum” günlük cümle oluyor |
Bizim ekipte bunun en somut ölçüsü ayakta toplantı süresi oldu: yedi kişiyken 8-9 dakikaydı, on üç kişide 25 dakikaya çıktı. Süre uzarken faydası azaldı — çünkü artık herkesi ilgilendiren madde oranı düşmüştü. On üç kişilik toplantıda kendi işini ilgilendiren üç cümleyi duymak için 22 dakika bekliyordun.
Bölme zamanının işaretleri
“Sekiz kişiyi geçince böl” gibi bir kural sanıldığı kadar işe yaramıyor; çünkü asıl belirleyici olan iş, kişi sayısı değil. Bakılacak işaretler şunlar:
- Ayakta toplantıda insanlar dinlemiyor. En erken ve en dürüst sinyal.
- Backlog’ta iki ayrı hikâye var. Sıralamayı yaparken elmayla armut karşılaştırıyorsan iki ürün konuşuyorsun demektir.
- Kod tabanında doğal bir sınır oluşmuş. İki alan var ve kimse ikisine birden dokunmuyor.
- Planlamada “bu bizi ilgilendirmiyor” sıklaşmış.
- Yönetici darboğaz olmuş. Bire birler haftaya sığmıyorsa ekip zaten fiilen büyümüş.
Buna karşılık erken bölmenin de bedeli var ve genelde hafife alınıyor: iki nöbet sırası, iki backlog, iki planlama toplantısı ve aralarında yeni bir koordinasyon yükü. Beş kişilik iki ekip, on kişilik bir ekipten her zaman daha hızlı değil.
Nereden bölmeli: Conway’i ciddiye almak
Conway yasası kısaca şunu söylüyor: sistemler, onları üreten organizasyonun iletişim yapısını taklit eder. Yani ekipleri nasıl bölersen mimari zamanla o sınırlara oturur. Bu, bölme kararını bir insan kaynağı kararı olmaktan çıkarıp mimari karar yapıyor.
- “Kim kiminle iyi anlaşıyor”
- Teknolojiye göre: frontend ekibi / backend ekibi
- Kıdeme göre: kıdemliler bir ekip
- Rastgele ikiye ayırıp sonra bakmak
Hepsinin ortak sonucu: her iş iki ekibi birden gerektiriyor.
Bir ekip, bir işi baştan sona tek başına bitirebilmeli: fikirden canlıya. Sınırı buna göre çiz — ürün akışı, müşteri yolculuğu ya da veri sahipliği.
Test şu: gelecek çeyreğin ilk beş işini yaz. Kaçı tek ekibin içinde bitiyor? Üçten azsa sınır yanlış yerde.
Teknolojiye göre bölme özellikle sinsi: kâğıt üstünde çok düzenli görünüyor, sonra her küçük özellik iki ekibin sprint’ini senkronize etmeyi gerektiriyor ve bekleme süresi işin kendisinden uzun sürüyor.
Bölerken kaybedilen şeyi geri koymak
Böldüğün an bir şey kaybediyorsun: ortak bağlam. Kimse artık her şeyi bilmiyor. Bunu kabul edip yerine ucuz bağlantılar koymak gerekiyor:
- Ortak demo. İki ekip iki haftada bir birbirine gösterir; 30 dakika, hazırlıksız.
- Yazılı karar kaydı. Mimari kararlar tek bir yerde, kısa. Böldüğün an bu şart oluyor.
- Geçici konukluk. Bir kişi bir sprint diğer ekipte çalışır; en hızlı bilgi taşıma yolu.
- Ortak nöbet, ayrı sprint. Sistem hâlâ tek; nöbeti tamamen ayırmak “o bizim servisimiz değil”a giden yol.
Bir de bölmenin yönetici tarafı var: iki ekip iki lider ister. İçeriden lider çıkarmıyorsan bölme kararı yarım kalır — ve bu, yeni bir yöneticinin geçiş dönemi demektir; bölmeyi planlarken hesaba katılmalı.
Kontrol listesi
- Ayakta toplantı kaç dakika? Kaç kişi dinliyor?
- Gelecek çeyreğin ilk beş işi tek ekibin içinde biter mi?
- Backlog’ta kaç ayrı ürün konusu var?
- Kod tabanında doğal bir sınır var mı, yoksa sınırı ben mi uyduruyorum?
- İkinci ekibin lideri kim? Hazır mı?
- Bölünce hangi bilgi kaybolacak, yerine ne koyacağım?
- Altı ay sonra bu sınır yanlış çıkarsa geri almanın maliyeti ne?
Sonuç
Ekip büyütmek kadro eklemek değil, ortak bağlamı yeniden kurmak. Beş kişilik ekipte bağlam kendiliğinden oluşuyordu; on beş kişide onu kasıtlı olarak inşa etmen gerekiyor: sınırlar, yazılı kararlar, ortak demolar.
Ve en iyi bölme, kimsenin başkasını beklemediği bölmedir. O sağlanmadıysa iki ekip kurmuş olmazsın; bir ekibi ikiye bölmüş, aralarına da bir bekleme sırası koymuş olursun.