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

• "मानवी घटक. यशस्वी प्रकल्प आणि संघ" (मूळ पुस्तकाला "पीपलवेअर" म्हणतात)
• "अस्वलांसह वाल्टझिंग: सॉफ्टवेअर प्रकल्पांमध्ये जोखीम व्यवस्थापित करणे"
• "एड्रेनालाईन-वेड आणि नमुन्यांद्वारे झोम्बिफाइड. प्रकल्प कार्यसंघांच्या वर्तनाचे नमुने"

ही सर्व पुस्तके त्यांच्या क्षेत्रातील अभिजात आहेत आणि सहकाऱ्यांसोबत एकत्र लिहिली गेली आहेत अटलांटिक सिस्टम्स गिल्ड. रशियामध्ये, त्याचे सहकारी सर्वात प्रसिद्ध आहेत - टॉम डीमार्को и पीटर ह्रुस्का, ज्यांनी अनेक प्रसिद्ध कामे देखील लिहिली.

टिमला सॉफ्टवेअर डेव्हलपमेंटचा 40 वर्षांचा अनुभव आहे; 1975 मध्ये (ज्यांनी हे हॅब्रापोस्ट लिहिले त्यापैकी कोणीही या वर्षी जन्माला आले नाही), टिम आधीच Yourdon Inc चे कार्यकारी उपाध्यक्ष होते. तो आता अधूनमधून भेटी देऊन सल्लामसलत करण्यात, शिकवण्यात आणि लेखन करण्यात आपला वेळ घालवतो अहवालांसह जगभरातील परिषदा.

आम्ही विशेषत: हॅब्रसाठी टिम लिस्टरची मुलाखत घेतली. तो DevOops 2019 परिषद उघडणार आहे आणि आमच्याकडे पुस्तकांबद्दल आणि बरेच काही प्रश्न आहेत. कॉन्फरन्स प्रोग्राम कमिटीकडून मिखाईल ड्रुझिनिन आणि ओलेग चिरुखिन यांनी मुलाखत घेतली आहे.

मायकेल: तुम्ही आता काय करत आहात याबद्दल काही शब्द बोलू शकाल का?

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

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

बरेच काम केले गेले होते, परंतु ते अजूनही अशा ठिकाणी पोहोचले जेथे पूर्वी त्यांनी अर्थ किंवा गरज नसताना आठवडे आणि महिने वारंवार चाचण्या घालवल्या, कारण कागदावर वर्णन केलेल्या त्यांच्या आवश्यकता ज्या सिस्टम तयार केल्या गेल्या त्या वास्तविक आवश्यकतांशी जुळत नाहीत. FDA ने त्यांना प्रत्येक वेळी सांगितले: तुमच्या गरजा बदलल्या आहेत, आता तुम्हाला सुरवातीपासून सर्वकाही तपासण्याची आवश्यकता आहे. संपूर्ण उत्पादनाची पूर्ण तपासणी एंटरप्राइझला मारून टाकत होती.

तर, अशी अद्भुत कार्ये आहेत जेव्हा आपण एखाद्या मनोरंजक गोष्टीच्या अगदी सुरूवातीस स्वतःला शोधता आणि अगदी पहिल्या क्रिया गेमचे पुढील नियम सेट करतात. जर तुम्ही हे सुनिश्चित केले की ही सुरुवातीची क्रिया व्यवस्थापकीय आणि तांत्रिक दोन्ही दृष्टीकोनातून चांगले कार्य करण्यास सुरुवात करते, तर तुम्हाला एक उत्तम प्रकल्प मिळण्याची शक्यता आहे. पण जर हा भाग रुळावरून गेला असेल आणि कुठेतरी चुकला असेल, जर तुम्हाला मूलभूत करार सापडले नाहीत तर... नाही, तुमचा प्रकल्प अयशस्वी होईल असे नाही. परंतु आपण यापुढे असे म्हणू शकणार नाही: "आम्ही उत्कृष्ट केले, आम्ही सर्वकाही खरोखर प्रभावीपणे केले." क्लायंटशी संवाद साधताना मी या गोष्टी करतो.

मायकेल: म्हणजेच, तुम्ही प्रोजेक्ट लाँच करता, काही प्रकारचे किकऑफ करता आणि रेल्वे योग्य दिशेने जात आहे का ते तपासता?

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

19 वर्षे चपळ

मायकेल: चपळ मध्ये, लोक अनेकदा आगाऊ काहीही परिभाषित न करण्याचा प्रयत्न करतात, परंतु शक्य तितक्या उशीरा निर्णय घेण्याचा प्रयत्न करतात, म्हणतात: आम्ही खूप मोठे आहोत, मी एकंदर आर्किटेक्चरबद्दल विचार करणार नाही. मी इतर अनेक गोष्टींबद्दल विचार करणार नाही; त्याऐवजी, मी आत्ताच ग्राहकांना कार्य करेल असे काहीतरी वितरीत करेन.

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

त्यामुळे “आम्ही चपळ आहोत, ग्राहक स्वतःच आम्हाला सांगेल की त्याला काय मिळवायचे आहे” - ही अतिशय भोळी आहे. ग्राहकांना त्यांना काय हवे आहे हे देखील माहित नसते आणि त्याहूनही अधिक म्हणजे त्यांना काय मिळू शकते हे माहित नसते. काही लोक तर्क म्हणून ऐतिहासिक उदाहरणे देऊ लागतील, हे मी आधीच पाहिले आहे. पण तांत्रिकदृष्ट्या प्रगत लोक सहसा असे म्हणत नाहीत. ते म्हणतात: "हे 2019 आहे, आमच्याकडे या संधी आहेत आणि आम्ही या गोष्टींकडे पाहण्याचा दृष्टिकोन पूर्णपणे बदलू शकतो!" विद्यमान सोल्यूशन्सची नक्कल करण्याऐवजी, त्यांना थोडे सुंदर आणि अधिक कंघी बनवण्याऐवजी, कधीकधी तुम्हाला बाहेर जाणे आवश्यक आहे आणि असे म्हणणे आवश्यक आहे: "आम्ही येथे काय करण्याचा प्रयत्न करीत आहोत ते पूर्णपणे पुन्हा शोधूया!"

आणि मला वाटत नाही की बहुतेक ग्राहक अशा प्रकारे समस्येबद्दल विचार करू शकतात. ते फक्त तेच पाहतात जे त्यांच्याकडे आधीपासून आहे, एवढेच. त्यानंतर ते “हे थोडे सोपे करूया” किंवा ते सहसा जे काही बोलतात अशा विनंत्या घेऊन येतात. पण आम्ही वेटर किंवा वेट्रेस नाही, त्यामुळे कितीही मूर्खपणा आला तरी आम्ही ऑर्डर घेऊ शकतो आणि मग स्वयंपाकघरात बेक करू शकतो. आम्ही त्यांचे मार्गदर्शक आहोत. आम्हाला त्यांचे डोळे उघडावे लागतील आणि म्हणावे: अहो, आमच्याकडे येथे नवीन संधी आहेत! तुमच्या व्यवसायाचा हा भाग आम्ही खरोखरच बदलू शकतो याची तुम्हाला जाणीव आहे का? चपळाईची एक समस्या अशी आहे की ती संधी काय आहे, समस्या काय आहे, आपल्याला काय करण्याची आवश्यकता आहे, या विशिष्ट परिस्थितीसाठी कोणते उपलब्ध तंत्रज्ञान सर्वात योग्य आहे याची जाणीव काढून टाकते.

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

