पुरुष, पकड़े गए अपवादों पर विराम

आइए एक बहुत ही दिलचस्प विषय के व्यावहारिक अनुप्रयोग के बारे में बात करते हैं - प्रणालीगत सोच।

प्रणालीगत सोच में कई सिद्धांत और विधियां हैं, मैं प्रासंगिक साहित्य को पढ़ने की अत्यधिक सलाह देता हूं। उदाहरण के लिए, एक सरल और दिलचस्प पुस्तक । आज हम केवल एक सिद्धांत - सिस्टम के उभरते, या उभरते हुए गुणों को स्पर्श करेंगे।

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

पहले, हालांकि, थोड़ा सिद्धांत।

सिस्टम और गुण

काम पर, हम लगभग हमेशा सिस्टम से निपटते हैं - लोगों के जटिल संग्रह, प्रक्रियाएं, रिश्ते (औपचारिक और अनौपचारिक), स्पष्ट और छिपे हुए नेता, भौतिक वस्तुएं, सूचना प्रणाली, ग्राहक, आपूर्तिकर्ता, उपकरण, आदि।

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

इस ढेर से बाहर निकलने की व्यवस्था कैसे करें? आपको तत्वों को उनके स्थान पर रखने और इसे चालू करने की आवश्यकता है - सिस्टम को काम में शुरू करें।

यह सामान्य प्रोग्रामर, या इंजीनियरों द्वारा अच्छी तरह से समझा जाता है। यहां प्रोग्राम कोड है, यहां एक कंप्यूटर या सर्वर है, यहां प्रोसेसिंग के लिए इनपुट डेटा हैं। प्रेस ऑन - सिस्टम काम कर रहा है। अगर इसमें कोई त्रुटि है तो ठीक है, या काम नहीं किया।

लोगों से मिलकर बनने वाली प्रणालियों में, आमतौर पर विपरीत सच होता है, और यह अंतर महत्वपूर्ण है। लोगों के सिस्टम ने आपके सामने काम किया, और आपके बाद काम करेगा। लेकिन वे आपकी उपस्थिति में, आपके साथ काम नहीं करेंगे। दरअसल, आपकी उपस्थिति में वे सिस्टम बनना बंद कर देते हैं, और फिर से तत्वों के एक समूह में बदल जाते हैं।

ऊपर दिए गए उदाहरण पर लौटते हुए, जब आपने एक ही स्थान पर सब कुछ और सिस्टम के सभी तत्वों को एकत्र किया। तुमने क्या किया है? आपने सिस्टम बंद कर दिया है।

सिस्टम के बीच में क्या अंतर है? लोगों को समान, समान पद, समान प्रक्रियाएँ, समान नेता - सब कुछ यथावत है।

प्रणाली के गुणों में अंतर, जो स्वयं को केवल तभी प्रकट करता है जब वह "चालू" होता है, अर्थात जब सिस्टम चल रहा है।

ऐसी प्रणाली गुणों के उदाहरण हर जगह हैं; आप उन्हें बिना किसी कठिनाई के पा सकते हैं।

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

सिस्टम के ऐसे गुणों को उद्भव , या उत्पन्न होना कहा जाता है।

वे उठते हैं जब एक सिस्टम को इकट्ठा किया जाता है और तत्वों के एक सेट से चालू किया जाता है। दोनों स्थितियां महत्वपूर्ण हैं - यह दोनों को इकट्ठा और चालू किया गया है। हमारे मामले में, जब यह बंद नहीं होता है।

इसलिए, हमारा कार्य सिस्टम को समझना है ताकि बाद में इसे बदल सकें। सिस्टम को कैसे समझें?

बंद न करें

उसे बंद किए बिना देखना बहुत सरल है।

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

पारंपरिक, गैर-कंप्यूटर प्रणालियों के साथ, यह अभी भी अधिक जटिल है। कोई "सूची" नहीं है। कल्पना करें कि "मानव" सिस्टम के साथ काम करना कितना ऊंचा होगा, अगर "पकड़े गए अपवादों पर रोक" चेकबॉक्स था?

हम आमतौर पर सिस्टम को कैसे बंद करते हैं:

1. हम कर्मचारियों के साथ व्यक्तिगत रूप से बात करते हैं
2. हम सभी कर्मचारियों के साथ एक बार में बात करते हैं
3. हम सभी को एक अनौपचारिक घटना पर ले जाते हैं
4. हम कर्मचारियों से एक अनुरोध करते हैं, एक कार्य निर्धारित करते हैं, एक रिपोर्ट मांगते हैं
5. कृपया उनकी गतिविधियों का वर्णन करें, या एक व्यावसायिक प्रक्रिया लिखें
6. एक बैठक में नेताओं को इकट्ठा करना
7. हम पूर्व कर्मचारियों से पूछते हैं कि सिस्टम कैसे काम करता है
8. आदि

