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

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

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

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

खासतौर पर हब्र के लिए, हमने टिम लिस्टर के साथ एक साक्षात्कार किया। वह देवओप्स 2019 सम्मेलन खोलेगा, और हमने बहुत सारे सवाल जमा किए हैं, पुस्तकों के बारे में और बहुत कुछ। सम्मेलन कार्यक्रम समिति से साक्षात्कार मिखाइल ड्रुजिन और ओलेग चिरुखिन द्वारा आयोजित किए जाते हैं।

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

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

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

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

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

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

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

19 साल की अजेल

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

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

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

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

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

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

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

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

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

ओलेग: मेनिफेस्टो की तरह पीपुलवेयर भी एक क्रांति थी?

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

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

माइकल: किताब के विमोचन के बाद पिछले 30 सालों में कुछ भी बदला है?

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

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

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

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

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

माइकल: Devopse का पूरा विचार जितनी जल्दी हो सके सार्थक कार्य वितरित करना है। मैं देख रहा हूं कि दुनिया में और तेजी आने लगी। ऐसी तेजी के लिए कैसे अनुकूल है? दस साल पहले, यह नहीं था!

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

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

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

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

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

, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».

: , ?

: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .

: , « , »: ?

: . - . – - , , ? , – . , , - : « ! !». गंभीरता से? .

«-»

: . - , «-» . : , , «-», ? , – , - .

: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?

, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».

- , , . , , . – , « ». ? , , . - , , , , , . , - , , , , . ! - .

- -. , , ? , , ? - : --, , , , , .

, , . , . , , : , . , . , . .

. – , , , , , , ! - . – …

« »

: ? , , , – « ».

: ! – , - . - , ( , ). – , – , - , .

, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .

: , . , , . , . , – , – . , , , .

: Move fast and break things!

: , , , – -. , ?

: : . . , - , . , , - , « », , : « ». , . , , . – .

, . , , , - . - , , . , – , , , , . , , , . .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

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

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

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

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

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

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

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

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

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

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

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

संचार की कीमत

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

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

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

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

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

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

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

टिम: यह मुझे लगता है कि वे काम के बारे में चिंतित नहीं हैं, लेकिन आगे बढ़ने की दृश्यता की कमी के बारे में। उनके लिए यह सोचने के लिए कि हम सफलता के करीब पहुंच रहे हैं, उन्हें यह देखने की जरूरत है कि हम कीबोर्ड पर बटन कैसे दबाते हैं। पूरे दिन सुबह से शाम तक। यह नंबर एक समस्या है।

ओलेग: मिशा, आपने कुछ सोचा है।

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

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

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

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

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

सर्वश्रेष्ठ टिप

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

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

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

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

जोखिम प्रबंधन में संलग्न!

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

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

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

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

हां, मैं अक्सर सुनता हूं, "हम उपलब्ध होने के साथ समस्याओं का समाधान करेंगे।" क्या हम सही होंगे? क्या हम बिल्कुल फैसला करेंगे?

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

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

टिम: रीसेट बटन दबाएं! नहीं, यह काम नहीं करता है।

DevOops 2019 में मुख्य

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

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

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

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

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

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

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