स्रोत: "कॉनवे का नियम"

प्रकाशन के 42 साल बाद लेखक का नोट:

शायद इस लेख में सबसे विशेष रूप से, यह अंत से तीसरे पैराग्राफ में वर्णित बयान के कारण प्रकाशित हुआ था। पिछले 45 पैराग्राफ पर काबू पाने की कठिनाई को कम करने के लिए, मैं इसे अब मुफ्त रूप में आवाज दूंगा:

कोई भी सिस्टम डिज़ाइन करने वाला संगठन (केवल एक सूचना प्रणाली से अधिक यहाँ व्याख्या की गई है) अनिवार्य रूप से एक मॉडल बनाएगा जो संगठन की संचार संरचना को दोहराएगा।

यह पता चला है कि यह सिद्धांत न केवल सॉफ्टवेयर विकास में मनाया जाता है, जिसके संदर्भ में इसे अक्सर संदर्भित किया जाता है।

मेरा सुझाव है कि आप खुद को सामग्री के साथ परिचित करें, और फिर आसपास देखें और अन्य क्षेत्रों में देखें।

वर्तमान में, मेरा पसंदीदा उदाहरण अमेरिका में गरीबी से संबंधित सामाजिक मुद्दों का जटिल है: श्रम बाजार, आवास, शिक्षा और स्वास्थ्य सेवा तक पहुंच। लेख को पढ़ने के बाद, विचार करें कि हमारी विभिन्न सरकारों की संरचनाएं ऐसे मुद्दों पर उनके दृष्टिकोण को कैसे प्रभावित करती हैं।

समितियाँ नई कैसे निर्मित करती हैं?

मेल्विन ई। कॉनवे
मूल पीडीएफ ।

बौद्धिक गतिविधि, जिसके परिणामस्वरूप एक पूरी तरह से असमान भागों से बनाई गई है, सिस्टम डिजाइन कहा जा सकता है। यह एक बड़े सैन्य परिसर की तैयारी, सामाजिक समस्याओं को हल करने के लिए सिफारिशें या कंप्यूटर कार्यक्रमों की एक सूची हो। एक डिजाइन संगठन का एक विशिष्ट लक्ष्य एक दस्तावेज तैयार करना है जिसमें जानकारी की सुसंगत संरचित मात्रा होती है। हम इस जानकारी को सिस्टम मॉडल कहते हैं। आमतौर पर, सर्जक एक ग्राहक होता है जो आगे की कार्रवाई प्रदान करने के लिए मॉडल का उपयोग करना चाहता है। उदाहरण के लिए, एक राजनेता हाल की आपदा की पुनरावृत्ति को रोकने के लिए एक विधेयक का प्रस्ताव करना चाहता है, इसके लिए वह आपदा के कारणों का पता लगाने के लिए एक टीम को काम पर रखता है। या निर्माता को एक नए उत्पाद की आवश्यकता होती है, और वह नए उत्पाद का निर्धारण करने और इसके रिलीज की योजना के लिए जिम्मेदार व्यक्तियों को नियुक्त करता है।

डिज़ाइन संगठन डिज़ाइन किए गए सिस्टम के कार्यान्वयन में शामिल हो भी सकता है और नहीं भी। अक्सर सरकारी प्रयासों में, ऐसे मानदंड होते हैं जो समूह को अपनी सिफारिशों के अनुसार कार्य करने से रोकते हैं, जबकि निजी क्षेत्र में रिवर्स स्थिति बनी रहती है। यह मान लेना उचित होगा कि यह स्थिति सिस्टम डिज़ाइन प्रक्रिया को प्रभावित करेगी, साथ ही अपने स्वयं के भविष्य के बारे में डेवलपर के अन्य विचारों के साथ। जैसा कि हम बाद में देखेंगे, पारंपरिक प्रबंधकीय वातावरण में मौजूद प्रोत्साहन ग्राहक के लक्ष्यों के विपरीत हो सकते हैं। [1]

डिजाइन चरणों

