Akvaryumda Lüfer Avlanmaz ya da Conway Yasası
Melvin Conway’ in bir kuramını yazılım yönetim tekniklerinde sıkça kullanıyoruz.
“Sistemleri tasarlayan organizasyonlar … kendi iletişim yapılarının birer kopyasını üretmekle sınırlıdır”
Conway, Melvin E. (April 1968), “How do Committees Invent?”, Datamation ‘da orijinal makaleyi incelebilirsiniz.
Conway ‘in bu tespiti Conway Yasası olarak adlandırılıyor.
Yazılım geliştiren ekiplerin aralarındaki iletişim ve diğer iş birimleri ile iletişimin şekli doğrudan doğruya ortaya çıkan yazılım işleme şeklini belirliyor.
Bu konudaki klasik örnek bir derleyici geliştirilme işidir. Bir derleyiciyi bağımsız çalışan dört farklı ekip ile yaparsanız, ortaya çıkan derleyici dört pass’ lı olacaktır. Eric S. Raymond (October 1996). The New Hacker’s Dictionary – 3rd Edition. ISBN 978-0-262-68092-9.
Bir yazılımı FRONTEND ve BACKEND olarak ayırdığımızı düşünelim. Bu iki ekibin arasındaki iletişimin şekli yazılımın yapısınıda belirler.
Aynı şekilde yazılım ekipleri ile müşteri, ürün yöneticisi ya da şirket yönetiminin iletişimi doğrudan doğruya ürünün yapısına etki edecektir.
İşlevsel yazılım için ekipler arası iletişim açık olmalıdır. Yazılımın müşterinin ihtiyaçlarını karşılaması için müşteri ile iletişim açık olmalıdır.
Bir şirketin iletişimi o şirketin damarlarıdır. Her şirketin damarları vardır, sinir ağları vardır ve yaşamını bir şekilde sürdürür. Biz yazılım projelerimizde kullanacağımız yönetim teknikleri şirketimizin yapısı ile uygun olmalıdır. Uygun olmadığı zaman çıkacak sorunlar yıkıcı olacaktır.
Şirketin sinir ağları ile yazılım ekibinin sinir ağları arasında etkileşimi “aynalama” adı verilen bir yöntem ile analiz eden akademik çalışmalar vardır.
Alan MacCormak, Josh Rusnak, Carliss Baldwin (2011), “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis”, Working Paper, Harvard Business School, 08 -39 , http://www.hbs.edu/research/pdf/08-039.pdf