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

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

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

सॉफ्टवेयर डेवलपर्स के बीच समस्याग्रस्त पहचान निम्नलिखित हैं:

• प्राइमा दोना
• आदर्शवादी
• रॉक स्टार
• प्रबंधकों पर अंकन
• हमलावर बंधकों
• चीन की एक दुकान में हाथी
• अक्षम
• आशावादी
• निराशावादी
• एक सैनिक
• टेक प्रशंसक
• विरासत का रक्षक

प्राइमा दोना

डेवलपर अपनी अपरिहार्यता के बारे में इतना आश्वस्त है कि वह अभिमानी और नेतृत्व करने के लिए असंभव हो जाता है।

• एक बंधक में बदलाव कर सकते हैं - raiser या प्रौद्योगिकी प्रशंसक
• टीम के कप्तान जैसे प्रोजेक्ट मैनेजर के साथ संयोजन में खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: कम

समस्या

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

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

आप विशिष्ट वाक्यांशों द्वारा एक प्राइम डोना की पहचान कर सकते हैं:

• "यह बेवकूफी है - मैं इसे इस तरह नहीं करूंगा"
• "हमें इसे इस तरह करना होगा।"
• "यदि आप इसे पसंद नहीं करते हैं, तो आप मेरे प्रबंधक से बात कर सकते हैं"
• "ठीक है, हम देखेंगे।"
• "मैं आपके बॉस से बात करूंगा और देखूंगा कि वह क्या कहता है"

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

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

निर्णय

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

• प्रतिस्थापन अधिक योग्य होना चाहिए।
• प्राइम डोना के लिए यह स्पष्ट करना आवश्यक है कि उसके प्रतिस्थापन के पास प्राइमा डोना की छाया का पालन करने के अलावा कोई और काम नहीं है और जानें कि इसे कैसे बदलना है।

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

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

आदर्शवादी

डेवलपर वास्तुशिल्प लालित्य और कोड उत्कृष्टता प्राप्त करने के लिए इतना जुनूनी है कि वह भूल जाता है कि उसके काम से व्यवसाय को लाभ होना चाहिए।

• एक आशावादी या दिवा में बदल सकता है
• प्रौद्योगिकी प्रशंसक के साथ संयोजन में खतरनाक
• सुधार की संभावना: नहीं
• प्रोजेक्ट खतरा: अत्यंत उच्च

समस्या

एक सॉफ्टवेयर इंजीनियर के पेशे में दो विरोधी कार्यों के निरंतर संतुलन की आवश्यकता होती है:

1. व्यवसाय को लाभान्वित करने की इच्छा (और भुगतान प्राप्त करें)।
2. उत्कृष्ट सॉफ्टवेयर लिखने की इच्छा (और गर्व करें)।

आदर्शवादी ने व्यवसाय को लाभ पहुंचाने के लक्ष्य को पूरी तरह से नजरअंदाज कर दिया, और इसके बजाय केवल महान सॉफ्टवेयर लिखने पर ध्यान केंद्रित किया।

आदर्शवादी डेवलपर आमतौर पर बहुत स्मार्ट, अनुभवी और पेशेवर होता है। वह वास्तव में जानता है कि वह किस बारे में बात कर रहा है। वह वास्तव में महान सॉफ्टवेयर लिखना जानता है, और यदि उसे पर्याप्त समय दिया जाता है, तो वह सही प्रणाली बना सकता है। समस्या यह है कि उनका मानना ​​है कि उनके पास दुनिया में हर समय और पूर्ण स्वतंत्रता है , हालांकि यह मामले से बहुत दूर है।

समझौता करने के बजाय उन्होंने सही प्रणाली बनाने पर ध्यान केंद्रित किया। उनका मानना ​​है कि यह व्यापार के लिए बेहतर है। उन्हें उन वैज्ञानिकों के साथ भ्रमित न करें जो कुछ "निरपेक्ष" या "शांत" बनाते हैं: आदर्शवादी ईमानदारी से मानते हैं कि उनकी आदर्श प्रणाली कंपनी के विकास के लिए सबसे उपयुक्त है। यह इस विश्वास की दृढ़ता के कारण है कि उन्हें सही करना बहुत मुश्किल है।

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

निर्णय

हम आदर्शवादी लक्षणों को संक्षेप में प्रस्तुत करते हैं:

• बहुत स्मार्ट, अनुभवी और पेशेवर।
• साभार का मानना ​​है कि उनका सिस्टम कंपनी के भविष्य के लिए बेहतर है।

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

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

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

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

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

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

रॉक स्टार

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

• एक बंधक लेने वाले और दिवा में उत्परिवर्तित कर सकते हैं
• यह एक आशावादी प्रकार के प्रबंधक के साथ संयोजन में खतरनाक है
• सुधार की संभावना: नहीं
• प्रोजेक्ट खतरा: अत्यंत उच्च

समस्या