प्रारंभिक डिजाइन चरण प्रणाली के विकास की तुलना में स्वयं प्रक्रिया की संरचना से अधिक संबंधित है [2]। पूर्ण विकास कुछ प्रारंभिक क्रियाओं से पहले होता है, अर्थात्:

1. परियोजना गतिविधियों की सीमाओं और ग्राहक और मौजूदा वास्तविकताओं द्वारा स्थापित अंतिम परिणाम को परिभाषित करना।
2. विकास टीमों के संतुलित गठन के लक्ष्य के साथ प्रणाली की संरचना का प्रारंभिक मूल्यांकन।

भविष्य में, हम विस्तार से बताएंगे कि टीम की संगठनात्मक संरचना पहले से ही प्रत्यक्ष या अप्रत्यक्ष रूप से परियोजना के कार्यान्वयन को प्रभावित करती है। इसलिए, यहां तक ​​कि कर्मचारियों की खोज के लिए आदर्श स्थिति प्रदान करने में असमर्थता, टीम का गठन बिल्कुल निष्पक्ष रूप से नहीं किया जाएगा। और टीम के गठन के बाद, अध्ययन के दायरे को कम करते हुए, उपसमूहों को जिम्मेदारियां सौंपी जाएंगी, जो एक साथ सिस्टम को विकसित करने के लिए विकल्पों की संख्या को कम कर देगा।

आवंटित जिम्मेदारियाँ होने के बाद, प्रबंधकों को कार्य समूहों के स्तर पर समन्वय की समस्या का सामना करना पड़ता है, जो एक समान प्रणाली बनाने के लिए प्रत्येक समूह के प्रयासों के समेकन को नकारात्मक रूप से प्रभावित करता है। एक व्यक्ति की इस भूमिका में संभावित कमी के बावजूद।

सिस्टम डिज़ाइन प्रक्रिया में निम्न चरण होते हैं:

1. मूल नियमों के अनुसार सीमाओं को परिभाषित करना।
2. एक प्रारंभिक प्रणाली अवधारणा का विकास।
3. अवधारणा के अनुसार डिजाइन कार्य और कार्यों के प्रतिनिधिमंडल का संगठन।
4. प्रत्यायोजित कार्यों के स्तर पर समन्वय।
5. एक सिस्टम में सबसिस्टम का संयोजन।

एक एकल डिजाइन कार्य में, सभी चरणों का पता नहीं लगाया जा सकता है। ऐसा हो सकता है कि इस प्रक्रिया में एक नया, अधिक सही प्रोजेक्ट कॉन्सेप्ट मिलेगा। यह, ज़ाहिर है, एक बहुत ही अनुकूल क्षण नहीं है, क्योंकि बाद में काम की समाप्ति दर्दनाक और महंगी होगी। बेशक, इतिहासकार के दृष्टिकोण से, सब कुछ दोहराया जाता है।

इस मामले में, हमेशा सब कुछ सही करने के लिए पर्याप्त समय क्यों नहीं होता है, लेकिन किसी चीज़ को फिर से बनाने के लिए हमेशा पर्याप्त समय होता है?

सिस्टम डिजाइन

किसी भी सीरियल सिस्टम में इंटरकनेक्टेड सबसिस्टम होते हैं। प्रणाली की आंतरिक संरचना का वर्णन बाहरी वातावरण और उसके उप-प्रणालियों के संबंध के साथ अपने संबंधों को प्रतिबिंबित करना चाहिए। निचले स्तर पर जाने पर, हम सबसिस्टम के बारे में एक ही बात कह सकते हैं, इसे एक प्रणाली के रूप में देखते हुए। और इतने पर, ऐसे उपतंत्र के नीचे, जो बेहद सरल और अविभाज्य होगा।

उदाहरण