ओलेग: तुम्ही चपळ जाहीरनाम्याचा उल्लेख केला. या समस्येचे आधुनिक आकलन लक्षात घेऊन आम्हाला ते कसे तरी अपडेट करणे किंवा सुधारणे आवश्यक आहे का?

टिम: मी त्याला हात लावणार नाही. माझ्या मते हा एक मोठा ऐतिहासिक दस्तऐवज आहे. म्हणजे, तो आहे तो आहे. तो 19 वर्षांचा होत आहे, तो म्हातारा झाला आहे, पण त्याच्या काळात त्याने क्रांती केली. त्याने काय चांगले केले की त्याने प्रतिक्रिया दिली आणि लोक त्याच्याबद्दल कुजबुजू लागले. आपण, बहुधा, 2001 मध्ये अद्याप उद्योगात काम करत नव्हते, परंतु नंतर प्रत्येकाने प्रक्रियेनुसार कार्य केले. सॉफ्टवेअर अभियांत्रिकी संस्था, सॉफ्टवेअर पूर्णता मॉडेलचे पाच स्तर (CMMI). सखोल पुरातन काळातील अशा दंतकथा तुम्हाला काही सांगतात की नाही हे मला माहित नाही, परंतु नंतर ही एक प्रगती होती. सुरुवातीला, लोकांचा असा विश्वास होता की जर प्रक्रिया योग्यरित्या सेट केल्या गेल्या असतील तर समस्या स्वतःच अदृश्य होतील. आणि मग जाहीरनामा येतो आणि म्हणतो: "नाही, नाही, नाही - आम्ही लोकांवर आधारित असू, प्रक्रियेवर नाही." आम्ही सॉफ्टवेअर डेव्हलपमेंटचे मास्टर आहोत. आदर्श प्रक्रिया ही एक मृगजळ आहे हे आपण समजतो; तसे होत नाही. प्रकल्पांमध्ये खूप वैशिष्ठ्य आहे, सर्व प्रकल्पांसाठी एकच परिपूर्ण प्रक्रियेच्या कल्पनेला काही अर्थ नाही. प्रत्येक गोष्टीवर एकच उपाय आहे असा दावा करण्यासाठी समस्या खूप गुंतागुंतीच्या आहेत (नमस्कार, निर्वाण).

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

लोकवेअर: 30 वर्षांनंतर

ओलेग: पीपलवेअर ही एक क्रांती तसेच जाहीरनामा होती का?

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

टीमने मोठ्या संख्येने भाषणे दिली असूनही, त्यापैकी फारच कमी यूट्यूबवर पोस्ट केल्या आहेत. तुम्ही 2007 चा “The Return of Peopleware” हा अहवाल पाहू शकता. गुणवत्ता, अर्थातच, इच्छित होण्यासाठी बरेच काही सोडते.

मायकेल: पुस्तक प्रकाशित झाल्यापासून गेल्या 30 वर्षांत काही बदल झाला आहे का?

टिम: तुम्ही याकडे अनेक वेगवेगळ्या कोनातून पाहू शकता. समाजशास्त्रीयदृष्ट्या... एकेकाळी, सोप्या काळात, तुम्ही आणि तुमची टीम एकाच ऑफिसमध्ये बसता. तुम्ही दररोज जवळ असू शकता, एकत्र कॉफी पिऊ शकता आणि कामावर चर्चा करू शकता. खरोखर काय बदलले आहे ते म्हणजे संघ आता भौगोलिकदृष्ट्या, वेगवेगळ्या देशांमध्ये आणि टाइम झोनमध्ये वितरित केले जाऊ शकतात, परंतु तरीही ते त्याच समस्येवर काम करत आहेत आणि यामुळे जटिलतेचा एक संपूर्ण नवीन स्तर जोडला जातो. हे जुने-शाळेचे वाटू शकते, परंतु समोरासमोर संप्रेषण करण्यासारखे काहीही नाही जेथे तुम्ही सर्व एकत्र आहात, एकत्र काम करत आहात आणि तुम्ही सहकाऱ्याकडे जाऊ शकता आणि म्हणू शकता, मी काय शोधले ते पहा, तुम्हाला हे कसे आवडते? समोरासमोर संभाषणे अनौपचारिक संप्रेषणात संक्रमण करण्याचा एक द्रुत मार्ग प्रदान करतात आणि मला वाटते की चपळ उत्साही लोकांना देखील ते आवडले पाहिजे. आणि मी देखील चिंतित आहे कारण प्रत्यक्षात जग खूप लहान झाले आहे आणि आता हे सर्व वितरित संघांनी व्यापलेले आहे आणि हे सर्व खूप गुंतागुंतीचे आहे.

आम्ही सर्व DevOps मध्ये राहतो

मायकेल: जरी कॉन्फरन्स प्रोग्राम कमिटीच्या दृष्टिकोनातून, आमच्याकडे कॅलिफोर्निया, न्यूयॉर्क, युरोप, रशियामध्ये लोक आहेत... सिंगापूरमध्ये अद्याप कोणीही नाही. भूगोलातील फरक बराच मोठा आहे आणि लोक आणखी पसरू लागले आहेत. आम्ही विकासाबद्दल बोलत असल्यास, तुम्ही आम्हाला डेव्हॉप्स आणि संघांमधील अडथळे तोडण्याबद्दल अधिक सांगू शकता? प्रत्येकजण आपापल्या बंकरमध्ये बसला आहे, आणि आता बंकर कोसळत आहेत, अशी एक संकल्पना आहे, या साधर्म्याबद्दल तुम्हाला काय वाटते?

टिम: मला असे वाटते की अलीकडील तांत्रिक प्रगतीच्या प्रकाशात, डेव्हॉप्सला खूप महत्त्व आहे. पूर्वी, तुमच्याकडे डेव्हलपर आणि प्रशासकांची टीम होती, त्यांनी काम केले, काम केले, काम केले आणि काही क्षणी एक गोष्ट दिसली ज्यासह तुम्ही प्रशासकांकडे येऊ शकता आणि उत्पादनासाठी रोल आउट करू शकता. आणि येथे बंकरबद्दल संभाषण सुरू झाले, कारण प्रशासक एक प्रकारचे सहयोगी आहेत, कमीतकमी शत्रू नाहीत, परंतु आपण त्यांच्याशी तेव्हाच बोललात जेव्हा सर्वकाही उत्पादनासाठी तयार होते. तुम्ही त्यांच्याकडे काही घेऊन गेलात आणि म्हणाल: आमच्याकडे कोणता अॅप्लिकेशन आहे ते बघा, पण तुम्ही हा अॅप्लिकेशन रोल आउट करू शकता का? आणि आता वितरणाची संपूर्ण संकल्पना चांगल्यासाठी बदलली आहे. म्हणजे, अशी कल्पना होती की आपण बदलांना त्वरीत पुढे ढकलू शकता. आम्ही फ्लाय वर उत्पादने अद्यतनित करू शकता. जेव्हा माझ्या लॅपटॉपवर फायरफॉक्स पॉप अप होतो आणि म्हणतो, तेव्हा मी नेहमी हसतो, अहो, आम्ही तुमचा फायरफॉक्स बॅकग्राउंडमध्ये अपडेट केला आहे आणि तुमच्याकडे एक मिनिट होताच, तुम्ही इथे क्लिक करायला हरकत नाही आणि आम्ही तुम्हाला नवीनतम प्रकाशन देऊ. आणि मी असे होते, "अरे हो, बाळा!" मी झोपेत असताना, ते माझ्या संगणकावर मला नवीन प्रकाशन देण्याचे काम करत होते. हे आश्चर्यकारक, अविश्वसनीय आहे.

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