सॉफ़्टवेयर उद्योग में, "रॉक स्टार" शब्द का उपयोग अक्सर उन भर्तियों द्वारा किया जाता है जो डेवलपर्स को अपने अहंकार को फुलाकर आकर्षित करने की कोशिश करते हैं, अर्थात, "हम रॉक स्टार के कई डेवलपर्स की तलाश कर रहे हैं।" असली रॉक स्टार्स को ढूंढना मुश्किल है, क्योंकि वे आदर्श प्रोग्रामर हैं:

• कोई समस्या नहीं है कि वे (और जल्दी से) हल नहीं कर सकते हैं।
• वे समय सीमा को पकड़ने के लिए पूरी रात काम करते हैं।
• उनके कोड में व्यावहारिक रूप से कोई बग नहीं हैं या कोई भी बग जल्दी ठीक नहीं हुआ है।
• वे परियोजना के सबसे कठिन हिस्सों को लेते हैं।
• वे आमतौर पर सहकर्मियों के बहुत शौकीन होते हैं।

दुर्भाग्य से, एक बार काम पर रखने के बाद, वे परियोजना में अपरिहार्य हो जाते हैं।

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

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

निर्णय

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

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

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

प्रबंधकों पर अंकन

एक डेवलपर जिसने प्रोग्रामिंग कठिनाइयों से बचने और प्रबंधकों में से एक बनने का फैसला किया।

• एक पूर्व प्रबंधक या कैरियर के रूप में एक विकास प्रबंधक में बदल सकते हैं
• किसी प्रोजेक्ट मैनेजर जैसे सांख्यिकी या मीटिंग प्लानर के साथ मिलकर खतरनाक
• सुधार की संभावना: नहीं
• परियोजना के लिए खतरा: कम

समस्या

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

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

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

निर्णय

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

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

हमलावर बंधकों

एक डेवलपर जिसने महत्वपूर्ण सॉफ़्टवेयर का एक टुकड़ा लिखा है और अपनी अपरिहार्यता को बनाए रखने के लिए किसी को उस पर काम करने की अनुमति नहीं देता है।

• एक विरासत कोड के दिवा या कीपर में उत्परिवर्तन हो सकता है
• अक्षम डेवलपर के साथ संयुक्त होने पर खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: उच्च

समस्या

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

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

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

निर्णय

कोई फर्क नहीं पड़ता कि बंधक-रेज़र कितना खतरनाक है, समाधान सरल है: आक्रमणकारी प्रणाली के हिस्से के लिए दो या अधिक डेवलपर्स जिम्मेदारी असाइन करें, इसे दूसरे भाग में स्थानांतरित करें। , , .

, .

• :
• :

समस्या

. « » , . , .

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

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

निर्णय

चूंकि समस्या व्यक्ति में नहीं है, इसलिए संगठन को निम्नलिखित कदम उठाने चाहिए:

1. , . .
2. , .
3. . . , , .
4. , . , .
5. , , .

, . , . , , .

, .

• :
• :

समस्या

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

तकनीकी शिक्षा के बिना प्रबंधक के लिए एक अक्षम डेवलपर को पहचानना मुश्किल हो सकता है, लेकिन कई संकेत हैं:

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

संपूर्ण सॉफ्टवेयर उद्योग अक्षमता की समस्या से ग्रस्त है। यह आपूर्ति और मांग का एक सरल उदाहरण है जब श्रम बाजार में पर्याप्त योग्य डेवलपर्स नहीं हैं।

निर्णय

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

जब सरल कार्य बहुत जटिल होते हैं, तो अगला कदम आमतौर पर प्रशिक्षण बजट को अलग करना होता है। यहां मुख्य समस्या यह है कि अगर कोई अक्षम डेवलपर सीख सकता है, तो वह पहले से ही ऐसा करेगा - अपने अधिक सक्षम सहयोगियों के रूप में, क्योंकि सक्षम डेवलपर्स खुद सीखते हैं।

एक विचार है कि राज्य में एक बहुत उत्पादक उत्पादक की उपस्थिति कोई नुकसान नहीं पहुंचाती है, लेकिन यह एक बड़ी गलती है। वे दो बहुत हानिकारक प्रभाव पैदा करते हैं:

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

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

आशावादी

एक डेवलपर जो लगातार किसी कार्य को पूरा करने के लिए आवश्यक समय की मात्रा को कम करके आंका जाता है।

• एक में उत्परिवर्तित कर सके निराशावादी
• एक आशावादी परियोजना प्रबंधक के साथ संयुक्त होने पर खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: मध्यम

समस्या

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

: . / , -. , , , , . , ; , , .

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

निर्णय

सौभाग्य से, कुछ नियमों का पालन करके एक आशावादी व्यक्ति को सुधारा जा सकता है:

• उनसे केवल उस कोड का मूल्यांकन करने के लिए कहें जिससे वे परिचित हैं।
• केवल उन तकनीकों के लिए मूल्यांकन के लिए पूछें जिनसे वे परिचित हैं।
• कभी भी नए कार्यों के कार्यान्वयन के समय का मूल्यांकन करने के लिए न कहें, बल्कि केवल मौजूदा सुधार करें।
• यह सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए कि वे सभी आवश्यकताओं को पूरी तरह से समझते हैं - वे मक्खी पर आवश्यकताओं की स्वतंत्र रूप से व्याख्या नहीं कर सकते।
• «TODO» , . .
• : , .

, , , .

, :

• (. ). , .
• , (. )? , .

, , , . , , , .

, , .

• :
• :

समस्या

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

निराशावादियों को नोटिस करना कभी-कभी असंभव होता है। उन्हें परिपक्व और जिम्मेदार के लिए गलत माना जा सकता है, क्योंकि उनके प्रतीत होने वाले कम अनुभवी साथी डेवलपर्स के विपरीत, वे कभी भी समय सीमा को याद नहीं करते हैं। लेकिन कुछ संकेत हैं:

• एक ही मूल्यांकन के साथ उनके साथी डेवलपर्स काफी कम लीड समय देते हैं।
• यदि आप उन्हें एक समय सीमा देते हैं, तो वे बिना किसी औपचारिक आकलन के तुरंत सहमत हो जाते हैं।
• जब वे जल्दी से सहमत हो जाते हैं, यदि आप तारीख को पहले की तारीख में थोड़ा आगे बढ़ाते हैं, तो वे उस तारीख से भी सहमत होंगे। इसका मतलब यह है कि दो तिथियों के बीच वास्तव में कार्य को पूरा करने के लिए अतिरिक्त समय नहीं लगता है।

एक निराशावादी कंपनी की प्रतिस्पर्धा को कम कर सकता है। यदि आप एक प्रतियोगी के साथ एक दौड़ में शामिल हैं, तो आप हमेशा उसकी तुलना में धीमे रहेंगे।

निर्णय

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

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

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

एक सैनिक

एक डेवलपर जो वास्तव में क्या कहता है, वह बिना किसी सवाल के करता है, चाहे वह सही हो।

• चीन की दुकान में हाथी में उत्परिवर्तन हो सकता है
• एक तानाशाह परियोजना प्रबंधक के साथ संयोजन में खतरनाक
• सुधार की संभावना: नहीं
• परियोजना के लिए खतरा: कम

समस्या

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

एक सैनिक किसी भी कौशल स्तर का हो सकता है: एक अक्षम से एक रॉक स्टार तक । एक प्रमुख विशेषता उसकी आज्ञाकारिता है: हर बार वह वही करेगा जो आप उसे बताते हैं। शानदार नेतृत्व के प्रभाव को देखते हुए गलती करना आसान है, लेकिन उत्कृष्ट बॉस बहुत दुर्लभ हैं।

सैनिकों का जन्म कई तरीकों से होता है:

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

नतीजतन, कोई भी व्यक्ति अपने कमांड में कितना सुखद लग सकता है, यह शायद ही अच्छा है।

निर्णय

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

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

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

सामान्य तौर पर, उन्हें ठीक करना लगभग असंभव है। इस प्रकार, ये आमतौर पर एक मजबूत नेता का समर्थन करने के लिए अच्छे कर्मचारी होते हैं।

टेक प्रशंसक

एक डेवलपर जो नई तकनीकों की कोशिश करने में बहुत खुश है कि वह उन्हें परियोजना में लागू करेगा, क्या यह उचित है या नहीं।

• एक बंधक लेने वाले में बदल सकता है
• आदर्शवादी के साथ संयोजन में खतरनाक
• सुधार की संभावना: उच्च
• परियोजना के लिए खतरा: कम

समस्या

. -, . .

- : , . , , -.

. , . , , . , , .

निर्णय

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

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

लीगेसी कीपर

एक डेवलपर जिसकी एकमात्र क्षमता पुराने सॉफ्टवेयर को बनाए रखने के लिए है, और इसलिए एक नई नौकरी लेने में सक्षम नहीं है।

• एक बंधक हमलावर या सैनिक में उत्परिवर्तित कर सकते हैं
• एक रचनात्मक डिजाइनर के साथ संयोजन में खतरनाक
• सुधार की संभावना: नहीं
• परियोजना के लिए खतरा: नहीं

समस्या

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

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

1. प्राचीन कोड आमतौर पर खराब लिखा जाता है और इसके साथ काम करना मुश्किल होता है।
2. समर्थन एक मृत अंत कैरियर मार्ग है क्योंकि आप कुछ भी नया या अभिनव नहीं कर रहे हैं, जिसके लिए आपको चिह्नित किया जा सकता है।

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

निर्णय

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

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

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

यह भी देखें:

• "परियोजना प्रबंधकों के बीच समस्या व्यक्ति"
• "परीक्षकों के बीच समस्या व्यक्ति"