राज्य ट्रांसकॉन्टिनेंटल ट्रांसपोर्ट सिस्टम में बस, ट्रेन, हवाई जहाज, टैक्सी, पार्किंग स्थल, टर्मिनल आदि शामिल हैं। यह एक बहुत ही विषम प्रणाली है, जिसका अर्थ है कि इसके उपतंत्र काफी विविध हैं। उदाहरण के लिए, निचले स्तर पर जाने पर, हम इसके सबसिस्टम देखेंगे: फ्रेम, इंजन, बिजली वितरण, संचार, पेलोड। इंजन प्रणाली में ईंधन, इग्निशन आदि जैसे सबसिस्टम शामिल हैं।

इतना स्पष्ट नहीं है, लेकिन सिद्धांत भी एक प्रणाली है। यह बाहरी वातावरण को संदर्भित घटनाओं को संदर्भित करता है, जिसे उन्हें समझाना चाहिए या कम से कम उनका विरोध नहीं करना चाहिए। इसमें ऐसे भाग-सिद्धांत होते हैं जो एक-दूसरे से समान तरीके से संबंधित होते हैं। उदाहरण के लिए, क्रैश जांच के दौरान, एक सिद्धांत बनाया गया था जो दुर्घटना के दौरान विमान के प्रक्षेपवक्र, उसके संचार, क्षति और अन्य वस्तुओं के साथ बातचीत का वर्णन करता है। इनमें से प्रत्येक आइटम अपने आप में एक अलग कहानी है और इसे सूचनाओं की अलग-अलग इकाइयों तक उप-मदों में भी विभाजित किया जा सकता है।

योजनाओं

अंजीर में। 1, प्रणाली को एक रेखाचित्र के रूप में चित्रित किया गया है - एक खड़खड़ के समान - लाइनों के रूप में कनेक्शन (शाखाओं) और हलकों के रूप में मुख्य नोड्स (नोड्स) के साथ। प्रत्येक नोड एक सबसिस्टम का प्रतीक है जो अन्य सबसिस्टम के साथ संचार करता है, जिसे एक समान तरीके से दर्शाया जा सकता है। टर्म इंटरफेस, जो डेवलपर्स के बीच लोकप्रियता हासिल कर रहा है, उप-पंक्तियों की बातचीत को संदर्भित करता है, लाइनों द्वारा इंगित किया गया है।



ग्राफिक छवि स्पष्ट रूप से दो अवधारणाओं के समान रूप को प्रदर्शित करती है जिन्हें हम विचार कर रहे हैं: सिस्टम और संगठन जो इसे डिजाइन करते हैं। बदलने का प्रयास करें:

1. "सिस्टम" से "समिति"
2. "उपसमिति" के लिए "सबसिस्टम"
3. "इंटरफ़ेस" से "समन्वयक"

जैसा कि सिस्टम के मामले में, हम देखते हैं कि डिजाइन संगठनों को जटिलता के कई स्तरों को ध्यान में रखा जा सकता है। संघीय सरकार एक जटिलता के स्तर के साथ एक डिजाइन संगठन का एक बड़ा उदाहरण है जो किसी भी इंजीनियर को संतुष्ट कर सकती है। यह एक विशेष रूप से दिलचस्प उदाहरण है, हम जिन दो अवधारणाओं पर विचार कर रहे हैं, उनकी समानता को दर्शाते हैं, क्योंकि संघीय सरकार दोनों एक डिजाइन संगठन (कानून, संधियों, नीतियों को विकसित करता है) और एक डिजाइन संगठन (प्राथमिक डिजाइन दस्तावेज के रूप में संविधान के साथ) है।

प्राथमिक बातचीत

अब हम इस लेख के मुख्य मुद्दे के लिए तैयार हैं। क्या डिजाइन संगठन की संरचना और इसे डिजाइन करने वाले सिस्टम के बीच एक अनुमानित संबंध है? सही उत्तर हाँ है, और यह कनेक्शन इतना सरल है कि यह अक्सर स्थिर होता है। निम्नलिखित "सबूत" पर विचार करें।

