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

• "मानव कारक। सफल परियोजनाहरू र टोलीहरू" (मूल पुस्तकलाई "पिपलवेयर" भनिन्छ)
• "भालुसँग वाल्ट्जिङ: सफ्टवेयर परियोजनाहरूमा जोखिम व्यवस्थापन"
• "एड्रेनालाईन-पागल र ढाँचाहरू द्वारा जोम्बिफाइड। परियोजना टोलीहरूको व्यवहारको ढाँचा"

यी सबै पुस्तकहरू तिनीहरूको क्षेत्रमा क्लासिक हुन् र सहकर्मीहरूसँग मिलेर लेखिएका थिए एट्लान्टिक प्रणाली गिल्ड। रूस मा, तिनका सहकर्मीहरू सबैभन्दा प्रसिद्ध छन् - टम डेमार्को и पिटर Hruschka, जसले धेरै प्रसिद्ध कृतिहरू पनि लेखे।

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

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

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

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

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

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

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

माइकल: त्यो हो, तपाइँ परियोजनाहरू सुरु गर्नुहुन्छ, केहि प्रकारको किकअफ गर्नुहुन्छ र रेलहरू सही दिशामा जाँदै हुनुहुन्छ भनेर जाँच गर्नुहुन्छ?

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

19 वर्ष फुर्तिलो

माइकल: फुर्तिलोमा, मानिसहरू प्रायः कुनै पनि कुरालाई पहिले नै परिभाषित नगर्ने प्रयास गर्छन्, तर सकेसम्म ढिलो निर्णय गर्न, यसो भन्दै: हामी धेरै ठूलो छौं, म समग्र वास्तुकलाको बारेमा सोच्दिन। म अन्य चीजहरूको गुच्छाको बारेमा सोच्दिन; यसको सट्टा, म ग्राहकलाई अहिले काम गर्ने चीज दिनेछु।

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

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

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

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

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

टिम: म उसलाई छुने छैन। मलाई लाग्छ कि यो एक महान ऐतिहासिक दस्तावेज हो। मेरो मतलब, उहाँ जे हुनुहुन्छ। उनी १९ वर्षको भइसकेका छन्, बूढो भइसकेका छन्, तर आफ्नो पालामा उनले क्रान्ति गरेका छन् । उसले के राम्रो गर्यो कि उसले एक प्रतिक्रिया ट्रिगर गर्यो र मानिसहरूले उनको बारेमा कानाफूसी गर्न थाले। तपाईं, सम्भवतः, 19 मा उद्योगमा काम गरिरहनुभएको थिएन, तर त्यसपछि सबैले प्रक्रिया अनुसार काम गरे। सफ्टवेयर इन्जिनियरिङ् संस्थान, सफ्टवेयर पूर्णता मोडेल (CMMI) को पाँच स्तर। मलाई थाहा छैन कि गहिरो पुरातनताका यस्ता किंवदन्तीहरूले तपाईंलाई केही बताउँछन्, तर त्यसपछि यो एक सफलता थियो। सुरुमा, मानिसहरूले विश्वास गरे कि यदि प्रक्रियाहरू सही रूपमा सेट अप गरियो भने, त्यसपछि समस्याहरू आफैं गायब हुनेछन्। र त्यसपछि घोषणापत्र आउँछ र भन्छ: "होइन, होइन, होइन - हामी मानिसहरूमा आधारित हुनेछौं, प्रक्रियाहरूमा होइन।" हामी सफ्टवेयर विकास को मालिक हो। हामी बुझ्छौं कि आदर्श प्रक्रिया मृगौला हो; त्यहाँ परियोजनाहरूमा धेरै idiosyncracy छ, सबै परियोजनाहरूको लागि एक एकल पूर्ण प्रक्रियाको विचार कुनै अर्थ छैन। सबै कुराको एउटै समाधान छ भनेर दाबी गर्न समस्याहरू धेरै जटिल छन् (नमस्ते, निर्वाण)।

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

Peopleware: 30 वर्ष पछि

ओलेग: के पिपुलवेयर भनेको क्रान्ति र घोषणापत्र पनि थियो?

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

यस तथ्यको बावजुद टिमले धेरै संख्यामा वार्ताहरू दिएका छन्, तिनीहरूमध्ये धेरै कम YouTube मा पोस्ट गरिएका छन्। तपाईं 2007 बाट "The Return of Peopleware" रिपोर्ट हेर्न सक्नुहुन्छ। गुणस्तर, निस्सन्देह, इच्छित हुन धेरै छोड्छ।

