टिम लिस्टर - पुस्तकों के सह-लेखक

• "मानवीय कारक। सफल परियोजनाएँ और टीमें" (मूल पुस्तक को "पीपलवेयर" कहा जाता है)
• "भालुओं के साथ घूमना: सॉफ्टवेयर परियोजनाओं में जोखिम का प्रबंधन"
• “एड्रेनालाईन-उन्मत्त और पैटर्न द्वारा ज़ोम्बीफाइड। परियोजना टीमों के व्यवहार के पैटर्न"

ये सभी पुस्तकें अपने क्षेत्र में उत्कृष्ट हैं और सहकर्मियों के साथ मिलकर लिखी गई थीं अटलांटिक सिस्टम्स गिल्ड. रूस में उनके सहयोगी सबसे प्रसिद्ध हैं - टॉम डेमार्को и पीटर ह्रुस्का, जिन्होंने कई प्रसिद्ध रचनाएँ भी लिखीं।

टिम के पास सॉफ्टवेयर विकास में 40 वर्षों का अनुभव है; 1975 में (इस हैब्रापोस्ट को लिखने वालों में से कोई भी इस वर्ष पैदा नहीं हुआ था), टिम पहले से ही योरडन इंक के कार्यकारी उपाध्यक्ष थे। अब वह अपना समय परामर्श देने, पढ़ाने और लिखने और कभी-कभार मिलने में बिताते हैं रिपोर्ट के साथ दुनिया भर में सम्मेलन।

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

माइकल: क्या आप इस बारे में कुछ शब्द बता सकते हैं कि आप अभी क्या कर रहे हैं?

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

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

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

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

माइकल: यानी, आप परियोजनाएं लॉन्च करते हैं, किसी प्रकार का किकऑफ़ करते हैं और जांचते हैं कि रेल सही दिशा में जा रही हैं या नहीं?

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

19 साल की चपलता

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

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

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

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

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

ओलेग: आपने एजाइल मेनिफेस्टो का उल्लेख किया। क्या हमें मुद्दे की आधुनिक समझ को ध्यान में रखते हुए इसे किसी तरह अद्यतन या संशोधित करने की आवश्यकता है?

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

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

पीपलवेयर: 30 साल बाद

ओलेग: क्या पीपलवेयर एक क्रांति के साथ-साथ घोषणापत्र भी था?

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

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

माइकल: क्या पुस्तक प्रकाशित होने के बाद से पिछले 30 वर्षों में कुछ बदला है?

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

हम सभी DevOps में रहते हैं

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

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

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

माइकल: डेवॉप्स का पूरा विचार यथाशीघ्र सार्थक विकास प्रदान करना है। मैं देख रहा हूं कि दुनिया और अधिक तेज गति से चलने लगी है। ऐसी तेजी के प्रति कैसे अनुकूलन करें? दस साल पहले यह अस्तित्व में नहीं था!

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

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

पैटर्न और एंटीपैटर्न

ओलेग: आप आमतौर पर पैटर्न और एंटीपैटर्न के बारे में बात करते हैं, और यही परियोजनाओं के जीवन और मृत्यु के बीच का अंतर है। और अब, देवोप्स हमारे जीवन में प्रवेश कर गया है। क्या इसका अपना कोई पैटर्न और एंटी-पैटर्न है जो प्रोजेक्ट को मौके पर ही खत्म कर सकता है?

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

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

माइकल: दरअसल, हमने अगली सिल्वर बुलेट के बारे में कितनी बार सुना है?

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

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

टिम: इस प्रश्न पर पहले से ही प्रौद्योगिकी समूह के साथ चर्चा की जा सकती है। शायद किसी सलाहकार को भी लाएँ। प्रोजेक्ट पर एक नजर डालें और समझें - क्या अब हम कुछ सही और उपयोगी, पहले से बेहतर कुछ करेंगे? शायद यह फिट होगा, शायद यह फिट नहीं होगा। लेकिन सबसे महत्वपूर्ण बात यह है कि ऐसा निर्णय डिफ़ॉल्ट रूप से न लें, सिर्फ इसलिए कि किसी ने कह दिया: “हमें ब्लॉकचेन की सख्त जरूरत है! मैंने विमान में एक पत्रिका में उसके बारे में पढ़ा था!” गंभीरता से? यह हास्यास्पद भी नहीं है.

पौराणिक "डेवोप्स इंजीनियर"

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

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

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

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

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

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

