सामान्य स्वचालन के दौरान क्या होता है? एक तकनीकी कार्य, कार्यात्मक आवश्यकताओं, वास्तुकला, और कागज के अन्य टुकड़ों का एक गुच्छा तैयार किया जाता है। यह पर्यावरण के आधार पर सभी स्थितियों, सीमाओं, कार्य एल्गोरिदम का वर्णन करता है, रूपों की उपस्थिति, डेटा सत्यापन आदि। अक्सर, कागज के इन टुकड़ों का डिज़ाइन और समन्वय स्वचालन से अधिक समय लगता है।
एक परियोजना दिखाई देती है, एक अनुसूची, कार्यों का अपघटन, एक निश्चित परियोजना प्रबंधक, या यहां तक कि कई। औपचारिकताएं पूरी होती हैं, अर्थात् सामग्री नहीं।
यह स्पष्ट है कि कुछ स्थितियों में यह कार्य करने का तरीका है। उदाहरण के लिए, यदि कोई बाहरी कंपनी स्वचालन में लगी हुई है, तो वह ऐसे कागजात के बिना जीवित नहीं रहेगी। वह केवल भगोड़ा आवश्यकताओं तक पहुंचने के बाद पीछा करेगा। कागजात स्थिरता, भुगतान की भविष्यवाणी और काम की डिलीवरी की गारंटी देता है। लेकिन ग्राहक को, कागज के ये टुकड़े केवल एक चीज की गारंटी देते हैं - एक लंबी, उबाऊ परियोजना जो कोई लाभ नहीं लाएगी।
व्यावसायिक प्रोग्रामिंग में, यह दृष्टिकोण उपयुक्त नहीं है। आपको याद दिला दूं कि ऑटोमेशन द्वारा समर्थित प्रक्रियाओं, प्रेरणा, लक्ष्यों, प्रबंधन प्रणाली के लिए व्यवसाय प्रोग्रामिंग एक जटिल बदलाव है।
उदाहरण के लिए, आप प्रक्रिया को बदलने का निर्णय लेते हैं। ऐसा कोई नहीं जो एक हजार लोगों को प्रभावित करता हो - आपके घुटने पर कोई समाधान नहीं है। उदाहरण के लिए, प्रक्रिया एक विभाग के पांच लोगों की चिंता करती है। ये सभी लोग, उनके नेता की तरह, आपके बगल में बैठे हैं - यहाँ वे हाथ की लंबाई पर हैं। और आपने फैसला किया, उनके साथ मिलकर, प्रक्रिया को बदलने के लिए। वे बैठ गए, बात की, सोचा, और फैसला किया। उदाहरण के लिए, प्रक्रिया को बदलने में आपको एक दिन लग गया।
ज्यादातर मामलों में, प्रक्रिया को बदलने के बाद, आपको स्वचालन की आवश्यकता होती है - आपको सूचना प्रणाली में परिवर्तन करने की आवश्यकता होती है। यदि आप कहते हैं - आपको एक तकनीकी कार्य, एक अनुसूची, एक नेता, क्यूरेटर और प्रायोजक के साथ एक परियोजना की आवश्यकता है, तो यह सब है। यह वह जगह है जहां आपके परिवर्तन समाप्त हो जाएंगे। औपचारिकताओं के साथ एक लंबी स्वचालन परियोजना प्रक्रिया में बदलाव को नकार देगी।
क्या विशेष रूप से महत्वपूर्ण है: प्रक्रियाओं में परिवर्तन प्रयोग हैं। आप, यहां तक कि एक परिष्कृत व्यवसाय प्रोग्रामर होने के नाते, यह सुनिश्चित करने के लिए नहीं जान सकते कि आपका परिवर्तन काम करेगा या नहीं। चुनी गई विधि खुद को एक अन्य प्रक्रिया में, या बिल्कुल उसी में भी दिखा सकती है, लेकिन एक अलग कंपनी में, लेकिन इस संदर्भ में यह निष्क्रिय हो सकती है।
चूंकि यह एक प्रयोग है, इसकी समय सीमा है - आज यह सोचा गया था, इसे कल लॉन्च किया गया था, हम इसे एक सप्ताह के लिए देखते हैं और निर्णय लेते हैं। यदि सब ठीक है, तो छोड़ दें। यदि नहीं, तो हम आगे सोचते हैं - या तो परिवर्तन को रद्द करें, या इसे परिष्कृत और सुधारें।
इस हफ्ते ऑटोमेशन का क्या होगा? यदि आप पारंपरिक मार्ग चुनते हैं, तो एक सप्ताह में आपके पास केवल तकनीकी कार्य होगा, और फिर सबसे अच्छा मामला होगा। तदनुसार, परिवर्तनों का कार्यान्वयन स्वचालन के बिना, मैन्युअल रूप से करना होगा। ठीक है, अगर आप ऐसे बदलाव करते हैं, जिसमें स्वचालन की आवश्यकता नहीं है - तो आप "आंख से" जांच सकते हैं। और अगर नहीं?
यह वह जगह है जहां तेज स्वचालन के सिद्धांत की आवश्यकता है। दरअसल, इसका सार नाम में निहित है - समन्वय और आवश्यकताओं के बिना, सिस्टम में बदलाव जल्दी से किया जाना चाहिए, उस हद तक जो मुख्य परिकल्पना का परीक्षण करने के लिए आवश्यक है जिसे आपने प्रक्रिया को बदलकर आगे रखा है।
आपको इंटरफ़ेस के बारे में अधिक चिंता करने की ज़रूरत नहीं है, इनपुट डेटा, कोड की इष्टतमता, डेटा संरचना और "सही" स्वचालन के अन्य स्तंभों की जांच करना। आपका कार्य इस प्रक्रिया में परिवर्तनों के स्वचालन का शीघ्रता से समर्थन करना है ताकि यह जांचा जा सके कि वे काम करते हैं या नहीं।
फास्ट ऑटोमेशन का सिद्धांत सभी प्रोग्रामर के लिए जाना जाता है। केवल वे इसे एक सिद्धांत के रूप में नहीं, बल्कि एक महान बुराई के रूप में जानते हैं - यह माना जाता है कि अज्ञानता, मध्यस्थता और शुरुआती ऐसे स्वचालन में लगे हुए हैं।
आंशिक रूप से प्रोग्रामर सही हैं। लेकिन उनके पास मौलिक रूप से अलग संदर्भ है। सहसा हो गया। कुछ "थिएटर" हैं - व्यापार विश्लेषक, उपयोगकर्ता और उनके नेता। वे वहां कुछ लेकर आए, और वे कहते हैं - तो, जल्दी से मुझे एक आकार / क्षेत्र / खिड़की बनाओ। क्या, कैसे, क्यों, क्यों - क्या नहीं समझाते। अभी भी जोड़ - जल्दी से आते हैं, जूते। प्रोग्रामर के पास क्या रहता है? यदि कोई अवसर है, तो वह डगमगाने लगेगा - यह कहें कि यह असंभव है ताकि आपको एक तकनीकी कार्य, विचारशील वास्तुकला, रीफैक्टरिंग, आदि की आवश्यकता हो। लेकिन, एक नियम के रूप में, धोखा देने की कोई संभावना नहीं है, और प्रोग्रामर बस जल्दी से करता है, "अपने घुटने पर", चरम प्रोग्रामिंग मोड में।
ठीक है, और, ठीक है, उसके साथ नरक करने के लिए, है ना? मैंने बिल्कुल वही प्रस्तावित किया - जल्दी से, बिना परेशानी के, अगर केवल यह काम करता है?
एक महत्वपूर्ण क्षण तब उत्पन्न होता है जब "देशद्रोही" परिवर्तन की व्यर्थता देखते हैं। व्यवसाय प्रोग्रामर बस ऐसे परिवर्तनों को रद्द कर देता है, और प्रोग्रामर को कोड के शुरू किए गए टुकड़ों को हटाने के लिए कहता है। "चीटर" के बारे में क्या? या, अधिक सटीक रूप से, "शोक-चीटर"?
वह कुछ भी रद्द नहीं करेगा। बस इसे छोड़ दें जैसा कि यह है, और, सबसे अच्छा, बस बदलाव करना जारी रखें। क्या आप समझते हैं? पिछले वाले को रद्द किए बिना, यह नए लोगों को हवा देगा, अधिक से अधिक।
एक राजनीतिक क्षण है, खासकर अगर विभाग का प्रमुख बदलाव के साथ आया। उसके लिए यह बहुत ज़रूरी है कि वह मूर्ख न दिखे, इसलिए, चाहे उसने कोई भी अविष्कार किया हो, वह उसे रद्द नहीं करेगा। इसके अलावा, यदि आप इसे दीवार के खिलाफ धक्का देते हैं, तो यह इसके परिवर्तनों की रक्षा करेगा।
सबसे अधिक बार ऐसा होता है कि कोई भी किए गए परिवर्तनों का उपयोग नहीं करेगा। यदि आप एक प्रोग्रामर हैं, तो यह स्थिति आपसे परिचित हो सकती है। उन्होंने पूछा, आदेश दिया, किसी तरह की व्यवस्था बनाने की मांग की, और फिर उन्होंने इसका उपयोग नहीं किया। यह "घुटने पर" भी नहीं किया जा सकता है, लेकिन सामान्य तौर पर, "सही" स्वचालन की सभी आवश्यकताओं और शर्तों के अनुपालन में, लेकिन फिर भी वे इसका उपयोग नहीं करते हैं। अब आप जानते हैं कि क्यों। और कोई भी इस कार्यक्षमता को सिस्टम से क्यों नहीं निकालता - आप भी अब जानते हैं।
यह इस तरह से है कि संवेदनाहीन, पैचवर्क स्वचालन के स्तरित पाई बाहर निकलते हैं और बढ़ते हैं। प्रोग्रामर चकल्लस करते हैं, लेकिन जो कहते हैं, वही करते हैं। बतख, गैर-इष्टतमता, वक्र संरचना और वास्तुकला एक स्नोबॉल की तरह बढ़ती है। और दूर, इस प्रक्रिया को रोकना और इसे उल्टा करना जितना मुश्किल होगा।
एक और समस्या समग्र रूप से प्रस्तावित परिवर्तनों की संवेदनहीनता है।
व्यावसायिक प्रोग्रामिंग में, किसी भी परिवर्तन में एक लक्ष्य होता है जिसे सभी प्रतिभागी समझते हैं। प्रक्रिया तेज, या अधिक विश्वसनीय, या अधिक नियंत्रित होनी चाहिए। इसलिए, परिवर्तनों का उद्देश्य और उनकी प्रभावशीलता के मूल्यांकन के मानदंड दोनों हमेशा स्पष्ट होते हैं।
लेकिन जब परिवर्तन "बस उस तरह", या "मेरे लिए इसे और अधिक सुविधाजनक बनाने के लिए", या "ठीक है, ठीक है!" के रूप में किए जाते हैं, तो परिणाम का मूल्यांकन करना असंभव है। इसलिए, परिवर्तन, चाहे वे कितने भी निरर्थक हों, रहने के लिए - प्रक्रिया और स्वचालन दोनों में।
अब आप समझते हैं कि समस्या क्या है - प्रक्रिया परिवर्तन और स्वचालन के बीच की खाई। जब कुछ लोग प्रक्रिया में बदलाव के साथ आते हैं, और फिर अन्य लोगों को स्वचालन कार्य निर्धारित करते हैं, तो अर्थ और सार को समझाए बिना, हमें एक सामान्य गड़बड़ मिलती है जो किसी को भी लाभ नहीं पहुंचाती है।
व्यावसायिक प्रोग्रामिंग के मानकों के अनुसार, एक टीम में काम किया जाता है - दोनों प्रक्रियाओं से लोग हैं और स्वचालन से लोग हैं। इससे भी बेहतर, जब यह काम एक व्यक्ति के नेतृत्व में है - एक व्यवसाय प्रोग्रामर। इससे भी बेहतर जब वह ऑटोमेशन खुद करता है।
इस मामले में, हम अस्थायी परिवर्तनों के जीवन चक्र को समझते हैं और प्रबंधित करते हैं - वे क्यों बनाए जाते हैं, जब वे शुरू होते हैं, और सबसे महत्वपूर्ण बात यह है कि वे कब और किन परिस्थितियों में समाप्त होते हैं।
मान लीजिए कि परिवर्तन गलत थे - यह सामान्य है, इसमें कुछ भी गलत नहीं है। फिर प्रोग्रामर के पास एक असामान्य काम है - सिस्टम में बदलाव को हटाने के लिए। बेशक, वे कभी-कभी ऐसे काम खुद करते हैं - उदाहरण के लिए, रीफैक्टरिंग। लेकिन व्यावसायिक प्रोग्रामिंग के मामले में, इस तरह के काम को समय-समय पर किया जाना चाहिए।
और अगर बदलाव सही थे? फिर "सही" स्वचालन के सभी कौशल खेलने में आते हैं, जो प्रोग्रामर बहुत गर्व करते हैं। आपको वास्तुकला, डेटा संरचना, एल्गोरिदम, दर्ज किए गए डेटा का सत्यापन, इंटरफ़ेस आदि का अनुमान लगाने की आवश्यकता है। लेकिन फर्क क्या है, देखिए
समस्या कथन के रूप में अंतर। आमतौर पर यह एक तकनीकी कार्य है, जो कागज का एक टुकड़ा है। हमारे मामले में, कार्य एक प्रोटोटाइप है। एक कार्यकर्ता जिसने अपनी उपयोगिता और प्रभावशीलता दिखाई है, परीक्षण किया है, इसलिए बोलने के लिए, लड़ाई में। इसे केवल मन में लाना आवश्यक है। आपको वास्तव में किसी भी चीज़ में समन्वय और चर्चा करने की आवश्यकता नहीं है - बस इसे लें और पर्यावरण के नियमों और मानकों के अनुसार एक प्रणाली बनाएं जिसमें कार्यक्रम बनाया जाता है।
यदि आप हर समय तेज प्रोग्रामिंग में संलग्न हैं, तो आप बहुत जल्दी कौशल प्राप्त करेंगे - तुरंत ऐसा करें ताकि आप इसे बाद में ठीक कर सकें। यहां प्रोग्रामर का "सही आलस्य" हमारे हाथों में चला जाएगा - वह एक ही समस्या को दो बार हल करने के लिए तैयार नहीं होगा, और वह जल्दी से एक प्रोटोटाइप बनाने के लिए और इसे न्यूनतम प्रयास के साथ पूर्ण समाधान में बदल देगा। हालांकि, व्यावसायिक प्रोग्रामिंग में, निश्चित रूप से, पूर्ण समाधान नहीं हैं।
अब यह प्रचलित हो गया है जैसे कि प्रोटोटाइप और मॉडलिंग, जब एक बड़ी स्वचालन परियोजना शुरू करने से पहले, जल्दी से, न्यूनतम प्रयासों के साथ, इंटरफ़ेस के साथ परेशानी के बिना, वे भविष्य की प्रणाली का एक निश्चित प्रोटोटाइप बनाते हैं। जैसा कि आप जानते हैं, यह बहुत तेजी से स्वचालन के सिद्धांत के समान है, हालांकि बिंदु, निश्चित रूप से नहीं है कि प्रोटोटाइप कैसे बनाया गया था, लेकिन यह कैसे बदलते परिवेश के अनुकूल होगा।
यदि प्रोटोटाइप एक इंटीग्रेटर कंपनी का सिर्फ एक विपणन चाल है, और फिर वैसे भी कागज का एक बड़ा टुकड़ा तकनीकी कार्य की तरह दिखाई देता है, तो यह सिर्फ एक चाल है। यह ग्राहक का भ्रम पैदा करता है कि "सब कुछ मेरी ज़रूरत के अनुसार होगा," लेकिन, अफसोस, यह जीवन में ऐसा नहीं होगा। प्रोटोटाइप लंबे समय तक नहीं रहेगा और अस्पष्टता में गायब हो जाएगा।
और अब आप समझते हैं कि क्यों। स्वचालन लगभग हमेशा एक गाड़ी है, न कि एक घोड़ा। घोड़ा प्रक्रियाओं में एक बदलाव है, और गाड़ी इस प्रकार है। लेकिन घोड़े से जुड़ा होने पर ही सवारी करता है।
घोड़ा मुड़ा, गाड़ी चली। देरी के साथ, बैकलैश और ड्रिफ्ट के साथ, लेकिन बदल गया। और अगर प्रत्येक घोड़े और गाड़ी अपना जीवन जीते हैं, तो दुखी प्रोग्रामर द्वारा गाड़ी ले जानी चाहिए। एक बड़ी स्वचालन परियोजना से पहले बनाई गई एक बड़ी प्रणाली का एक बड़ा प्रारूप एक स्नैपशॉट है, एक गाड़ी के लिए घोड़े का एक स्नैपशॉट है। सब कुछ सुंदर है, हर कोई खुश है, हर कोई इसे पसंद करता है, लेकिन एक दिन, या एक सप्ताह, या यहां तक कि एक महीना बीत जाता है, और घोड़ा गाड़ी को फेंक देता है, और वह चला जाता है जहां इसकी आवश्यकता होती है। और गाड़ी सुंदर, सुरुचिपूर्ण है, सभी तोपों के अनुसार बनाई गई है, यह मैदान में अकेले खड़ी रहती है।
इसलिए, "बड़ा" प्रोटोटाइप इसके लायक नहीं है। साथ ही "बड़ा" स्वचालन। एक बड़ी स्वचालन परियोजना को शुरू करने और आगे बढ़ाने के लिए, एक लानत असाधारण दिमाग, दूरदर्शिता और प्रबंधन में अविश्वसनीय प्रतिभा होनी चाहिए। यदि ये शब्द आपके बारे में हैं, तो मैं ईमानदारी से आपको बधाई देता हूं और आपकी हर सफलता की कामना करता हूं।
मैं बाकी को तेज स्वचालन के सिद्धांत का उपयोग करने की सलाह देता हूं।
और एक बार फिर मैं आपको याद दिलाता हूं: स्वचालन प्रक्रियाओं के परिवर्तन का अनुसरण करता है। परिवर्तन से पहले नहीं, परिवर्तन के बजाय नहीं, परिवर्तन से अलग नहीं। उन्होंने प्रक्रिया को बदल दिया, जल्दी से स्वचालित, परिणाम को देखा। अच्छा - जल्दी दिमाग में लाओ। अच्छा नहीं है - इसे फेंक दो।