मनमाने ढंग से सिस्टम और उस संगठन को चुनें जो इसे विकसित करता है और बेतरतीब ढंग से डिजाइन किए गए सिस्टम की जटिलता के स्तर का चयन करता है, इसे स्केच करें (हमारी पसंद मनमानी है, क्योंकि यदि हम दिलचस्प रिश्तों का पालन करते हैं, तो हम उन्हें किसी भी डिजाइन संगठन और जटिलता के स्तर तक बढ़ा सकते हैं)। अंजीर में। चित्र 2 दिखाता है (स्पष्टता के लिए) एक संरचना जिसके लिए नीचे दिया गया कथन सत्य है।



सिस्टम में किसी भी नोड एक्स के लिए, हम डिजाइन संगठन के कार्य समूह की पहचान कर सकते हैं जिसने इसे विकसित किया है (एक्स द्वारा इसे निरूपित करें)। इस तरह से

इस प्रक्रिया को संक्षेप में, सिस्टम में किसी भी नोड के लिए हमारे पास उचित कार्य समूह खोजने के लिए एक नियम है। कृपया ध्यान दें कि अनुपात 1: 1, अर्थात दो उप-प्रणालियों को एक ही डिज़ाइन संगठन द्वारा डिज़ाइन किया जा सकता है।

दिलचस्प है, हम शाखाओं के संबंध में एक समान बयान दे सकते हैं। एक ही सिस्टम, x और y के किसी भी दो नोड लें। वे कनेक्ट हो सकते हैं या नहीं भी हो सकते हैं (यानी, या तो वे एक-दूसरे के साथ बातचीत करते हैं या सिस्टम के कामकाज के लिए महत्वपूर्ण हैं या नहीं)। यदि उनके बीच एक संबंध है, तो दो काम करने वाले समूह एक्स और यू, जिन्होंने दो डेटा नोड विकसित किए हैं, को नोड्स के बीच संचार की संभावना का एहसास करने के लिए इंटरफ़ेस की सुविधाओं पर सहमत होना पड़ा। यदि x और y के बीच कोई संबंध नहीं है, तो सबसिस्टम एक-दूसरे के साथ संवाद नहीं करते हैं, जिसका अर्थ है कि कार्य समूह एक-दूसरे के साथ बातचीत नहीं करते थे (क्योंकि एक्स और वाई के बीच कोई संबंध नहीं है)। [3]

हमने अभी क्या दिखाया है? सरल शब्दों में, हमने प्रदर्शित किया है कि प्रणाली की संरचना और संगठन की संरचना के बीच घनिष्ठ संबंध है जो इसके डिजाइन में शामिल है। जब प्रत्येक सबसिस्टम का अपना अलग कार्य समूह होता है, तो हम यह देख सकते हैं कि वर्किंग ग्रुप और सबसिस्टम की संरचनाएँ (योजनाएँ) समान हैं। मामले में जब कई कार्य समूह एक सबसिस्टम विकसित करते हैं, तो डिजाइन संगठन संरचना एक सिस्टम संरचना की तरह दिखती है, लेकिन कम सबसिस्टम (आरेख में नोड्स) के साथ।

दो वस्तुओं के बीच समान संरचना-संरक्षण संबंध को एक समरूपता कहा जाता है। गणितीय भाषा में, सिस्टम आरेख और आरेख को प्रस्तुत करने वाले संगठन के बीच एक समरूपता है।

प्रणाली संगठन का एक प्रतिबिंब है जो इसे डिजाइन करता है

कई अनुभवी सिस्टम डिजाइनरों का मानना ​​है कि कोई भी किसी भी सिस्टम डिज़ाइन को कभी भी बेहतर कर सकता है। दूसरे शब्दों में, जगह, समय, ज्ञान के स्तर और प्रौद्योगिकी के संदर्भ में छोड़कर डिजाइन कार्य के बारे में बात करना गलत और गलत है। यह उन लोगों द्वारा याद किया जाना चाहिए जो किसी वस्तु को डिजाइन करने या उनके काम को याद रखने और उनका विश्लेषण करने के काम की कहानी पढ़ते हैं।