मुझे अब इसकी काफी मांग दिख रही है।' यदि आप एक तकनीकी विशेषज्ञ हैं, तो आपकी कंपनी आपकी मदद कर सकती है, लेकिन इसकी परवाह किए बिना, आपको वास्तव में अपना खुद का करियर पथ खोजने की ज़रूरत है क्योंकि तकनीक बदलती रहती है और आपको इसके साथ-साथ खुद को भी नया रूप देने की ज़रूरत है! केवल बीस वर्षों में, प्रौद्योगिकियाँ कम से कम पाँच बार बदल सकती हैं। टेक्नोलॉजी एक अजीब चीज़ है...

"हर चीज़ के विशेषज्ञ"

माइकल: लोग प्रौद्योगिकी परिवर्तन की इतनी गति का सामना कैसे कर सकते हैं? उनकी जटिलता बढ़ रही है, उनकी संख्या बढ़ रही है, लोगों के बीच संचार की कुल मात्रा भी बढ़ रही है, और यह पता चला है कि आप "हर चीज़ में विशेषज्ञ" नहीं बन सकते।

टिम: सही! यदि आप प्रौद्योगिकी के क्षेत्र में काम करते हैं, तो हाँ, आपको निश्चित रूप से कुछ विशिष्ट चुनने और उसमें गहराई से उतरने की ज़रूरत है। कुछ तकनीक जो आपके संगठन को उपयोगी लगती है (और शायद वास्तव में उपयोगी होगी)। और यदि अब आपकी इसमें कोई दिलचस्पी नहीं है - मुझे कभी विश्वास नहीं होता कि मैं ऐसा कहूंगा - ठीक है, शायद आपको किसी अन्य संगठन में चले जाना चाहिए जहां तकनीक अध्ययन के लिए अधिक दिलचस्प या अधिक सुविधाजनक हो।

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

जोखिम और अनिश्चितता

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

ओलेग: तेज़ी से आगे बढ़ें और चीज़ों को तोड़ें!

माइकल: हां, तेजी से आगे बढ़ें, चीजों को तोड़ें, अधिक से अधिक चीजों को, जब तक कि आप किसी चीज से मर न जाएं। आपके दृष्टिकोण से, औसत डेवलपर को अब जोखिम प्रबंधन सीखने के लिए किस प्रकार दृष्टिकोण अपनाना चाहिए?

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

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

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

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

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

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

वयस्क इंजीनियरिंग सोच

माइकल: बच्चों के साथ उदाहरण अच्छा है. अगर मैं एक साधारण इंजीनियर हूं तो बच्चा बनकर भी खुश हूं। लेकिन आप अधिक वयस्क सोच की ओर कैसे बढ़ेंगे?

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

ओलेग: तुलनात्मक रूप से कहें तो, यदि आप कानबन के अनुसार काम करते हैं, तो जब आप किसी परीक्षण में बाधा डालते हैं, तो आप वहां जो कर रहे थे उसे छोड़ सकते हैं (उदाहरण के लिए, प्रोग्रामिंग) और परीक्षकों की मदद करने के लिए जा सकते हैं।

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

ओलेग: आपका जीवन आपका प्रोजेक्ट है, जिसे आप प्रबंधित करते हैं।

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

जोखिम प्रबंधन में कैसे शामिल हों

ओलेग: क्या इस क्षेत्र में कोई औपचारिक ज्ञान संरचना है? उदाहरण के लिए, मैं एक जावा डेवलपर हूं और शिक्षा के माध्यम से वास्तविक परियोजना प्रबंधक बने बिना जोखिम प्रबंधन को समझना चाहता हूं। मैं शायद सबसे पहले मैककोनेल की "एक सॉफ्टवेयर परियोजना की लागत कितनी है" पढ़ूंगा, और फिर क्या? पहले कदम क्या हैं?

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

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

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

उन्हें अनुकूलन में मदद करने के लिए, वे अक्सर तकनीकी विशेषज्ञों को प्रशिक्षण के लिए भेजना चाहते हैं, और वे प्रशिक्षण पर चर्चा करते हैं। मेरा एक मित्र यह कहना चाहता है कि प्रशिक्षण कुत्तों के लिए है। लोगों के लिए ट्रेनिंग है. एक डेवलपर के रूप में सीखने के बारे में सबसे अच्छी चीज़ों में से एक है अपने साथियों के साथ बातचीत करना। यदि कोई वास्तव में किसी चीज़ में अच्छा है, तो आपको उसे काम करते हुए देखना चाहिए या उससे उसके काम या किसी चीज़ के बारे में बात करनी चाहिए। कुछ पारंपरिक केंट बेक लगातार चरम प्रोग्रामिंग के बारे में बात करते थे। यह हास्यास्पद है क्योंकि XP ​​एक बहुत ही सरल विचार है, लेकिन यह बहुत सारी समस्याओं का कारण बनता है। कुछ लोगों के लिए XP करना दोस्तों के सामने नग्न होने के लिए मजबूर होने जैसा है। वे देखेंगे कि मैं क्या कर रहा हूँ! वे मेरे सहकर्मी हैं, न केवल देखेंगे, बल्कि समझेंगे भी! भयानक! कुछ लोग गंभीर रूप से घबराने लगे हैं। लेकिन जब आपको एहसास होता है कि यह सीखने का अंतिम तरीका है, तो सब कुछ बदल जाता है। आप लोगों के साथ मिलकर काम करते हैं और कुछ लोग विषय को आपसे बेहतर समझते हैं।

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

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