मायकेल: devops ची संपूर्ण कल्पना अर्थपूर्ण विकास शक्य तितक्या लवकर वितरित करणे आहे. मी पाहतो की जग अधिकाधिक वेगवान होऊ लागले आहे. अशा प्रवेगांशी कसे जुळवून घ्यावे? दहा वर्षांपूर्वी हे अस्तित्वात नव्हते!

टिम: अर्थात, प्रत्येकाला अधिकाधिक कार्यक्षमता हवी असते. हलविण्याची गरज नाही, फक्त अधिक ढीग करा. काहीवेळा तुम्हाला काहीही उपयुक्त आणण्यासाठी पुढील वाढीव अपडेटसाठी वेग कमी करावा लागतो - आणि ते पूर्णपणे सामान्य आहे.

आपण धावणे, धावणे, धावणे आवश्यक आहे ही कल्पना सर्वोत्तम नाही. कोणालाही त्यांचे जीवन असे जगायचे आहे हे संभव नाही. मला प्रसूतीची लय प्रोजेक्टची स्वतःची लय सेट करायची आहे. जर तुम्ही फक्त लहान, तुलनेने निरर्थक गोष्टींचा प्रवाह तयार केला तर त्या सर्वांचा काही अर्थ नाही. शक्य तितक्या लवकर गोष्टी सोडवण्याचा निर्विकारपणे प्रयत्न करण्याऐवजी, मुख्य विकासक आणि उत्पादन आणि प्रकल्प व्यवस्थापक यांच्याशी चर्चा करणे योग्य आहे ते म्हणजे धोरण. यालाही काही अर्थ आहे का?

नमुने आणि अँटीपॅटर्न

ओलेग: तुम्ही सहसा पॅटर्न आणि अँटीपॅटर्नबद्दल बोलता आणि हा प्रकल्पांच्या जीवन आणि मृत्यूमधील फरक आहे. आणि आता, डेव्हॉप्स आपल्या आयुष्यात फुटतात. त्याचे स्वतःचे असे कोणतेही पॅटर्न आणि अँटी-पॅटर्न आहेत जे प्रकल्पाला जागेवरच मारून टाकू शकतात?

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

आम्ही आमच्या सोबत्यांसोबत चर्चा करत होतो की हे वर्ष वर्धापन दिन आहे, लोकांना चंद्रावर उतरून पन्नास वर्षे झाली आहेत. हे 1969 मधील होते. ज्या तंत्रज्ञानाने लोकांना तेथे पोहोचण्यास मदत केली ते 1969 चे तंत्रज्ञान नसून 1960 किंवा 62 मधील तंत्रज्ञान आहे, कारण NASA ला तेच वापरायचे होते जे विश्वसनीयतेचे चांगले पुरावे आहेत. आणि म्हणून आपण ते पहा आणि समजून घ्या - होय, आणि ते खरे होते! आता, नाही, नाही, परंतु आपण तंत्रज्ञानाच्या समस्येत अडकता कारण सर्व काही खूप जोरात ढकलले जाते, सर्व क्रॅकमधून विकले जाते. लोक सर्वत्र ओरडत आहेत: "बघा, काय गोष्ट आहे, ही सर्वात नवीन गोष्ट आहे, जगातील सर्वात सुंदर गोष्ट आहे, सर्वांसाठी योग्य आहे!" बरं, तेच आहे... सहसा हे सर्व फक्त फसवणूक होते आणि मग ते सर्व फेकून द्यावे लागते. कदाचित हे सर्व आहे कारण मी आधीच एक म्हातारा माणूस आहे आणि अशा गोष्टींकडे मोठ्या संशयाने पाहतो, जेव्हा लोक संपतात आणि म्हणतात की त्यांना सर्वोत्तम तंत्रज्ञान तयार करण्याचा एकमेव, सर्वात योग्य मार्ग सापडला आहे. या क्षणी, माझ्या आत एक आवाज उठतो जो म्हणतो: "काय गोंधळ आहे!"

मायकेल: खरंच, आम्ही पुढच्या चांदीच्या बुलेटबद्दल किती वेळा ऐकले आहे?

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

मायकेल: होय, मुख्य "जीवनाचा प्रश्न, विश्व आणि सर्व काही": हे तंत्रज्ञान किंवा दृष्टीकोन आपल्या परिस्थितीसाठी योग्य आहे की नाही?

टिम: या प्रश्नावर आधीच तंत्रज्ञान गटाशी चर्चा केली जाऊ शकते. कदाचित काही सल्लागार देखील आणा. प्रकल्पावर एक नजर टाका आणि समजून घ्या - आता आपण पूर्वीपेक्षा चांगले आणि उपयुक्त काहीतरी करू का? कदाचित ते फिट होईल, कदाचित नाही. परंतु सर्वात महत्त्वाचे म्हणजे, असा निर्णय बाय डीफॉल्ट घेऊ नका, कारण कोणीतरी स्पष्ट केले आहे: “आम्हाला ब्लॉकचेनची नितांत गरज आहे! मी विमानातल्या एका मासिकात त्याच्याबद्दल वाचलं होतं!” गंभीरपणे? हे मजेदार देखील नाही.

पौराणिक "डिव्हॉप्स इंजिनियर"

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

टिम: तर-तसे. त्यांना लगेच या संज्ञेचे काही स्पष्टीकरण द्या. ते अद्वितीय करण्यासाठी काहीतरी. जोपर्यंत ते सिद्ध करत नाहीत की यासारख्या रिक्त पदामागे कौशल्यांचा काही अद्वितीय संयोजन आहे, तोपर्यंत मी ते विकत घेणार नाही! म्हणजे, बरं, आमच्याकडे नोकरीचे शीर्षक आहे, “deops engineer,” एक मनोरंजक शीर्षक, होय, पुढे काय? नोकरी शीर्षके साधारणपणे एक अतिशय मनोरंजक गोष्ट आहे. चला "विकासक" म्हणू - तरीही ते काय आहे? भिन्न संस्था म्हणजे पूर्णपणे भिन्न गोष्टी. काही कंपन्यांमध्ये, उच्च-गुणवत्तेचे प्रोग्रामर अशा चाचण्या लिहितात ज्या इतर कंपन्यांमधील विशेष व्यावसायिक परीक्षकांनी लिहिलेल्या चाचण्यांपेक्षा अधिक अर्थपूर्ण असतात. मग काय, ते आता प्रोग्रामर किंवा परीक्षक आहेत?

