जेएच वर्षा जल "बिल्लियों को कैसे चरना है": प्रोग्रामर और उनकी प्रजनन की विशेषताएं

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

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

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

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

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

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

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

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

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

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

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

लेखक नस्लों को तीन समूहों में विभाजित करता है: आम (सबसे अधिक बार पकड़ा जाता है), दुर्लभ (कभी-कभी पकड़ा जाता है) और मोंगरेल (अपने मूल रूप में कुल द्रव्यमान की तुलना में कम मूल्य लेते हैं)।

सामान्य नस्लों

वास्तुकार

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

रचनावादी

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

कलाकार

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

इंजीनियर

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

वैज्ञानिक

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

जलानेवाला

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

दुर्लभ नस्लें

जादूगर

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

minimalist

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

Analogist

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

स्टंट मैन

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

संस्थानिक आधारशिला रखी थी

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

लापरवाही से काम करनेवाला

मैला, मैला कोड का मुख्य प्रदाता। अक्सर स्टाइल से स्टाइल तक। एक स्कोरर की तरह, वह डिजाइन और टीम द्वारा अपनाए गए समझौतों का पालन करता है, लेकिन, स्कोरर के विपरीत, वह काम की उच्च गति से भी उचित नहीं ठहराया जा सकता है। यह उसका कोड है जिसे कभी-कभी खरोंच से फिर से लिखना पड़ता है - इसे समझने के लिए इतना थकाऊ और संसाधन-गहन।

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

ब्रेक

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

शौकिया

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

मूर्ख

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

उदार

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

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

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

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

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

उदाहरण संख्या १

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

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

उदाहरण संख्या 2

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

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

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