प्रोग्रामिंग भाषाओं जैसे फोरट्रान और कोबोल के कंप्यूटर अनुवादकों का विकास एक उत्कृष्ट उदाहरण है। 1950 के दशक के मध्य में, जब इन भाषाओं के प्रोटोटाइप दिखाई दिए, तो उनके कंपाइलर कंप्यूटर की तुलना में अधिक बोझिल थे, उन दिनों में विशाल थे जो कि कमांड निष्पादित करने वाले थे। आज, ये अनुवादक केवल ऐतिहासिक चमत्कार हैं जिनमें आधुनिक संकलक के साथ कुछ भी सामान्य नहीं है। (यह ध्यान देने योग्य है कि कंपाइलरों के विकास में एक बड़ी सफलता कंप्यूटर निर्माताओं के क्षेत्र में पहले से मौजूद लोगों के नए समूहों के उद्भव से जुड़ी थी - यह पहले शोधकर्ताओं का एक छोटा सा एकजुट विश्वविद्यालय समूह था, जिसके बाद स्वतंत्र सॉफ्टवेयर डेवलपर्स थे)।

अगर हम मानते हैं कि किसी भी सिस्टम की आवश्यकता के लिए कई सिस्टम प्रोजेक्ट हैं जो इस आवश्यकता को पूरा करेंगे, तो हमें यह भी पूछना चाहिए कि क्या डिजाइन संगठन का विकल्प इस श्रृंखला से सिस्टम प्रोजेक्ट चुनने की प्रक्रिया को प्रभावित करता है। यदि हम अपनी समरूपता पर विश्वास करते हैं, तो हम किन प्रभावों से सहमत होंगे। यह देखते हुए कि संगठन के पास एक लचीली संचार संरचना नहीं है, यह संगठन किसी भी परियोजना उत्पाद में खुद की एक प्रति पर मुहर लगाएगा। संगठन जितना बड़ा होगा, यह उतना ही कम लचीला होगा और यह संपत्ति अधिक प्रकट होगी।

उदाहरण

एक शोध संगठन में, आठ लोग थे जो कोबोल और ALGOL कंपाइलर बनाने वाले थे। जटिलता और संभावित समय सीमा के प्रारंभिक मूल्यांकन के बाद, उनमें से पांच को कोबोल के साथ काम करने के लिए निर्धारित किया गया था, और तीन को ALGOL के साथ काम करने के लिए सौंपा गया था। नतीजतन, COBOL कंपाइलर ने पांच पास और ALGOL कंपाइलर ने तीन पास में काम किया।

उनके कमांडरों-इन-चीफ के नेतृत्व में दो सैन्य सेवाओं ने अपनी आवश्यकताओं के लिए एक हथियार प्रणाली विकसित की है। उसके बाद, बिना प्रयास के, उन्होंने अपनी संगठनात्मक संरचना की एक प्रति बनाई (देखें चित्र 3 ए)



इस कार्य में शामिल कंप्यूटर ऑपरेटिंग सिस्टम पर ध्यान दें। इसका विस्तार से अध्ययन करने के बाद, हम देखते हैं कि इसमें तीन भाग होते हैं: हार्डवेयर, सॉफ्टवेयर और अनुप्रयोग (चित्र 3 बी देखें)। उनके डेवलपर्स इन सबसिस्टमों के अनुरूप हैं: कंप्यूटर निर्माता, उनके सिस्टम प्रोग्रामर और कस्टम एप्लिकेशन के डेवलपर्स (जो दुर्लभ मामला है जब हार्डवेयर और सॉफ़्टवेयर विशेषज्ञ सहयोग करते हैं, और न केवल कठिनाई के साथ एक दूसरे को सहते हैं)।

सिस्टम प्रबंधन