होय, आमच्याकडे नोकरीची शीर्षके आहेत, परंतु जर तुम्ही प्रश्न विचारले तर शेवटी असे दिसून येते की आम्ही सर्व समस्या सोडवणारे आहोत. आम्ही समाधान साधक आहोत, आणि काहींमध्ये काही तांत्रिक कौशल्ये आहेत आणि काहींमध्ये वेगळी आहेत. तुम्ही अशा वातावरणात रहात असाल जिथे DevOps प्रवेश केला आहे, तुम्ही विकास आणि प्रशासनाच्या एकत्रीकरणात गुंतलेले आहात आणि या क्रियाकलापाचा काही महत्त्वाचा उद्देश आहे. पण तुम्ही नेमके काय करता आणि तुम्ही कशासाठी जबाबदार आहात, असे विचारले तर असे दिसून येते की या सर्व गोष्टी लोक अनादी काळापासून करत आले आहेत. "मी आर्किटेक्चरसाठी जबाबदार आहे", "मी डेटाबेससाठी जबाबदार आहे" आणि असेच, जे काही, तुम्ही पहा - हे सर्व "डेव्हॉप्स" च्या आधी होते.

जेव्हा कोणी मला त्यांच्या नोकरीचे शीर्षक सांगते तेव्हा मी फारसे ऐकत नाही. तो खरोखर कशासाठी जबाबदार आहे हे त्याला सांगणे चांगले आहे, यामुळे आम्हाला समस्या अधिक चांगल्या प्रकारे समजू शकेल. माझे आवडते उदाहरण म्हणजे जेव्हा एखादी व्यक्ती “प्रकल्प व्यवस्थापक” असल्याचा दावा करते. काय? याचा काही अर्थ नाही, तुम्ही काय करता हे मला अजूनही कळत नाही. प्रोजेक्ट मॅनेजर हा डेव्हलपर असू शकतो, चार लोकांच्या टीमचा लीडर, कोड लिहितो, काम करतो, जो टीम लीड बनला आहे, ज्याला लोक स्वतःमध्ये नेता म्हणून ओळखतात. आणि तसेच, प्रोजेक्ट मॅनेजर असा मॅनेजर असू शकतो जो प्रोजेक्टवर सहाशे लोकांना मॅनेज करतो, इतर मॅनेजर्स मॅनेज करतो, शेड्यूल काढण्यासाठी आणि बजेटचे नियोजन करण्यासाठी जबाबदार असतो, एवढेच. ही दोन पूर्णपणे भिन्न जगे आहेत! पण त्यांचे नोकरीचे शीर्षक सारखेच वाटते.

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

आणि तसे, मी अशा दृष्टिकोनाचा एक मोठा समर्थक आहे ज्यामध्ये या प्रकारचे कौशल्य वेगळे करणे चांगले कार्य करते. जिथे तंत्रज्ञ त्यांचे करिअर त्यांना हवे तसे वाढवू शकतात. तथापि, मला अजूनही अशा संस्था दिसतात जिथे तंत्रज्ञाने तक्रार करतात: मला प्रकल्प व्यवस्थापनात जावे लागेल कारण या कंपनीत हा एकमेव मार्ग आहे. कधीकधी यामुळे भयानक परिणाम होतात. सर्वोत्कृष्ट तंत्रज्ञ अजिबात चांगले व्यवस्थापक नसतात आणि सर्वोत्तम व्यवस्थापक तंत्रज्ञान हाताळू शकत नाहीत. याविषयी प्रामाणिक राहू या.

मला आता याला खूप मागणी दिसत आहे. जर तुम्ही तंत्रज्ञ असाल तर तुमची कंपनी तुम्हाला मदत करू शकते, परंतु याची पर्वा न करता, तुम्हाला तुमचा स्वतःचा करिअरचा मार्ग शोधण्याची गरज आहे कारण तंत्रज्ञान सतत बदलत राहते आणि त्यासोबत तुम्हाला स्वतःला नव्याने शोधण्याची गरज आहे! अवघ्या वीस वर्षांत तंत्रज्ञान किमान पाच वेळा बदलू शकते. तंत्रज्ञान ही एक विचित्र गोष्ट आहे...

"सर्वकाही तज्ञ"

मायकेल: तंत्रज्ञानाच्या बदलाच्या एवढ्या वेगाला लोक कसे तोंड देऊ शकतात? त्यांची जटिलता वाढत आहे, त्यांची संख्या वाढत आहे, लोकांमधील संवादाचे एकूण प्रमाण देखील वाढत आहे आणि असे दिसून आले की आपण "प्रत्येक गोष्टीत तज्ञ" होऊ शकत नाही.

टिम: बरोबर! जर तुम्ही तंत्रज्ञानामध्ये काम करत असाल तर, होय, तुम्हाला निश्चितपणे काहीतरी विशिष्ट निवडण्याची आणि त्यामध्ये सखोल अभ्यास करण्याची आवश्यकता आहे. तुमच्या संस्थेला उपयुक्त वाटणारे काही तंत्रज्ञान (आणि कदाचित प्रत्यक्षात उपयोगी पडेल). आणि जर तुम्हाला यापुढे यात स्वारस्य नसेल - तर मी असे म्हणेन यावर माझा कधीच विश्वास बसला नसता - बरं, कदाचित तुम्ही इतर एखाद्या संस्थेकडे जावे जिथे तंत्रज्ञान अधिक मनोरंजक किंवा अभ्यासासाठी अधिक सोयीस्कर असेल.

पण सर्वसाधारणपणे, होय, तुम्ही बरोबर आहात. तंत्रज्ञान एकाच वेळी सर्व दिशांनी वाढत आहे; कोणीही असे म्हणू शकत नाही की "अस्तित्वात असलेल्या सर्व तंत्रज्ञानामध्ये मी एक तज्ञ तंत्रज्ञ आहे." दुसरीकडे, असे स्पंज लोक आहेत जे अक्षरशः तांत्रिक ज्ञान आत्मसात करतात आणि त्याबद्दल वेडे आहेत. मी अशा काही लोकांना पाहिले आहे, ते अक्षरशः श्वास घेतात आणि जगतात, त्यांच्याशी बोलणे उपयुक्त आणि मनोरंजक आहे. ते केवळ संस्थेमध्ये काय घडत आहे याचा अभ्यास करत नाहीत, परंतु सर्वसाधारणपणे ते त्याबद्दल बोलतात, ते खरोखर छान तंत्रज्ञ देखील आहेत, ते खूप जागरूक आणि हेतूपूर्ण आहेत. त्यांचे मुख्य काम काय आहे याची पर्वा न करता ते फक्त लाटेच्या शिखरावर राहण्याचा प्रयत्न करतात, कारण तंत्रज्ञानाची चळवळ, तंत्रज्ञानाचा प्रचार ही त्यांची आवड आहे. जर तुम्ही अचानक अशा व्यक्तीला भेटलात तर तुम्ही त्याच्यासोबत जेवायला जावे आणि दुपारच्या जेवणात विविध मस्त गोष्टींवर चर्चा करावी. मला वाटते की कोणत्याही संस्थेला किमान अशा दोन-तीन लोकांची गरज असते.

जोखीम आणि अनिश्चितता

मायकेल: आदरणीय अभियंते, होय. आमच्याकडे वेळ असताना जोखीम व्यवस्थापनाला स्पर्श करूया. आम्ही या मुलाखतीची सुरुवात वैद्यकीय सॉफ्टवेअरच्या चर्चेने केली आहे, जिथे त्रुटींचे गंभीर परिणाम होऊ शकतात. मग आम्ही चंद्र कार्यक्रमाबद्दल बोललो, जिथे त्रुटीची किंमत लाखो डॉलर्स आहे आणि कदाचित अनेक मानवी जीवने आहेत. पण आता मला इंडस्ट्रीत उलटी हालचाल दिसत आहे, लोक जोखमींचा विचार करत नाहीत, त्यांचा अंदाज घेण्याचा प्रयत्न करत नाहीत, त्यांचे निरीक्षणही करत नाहीत.