माइकल: पुस्तक प्रकाशित भएको ३० वर्षमा केही परिवर्तन भएको छ ?

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

हामी सबै DevOps मा बस्छौं

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

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

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

माइकल: devops को सम्पूर्ण विचार सकेसम्म चाँडो अर्थपूर्ण विकासहरू प्रदान गर्नु हो। म देख्छु कि संसारले अझ धेरै गति लिन थालेको छ। कसरी यस्तो प्रवेग अनुकूलन गर्न? दस वर्ष पहिले यो अवस्थित थिएन!

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

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

ढाँचा र antipatterns

ओलेग: तपाइँ सामान्यतया ढाँचा र एन्टिप्याटर्नहरूको बारेमा कुरा गर्नुहुन्छ, र यो परियोजनाहरूको जीवन र मृत्यु बीचको भिन्नता हो। र अब, डेभोप्स हाम्रो जीवनमा फट्छन्। के यसको आफ्नै ढाँचा र विरोधी ढाँचाहरू छन् जसले परियोजनालाई ठाउँमा मार्न सक्छ?

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

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

माइकल: वास्तवमा, हामीले अर्को चाँदीको बुलेटको बारेमा कति पटक सुनेका छौं?

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

माइकल: हो, मुख्य "जीवन, ब्रह्माण्ड र सबै चीजको प्रश्न": के यो प्रविधि वा दृष्टिकोण तपाईंको अवस्थाको लागि उपयुक्त छ कि छैन?

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

पौराणिक "डिभोप्स इन्जिनियर"

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

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

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

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

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

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

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

"सबै कुरामा विशेषज्ञहरू"

माइकल: प्रविधिको परिवर्तनको यस्तो गतिलाई मानिसहरूले कसरी सामना गर्न सक्छन्? तिनीहरूको जटिलता बढ्दै छ, तिनीहरूको संख्या बढ्दै छ, मानिसहरू बीचको संचारको कुल मात्रा पनि बढ्दै छ, र यो बाहिर जान्छ कि तपाईं "सबै कुरामा विशेषज्ञ" बन्न सक्नुहुन्न।

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

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

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

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

ओलेग: छिटो सार्नुहोस् र चीजहरू तोड्नुहोस्!

माइकल: हो, छिटो जानुहोस्, चीजहरू तोड्नुहोस्, अधिक र धेरै चीजहरू, जबसम्म तपाईं कुनै चीजबाट मर्नु हुँदैन। तपाईंको दृष्टिकोणबाट, औसत विकासकर्ताले अब जोखिम व्यवस्थापन सिक्ने दृष्टिकोण कसरी लिनुपर्छ?

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

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

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

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

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

अर्कोतर्फ, मलाई यो व्यवसाय धेरै मनपर्ने कारण यो हो कि यो जोखिमपूर्ण छ। हामी चीजहरू गर्छौं, र ती चीजहरू जोखिमपूर्ण छन्। तिनीहरूलाई वयस्क दृष्टिकोण चाहिन्छ। केवल उत्साहले तपाईको समस्या समाधान गर्दैन!

वयस्क ईन्जिनियरिङ् सोच

माइकल: बच्चाहरु संग उदाहरण राम्रो छ। यदि म एक साधारण इन्जिनियर हुँ भने, म बच्चा भएकोमा खुशी छु। तर तपाईं कसरी थप वयस्क सोच तिर जानुहुन्छ?

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

ओलेग: सापेक्षिक रूपमा भन्नुपर्दा, यदि तपाइँ कानबन अनुसार काम गर्नुहुन्छ भने, तपाइँले केहि परीक्षणको बाधा पर्दा, तपाइँ त्यहाँ के गर्दै हुनुहुन्थ्यो (उदाहरणका लागि, प्रोग्रामिङ) छोड्न सक्नुहुन्छ र परीक्षकहरूलाई मद्दत गर्न सक्नुहुन्छ।

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

ओलेग: तपाईंको जीवन तपाईंको परियोजना हो, जुन तपाईंले व्यवस्थापन गर्नुहुन्छ।

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

जोखिम व्यवस्थापनमा कसरी प्रवेश गर्ने