संचार की कीमत

ओलेग: क्या विभिन्न कारणों से ऐसे निवर्तमान कर्मचारियों को नियोजित करना अधिक महंगा नहीं है? आख़िरकार, वे काम करने के बजाय लगातार चैट कर रहे हैं!

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

माइकल: यह परियोजना में शामिल सभी लोगों पर लागू होता है, विशेषज्ञता, कौशल या काम करने के तरीके की परवाह किए बिना। आप सभी परियोजना की सफलता में रुचि रखते हैं।

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

ओलेग: वास्तव में, बातूनी कर्मचारियों के बारे में बोलते हुए, मैंने लोगों, विशेष रूप से प्रबंधकों की आपत्तियों का अनुकरण करने की कोशिश की, जिन्हें दुनिया की इस पूरी नई दृष्टि के लिए डेवॉप्स पर स्विच करने के लिए कहा जाता है। और सलाहकार के रूप में आपको इन आपत्तियों के बारे में एक डेवलपर के रूप में मुझसे कहीं बेहतर तरीके से अवगत होना चाहिए! साझा करें कि प्रबंधकों को सबसे अधिक चिंता किस बात से है?

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

माइकल: जाओ कुछ कोड लिखो!

टिम: मुझे ऐसा लगता है कि उन्हें काम की चिंता नहीं है, बल्कि प्रगति दिखाई न देने की चिंता है। यह दिखाने के लिए कि हम सफलता के करीब पहुँच रहे हैं, उन्हें हमें कीबोर्ड पर बटन दबाते हुए देखना होगा। सुबह से शाम तक पूरा दिन. यह समस्या नंबर एक है.

ओलेग: मिशा, तुम कुछ सोच रही हो।

माइकल: क्षमा करें, मैं सोच में पड़ गया और फ्लैशबैक में आ गया। यह सब मुझे कल हुई एक दिलचस्प रैली की याद दिलाता है... कल बहुत सारी रैलियाँ थीं... और यह सब बहुत परिचित लगता है!

वेतन के बिना जीवन

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

ओलेग: वैसे, आपकी किताब में क्या अच्छा है और क्या बुरा है, इसके बारे में ढेर सारी टिप्पणियाँ हैं। क्या आप स्वयं उनमें से किसी का उपयोग करते हैं? तुलनात्मक रूप से कहें तो, अब आपके पास एक कंपनी है, और वह बहुत ही अपरंपरागत तरीके से संरचित है...

टिम: अपरंपरागत, लेकिन यह उपकरण हमारे लिए बिल्कुल उपयुक्त है। हम एक-दूसरे को लंबे समय से जानते हैं।' हम एक-दूसरे पर भरोसा करते हैं, साझेदार बनने से पहले हमने एक-दूसरे पर बहुत भरोसा किया था। और उदाहरण के लिए, हमारे पास कोई वेतन नहीं है। हम बस काम करते हैं, और उदाहरण के लिए, अगर मैंने अपने ग्राहकों से पैसा कमाया, तो सारा पैसा मेरे पास चला गया। उसके बाद, हम संगठन को सदस्यता शुल्क का भुगतान करते हैं, और यह कंपनी को समर्थन देने के लिए पर्याप्त है। साथ ही, हम सभी अलग-अलग चीजों में विशेषज्ञ हैं। उदाहरण के लिए, मैं अकाउंटेंट के साथ काम करता हूं, टैक्स रिटर्न भरता हूं, कंपनी के लिए सभी प्रकार के प्रशासनिक काम करता हूं, और कोई भी मुझे इसके लिए भुगतान नहीं करता है। जेम्स और टॉम हमारी वेबसाइट पर काम करते हैं और कोई उन्हें भुगतान भी नहीं करता। जब तक आप अपना बकाया चुकाते रहेंगे, कोई भी आपको यह बताने के बारे में नहीं सोचेगा कि आपको क्या करने की आवश्यकता है। उदाहरण के लिए, टॉम अब पहले की तुलना में बहुत कम काम करता है। अब उसके अन्य हित हैं; वह कुछ चीजें गिल्ड के लिए नहीं करता है। लेकिन जब तक वह अपना बकाया चुकाता है, कोई भी उसके पास आकर नहीं कहेगा, "अरे, टॉम, काम पर जाओ!" जब आपके बीच पैसे की कमी हो तो सहकर्मियों के साथ व्यवहार करना बहुत आसान होता है। और अब हमारा संबंध विभिन्न विशिष्टताओं के संबंध में मौलिक विचारों में से एक है। यह काम करता है और यह बहुत अच्छा काम करता है।