बड़े सिस्टम की संरचना विकसित होते ही सड़ने लगती है। पिछले दस वर्षों की बड़ी सैन्य सूचना प्रणालियों पर विचार करते समय यह अवलोकन विशेष रूप से स्पष्ट है। वे मनुष्य द्वारा बनाई गई पहले की सबसे जटिल वस्तुएं हैं। "प्रणाली प्रबंधन" नामक एक गतिविधि उत्पन्न हुई है, जिसमें सिस्टम की उनके घटक तत्वों में अलग होने की प्रवृत्ति के कारण शामिल है। आइए इस लेख के मुख्य विचार के संदर्भ में सिस्टम प्रबंधन की व्यावहारिकता को देखें।

बड़े सिस्टम क्यों टूट जाते हैं? यह प्रक्रिया तीन चरणों से गुज़रती है, जिनमें से पहले दो नियंत्रणीय हैं, और तीसरी अवस्था हमारे समरूपता का प्रत्यक्ष परिणाम है।

1. सबसे पहले, डेवलपर्स, अनुमानित प्रणाली के आकार का एहसास करते हुए, इसे बनाने के लिए अधिक से अधिक लोगों को नियुक्त करने के प्रलोभन का विरोध नहीं कर सकते।
2. दूसरे, इतने बड़े पैमाने पर परियोजना के कार्यान्वयन के लिए सामान्य प्रबंधकीय मॉडल को लागू करते समय, इसकी संचार संरचना अलग-अलग हिस्सों में टूट जाती है।
3. तीसरा, संगठन-डिजाइनर की संरचना में होने वाली विघटन प्रक्रियाएं सिस्टम की संरचना में होती हैं, जो कि होमोमोर्फिज्म की घटना के अनुसार होती है।

शुरू करने के लिए, "ओवरपॉपुलेशन" के साथ स्थिति पर विचार करें। जब सिस्टम की जटिलता का स्तर उसकी समझ की सीमाओं के करीब पहुंचता है, तो कार्यों को सौंपने की डेवलपर की स्वाभाविक इच्छा काफी समझ में आती है। यह विकास की प्रक्रिया में एक महत्वपूर्ण मोड़ है। या तो वह प्रणाली को सरल बनाने के लिए लड़ता है और जीतता है, या वह इस पर नियंत्रण खो देता है। समय सीमा और बजट के दबाव को देखते हुए परिणाम लगभग अनुमानित है।

यदि समय सीमा खो जाती है, तो प्रबंधक को दोष देना होगा यदि उसने इसे रोकने के लिए सभी संसाधनों का उपयोग नहीं किया है। इसलिए, वह डेवलपर को प्रभावित करने की कोशिश करेगा, जो, शायद, सिस्टम की जटिलता से निपटना पसंद करेगा, न कि दूसरों को कार्य सौंपना। नतीजतन, शामिल संसाधनों की संख्या में वृद्धि होगी।

या एक अन्य उदाहरण, प्रबंधक के संघर्ष के एक समान मामले और डिजाइन प्रणाली की अखंडता का प्रदर्शन। कार्यान्वयन के लिए प्रबंधक को कार्य का महत्वपूर्ण और जटिल हिस्सा देना होगा। वह दो कलाकारों में से एक को चुन सकता है: एक नई छोटी कंपनी, जो एक रचनात्मक दृष्टिकोण और कम वेतन, या एक प्रतिष्ठित कार्यालय द्वारा प्रतिष्ठित है, जिसने खुद को स्थापित किया है, जिसमें अधिक "यथार्थवादी" कीमतें हैं। वह जानता है कि यदि एक उज्ज्वल युवा कंपनी कार्य के साथ सामना नहीं करती है, तो वह परियोजना को बाधित करने का दोषी होगा। यदि एक प्रसिद्ध संगठन विफल हो जाता है, तो यह केवल संकेत देगा कि कार्य वास्तव में मुश्किल है।

