Yazılım dünyasında proje yöneticilerinin ve üst yönetimin en sık düştüğü yanılgılardan biri, insan kaynağını bir fabrikadaki hammadde gibi görmektir. Bir inşaatta işçi sayısını iki katına çıkarmak, belirli sınırlara kadar (azalan verim kanunu) işi hızlandırabilir; ancak kod satırlarının ve mantıksal mimarilerin inşa edildiği yazılım projelerinde durum genellikle tam tersi bir seyir izler.
Fred Brooks’un 1975 yılında kaleme aldığı “The Mythical Man-Month” kitabında literatüre kazandırdığı Brook Kanunu, bugün her zamankinden daha geçerli bir operasyonel gerçekliği temsil ediyor: “Geciken bir yazılım projesine daha fazla insan kaynağı eklemek, o projeyi daha da geciktirir.” Bu prensip, bir verimlilik sınırı analizinden ziyade, karmaşık sistemlerdeki iletişim ve eğitim maliyetlerinin rasyonel bir hesaplaşmasıdır.
Brooks Kanunu’nun çalışma mantığı
Brooks’un bu kanunu ortaya koyarken dayandığı temel, çalışan/ay kavramının bir illüzyon olduğudur. Eğer bir iş 10 ay sürüyorsa, bu işe 10 kişi ekleyerek 1 ayda bitiremezsiniz. Bunun nedeni, yazılım geliştirmenin “bölünemez” ve “yüksek etkileşimli” doğasıdır.
Yazılımda verimlilik kaybı iki ana koldan sisteme saldırır.
Eğitim ve oryantasyon süreci
Yeni eklenen her yazılımcı, projenin mevcut kod yapısını, iş mantığını ve kullanılan araçları öğrenmek zorundadır. Bu öğrenme süreci boyunca yeni gelen personel sadece “sıfır verimlilikle” çalışmakla kalmaz, aynı zamanda projenin en verimli üyelerinin vaktini de alır.
Mevcut kıdemli geliştiriciler, kod yazmak yerine yeni gelene mentorluk yapmak zorunda kaldıkları için projenin toplam üretim kapasitesi geçici olarak negatife düşer.
İletişim kanallarının üstel artışı
Bir projeye dahil olan kişi sayısı lineer (doğrusal) olarak artarken, bu kişiler arasındaki iletişim kanallarının sayısı üstel olarak artar. $n$ kişi arasındaki iletişim kanalı sayısı n(n-1)/2 formülüyle hesaplanır.
- 3 kişi varken sadece 3 kanal mevcuttur.
- 10 kişi olduğunda kanal sayısı 45’e çıkar.
- 50 kişi olduğunda bu sayı 1225 olur.
Bu geometrik artış, toplantıların uzamasına, e-posta trafiğinin kaosa dönüşmesine ve her bir geliştiricinin “kimin neyi yaptığını” anlamak için harcadığı eforun, gerçek işe harcadığı eforu geçmesine neden olur.
Bölünemez görevler ve verimlilik sınırı
Ekonomideki azalan verim kanunu (law of diminishing returns), Brooks Kanunu’nda zirve noktasına ulaşır. Belirli bir noktadan sonra eklenen her yeni personel, sisteme sağladığı marjinal katkıdan daha fazla “koordinasyon yükü” getirir.
Yazılım süreçlerinde bazı görevler biyolojik süreçler gibi bölünemezdir. Brooks’un meşhur benzetmesiyle: “Dokuz kadın bir araya gelerek bir bebeği bir ayda doğuramaz.” Eğer bir kod parçasının mantıksal bütünlüğü tek bir zihnin odaklanmasını gerektiriyorsa, o işi ikiye bölmek hata payını artırır ve entegrasyon için harcanan zamanı, işin kendisinden daha uzun hale getirir.
Yazılım mimarisi ve “sürtünme” katsayısı
Brooks Kanunu’nun şiddeti, yazılımın mimari yapısıyla doğrudan ilişkilidir. Eğer sistem “monolitik” (tek parça ve sıkı bağlı) bir yapıdaysa, yeni gelen birinin sisteme dokunması her yerin sallanmasına neden olur ve iletişim ihtiyacı maksimuma çıkar.
Buna karşın, mikro-hizmet mimarileri veya modüler yapılar, bu kanunun etkilerini bir nebze hafifletir. Bağımsız ekiplerin birbirine minimum düzeyde dokunarak çalıştığı yapılar, iletişim yükünü stabilize eder. Ancak unutulmamalıdır ki; mimari ne kadar temiz olursa olsun, “geciken bir proje” her zaman kriz anındadır ve kriz anında yapılan panik atamalar, organizasyonel sürtünmeyi artırır.
Geciken projeler için çözüm önerileri
Brooks Kanunu, projeye asla insan eklenmemesi gerektiğini söylemez; sadece “gecikmiş bir projeyi kurtarmak için” son anda yapılan eklemelerin felaket getireceğini savunur. Rasyonel bir operasyon yöneticisi için stratejik adımlar şunlardır:
- Kapsamı daraltmak: Daha fazla çalışan eklemek yerine, projenin özelliklerini (features) azaltarak teslim tarihine sadık kalmak.
- Zamanı esnetmek: Teslim tarihini makul bir seviyeye çekerek mevcut ekibin fazla mesaiyle tükenmesini engellemek.
- Bilişsel yükü optimize etmek: Yeni personel eklenecekse, bu personeli “ana hat” üzerine değil, destekleyici veya bağımsız modüllere yönlendirmek.
