در سال ۱۹۶۷ مجله کسب‌وکار هاروارد (Harvard Business Review) مقاله‌ای را که توسط ملوین کانوی (Melvin Conway) ارائه شده بود، رد کرد. یک سال بعد مفهومی که او در پایان‌نامه‌اش ارائه کرده بود، به قانون کانوی (Conway’s Law) معروف شد. او در پروژه‌های تولید نرم‌افزار مختلفی شرکت کرده بود و متوجه یک پدیده شده بود: محصولات نرم‌افزاری که توسط تیم‌ها در یک سازمان تولید می‌شوند، منعکس‌کننده ساختار سازمانی آن هستند.
قانون کانوی بیان می‌کند: “سازمان‌هایی که سیستم‌ها را طراحی می‌کنند، محصولاتشان توسط ساختار ارتباطی داخلی سازمان‌ها محدود می‌شود.”
منطق قانون کانوی این است که اگر یک نرم‌افزار بخواهد توسط تیمی از افراد مختلف طراحی و تولید بشود، این افراد باید دائماً با یکدیگر در ارتباط باشند و ساختار سازمانی، روش‌های حل مسئله و الگوهای ارتباطی بین افراد فضای یافتن راه‌حل‌های جدید و نوآورانه را محدود می‌کند. به‌بیان‌دیگر ساختار و فضای کاربری نرم‌افزار منعکس‌کننده مرزها و محدودیت روابط اجتماعی بین افرادی است که آن را تولید می‌کنند. با توجه به اینکه معماری نرم‌افزار پیش‌بینی کننده مهمی برای عملکرد و انعطاف‌پذیری محصول و همچنین سیر تحولات بعدی محصول و حتی صنعت است، این روابط بسیار مهم می‌شوند.
مطالعات محققان شواهدی قوی در مورد صحیح بودن آن به دست داده است. برای مثال، در یک مطالعه ساختار سازمانی شرکت‌های تولیدکننده نرم‌افزارهای تجاری و ساختار جوامع تولیدکننده نرم‌افزارهای متن‌باز (Open Source Software) مورد بررسی قرار گرفت. در سازمان‌های تولیدکننده نرم‌افزارهای تجاری افراد به‌شدت به اهداف، رویه‌ها و ساختار سازمانی متعهد هستند درحالی‌که در جوامع متن‌باز این تعهد بسیار کمتر است. این تفاوت در ساختارهای سازمان‌دهی تفاوت کاملاً آشکاری بر معماری نرم‌افزارهای تولیدشده گذاشته است. به‌طور مشخص در نرم‌افزارهای تولیدشده در جوامع متن‌باز طراحی‌های پیمانه‌ای (Modular) بسیار بیشتر از سازمان‌های تجاری دیده می‌شود.
در طول زمان نسخه‌های دیگری نیز از این قانون بیان شد. برای مثال اینکه محتوا و ساختار وب‌سایت‌های سازمان‌ها بیشتر بر اساس دغدغه‌های بخش‌های مختلف سازمان طراحی می‌شوند تا نیازهای مشتریان و یا اینکه ساختار مشکلات بیشتر منعکس‌کننده ساختار سازمانی است که آن را ایجاد کرده است.
قانون کانوی به ما اطلاعات بیشتری در مورد اینکه آیا ساختار سازمان برای توسعه یک محصول مناسب است یا خیر نمی‌دهد، تنها یادآوری می‌کند که این سؤال را از خود بپرسیم آیا ساختار گروه‌ها و سازمان ما برای تولید محصولی که بتواند نیاز مشتری را برآورده کند، متناسب است یا خیر. مدیران توسعه محصول باید متوجه اثرات نحوه سازمان‌دهی گروهشان بر روی گزینه‌های طراحی باشند چراکه همان‌طور که گفته شد رویه‌های حل مسئله، نحوه انتقال و تحلیل اطلاعات در تعیین فضای جستجوی راه‌حل‌ها بسیار مؤثر است.
منابع:
Conway, M. E. (1968), “How Do Committees Invent?” Datamation Magazine, April
MacCormack, A., Rusnak, J., & Baldwin, C. (2011). “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis” Harvard Business School Technology & Operations Mgt. Unit Research Paper 08-039: 08-039
تنها متن فارسی این قانون که پیدا کردم که به شدت تحلیل اون به صورت دقیق مورد نیاز شرکت های نرم افزاری هست.
با اینکه جا داره جزییات بیشتری ارائه بشه ولی بهرحال عالی بود