ओलेग: जलद हलवा आणि गोष्टी खंडित करा!

मायकेल: होय, वेगाने हालचाल करा, गोष्टी खंडित करा, अधिकाधिक गोष्टी करा, जोपर्यंत तुम्ही एखाद्या गोष्टीपासून मरेपर्यंत. तुमच्या दृष्टिकोनातून, आता सरासरी विकसकाने जोखीम व्यवस्थापन शिकण्याचा दृष्टिकोन कसा ठेवावा?

टिम: येथे दोन गोष्टींमध्ये एक रेषा काढू: जोखीम आणि अनिश्चितता. या वेगवेगळ्या गोष्टी आहेत. एखाद्या निश्चित उत्तरापर्यंत पोहोचण्यासाठी तुमच्याकडे वेळेच्या कोणत्याही वेळी पुरेसा डेटा नसतो तेव्हा अनिश्चितता उद्भवते. उदाहरणार्थ, एखाद्या प्रकल्पाच्या अगदी सुरुवातीच्या टप्प्यावर, जर कोणी तुम्हाला विचारले की "तुम्ही काम कधी पूर्ण कराल," जर तुम्ही प्रामाणिक व्यक्ती असाल तर तुम्ही म्हणाल, "मला कल्पना नाही." तुम्हाला माहीत नाही, आणि ते ठीक आहे. आपण अद्याप समस्यांचा अभ्यास केलेला नाही आणि संघाशी परिचित नाही, आपल्याला त्यांचे कौशल्य माहित नाही, इत्यादी. ही अनिश्चितता आहे.

संभाव्य समस्या आधीच ओळखल्या जाऊ शकतात तेव्हा जोखीम उद्भवतात. अशा प्रकारची गोष्ट घडू शकते, त्याची संभाव्यता शून्यापेक्षा जास्त आहे, परंतु शंभर टक्क्यांपेक्षा कमी आहे, कुठेतरी दरम्यान. यामुळे, विलंब आणि अनावश्यक कामापासून काहीही होऊ शकते, परंतु प्रकल्पासाठी घातक परिणाम देखील होऊ शकतात. परिणाम, जेव्हा तुम्ही म्हणता - मित्रांनो, चला आमच्या छत्र्या फोल्ड करू आणि समुद्रकिनारा सोडू, आम्ही ते कधीही पूर्ण करणार नाही, हे सर्व संपले आहे. आम्ही गृहित धरले की ही गोष्ट कार्य करेल, परंतु ते अजिबात कार्य करत नाही, थांबण्याची वेळ आली आहे. या परिस्थिती आहेत.

बर्‍याचदा, समस्या आत्ताच उद्भवत असताना, जेव्हा ते आधीच उद्भवलेले असतात तेव्हा त्यांचे निराकरण करणे सर्वात सोपे असते. परंतु जेव्हा एखादी समस्या तुमच्या समोर असते, तेव्हा तुम्ही जोखीम व्यवस्थापन करत नाही - तुम्ही समस्या सोडवणे, संकट व्यवस्थापन करत आहात. तुम्ही लीड डेव्हलपर किंवा मॅनेजर असाल, तर तुम्ही विचार करत असाल की काय होऊ शकते ज्यामुळे विलंब, वाया जाणारा वेळ, अनावश्यक खर्च किंवा संपूर्ण प्रकल्प कोसळेल? काय आम्हाला थांबवून पुन्हा सुरुवात करेल? या सर्व गोष्टी चालतात तेव्हा आपण त्यांचे काय करणार? एक साधे उत्तर आहे जे बहुतेक परिस्थितींसाठी वैध आहे: जोखमीपासून दूर जाऊ नका, त्यांच्यावर कार्य करा. तुम्ही एखाद्या जोखमीच्या परिस्थितीचे निराकरण कसे करू शकता, ते कमी करू शकता, समस्येपासून ते कशात तरी बदलू शकता ते पहा. असे म्हणण्याऐवजी: ठीक आहे, जसे की समस्या उद्भवतील तसे आम्ही सोडवू.

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

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

दुसरीकडे, मला हा व्यवसाय इतका आवडण्याचे कारण म्हणजे तो धोकादायक आहे. आम्ही गोष्टी करतो आणि त्या गोष्टी धोकादायक असतात. त्यांना प्रौढ दृष्टीकोन आवश्यक आहे. केवळ उत्साहाने तुमचे प्रश्न सुटणार नाहीत!

प्रौढ अभियांत्रिकी विचार

मायकेल: मुलांचे उदाहरण चांगले आहे. जर मी एक सामान्य इंजिनियर आहे, तर मला लहान मुलाचा आनंद आहे. पण आपण अधिक प्रौढ विचारांकडे कसे जाल?

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

ओलेग: तुलनेने सांगायचे तर, तुम्ही कानबननुसार काम केल्यास, जेव्हा तुम्ही काही चाचणीच्या अडथळ्याला सामोरे जाल, तेव्हा तुम्ही तेथे जे करत होता ते तुम्ही सोडू शकता (उदाहरणार्थ, प्रोग्रामिंग) आणि परीक्षकांना मदत करू शकता.

टिम: नक्की. मला वाटते सर्वोत्तम तंत्रज्ञ, जर तुम्ही त्यांच्याकडे बारकाईने पाहिले तर ते त्यांचे स्वतःचे व्यवस्थापक आहेत. मी हे कसे तयार करू शकतो ...

ओलेग: तुमचे जीवन हा तुमचा प्रकल्प आहे, जो तुम्ही व्यवस्थापित करता.

टिम: नक्की! म्हणजे, तुम्ही जबाबदारी घेता, तुम्हाला समस्या समजते आणि जेव्हा तुम्ही पाहता की तुमच्या निर्णयांचा त्यांच्या कामावर परिणाम होऊ शकतो, तेव्हा तुम्ही लोकांशी संपर्क साधता. हे फक्त तुमच्या डेस्कवर बसणे, तुमचे काम करणे आणि तुमच्या आजूबाजूला काय चालले आहे हे लक्षात न घेणे असे नाही. नाही नाही नाही. तसे, चपळ बद्दल सर्वात चांगली गोष्ट म्हणजे त्यांनी लहान स्प्रिंट प्रस्तावित केले, कारण अशा प्रकारे सर्व सहभागींची स्थिती स्पष्टपणे पाहण्यायोग्य आहे, ते सर्व एकत्र पाहू शकतात. आम्ही रोज एकमेकांबद्दल बोलतो.

जोखीम व्यवस्थापनात कसे जायचे

ओलेग: या क्षेत्रात कोणतीही औपचारिक ज्ञान रचना आहे का? उदाहरणार्थ, मी जावा डेव्हलपर आहे आणि मी शिक्षणाद्वारे वास्तविक प्रकल्प व्यवस्थापक न बनता जोखीम व्यवस्थापन समजून घेऊ इच्छितो. मी कदाचित प्रथम McConnell चे "How Much Does a Software Project Cost" वाचेन आणि मग काय? पहिली पायरी कोणती?

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