यह पता चला है कि हमारी सभी सामान्य क्रियाएं सिस्टम के बंद होने का कारण बनती हैं और तत्वों के एक सेट के उद्भव गुणों को समझने का प्रयास करती हैं।

शर्लक होम्स ने इस काम के साथ एक उत्कृष्ट काम किया, उन्होंने इसे कटौती कहा - तस्वीर को विस्तार से समझने के लिए। सच है, उसके पास कोई और विकल्प नहीं था - आपने अपराधी को खोज प्रतिभा की उपस्थिति में फिर से अपराध करने के लिए नहीं कहा।

हमारी स्थिति सरल है, और काम करने, अपरिवर्तित प्रणालियों का निरीक्षण करने का अवसर है।

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

एक समान उदाहरण एक कोच है, उदाहरण के लिए, एक फुटबॉल टीम में। वहां, कार्रवाई में सिस्टम की निगरानी करना, अपनी सारी शक्ति में, नौकरी का हिस्सा है।

विभाजन, अलमारियाँ, कभी-कभी महाद्वीपों द्वारा विभाजित हम, कार्यालय कार्यकर्ता क्या करते हैं?

व्यक्ति या तकनीकी साधनों का उपयोग करके गुप्त निगरानी का संचालन करना।

देख

व्यक्तिगत अवलोकन हमेशा संभव नहीं होता है, यह सब मनाया प्रणाली के बारे में आपकी स्थिति पर निर्भर करता है।

यदि आप एक संगठन के भीतर काम करते हैं, तो आप बस अपने कार्यस्थल को रख सकते हैं जहां सिस्टम स्थित है - ऐसे लोग जिनके संपर्क आप समझना चाहते हैं।

सबसे पहले आप एक विदेशी तत्व होंगे जो सिस्टम को बंद कर देता है। लेकिन धीरे-धीरे उन्हें आपकी आदत हो जाएगी और आप पर ध्यान देना बंद कर देंगे।

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

यदि आपकी टीम में ऐसे लोग हैं जो सिस्टम से जुड़ना आसान समझते हैं, तो आप उन्हें एक स्पष्ट इंस्टॉलेशन के साथ भेज सकते हैं।

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

अभ्यास से पता चलता है कि आमतौर पर 2-5 दिन सिस्टम का अंदाजा लगाने के लिए पर्याप्त हैं। यह एक अत्यंत सटीक चित्र नहीं होगा, लेकिन एक स्केच जो सिस्टम की एक सामान्य, अभिन्न दृष्टि देता है।

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

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

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

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

वास्तव में, इस दृष्टिकोण में कोई नई बात नहीं है, यह अक्सर कुछ क्षेत्रों में उपयोग किया जाता है।

उदाहरण के लिए, खुदरा और सेवा क्षेत्र में, रहस्य दुकानदारों का उपयोग किया जाता है - जो लोग उद्देश्यपूर्वक स्टोर, होटल आदि में भेजे जाते हैं, ताकि वे सिस्टम को कार्रवाई में देख सकें जैसा कि यह है।

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

भविष्यवाणी

अब पूर्वानुमान के बारे में। एक प्रोग्रामर के काम में, एक स्थिति अक्सर सामने आती है जब आपको किसी परियोजना की सफलता का पूर्वानुमान देने की आवश्यकता होती है। आमतौर पर हम कंपनी के आंतरिक संगठनात्मक विकास की परियोजनाओं के बारे में बात कर रहे हैं। सीधे शब्दों में कहें तो ड्राफ्ट में बदलाव के बारे में।

वे आम तौर पर अन्य लोगों की परियोजनाओं के बारे में पूछते हैं - वे जिनमें एक व्यवसाय प्रोग्रामर शामिल नहीं है। यानी व्यवसाय प्रोग्रामिंग के नियमों के अनुसार नहीं किए गए प्रोजेक्ट के बारे में, लेकिन नियम के अनुसार "जैसा मैं कर सकता हूं।"

एक व्यावसायिक प्रोग्रामर, एक योजनाबद्ध परियोजना के बारे में जानकारी के एक संक्षिप्त अध्ययन के बाद, आमतौर पर कहता है कि उपयोगी कुछ भी नहीं आएगा। या - कुछ भी काम नहीं करेगा। अंतर स्पष्ट है - परियोजना को समय और बजट पर सफलतापूर्वक पूरा किया जा सकता है, लेकिन कंपनी को कोई लाभ नहीं होगा।