ओलेग: के यस क्षेत्रमा कुनै औपचारिक ज्ञान संरचना छ? उदाहरण को लागी, म एक जाभा विकासकर्ता हुँ र शिक्षा द्वारा एक वास्तविक परियोजना प्रबन्धक बिना जोखिम व्यवस्थापन बुझ्न चाहन्छु। म सायद McConnell को "How Much Does A Software Project Cost" पहिले पढ्छु, र त्यसपछि के? पहिलो चरणहरू के हुन्?

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

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

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

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

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

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

सञ्चारको मूल्य

ओलेग: यस्ता बहिर्गमन कर्मचारीहरूलाई विभिन्न कारणले गर्दा महँगो परेको होइन र? आखिर, तिनीहरू कामको सट्टा लगातार च्याट गर्दै छन्!

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

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

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

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

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

माइकल: केही कोड लेख्न जानुहोस्!

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

ओलेग: Misha, तपाईं केहि सोच्दै हुनुहुन्छ।

माइकल: माफ गर्नुहोस्, म सोचमा हराएँ र फ्ल्यासब्याक समातें। यी सबैले मलाई हिजो भएको एउटा रोचक र्‍यालीको याद दिलायो... हिजो धेरै र्यालीहरू थिए... र यो सबै धेरै परिचित लाग्छ!

तलब बिनाको जीवन

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

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

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

उत्तम सल्लाह

माइकल: "उत्तम सल्लाह" मा फर्किदै हुनुहुन्छ, के तपाइँ तपाइँका ग्राहकहरूलाई बारम्बार बताउनुहुन्छ? त्यहाँ 80/20 को बारे मा एक विचार छ, र केहि सल्लाह शायद धेरै पटक दोहोर्याइएको छ।

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

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

मलाई, यो सबै डरलाग्दो देखिन्छ। मानिसहरूले जटिल, घृणित समस्याहरूको सामना गर्छन् र यदि तिनीहरू केवल आफ्नो औंलाहरू पार गर्छन् र राम्रोको आशा गर्छन् भने, "सर्वश्रेष्ठ" वास्तवमा हुनेछ। होइन, यसले त्यसरी काम गर्दैन।

जोखिम व्यवस्थापन अभ्यास गर्नुहोस्!

माइकल: तपाईंको विचारमा, कतिवटा संस्थाहरू जोखिम व्यवस्थापनमा संलग्न छन्?

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

माइकल: र अझै, यी मध्ये कति कम्पनीहरू जोखिम व्यवस्थापनमा संलग्न छन्, पाँच प्रतिशत?

टिम: दुर्भाग्यवश, म यो भन्न घृणा गर्छु, तर यो केहि धेरै नगण्य भाग हो। तर पाँच भन्दा बढी, किनभने त्यहाँ साँच्चै ठूला परियोजनाहरू छन्, र तिनीहरूले कम्तिमा केही नगरेमा तिनीहरू अवस्थित हुन सक्दैनन्। यो कम्तिमा 25% छ भने म धेरै छक्क पर्नेछु भनौं। साना परियोजनाहरूले सामान्यतया त्यस्ता प्रश्नहरूको जवाफ दिन्छन्: यदि समस्याले हामीलाई असर गर्छ भने, हामी यसलाई समाधान गर्नेछौं। त्यसपछि तिनीहरू सफलतापूर्वक समस्यामा पर्छन् र समस्या व्यवस्थापन र संकट व्यवस्थापनमा संलग्न हुन्छन्। जब तपाइँ समस्या समाधान गर्न प्रयास गर्नुहुन्छ र समस्या समाधान हुँदैन, संकट व्यवस्थापनमा स्वागत छ।

हो, म प्रायः सुन्छु, "हामी समस्याहरू उठ्ने बित्तिकै समाधान गर्नेछौं।" पक्कै हामी गर्नेछौं? के हामी साँच्चै निर्णय गर्छौं?

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

माइकल: हो, यो मलाई भयो कि जब जोखिमहरू ट्रिगर गरियो, परियोजनालाई पुन: परिभाषित गरिएको थियो। राम्रो, बिंगो, समस्या हल भयो, अब चिन्ता नगर्नुहोस्!

टिम: रिसेट बटन थिचौं! होइन, यसले त्यसरी काम गर्दैन।

DevOops 2019 मा कीनोट

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

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

माइकल: म पनि वर्षौंदेखि परामर्शमा काम गरिरहेको छु र तपाई के कुरा गर्दै हुनुहुन्छ भन्ने कुरा राम्ररी बुझ्नुहुन्छ।

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

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

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

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

स्रोत: www.habr.com