ओलेग: आलेखावरील आकड्यांपेक्षा लोक आनंदाची अधिक काळजी कशी घेतात याबद्दल तुम्ही पुस्तके आणि मुलाखतींमध्ये बोलले आहे. दुसरीकडे, जेव्हा तुम्ही संघाला सांगता: आम्ही डेव्हॉप्सकडे जात आहोत, आणि आता प्रोग्रामरने सतत संवाद साधला पाहिजे, हे त्याच्या आराम क्षेत्राच्या बाहेर असू शकते. आणि या क्षणी तो, असे म्हणू शकतो की, खूप दुःखी असेल. या परिस्थितीत काय करावे?

टिम: मला नक्की काय करावं हे समजत नाही. जर एखादा विकासक खूप वेगळा असेल, तर ते काम का केले जात आहे हे प्रथमतः पाहत नाही, ते फक्त त्यांच्या कामाचा भाग पाहतात आणि त्यांना मी "संदर्भ" म्हणतो त्यामध्ये प्रवेश करणे आवश्यक आहे. त्याला सर्वकाही एकत्र कसे जोडलेले आहे हे शोधण्याची आवश्यकता आहे. आणि अर्थातच, माझा अर्थ औपचारिक सादरीकरणे किंवा तत्सम काहीही नाही. मी या वस्तुस्थितीबद्दल बोलत आहे की तुम्हाला संपूर्ण कामाबद्दल सहकाऱ्यांशी संवाद साधण्याची आवश्यकता आहे, आणि केवळ त्या भागाबद्दल नाही ज्यासाठी तुम्ही जबाबदार आहात. येथूनच तुम्ही कल्पनांवर चर्चा सुरू करू शकता, तुमचे कार्य एकत्र बसण्यासाठी सामायिक करार आणि एकत्रित समस्या कशी हाताळायची.

त्यांना जुळवून घेण्यास मदत करण्यासाठी, त्यांना अनेकदा तंत्रज्ञांना प्रशिक्षणासाठी पाठवायचे असते आणि ते प्रशिक्षणावर चर्चा करतात. माझ्या एका मित्राला असे म्हणणे आवडते की प्रशिक्षण कुत्र्यांसाठी आहे. लोकांसाठी प्रशिक्षण आहे. विकसक म्हणून शिकण्याबद्दलची एक उत्तम गोष्ट म्हणजे तुमच्या समवयस्कांशी संवाद साधणे. जर एखादी व्यक्ती एखाद्या गोष्टीत खरोखरच चांगली असेल, तर तुम्ही त्यांना काम करताना पहावे किंवा त्यांच्याशी त्यांच्या कामाबद्दल किंवा कशाबद्दल बोलले पाहिजे. काही पारंपारिक केंट बेक सतत अत्यंत प्रोग्रामिंगबद्दल बोलतात. हे मजेदार आहे कारण XP ही एक सोपी कल्पना आहे, परंतु त्यामुळे बर्याच समस्या उद्भवतात. काहींसाठी, XP करणे म्हणजे मित्रांसमोर नग्न होण्यास भाग पाडण्यासारखे आहे. मी काय करतो ते ते पाहतील! ते माझे सहकारी आहेत, ते नुसते पाहणार नाहीत, तर समजूनही घेतील! भयानक! काही लोक गंभीरपणे चिंताग्रस्त होऊ लागले आहेत. पण जेव्हा तुम्हाला कळते की हा शिकण्याचा अंतिम मार्ग आहे, तेव्हा सर्वकाही बदलते. तुम्ही लोकांशी जवळून काम करता आणि काही लोक हा विषय तुमच्यापेक्षा जास्त चांगल्या प्रकारे समजतात.

मायकेल: परंतु हे सर्व तुम्हाला तुमच्या कम्फर्ट झोनमधून बाहेर पडण्यास भाग पाडते. एक अभियंता म्हणून, तुम्हाला तुमच्या कम्फर्ट झोनमधून बाहेर पडून संवाद साधावा लागेल. समस्या सोडवणारा म्हणून, तुम्हाला सतत कमकुवत स्थितीत ठेवावे लागेल आणि काय चूक होऊ शकते याचा विचार करावा लागेल. या प्रकारचे काम उपद्रव होण्यासाठी उपजतच डिझाइन केलेले आहे. तुम्ही जाणीवपूर्वक स्वतःला तणावपूर्ण परिस्थितीत ठेवता. सहसा लोक त्यांच्यापासून दूर पळतात, लोकांना आनंदी मुले व्हायला आवडते.

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

संवादाची किंमत

ओलेग: अशा आउटगोइंग कर्मचार्‍यांना वेगवेगळ्या कारणांनी कामावर ठेवणे अधिक महाग नाही का? शेवटी, ते काम करण्याऐवजी सतत गप्पा मारत असतात!

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

मायकेल: स्पेशलायझेशन, कौशल्ये किंवा काम करण्याच्या पद्धतींकडे दुर्लक्ष करून हे प्रकल्पात गुंतलेल्या प्रत्येकाला लागू होते. आपणा सर्वांना प्रकल्पाच्या यशामध्ये रस आहे.

टिम: होय, तुम्हाला असे वाटते की तुम्ही प्रकल्पात पुरेसा बुडून गेला आहात, तुमचे कार्य प्रकल्प पूर्ण होण्यास मदत करणे आहे. तुम्ही प्रोग्रामर, विश्लेषक, इंटरफेस डिझायनर, कोणीही असाल. हेच कारण आहे की मी रोज सकाळी कामावर येतो आणि आम्ही हेच करतो. या सर्व लोकांच्या कौशल्याची पर्वा न करता आपण त्याला जबाबदार आहोत. हा प्रौढ संभाषण करणाऱ्या लोकांचा समूह आहे.

ओलेग: खरं तर, बोलक्या कर्मचार्‍यांबद्दल बोलताना, मी लोकांच्या, विशेषतः व्यवस्थापकांच्या आक्षेपांचे अनुकरण करण्याचा प्रयत्न केला, ज्यांना डेव्हॉप्सकडे जाण्यास सांगितले जाते, जगाच्या या संपूर्ण नवीन दृष्टीकडे. आणि तुम्हाला, सल्लागार म्हणून, विकासक म्हणून, माझ्यापेक्षा या आक्षेपांची जाणीव असली पाहिजे! व्यवस्थापकांना सर्वात जास्त कशाची चिंता वाटते?

टिम: व्यवस्थापक? हं. बर्‍याचदा, व्यवस्थापकांवर समस्यांचा दबाव असतो, त्यांना त्वरित काहीतरी सोडण्याची आणि वितरण करण्याची आवश्यकता असते आणि यासारख्या गोष्टींचा सामना करावा लागतो. ते पाहतात की आपण कशाविषयी सतत चर्चा करतो आणि वाद घालतो आणि ते असे पाहतात: संभाषणे, संभाषणे, संभाषणे... इतर कोणती संभाषणे? कामावर परत या! कारण बोलणे त्यांना कामाचे वाटत नाही. तुम्ही कोड लिहीत नाही, सॉफ्टवेअरची चाचणी घेत नाही, काहीही करत नाही असे वाटत नाही - तुम्हाला काहीतरी करायला का पाठवत नाही? शेवटी, डिलिव्हरी आधीच एका महिन्यात आहे!

मायकेल: जा काही कोड लिहा!