सर्वोत्तम सलाह

माइकल: "सर्वोत्तम सलाह" पर वापस लौटते हुए, क्या ऐसी कोई बात है जो आप अपने ग्राहकों को बार-बार बताते हैं? 80/20 के बारे में एक विचार है, और कुछ सलाह संभवतः अधिक बार दोहराई जाती है।

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

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

मुझे तो ये सब डरावना लग रहा है. लोग जटिल, परेशान करने वाली समस्याओं से जूझते हैं और यह दिखावा करते रहते हैं कि यदि वे बस अपनी उंगलियाँ क्रॉस करके सर्वश्रेष्ठ की आशा करते हैं, तो वास्तव में "सर्वश्रेष्ठ" घटित होगा। नहीं, यह उस तरह से काम नहीं करता.

जोखिम प्रबंधन का अभ्यास करें!

माइकल: आपकी राय में, कितने संगठन जोखिम प्रबंधन में संलग्न हैं?

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

माइकल: और फिर भी, इनमें से कितनी कंपनियाँ जोखिम प्रबंधन में शामिल हैं, पाँच प्रतिशत?

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

हाँ, मैं अक्सर सुनता हूँ, "समस्याएँ उत्पन्न होने पर हम उनका समाधान कर देंगे।" निश्चित रूप से हम करेंगे? क्या हम सचमुच निर्णय लेंगे?

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

माइकल: हाँ, मेरे साथ ऐसा हुआ कि जब जोखिम उत्पन्न हुआ, तो परियोजना को फिर से परिभाषित किया गया। बढ़िया, बिंगो, समस्या हल हो गई, अब चिंता मत करो!

टिम: आइए रीसेट बटन दबाएँ! नहीं, यह उस तरह से काम नहीं करता.

DevOops 2019 में मुख्य वक्ता

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

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

माइकल: मैं भी वर्षों से परामर्श के क्षेत्र में काम कर रहा हूं और अच्छी तरह समझता हूं कि आप किस बारे में बात कर रहे हैं।

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

यदि आप त्वरित परिणाम प्राप्त करना चाहते हैं, तो यहां आपके लिए एक अच्छा विषय है: क्या आपने ऐसी कंपनियां देखी हैं जहां कोई यह नहीं कहता कि "मुझे नहीं पता"? ऐसी जगहें हैं जहां आप किसी व्यक्ति को तब तक यातना देते हैं जब तक वह यह स्वीकार नहीं कर लेता कि वह कुछ नहीं जानता है। हर कोई सब कुछ जानता है, हर कोई अविश्वसनीय विद्वान है। आप किसी भी व्यक्ति से संपर्क करें, और उसे तुरंत प्रश्न का उत्तर देना होगा। "मैं नहीं जानता" कहने के बजाय। हुर्रे, उन्होंने विद्वानों के एक समूह को काम पर रखा है! और कुछ संस्कृतियों में यह कहना आम तौर पर बहुत खतरनाक होता है कि "मैं नहीं जानता"; इसे कमजोरी का संकेत माना जा सकता है। ऐसे संगठन भी हैं जिनमें, इसके विपरीत, हर कोई कह सकता है "मुझे नहीं पता।" वहां यह पूरी तरह से कानूनी है, और यदि कोई किसी प्रश्न के उत्तर में बकवास करना शुरू कर देता है, तो उत्तर देना पूरी तरह से सामान्य है: "आप नहीं जानते कि आप किस बारे में बात कर रहे हैं, ठीक है?" और इसे एक मजाक में बदल दो।

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

टिम लिस्टर मुख्य भाषण के साथ पहुंचेंगे "चरित्र, समुदाय और संस्कृति: समृद्धि के लिए महत्वपूर्ण कारक"DevOops 2019 सम्मेलन के लिए, जो 29-30 अक्टूबर, 2019 को सेंट पीटर्सबर्ग में होगा। आप टिकट खरीद सकते हैं आधिकारिक वेबसाइट पर. हम DevOops पर आपका इंतजार कर रहे हैं!

स्रोत: www.habr.com