यहाँ क्या पकड़ है? मूल रूप से, संसाधनों के मूल्यांकन और आवंटन की विधि में, जो पारंपरिक रूप से उपयोग किया जाता है। तो, संसाधन की इकाई डॉलर है, इसलिए सभी संसाधन डॉलर के संदर्भ में व्यक्त किए जाते हैं। यदि संसाधन मानव श्रम है, तो माप की इकाई श्रमिकों की संख्या से गुणा एक घंटे के काम की लागत होगी।

इस दृष्टिकोण की गिरावट यह है कि वर्ष के दौरान दो लोगों के काम का मूल्यांकन उसी तरह किया जाता है जैसे कि सप्ताह के दौरान सैकड़ों लोगों के काम का। लेकिन चूंकि दो और सौ के काम की संगठनात्मक संरचना अलग-अलग होगी, इसलिए होमोमोर्फिज्म को देखते हुए, यह तर्क दिया जा सकता है कि वे अलग-अलग सिस्टम बनाएंगे, इसलिए आपको उनके काम की लागत की तुलना नहीं करनी चाहिए। अनुभव से, हम जानते हैं कि दो सही ढंग से चयनित लोग, यदि वे सामना करते हैं, तो सबसे अच्छा परिणाम दिखाएगा। आलू को छीलने या ईंट बिछाने के लिए मान्यताओं को सिस्टम डिज़ाइन में गलत माना जाता है।

परियोजना की गतिविधियों में श्रम संसाधनों के पुनर्वितरण में पार्किंसंस कानून [4] का बहुत महत्व है। जब तक प्रबंधक की प्रतिष्ठा बजट के आकार पर निर्भर करती है, तब तक वह अपने संगठन के विस्तार में रुचि रखेगा। यह सिस्टम की विकास समस्याओं को हल करने के लिए एक उपयुक्त प्रेरणा नहीं है। एक बार एक संगठन मौजूद है, तो निश्चित रूप से इसका इस्तेमाल किया जाएगा। शायद इतने खराब डिज़ाइन वाले सिस्टम के अस्तित्व का सबसे सम्मोहक कारण आज काम की तलाश में डिज़ाइन संगठनों की मौजूदगी है।

दूसरे स्थान पर, सिस्टम डिज़ाइन प्रक्रिया के पतन का कारण - डिज़ाइन संगठन के संचार संरचना का विखंडन - कार्यों के प्रतिनिधिमंडल की शुरुआत के साथ ही प्रकट होना शुरू होता है। प्राथमिक संभाव्यता के सिद्धांत के अनुसार, संभावित संचार की संख्या संगठन के कर्मचारियों की संख्या के आधे वर्ग के बराबर है। , . .

. , . . , .

निष्कर्ष

— , ( ) , . , . : , , . , . , , , , , - , .

, . , , . . .

[1] . « » (John Kenneth Galbraith's The New Industrial State). VI, «».

[2] C. « » (.J. Middleton, «How to Set Up a Project Organization,» 1967, . 73).

[3] . , . , , .

[4] .. « » (C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration, 1957)

:

अधिक

• «How do Committees Invent?»
• Exploring the Duality between Product and Organizational Architectures: A Test of the «Mirroring» Hypothesis
• Does Conway's Law apply to Linux?
• Conway's Law [Framework of the Day]
• One-on-one with Mel Conway and Mike Amundsen

«»

«Augmenting Human Intellect:
A Conceptual Framework» , .

«» — « », «» , , () .

— ( , ! , .) — , , , , , , , , WikiPedia, Web Archive, Knol, Quora, Cybersyn, Xanadu, DARPA, IARPA.

— 50 . सभी डेमो की माँ

यदि आप वास्तव में एनएलएस को समझना चाहते हैं, तो आपको आज की वास्तविकता को भूल जाना चाहिए। कंप्यूटर के बारे में जो कुछ भी आप जानते हैं उसे भूल जाइए। कल्पना कीजिए कि आप अभी भी नहीं जानते कि कंप्यूटर क्या है। 1962 पर लौटें। और फिर उसके मन में जो है, उसे पढ़ें ।
- ब्रेट विक्टर, डगलस एंजेलबर्ट के बारे में कुछ शब्द