टिम: मला असे दिसते की त्यांना कामाची चिंता नाही, परंतु प्रगतीच्या दृश्यमानतेच्या अभावाबद्दल. आपण यशाच्या जवळ पोहोचलो आहोत असे वाटण्यासाठी, त्यांनी आपल्याला कीबोर्डवरील बटणे दाबताना पाहणे आवश्यक आहे. सकाळपासून संध्याकाळपर्यंत संपूर्ण दिवस. ही समस्या क्रमांक एक आहे.

ओलेग: मिशा, तू काहीतरी विचार करत आहेस.

मायकेल: सॉरी, मी विचारात हरवून गेलो आणि फ्लॅशबॅक पकडला. या सर्व गोष्टींमुळे मला काल झालेल्या एका मनोरंजक रॅलीची आठवण झाली... काल खूप मोर्चे निघाले होते... आणि हे सर्व खूप ओळखीचे वाटते!

पगाराशिवाय जीवन

टिम: तसे, संवादासाठी “रॅली” आयोजित करणे अजिबात आवश्यक नाही. म्हणजे, विकसकांमधील सर्वात उपयुक्त चर्चा जेव्हा ते एकमेकांशी बोलतात तेव्हा होतात. तुम्ही सकाळी एक कप कॉफी घेऊन चालता, आणि तिथे पाच लोक जमले आहेत आणि काहीतरी तांत्रिक चर्चा करत आहेत. माझ्यासाठी, मी या प्रकल्पाचा व्यवस्थापक असल्यास, फक्त हसणे आणि माझ्या व्यवसायाबद्दल कुठेतरी जाणे चांगले आहे, त्यांना त्यावर चर्चा करू द्या. ते आधीच शक्य तितके गुंतलेले आहेत. हे एक चांगले लक्षण आहे.

ओलेग: तसे, तुमच्या पुस्तकात तुमच्याकडे काय चांगले आणि काय वाईट याच्या नोट्स आहेत. तुम्ही स्वतः त्यापैकी काही वापरता का? तुलनेने बोलायचे झाले तर, आता तुमच्याकडे एक कंपनी आहे आणि ती अतिशय अपारंपरिक पद्धतीने तयार केलेली आहे...

टिम: अपरंपरागत, परंतु हे डिव्हाइस आम्हाला उत्तम प्रकारे अनुकूल करते. आम्ही एकमेकांना खूप दिवसांपासून ओळखतो. आमचा एकमेकांवर विश्वास आहे, आम्ही भागीदार होण्यापूर्वी आम्ही एकमेकांवर खूप विश्वास ठेवला. आणि उदाहरणार्थ, आमच्याकडे पगार नाही. आम्ही फक्त काम करतो आणि उदाहरणार्थ, जर मी माझ्या क्लायंटकडून पैसे कमावले तर सर्व पैसे माझ्याकडे गेले. त्यानंतर, आम्ही संस्थेला सदस्यत्व शुल्क भरतो आणि हे कंपनीला स्वतःला समर्थन देण्यासाठी पुरेसे आहे. शिवाय, आम्ही सर्व वेगवेगळ्या गोष्टींमध्ये माहिर आहोत. उदाहरणार्थ, मी अकाउंटंट्ससोबत काम करतो, टॅक्स रिटर्न भरतो, कंपनीसाठी सर्व प्रकारच्या प्रशासकीय गोष्टी करतो आणि त्यासाठी मला कोणीही पैसे देत नाही. जेम्स आणि टॉम आमच्या वेबसाइटवर काम करतात आणि त्यांना कोणीही पैसे देत नाही. जोपर्यंत तुम्ही तुमची थकबाकी भरता तोपर्यंत तुम्हाला काय करावे लागेल हे सांगण्याचा कोणीही विचार करणार नाही. उदाहरणार्थ, टॉम आता पूर्वीपेक्षा खूपच कमी काम करतो. आता त्याला इतर स्वारस्ये आहेत; तो काही गोष्टी गिल्डसाठी करत नाही. पण जोपर्यंत तो त्याची देणी देतो तोपर्यंत कोणीही त्याच्याकडे येऊन म्हणणार नाही, "अरे, टॉम, कामावर जा!" तुमच्यामध्ये पैसे नसताना सहकाऱ्यांशी व्यवहार करणे खूप सोपे आहे. आणि आता आमचा संबंध वेगवेगळ्या वैशिष्ट्यांच्या संबंधात मूलभूत कल्पनांपैकी एक आहे. हे कार्य करते आणि ते खूप चांगले कार्य करते.

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

मायकेल: "सर्वोत्तम सल्ला" वर परत जाणे, तुम्ही तुमच्या क्लायंटला पुन्हा पुन्हा काही सांगता का? 80/20 बद्दल एक कल्पना आहे, आणि काही सल्ला कदाचित अधिक वेळा पुनरावृत्ती केला जातो.

टिम: मला एकदा वाटले की जर तुम्ही वॉल्टझिंग विथ बिअर्स सारखे पुस्तक लिहिले तर ते इतिहासाचा मार्ग बदलेल आणि लोक थांबतील, पण... बरं, बघा, कंपन्या बर्‍याचदा असे भासवतात की त्यांच्याबरोबर सर्व काही ठीक आहे. काही वाईट घडले की त्यांच्यासाठी हा धक्का आणि आश्चर्याचा धक्का असतो. “पाहा, आम्ही सिस्टमची चाचणी केली, आणि ती कोणत्याही सिस्टम चाचण्या उत्तीर्ण होत नाही, आणि हे आणखी तीन महिन्यांचे अनियोजित काम आहे, हे कसे होऊ शकते? कोणाला माहित होते? काय चूक होऊ शकते? गंभीरपणे, तुमचा यावर विश्वास आहे का?

मी समजावून सांगण्याचा प्रयत्न करत आहे की तुम्ही सध्याच्या परिस्थितीबद्दल जास्त रागावू नका. आपण त्याबद्दल बोलणे आवश्यक आहे, खरोखर काय चूक झाली आहे हे समजून घेणे आणि भविष्यात अशा गोष्टी घडण्यापासून कसे रोखायचे. जर एखादी समस्या उद्भवली, तर आपण ती कशी लढू, ती कशी रोखू?

माझ्यासाठी, हे सर्व भयानक दिसते. लोक गुंतागुंतीच्या, त्रासदायक समस्यांना सामोरे जातात आणि असे ढोंग करत राहतात की जर त्यांनी फक्त बोटे ओलांडली आणि सर्वोत्तमची आशा केली तर "सर्वोत्तम" प्रत्यक्षात घडेल. नाही, ते तसे काम करत नाही.

जोखीम व्यवस्थापनाचा सराव करा!

मायकेल: तुमच्या मते, किती संस्था जोखीम व्यवस्थापनात गुंतलेली आहेत?

