सिस्टम में सोच

सिस्टम्स में सोच ने मुझे कई साल पहले सिस्टम्स थिंकिंग से परिचित कराया , जिसने दुनिया को देखने के मेरे तरीके को बदल दिया और समस्या समाधान पर मेरे कुछ दृष्टिकोणों को आकार दिया। प्रोग्रामिंग या वितरित सिस्टम संदर्भों में सॉफ़्टवेयर इंजीनियरों से परिचित संज्ञा के रूप में यह मानसिकता "सिस्टम" के सामान्य उपयोग से परे है।

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

सिस्टम से :

कैसे पता करें कि आप एक प्रणाली को देख रहे हैं या सिर्फ सामान का एक गुच्छा:

ए) क्या आप भागों की पहचान कर सकते हैं?

बी) क्या हिस्से एक दूसरे को प्रभावित करते हैं?

सी) क्या भाग एक साथ एक प्रभाव उत्पन्न करते हैं जो प्रत्येक भाग के प्रभाव से अलग होता है?

डी) क्या प्रभाव, समय के साथ व्यवहार, विभिन्न परिस्थितियों में बना रहता है?

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

उदाहरण के लिए, अक्सर ऐसा होता है कि इंजीनियरों को "खराब कोड" का सामना करना पड़ता है, और जल्दबाजी में निष्कर्ष निकालते हैं कि खराब कोड "खराब इंजीनियर" द्वारा निर्मित किया गया था। हालाँकि, एक प्रणाली विचारक आगे की जाँच कर सकता है:

खराब कोड क्यों किया गया? (उत्पादक टीम पर जल्दी भेजने का दबाव था)

टीम ने टाइमलाइन पर पीछे धकेलने और मानकों को बनाए रखने के बजाय कोनों में कटौती करने का फैसला क्यों किया? (टीम ने अपने सभी वरिष्ठ इंजीनियरों को खो दिया)

टीम ने अपने सभी वरिष्ठ या अनुभवी प्रतिभाओं को क्यों खो दिया? (उन्हें विश्वास की कमी महसूस हुई क्योंकि अतीत में पीछे धकेलने के उनके प्रयासों को खारिज कर दिया गया था)

संगठन ने अपने वरिष्ठ इंजीनियरों की बात क्यों नहीं मानी या उन पर भरोसा क्यों नहीं किया? (संगठन के प्रभारी निदेशक कई तिमाहियों से प्रतिबद्धताओं को पूरा करने में विफल रहे हैं)

संगठन देने में विफल क्यों है? (बहुत अधिक तकनीकी ऋण और "खराब कोड" टीमों के लिए कोडबेस में पुनरावृति करना कठिन बना देता है)

और इसी तरह। ये प्रश्न आश्चर्यजनक उत्तर दे सकते हैं, जैसे " अनुभवी इंजीनियरिंग निदेशकों के लिए संगठन का दायरा अनाकर्षक है "।

कुछ पाठक इस विचार प्रक्रिया की तुलना 5 Whys जांच तकनीक से करेंगे, जिसका उपयोग अक्सर घटना के मूल कारण विश्लेषण के लिए किया जाता है । आरसीए सिस्टम थिंकिंग का एक व्यावहारिक अनुप्रयोग है जो सिस्टम में गड़बड़ी के एकमात्र कारण को उजागर करने की कोशिश करता है। दोबारा, किताब से:

मुझे लगता है कि मैं गतिशील प्रणालियों के बारे में जानता हूं और वास्तविक दुनिया के मेरे अनुभव के बीच की बातचीत कभी भी विनम्र होने में विफल नहीं होती है। वे मुझे तीन सत्यों की याद दिलाते रहते हैं:

1) दुनिया के बारे में हम जो कुछ भी सोचते हैं वह एक मॉडल है

2) हमारे मॉडल आमतौर पर दुनिया के साथ मजबूत अनुरूपता रखते हैं

3) हमारे मॉडल पूरी तरह से दुनिया का प्रतिनिधित्व करने से चूक जाते हैं

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

इस मानसिकता के बारे में सीखना, और इसे अपनाने से आपके काम को प्रभावित करने वाली परिस्थितियों के बड़े सेट के लिए सराहना पैदा करने में मदद मिलती है, और आपको अपने काम की दुनिया से जुड़ाव को समझने में मदद मिलती है।