राय व्यक्त की, अर्थात्। व्यवसाय प्रोग्रामर का पूर्वानुमान आमतौर पर नकारात्मक प्रतिक्रियाओं का कारण बनता है - अवसाद, क्रोध, अस्वीकृति, "आप कौन हैं?", "अभिनय भगवान पृथ्वी पर, या क्या? " आदि

एक नकारात्मक प्रतिक्रिया तेज हो जाती है जब पूर्वानुमान सच हो जाता है, और यह बहुत बार सच हो जाता है।

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

अब देखते हैं कि एक व्यावसायिक प्रोग्रामर ऐसे पूर्वानुमान कैसे लगाता है।

पूर्वानुमान कहाँ से आते हैं?

यह सिस्टम व्यवहार के ज्ञान का उपयोग करने के बारे में है।

परिवर्तन की परियोजना में हमेशा कम से कम दो प्रणालियाँ होती हैं: परिवर्तनशील और परिवर्तनशील।

परिवर्तनीय - हम क्या सुधार करने जा रहे हैं । व्यावसायिक प्रक्रिया, इकाई कार्य, कार्यों की सहभागिता आदि। हम इसे परिवर्तन की वस्तु कहेंगे।

परिवर्तन - जो आक्रमण करता है, वह लागू होता है और लागू होता है । सीधे शब्दों में कहें, परिवर्तन कार्यान्वयन टीम। हम उसे परिवर्तन का विषय कहेंगे।

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

विषय में, अर्थात परियोजना और परिवर्तनों की टीम, विशिष्ट तत्व हैं - कार्यान्वित होने के तरीकों को चुनने के लिए एल्गोरिथ्म, परियोजना प्रबंधक और टीम के लक्ष्य और प्रेरणा, कार्यान्वयन पद्धति, परियोजना प्रबंधन के सिद्धांत, परियोजना की प्रगति और परिणामों का आकलन करने के लिए प्रबंधन दृष्टिकोण, परियोजना के बाद जीवन के लिए टीम की योजना, हल होने वाली समस्या का विकल्प आदि। .D।

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

हालांकि, यह व्यवसाय प्रोग्रामर है जो सबसे सटीक पूर्वानुमान देता है। हर कोई एक ही चीज को देख रहा है। ऑब्जेक्ट देखें, विषय, परियोजना योजना, संसाधन, पर्यावरण देखें। लेकिन पूर्वानुमान मौलिक रूप से अलग है। क्यों?

उत्तर बहुत सरल है, और यहां तक ​​कि उबाऊ भी है: एक व्यवसायी प्रोग्रामर ऐतिहासिक जानकारी को ध्यान में रखता है। समान प्रणालियों के व्यवहार के बारे में ऐतिहासिक और सांख्यिकीय जानकारी।

परिवर्तन कार्यान्वयन परियोजना के परिणाम में दो प्रणालियों का संयोजन होता है - एक वस्तु और एक विषय। यदि सिस्टम सही ढंग से फिट नहीं होते हैं, तो परिणाम नकारात्मक होगा।

यदि परिवर्तनों की एक नई परियोजना की कल्पना की जा रही है, लेकिन वस्तु और विषय की प्रणालियों में बहुत बदलाव नहीं हुआ है, तो परिणाम सबसे अधिक समान होगा। वही लोग एक ही इकाई में एक ही विधि को लागू करने की कोशिश कर रहे हैं।

बहुत सारे उदाहरण। यदि आप अपनी कंपनी में परिवर्तनों की शुरूआत के इतिहास को व्यवस्थित रूप से देखते हैं, तो आप इस पैटर्न की पुष्टि देखेंगे।

आप सड़क पर उदाहरण के लिए देख सकते हैं, अब सिर्फ सही प्रणाली - "सर्दियों" कहा जाता है। शीतकालीन + शहर + ये, उनकी तरह, जो बर्फ हटाया जाना चाहिए। साल बीतते हैं, और परिणाम समान होता है। क्योंकि सभी सिस्टम अपरिवर्तित हैं। अरे हाँ, कभी-कभी सर्दियों में बर्फ के बिना होता है - तो परिणाम बहुत अच्छा है। किसका है?

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

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

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

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

जितनी बार आप इस अभ्यास को करते हैं, उतनी ही तेजी से आपके कौशल का विकास होगा, और आपकी भविष्यवाणी जितनी सटीक होगी।

हमारे देश में इस तरह की एक लोकप्रिय अभिव्यक्ति है - "वे सबसे अच्छा चाहते थे, लेकिन यह हमेशा की तरह निकला"। अब, पढ़ने के बाद, आप समझते हैं कि यहाँ कुछ गायब है। यह अधिक सही होगा "वे सबसे अच्छा चाहते थे, हमेशा की तरह कार्य करते थे, ठीक है, यह परिणाम है ..."।

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

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

अब तक, ऐसा लगता है, लावरोव सही है।