टिम: मला चिडवणारी गोष्ट म्हणजे लोक फक्त जोखीम लिहून ठेवतात, परिणामी यादी पाहतात आणि कामावर जातात. खरं तर, त्यांच्यासाठी जोखीम ओळखणे म्हणजे जोखीम व्यवस्थापन. पण मला हे विचारण्याचे कारण वाटते: ठीक आहे, एक यादी आहे, तुम्ही नक्की काय बदलाल? हे धोके लक्षात घेऊन तुम्हाला तुमच्या कृतींचा मानक क्रम बदलण्याची आवश्यकता आहे. कामाचा काही सर्वात कठीण भाग असल्यास, तुम्हाला ते हाताळण्याची आवश्यकता आहे आणि त्यानंतरच काहीतरी सोप्याकडे जा. पहिल्या स्प्रिंटमध्ये, जटिल समस्या सोडवणे सुरू करा. हे आधीच जोखीम व्यवस्थापनासारखे दिसते. परंतु जोखमींची यादी संकलित केल्यानंतर ते काय बदलले हे सहसा लोक सांगू शकत नाहीत.

मायकेल: आणि तरीही, यापैकी किती कंपन्या जोखीम व्यवस्थापनात गुंतलेल्या आहेत, पाच टक्के?

टिम: दुर्दैवाने, मला हे सांगणे आवडत नाही, परंतु हा काही अत्यंत क्षुल्लक भाग आहे. परंतु पाच पेक्षा जास्त, कारण खरोखर मोठे प्रकल्प आहेत आणि त्यांनी किमान काही केले नाही तर ते अस्तित्वात असू शकत नाहीत. चला फक्त असे म्हणूया की ते किमान 25% असल्यास मला खूप आश्चर्य वाटेल. लहान प्रकल्प सामान्यत: अशा प्रश्नांची उत्तरे देतात: जर समस्या आपल्यावर परिणाम करत असेल तर आम्ही त्याचे निराकरण करू. मग ते यशस्वीरित्या स्वतःला अडचणीत आणतात आणि समस्या व्यवस्थापन आणि संकट व्यवस्थापनात गुंततात. जेव्हा तुम्ही एखादी समस्या सोडवण्याचा प्रयत्न करता आणि समस्या सुटत नाही, तेव्हा संकट व्यवस्थापनामध्ये तुमचे स्वागत आहे.

होय, मी बर्‍याचदा ऐकतो, "जशा समस्या उद्भवतील तशा आम्ही सोडवू." नक्कीच आम्ही करू? आपण खरंच ठरवू का?

ओलेग: तुम्ही ते साधेपणाने करू शकता आणि प्रकल्प चार्टरमध्ये फक्त महत्त्वाचे अपरिवर्तनीय लिहू शकता आणि जर अपरिवर्तनीय तुटले तर प्रकल्प पुन्हा सुरू करा. तो खूप piembucky बाहेर वळते.

मायकेल: होय, माझ्या बाबतीत असे घडले की जेव्हा जोखीम सुरू होते तेव्हा प्रकल्पाची फक्त पुन्हा व्याख्या केली गेली. छान, बिंगो, समस्या सोडवली, आता काळजी करू नका!

टिम: चला रीसेट बटण दाबूया! नाही, ते तसे काम करत नाही.

DevOops 2019 मधील कीनोट

मायकेल: आम्ही या मुलाखतीच्या शेवटच्या प्रश्नाकडे आलो आहोत. तुम्ही पुढच्या DevOops वर मुख्य सूचना घेऊन येत आहात, तुम्ही जे सांगणार आहात त्यावरील गुप्ततेचा पडदा तुम्ही उचलू शकता का?

टिम: सध्या त्यापैकी सहा जण वर्क कल्चर, संस्थांचे न बोललेले नियम याबद्दल एक पुस्तक लिहित आहेत. संस्थेच्या मूलभूत मूल्यांद्वारे संस्कृती निश्चित केली जाते. सहसा लोकांच्या हे लक्षात येत नाही, परंतु बर्याच वर्षांपासून सल्लामसलत करण्याचे काम केल्यामुळे आम्हाला ते लक्षात घेण्याची सवय आहे. तुम्ही कंपनीत प्रवेश करता आणि अक्षरशः काही मिनिटांत तुम्हाला काय घडत आहे हे जाणवू लागते. आम्ही याला "स्वाद" म्हणतो. कधीकधी हा सुगंध खरोखरच चांगला असतो, आणि कधीकधी तो, अरेरे. वेगवेगळ्या संस्थांसाठी गोष्टी खूप वेगळ्या आहेत.

मायकेल: मी सुद्धा वर्षानुवर्षे सल्लामसलत करत आहे आणि तुम्ही काय बोलत आहात हे मला चांगले समजते.

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

तुम्हाला झटपट परिणाम मिळवायचे असल्यास, तुमच्यासाठी हा एक चांगला विषय आहे: तुम्ही अशा कंपन्या पाहिल्या आहेत का जेथे कोणीही “मला माहित नाही” असे म्हणत नाही? अशी काही ठिकाणे आहेत जिथे आपण एखाद्या व्यक्तीला काहीतरी माहित नाही हे कबूल करेपर्यंत आपण त्याचा अक्षरशः छळ करता. प्रत्येकाला सर्वकाही माहित आहे, प्रत्येकजण अविश्वसनीय विद्वान आहे. तुम्ही कोणत्याही व्यक्तीशी संपर्क साधा आणि त्याला त्वरित प्रश्नाचे उत्तर द्यावे लागेल. "मला माहित नाही" असे म्हणण्याऐवजी. हुर्रे, त्यांनी पांडित्यांचा समूह भाड्याने घेतला! आणि काही संस्कृतींमध्ये "मला माहित नाही" असे म्हणणे सामान्यतः खूप धोकादायक आहे; हे दुर्बलतेचे लक्षण मानले जाऊ शकते. अशा संस्था देखील आहेत ज्यात, त्याउलट, प्रत्येकजण "मला माहित नाही" म्हणू शकतो. तेथे हे पूर्णपणे कायदेशीर आहे आणि जर एखाद्या प्रश्नाच्या उत्तरात कोणी कचरा टाकू लागला तर उत्तर देणे पूर्णपणे सामान्य आहे: "तुम्ही कशाबद्दल बोलत आहात हे तुम्हाला माहिती नाही, बरोबर?" आणि हे सर्व विनोदात बदला.

आदर्शपणे, तुम्हाला अशी नोकरी हवी आहे जिथे तुम्ही सतत आनंदी राहू शकता. हे सोपे होणार नाही, प्रत्येक दिवस सनी आणि आनंददायी नसतो, कधीकधी तुम्हाला कठोर परिश्रम करण्याची आवश्यकता असते, परंतु जेव्हा तुम्ही स्टॉक घेणे सुरू करता तेव्हा ते दिसून येईल: व्वा, हे खरोखर आश्चर्यकारक ठिकाण आहे, मला येथे काम करणे चांगले वाटते, भावनिक आणि बौद्धिक दोन्ही. आणि अशा काही कंपन्या आहेत जिथे तुम्ही सल्लागार म्हणून जाता आणि लगेच लक्षात येते की तुम्ही ते तीन महिने सहन करू शकत नाही आणि घाबरून पळून जाल. या अहवालात मला याबद्दल बोलायचे आहे.

टीम लिस्टर मुख्य सूचना घेऊन येईल "वर्ण, समुदाय आणि संस्कृती: समृद्धीसाठी महत्त्वाचे घटक"सेंट पीटर्सबर्ग येथे 2019-29 ऑक्टोबर 30 रोजी होणाऱ्या DevOops 2019 परिषदेसाठी. तुम्ही तिकिटे खरेदी करू शकता अधिकृत वेबसाइटवर. DevOops वर आम्ही तुमची वाट पाहत आहोत!

स्त्रोत: www.habr.com