लगभग। अनुवादक - मूल में, परिचित शब्द "सॉफ्टवेयर इंजीनियर" का उपयोग किया गया था। चूंकि उनके रूसी समकक्ष, "सॉफ्टवेयर इंजीनियर," का उपयोग रोज़मर्रा के भाषण में शायद ही कभी किया जाता है, इसलिए मुझे "डेवलपर" शब्द का उपयोग निकटतम के रूप में करना पड़ा। इसके अलावा, "शॉर्ट-ऑर्डर कुक" का पेशा, जिसके साथ लेखक उद्योग में कई डेवलपर्स की स्थिति की तुलना करता है, का अनुवाद "गलत लड़का" के रूप में किया गया था - मुझे ऐसा लगता है कि यह पूरी तरह से डेवलपर्स के प्रति दृष्टिकोण की समस्या का सार दर्शाता है। अंत में, मैंने "कोड" और "प्रोग्रामिंग" शब्दों के बजाय "कोड" और "प्रोग्रामिंग" शब्दों के नकारात्मक अर्थों के कारण हर जगह "विकास" और "विकास" का उपयोग करने की कोशिश की, जो रूसी में विकसित हुई हैं, जो निम्न या मशीन निर्देशों में आवश्यकताओं के अनुवाद के लिए आदिम प्रक्रियाओं के रूप में विकसित हुई हैं। उच्च स्तर।
मूल लेख के लेखक निकोलस सी। ज़कस हैं, जो एक प्रसिद्ध फ्रंट-एंड डेवलपर और जावास्क्रिप्ट इंजीलवादी हैं जिन्होंने एक समय में याहू में पांच साल से अधिक समय तक काम किया था। यह उनके ब्लॉग से एक प्रविष्टि है जिसमें वह इस बारे में बात करता है कि डेवलपर्स के साथ सहमत होना इतना मुश्किल क्यों है और इसके बारे में क्या करना है।बहुत समय पहले ऐसा नहीं था, जेना ब्यलॉट ने एक अद्भुत लेख लिखा,
"कैसे डिजाइनरों को डेवलपर्स के साथ मिलता है," जिसमें वह टीमवर्क के तरीकों का वर्णन करते हैं जो डिजाइनरों और डेवलपर्स को बेहतर प्रदर्शन प्राप्त करने की अनुमति देते हैं। मैंने एक बार डिजाइनरों के साथ काम किया (और, UI में काम कर रहे हैं, और डेवलपर्स के साथ) और इसी तरह की समस्याओं का सामना किया, इसलिए मैं इसके व्यावहारिक दृष्टिकोण को समझता हूं। टीम के काम के दौरान, अपने सहयोगियों के काम का सम्मान करने और उनके सोचने के तरीके को समझने में कभी भी तकलीफ नहीं होती है।
उस लेख का एक मुख्य विचार यह था कि डेवलपर्स बहुत जल्दी नहीं कहते हैं। यह विचार तुरंत मेरे दिमाग में आया और लंबे समय तक वहाँ से बाहर निकलने से इनकार कर दिया। मैं कहना चाहता था: "लेकिन ठहरो, तुम यह नहीं समझते कि हम क्यों नहीं कहते!" एक लाख अन्य रक्षात्मक तर्क तुरंत दिखाई दिए। वास्तव में, वह, ज़ाहिर है, सही है - हम वास्तव में बहुत जल्दी कहते हैं "नहीं", न केवल डिजाइनरों के लिए, बल्कि सभी के लिए। इसने मुझे डेवलपर्स के मनोविज्ञान पर प्रतिबिंबित करने के लिए प्रेरित किया और हमारे वास्तविक सार का गठन किया।
हमारी प्रतिष्ठा
ईमानदारी से, हम, डेवलपर्स, नियमित रूप से मिजाज वाले ऐसे गर्वित वाद-विवादकर्ताओं की प्रतिष्ठा रखते हैं। हम लगातार "नहीं" कहते हैं, अशोभनीय पैदल सेना के विवरण को स्पष्ट करते हैं और मानते हैं कि हम अपने गैर-तकनीकी सहयोगियों में से किसी का काम खुद से बहुत बेहतर कर सकते हैं। और, जो पहले से ही है, यह स्टीरियोटाइप काफी हद तक सही है - यह वह है जो हम दिन-प्रतिदिन करते हैं, कोड लिखने और हैकर न्यूज के साथ ट्विटर पढ़ने के बीच।
(नोट: आप में से एक कहेगा कि सभी डेवलपर्स ऐसे नहीं हैं, और वह सही होगा। डेवलपर्स का एक छोटा प्रतिशत है, जिसे ऊपर रैंक नहीं किया जा सकता है। स्क्रॉल करने के लिए जल्दी मत करो और टिप्पणियों में लिखें कि लेखक एक बेवकूफ है, पर पढ़ें )।
कोई भी सिर्फ एक प्रतिष्ठा नहीं देता है, वे इसे कमाते हैं। इस प्रतिष्ठा में मुझे क्या आश्चर्य है कि मैं व्यक्तिगत रूप से डेवलपर्स का एक गुच्छा जानता हूं, और, एक नियम के रूप में, वे दोस्ताना, सुखद (यदि उनके साथ जिद्दी नहीं हैं) और सिर्फ मजाकिया लोग हैं। काम के बाद या वीकेंड पर आप उनके साथ बेहतरीन समय बिता सकते हैं। तो वे काम पर पूरी तरह से अलग लोग क्यों बनते हैं?
हम निर्माता हैं, बिल्डर नहीं
मेरे पास एक सिद्धांत है। यह इस तथ्य में निहित है कि डेवलपर्स खुद को अपने सहयोगियों की तुलना में पूरी तरह से अलग देखते हैं। मैं बड़ी और छोटी सॉफ्टवेयर डेवलपमेंट कंपनियों में दस साल के काम पर इस नतीजे पर पहुंचा। ऐसी कंपनियों के कर्मचारी (उत्पाद प्रबंधक, डिजाइनर, अन्य प्रबंधक) आमतौर पर डेवलपर्स को साधारण बिल्डरों के रूप में देखते हैं। उत्पाद प्रबंधक को एक मूल विचार के साथ आना चाहिए, डिजाइनर को इसे एक सुंदर रूप में व्यक्त करना होगा, और डेवलपर को केवल इन विचारों को जीवन में लाना होगा। वास्तव में, इंजीनियरों को गलत लड़कों के रूप में देखा जाता है जो वास्तव में केवल और केवल वही करते हैं जो उन्हें बताया गया था।
मेरे पहले मैनेजर ने मुझे इस बारे में चेतावनी दी। जब मैंने पहली कंपनी के लिए काम किया, तब हम अलग हो गए, हमने अपने भविष्य के करियर के बारे में बहुत स्पष्ट बातचीत की। हालाँकि हमें हमेशा साथ नहीं मिला, फिर भी उन्होंने मुझे उत्कृष्ट सलाह दी (बाद में गलत उद्धरण):
निकोलस, आप जो कोड लिखते हैं, उससे अधिक मूल्य के हैं। जहां भी आप आगे काम करते हैं, आपको कभी भी एक गलत लड़के की तरह नहीं समझा जाता है। काम करने के लिए सहमत न हों यदि आपको बताया गया कि वास्तव में क्या किया जाना चाहिए और कैसे। आपको काम करने की ज़रूरत है जहां वे न केवल इस तथ्य को महत्व देते हैं कि आप एक उत्पाद बना सकते हैं, बल्कि यह भी कि आप इसे कैसे सुधार सकते हैं।
वह बिल्कुल सही था। ऐसी कई कंपनियां हैं जिन्हें लड़कों की जरूरत है, उन्हें बिल्डरों की जरूरत है जो पक्ष को एक कदम उठाने के अधिकार के बिना स्पष्ट रूप से परिभाषित पैटर्न के अनुसार कोड लिखेंगे। मैं यहां तक कहूंगा कि ये बड़ी और छोटी दोनों कंपनियों के बहुमत हैं। मेरे पास लंबे समय से इस बात की गिनती है कि स्टार्टअप के कितने संस्थापकों ने मुझे अपनी कॉपीराइट दृष्टि के कार्यान्वयन के बदले कंपनी में हिस्सेदारी की पेशकश की। वे सभी इस तथ्य से आगे बढ़ते हैं कि उनके पास पहले से ही विचार हैं, उन्हें केवल उसी की आवश्यकता है जो उन्हें जीवन में लाएगा।
और यहां समस्या की मुख्य जड़ दफन है - डेवलपर्स वास्तव में आज्ञाकारी बिल्डरों नहीं हैं। डेवलपर्स निर्माता हैं। आप स्वयं एक अर्थ में, इक्या से फर्नीचर को इकट्ठा करने के लिए हर बार विधानसभा निर्माण में लगे हुए हैं। आपके हाथों में सभी निर्देश हैं, और यदि आप उन्हें कदम से कदम का पालन करते हैं, तो आप हास्यास्पद रूप से छोटी तालिका को इकट्ठा करेंगे जो आप चाहते थे। रचनात्मकता एक पूरी तरह से अलग काम है, यह विशिष्ट निर्देशों या निर्देशों के बिना किसी चीज का निर्माण है। आप एक रिक्त कैनवास से शुरू करते हैं और कला के काम के साथ समाप्त होते हैं। डेवलपर्स प्रोग्रामिंग से बहुत प्यार करते हैं, क्योंकि वे किसी और के निर्देशों का पालन करना चाहते हैं, लेकिन क्योंकि उन्हें एहसास हुआ कि वे इसके साथ अलग-अलग दिलचस्प चीजें कर सकते हैं। हम सभी को विकास प्रक्रिया से प्यार हो गया, क्योंकि एक बार जब हमने एक मामूली लेकिन उपयोगी एप्लिकेशन लिखा था, और हम झुके हुए थे।
सॉफ़्टवेयर डेवलपमेंट की जीत में, उत्पाद प्रबंधकों, डिजाइनरों और डेवलपर्स से मिलकर, केवल डेवलपर्स को अपने रचनात्मक नस को डिस्कनेक्ट करने और सामान्य उत्पादन में संलग्न करने की आवश्यकता होती है। लेकिन डेवलपर्स बिल्कुल भी बेवकूफ नहीं हैं, वे पूरी तरह से ऐसा रवैया महसूस करते हैं, और उनमें असंतोष प्रकट होने लगता है। डेवलपर्स समग्र रचनात्मक प्रक्रिया का हिस्सा बनना चाहते हैं, और वे इससे वंचित हो रहे हैं। और अब, एक पूरी तरह से सामान्य डेवलपर एक क्रोनिक ग्रंबलर में बदल जाता है।
अरे, तो क्या समस्या है?
उत्पाद प्रबंधक आमतौर पर असाधारण लोग हैं। उनके विचार और बाजार के रुझान को समझने की क्षमता प्रभावशाली है। लेकिन उनके पास अपने विचारों को पूरी तरह से गलतफहमी से रहित करने की क्षमता है, जबकि वास्तव में उनके पास छेद हैं जिनके माध्यम से एक पूरी ट्रेन गुजर सकती है। मैं इसे बहुत कोमलता के साथ कहता हूं, कुछ उत्पाद प्रबंधक मेरे अच्छे दोस्त हैं, और निश्चित रूप से, मैंने अक्सर उन्हें व्यक्तिगत रूप से इस बारे में बताया है। किसी भी मामले में मैं उनकी आलोचना नहीं करता, यह सिर्फ उनका सार है। वे रचनात्मक कार्य में लगे हुए हैं, और एक दुर्लभ विचार आदर्श का जन्म होता है। और इस से यह ठीक डेवलपर्स है जो grumbler बन जाते हैं।
डेवलपर्स और उत्पाद प्रबंधक दोनों अक्सर गलत तरीके से मानते हैं कि उत्पाद की आवश्यकताएं या विनिर्देश Ikea से फर्नीचर के तैयार टुकड़े के समान हैं। वास्तव में, इन दस्तावेजों में शायद ही कभी पर्याप्त जानकारी होती है ताकि उन्हें एक पूर्ण उत्पाद एकत्र करने में सक्षम बनाया जा सके। यह आमतौर पर सिर्फ एक शुरुआती बिंदु है - और यह डेवलपर को हल करने के लिए एक अनूठी समस्या प्रदान करता है।
इस समस्या को बेहतर ढंग से समझने के लिए, आइए घर बनाने के काम को देखें। मान लीजिए किसी ने जमीन के एक निश्चित भूखंड पर घर बनाने का फैसला किया। घर में दो मंजिल और एक गैरेज होना चाहिए। यहां तक कि हमारे पास घर के सामने की एक मोटी रूपरेखा है, जिसे एक नैपकिन पर खींचा गया है। और इसलिए ग्राहक आपके पास यह सब जानकारी और एक नैपकिन लेकर आता है और पूछता है: "यह आपके लिए निर्माण शुरू करने के लिए पर्याप्त है, ठीक है?" और यह आपके लिए पर्याप्त कैसे है?
यदि आप तार्किक रूप से सोचते हैं, तो आप वैसे भी निर्माण शुरू नहीं कर सकते। आप फुटेज नहीं जानते हैं, आपके पास एक मंजिल योजना नहीं है, आप यह भी कल्पना नहीं कर सकते हैं कि नए घर बनाने में शहर की क्या आवश्यकताएं हैं। नींव के नीचे धरती खोदना शुरू करने के लिए आपके पास पर्याप्त जानकारी नहीं है। एकमात्र तार्किक समाधान ग्राहक को यह बताना है कि वह पागल है और उसे पहले यह तय करना चाहिए कि उसे क्या चाहिए। अब कल्पना कीजिए कि आप ऐसा नहीं कर सकते, क्योंकि किसी ने एक समय सीमा लगा दी है, और आपको नाक के छेद के लिए समय चाहिए।
"ठीक है" ग्राहक आपको बताता है, "चलिए इसे बनाना शुरू करते हैं; और जहां तक संभव हो, आपको नई जानकारी से अवगत कराऊंगा। इसलिए हम समय बर्बाद नहीं करेंगे।
आप यह सुनिश्चित करने के लिए जानते हैं कि निर्माण के लिए पर्याप्त जानकारी नहीं है, और आगे ग्राहक पूछताछ अभी तक कुछ भी नहीं देगी। लेकिन कोई भी समय सीमा को रद्द करने वाला नहीं है, और आप इस उम्मीद में अपनी पैंट में नहीं बैठ सकते कि ग्राहक विवरण के साथ उदार हो जाएगा। और तुम्हारे लिए क्या बचा है? धारणाएं और धारणाएं बनाएं।
पुरानी कहावत है: "जब आप मानते हैं, आप
यू और
मुझे एक
गधा बनाते हैं" (जब आप धारणा बनाते हैं, तो हम दोनों को बेवकूफ बनाते हैं), और यह सच है। अनुमान खतरनाक और बहुत बार झूठे होते हैं। और फिर भी, मान्यताओं के बिना, परियोजना शुरू नहीं की जा सकती। तो आप क्या कर रहे हैं आप इस धारणा से शुरू करते हैं कि आप सच्चाई के बारे में सुनिश्चित हैं - कि घर में दो मंजिल और एक गेराज होगा। सवाल है - गैरेज को विस्तार होना चाहिए या अलग से? और इसे बनाने के लिए आपको किस आकार की आवश्यकता है? हम जटिल नहीं होंगे, उदाहरण के लिए, गैरेज को अलग से बनाया जाना चाहिए और एक कार के लिए डिज़ाइन किया जाना चाहिए। अब आप गेराज पर एक अलग इमारत के रूप में काम कर सकते हैं, और फिर, जब घर का विवरण ज्ञात हो जाता है, तो यह गैरेज के बगल में बनाया जा सकता है।
गैरेज पर एक सप्ताह के काम के बाद, ग्राहक आपको नए विवरणों की सूचना देता है। यह पता चला है कि घर में तीन मंजिलें होनी चाहिए (उह, यह अच्छा है कि हमने अभी तक घर का निर्माण शुरू नहीं किया है) और आठ बाथरूम। गैरेज पर अभी तक कोई जानकारी नहीं है, लेकिन घर को नीले रंग से पेंट किया जाना चाहिए। आप निष्कर्ष निकालते हैं कि गेराज भी नीला होना चाहिए, और इसे पेंट करने के लिए आगे बढ़ना चाहिए।
कुछ और दिनों के बाद, गैरेज लगभग समाप्त हो गया है। आप परिणाम की गुणवत्ता से संतुष्ट हैं, क्योंकि आपको इतनी कम जानकारी थी! आप घर का निर्माण शुरू करने के लिए तैयार हैं जब ग्राहक नए विवरण प्रदान करता है - गैरेज को दो कारों के लिए डिज़ाइन किया जाना चाहिए और घर से जुड़ा होना चाहिए। आपके पास एक त्रासदी है - आपने इस तरह का एक अच्छा गेराज बनाया है, और अब "आवश्यक" एक का निर्माण करने के लिए इसे ध्वस्त करना होगा। इससे भी बदतर, अब आपके पास पूरी परियोजना को खत्म करने के लिए कम समय बचा है - और अब आप पहले से ही गड़गड़ाहट शुरू कर रहे हैं।
यदि यह सादृश्य आपको पागल लगता है, तो आपने स्पष्ट रूप से कभी भी डेवलपर के रूप में काम नहीं किया है। हम हर पहले दिन इसका निरीक्षण करते हैं। हम अपनी सभी रचनात्मक शक्तियों का उपयोग करते हुए परियोजनाओं को बनाए रखने की कोशिश करते हैं, लेकिन अंत में यह पता चलता है कि हम अन्य लोगों के विचारों को नहीं पढ़ सकते हैं और गलत अनुमान लगाया है कि हम क्या बना रहे थे। लेकिन, यदि हम ऐसा नहीं करते हैं, तो हम सिर्फ समय बर्बाद करने के लिए इंतजार करेंगे - और, जैसा कि आप जानते हैं, कैस्केडिंग विकास मॉडल में कई प्रशंसक नहीं हैं।
लगभग हर उद्योग में जहां आपको कुछ बनाने की आवश्यकता होती है, यह उम्मीद की जाती है कि निर्माण शुरू होने से पहले सभी आवश्यकताओं और इच्छाओं की पहचान की जाएगी और अनुमोदित किया जाएगा। लेकिन सॉफ्टवेयर डेवलपमेंट में नहीं। सॉफ़्टवेयर विकसित करते समय, अग्रिम में सभी आवश्यकताओं को इकट्ठा करने के लिए हमेशा "पर्याप्त समय नहीं" होता है। हमें हर दिन बताया जाता है कि हमें आगे बढ़ने की जरूरत है - और इसलिए डेवलपर्स को परियोजना को आगे बढ़ाना होगा, उत्पाद प्रबंधकों द्वारा छोड़े गए छेदों को भरना सीखना होगा। यह मत भूलो कि उत्पाद प्रबंधक अपने प्यार को लगातार बदलने के लिए अपने प्यार के लिए प्रसिद्ध हैं, जिससे डेवलपर्स की धारणाएं अक्सर गलत हो जाती हैं।
और किसी और को आश्चर्य है कि डेवलपर्स इतनी जल्दी "बाहर जला" और नौकरी बदलते हैं?
शीर्ष प्राथमिकताएँ
किसी भी रचनाकार का मुख्य शत्रु संदर्भ परिवर्तन होता है। जैसे ही आप एक गहरी रचनात्मक मोड में प्रवेश करते हैं, तथाकथित "प्रवाह", कोई भी बाहरी हस्तक्षेप तुरंत पूरी प्रक्रिया को नष्ट कर देता है। हां, कोड लिखना एक रचनात्मक प्रक्रिया भी है, रचनात्मक और तार्किक दोनों। हम सिर्फ कोड नहीं लिखते हैं, हम इसे बनाते हैं।
डेवलपर के समय का प्रबंधन करने वाले लोगों में, एक राय है कि एक कार्य से दूसरे में स्विच करना उनके लिए एक दुखद बात है। उनका तर्क है कि अफ्रीका में काम करने का समय भी काम कर रहा है। आप इसे वांछित कार्य पर पर्याप्त खर्च करते हैं, और वॉइला - यह परिणाम है। बेशक ऐसा नहीं है। यदि आप पहले से ही एक कार्य के दूसरे दिन पहले से ही बैठे हैं, और आपको दूसरे में स्थानांतरित कर दिया गया है, तो आप अब उस स्थान पर वापस नहीं लौट सकते हैं जहां आप समाप्त हो गए हैं। आपको संदर्भ में शामिल होने के लिए कुछ समय बिताना होगा, इसे बदलने की कीमत है। यहां तक कि अगर किसी अन्य कार्य में केवल कुछ मिनट लगते हैं, तो यह "प्रवाह" को बाधित करेगा और डेवलपर की उत्पादकता को कम करेगा।
यह उन मुख्य समस्याओं में से एक है, जिसके बारे में डेवलपर्स प्राथमिकता देते हैं - प्राथमिकताओं का लगातार परिवर्तन। आज हमारे पास एक मुख्य प्राथमिकता है, कल दूसरा - यह संदर्भ के अपरिहार्य परिवर्तन की ओर ले जाता है। रचनात्मक लोगों को मामले के बीच में फटे रहना पसंद नहीं है, यही वजह है कि कई डेवलपर्स सुबह तक खुशी के साथ लिखने को तैयार हैं, केवल अपना काम पूरा करने के लिए। संदर्भ का परिवर्तन उन्हें कम उत्पादक बनाता है।
लेकिन वास्तव में महत्वपूर्ण प्राथमिकताएं कभी नहीं बदलती हैं, वे निरंतर हैं। जिस आवृत्ति के साथ हमारे आस-पास के लोग अपने मन को बदलते हैं वह डेवलपर्स को बहुत प्रभावित करता है। सामान्य तौर पर, हम लगातार अलर्ट पर रहते हैं और केवल दुश्मन की ओर इशारा करते हैं। लेकिन अगर आज आप घर बनाने के लिए हमसे मांग करते हैं, और कल - इसे एक कार में रीमेक करने के लिए, तो आपको आश्चर्य नहीं होना चाहिए यदि आप रैंकों में असंतोष महसूस कर रहे हैं।
डेवलपर्स में एक भयानक दोष
डेवलपर्स को लगातार एक कठिन स्थिति में रखा जाता है, लेकिन हम पीड़ित नहीं हैं, भले ही हम में से सबसे हिस्टेरिकल खुद को ज्ञात करने का प्रयास करते हैं। हमारे ग्राउची का एक हिस्सा अंदर से आता है, यह इस कारण से है, अधिकांश डेवलपर्स के अंदर गहरे तार। हमारे पास एक भयानक दोष है, और यह इस तथ्य में निहित है कि हम अपने ज्ञान और क्षमताओं को अनदेखा करते हैं।
यह दोष अलग-अलग तरीकों से प्रकट होता है, लेकिन अधिकतर जब किसी कार्य के लिए समय का आकलन करते हैं। लगभग सभी मेरे मित्र डेवलपर्स एक विशेष कार्य पर खर्च करने के लिए आवश्यक समय को बहुत कम आंकते हैं। केवल हम में से सबसे अच्छा एक समय सीमा निर्धारित करने और इसे पूरा करने में सक्षम हैं। अधिकांश आमतौर पर दो बार या उससे भी अधिक गलतियाँ करते हैं। यह इस तथ्य के कारण है कि, किसी भी अन्य रचनात्मक लोगों की तरह, डेवलपर्स अक्सर उन सभी समस्याओं का पूर्वाभास नहीं कर सकते हैं जो वे सामना करेंगे।
भले ही कई डेवलपर्स शिकायत करते हैं कि उत्पाद प्रबंधक अपना दिमाग बदलते हैं, उनमें से लगभग कोई भी कार्य के लिए समय का मूल्यांकन करते समय इसे ध्यान में नहीं रखता है। कोई भी बैठकों, आवश्यकताओं के स्पष्टीकरण और संभावित परिवर्तनों का समय नहीं लेता है। बग? हां, हमारे आदर्श कोड में कोई भी नहीं हो सकता है, चिंता करने की कोई जरूरत नहीं है (और अगर कुछ होता है, तो परीक्षकों को सबकुछ सही मिलेगा;)। क्या परियोजना के लिए लोग छुट्टी पर जा रहे हैं या बीमार हो रहे हैं? यह ठीक है, कोई निश्चित रूप से उन्हें बदल देगा।
यह सब प्रत्यक्ष सड़क एक चूक की ओर जाता है, लेकिन कुछ भी परियोजना में इतनी देरी नहीं करता है कि तथ्य यह है कि डेवलपर्स समस्या क्षेत्र का अध्ययन करने के लिए समय का ध्यान नहीं रखते हैं। यह सीधे हमारे मुख्य दोष से संबंधित है। हम सोचते हैं कि हम पहले से ही वह सब कुछ जानते हैं जो हमें कार्य पूरा करने की आवश्यकता है, हालांकि हमें अक्सर उन तकनीकों के साथ काम करना पड़ता है जो हम अपने जीवन में पहली बार देखते हैं। वे शब्द जिन्हें हम आदर्श ज्ञान को परिभाषित करते हैं जिनके साथ हम सॉफ्टवेयर लिख सकते हैं जैसे कि एक आईकेई अनुदेश के अनुसार। वास्तव में, कई कार्यों के लिए हमें उनकी पृष्ठभूमि के बारे में विस्तार से अध्ययन करने की आवश्यकता है।
जो छात्र विश्वविद्यालय से स्नातक होते हैं, वे स्नातक होने के बाद सुरक्षा की झूठी भावना प्राप्त करते हैं। वे खुद को सॉफ्टवेयर और संपूर्ण विकास प्रक्रिया के विशेषज्ञ होने की कल्पना करते हैं, जब वास्तव में उनका ज्ञान शून्य से थोड़ा अधिक होता है। जब मैं अपनी पहली नौकरी के लिए गया था, तो मुझे एक स्नातक के रूप में गर्व था, हर किसी को उनकी गलतियों की ओर इशारा करते हुए। वर्षों के बाद ही मुझे एहसास हुआ कि मैं वास्तव में कुछ नहीं जानता था।
कंप्यूटर विश्वविद्यालय आपको उद्योग में आने वाली चुनौतियों के लिए तैयार नहीं करते हैं। सबसे पहले, वे आपको विभिन्न विषयों पर वैचारिक ज्ञान देते हैं ताकि आप बाद में बदनाम न हों, वर्तमान कार्य के दौरान उनका सामना करना पड़ता है। आपको चर, फ़ंक्शन और ऑब्जेक्ट सिखाए जाते हैं, क्योंकि यह उनके साथ है कि आप अपना अधिकांश समय काम करेंगे। आपको डेटाबेस सिखाया जाता है और उन्हें क्वेरी करना (हालांकि सामान्य रूप व्यवहार में बेकार साबित होंगे)। आप ज्यादातर समय एल्गोरिदम और डेटा संरचनाओं का अध्ययन करने में असामान्य रूप से बिताते हैं, जो कि व्यावसायिक विकास के दौरान, आप पर एक सार की परत के नीचे छिपा होगा। संक्षेप में, कंप्यूटर विश्वविद्यालय उन समस्याओं को हल करने पर विचार कर रहे हैं जिन्हें आपको अभ्यास में कभी हल नहीं करना पड़ेगा। अगर मुझे कुछ छाँटने की जरूरत है, तो मैं सिर्फ छाँट () विधि कहता हूँ। अगर मुझे एक कतार या लिंक की गई सूची चाहिए, तो मैं उस भाषा के मूल कार्यान्वयन का उपयोग करता हूं, जिसमें मैं लिखता हूं। ये सभी समस्याएं मेरे लिए पहले ही हल हो चुकी हैं।
विश्वविद्यालयों से स्नातक, हम मानते हैं कि हम दुनिया में सब कुछ कर सकते हैं, हालांकि वास्तव में हम केवल वही कर सकते हैं जो हमारे सामने किया गया है, और फिर भी इसका केवल एक छोटा सा हिस्सा है। लेकिन एक ही समय में, हम धूमधाम से जानते हैं कि यह सभी का व्यवहार करता है और, हमारे ज्ञान को आदर्श मानते हुए, विकास के समय को बिना सोचे समझे निर्धारित करना है कि हमें कुछ नया सीखना होगा।
इस समस्या का एक हिस्सा हमारी नाजुक घमंड से उत्पन्न होता है।
हमें डर है कि अगर हम बहुत लंबी समय सीमा तय करते हैं, तो लोग हमारी क्षमता पर सवाल उठाएंगे। हमें बताया गया है कि "अच्छे डेवलपर्स" को जल्दी से काम करना चाहिए, और हम अनिच्छा से इससे सहमत हैं। मैं हमेशा उन स्थितियों से मारा गया था जिसमें डेवलपर्स पहले परियोजना की अवधि निर्धारित करते हैं, और फिर उनके नेताओं में से एक शिकायत करना शुरू कर देता है कि यह बहुत अधिक है। सबसे पहले, जैसा कि मैंने पहले ही देखा है, समय सीमा शायद बहुत कम है। दूसरे, डेवलपर को प्रबंधक से बेहतर पता होना चाहिए कि उसे विकसित होने में कितना समय लगेगा, है ना? और यह एक और समस्या की ओर जाता है।मैं भी प्रोग्राम करता था
कुछ वाक्यांश एक डेवलपर को इतना पागल बना सकते हैं कि "मैं भी कार्यक्रम करता था।" जो कोई भी यह कहता है, एक उत्पाद प्रबंधक, डिजाइनर या नेतृत्व का कोई व्यक्ति, यह उनकी निर्दोषता के सबूत के रूप में उपयोग करने से केवल डेवलपर से अवमानना होती है। अगर मैंने लेब्रोन जेम्स (एक प्रसिद्ध बास्केटबॉल खिलाड़ी) से पूछा कि वह खेल से पहले कितना समय प्रशिक्षित करता है, तो वह बहुत आश्चर्यचकित होगा अगर मैंने उसे केवल सलाह देना शुरू कर दिया क्योंकि मैंने स्कूल में बास्केटबॉल खेला। डेवलपर्स को हर समय इस तरह सिखाया जाता है।यहाँ मेरी उपस्थिति में प्रबंधकों द्वारा अज्ञानता के कुछ उदाहरण दिए गए हैं:मैं नहीं समझता, क्या यह इतनी बड़ी समस्या है? यहां, कोड की कुछ पंक्तियों को जोड़ें।
तकनीकी रूप से, किसी भी समस्या को "कोड की एक जोड़ी को जोड़कर" हल किया जाता है। इससे यह आसान नहीं होता।एन का कहना है कि इस कार्य के लिए कुछ दिन पर्याप्त हैं।
हां, क्योंकि एन पहले से ही अपने समस्या क्षेत्र को अच्छी तरह से जानता है। मुझे नहीं पता, मुझे इसके अध्ययन के लिए समय चाहिए।प्रक्रिया को गति देने के लिए हम क्या कर सकते हैं? अधिक डेवलपर्स आवंटित करें?
एक नियम के रूप में, समस्या में शामिल डेवलपर्स की संख्या में वृद्धि, केवल इसे बढ़ा देती है। कुछ तेजी से करने का एकमात्र तरीका छोटी समस्याओं से शुरू करना है।लेकिन सबसे खराब चीज जो आप कर सकते हैं वो है डेवलपर्स को बताना कि आपने एक बार प्रोग्राम भी किया था। कृपया ध्यान दें कि अतीत में एक पेशेवर डेवलपर होने के नाते यह बिल्कुल भी नहीं है। एक डेवलपर, जो एक प्रबंधक बन जाता है, एक नियम के रूप में, अंतिम अवधि के दौरान कुछ कौशल रखता है (एक नियम के रूप में, यह पांच साल है, फिर प्रौद्योगिकियां पहले से पूरी तरह से बदल रही हैं)। लेकिन जो लोग पेशेवर सॉफ्टवेयर विकास में कभी शामिल नहीं हुए हैं, उनके लिए अपने शौक को अपने आप में बनाए रखना बेहतर है, क्योंकि यह उनके भोलेपन के सबूत के रूप में उपयोग करता है।(अगर निष्पक्षता में, तो डिजाइनर भी इस तरह के अज्ञान से ग्रस्त हैं। हर कोई खुद को डिजाइन विशेषज्ञ मानता है, क्योंकि हर कोई सुंदर चीजों को पसंद करता है। लेकिन यह आपको पेशेवर डिजाइनर नहीं बनाता है।)अधिक दाई
डेवलपर्स को "एक टीम में सात nannies" की समस्या का सामना करना पड़ रहा है। चूंकि हम लगातार कार्यों को पूरा करने के लिए वास्तविक समय सीमा को कम आंकते हैं, इसलिए अधिकांश सॉफ्टवेयर देर से निकलते हैं। भले ही वे बड़ी कंपनियां हों या छोटी कंपनियां, अनजान स्टार्टअप या प्रतिष्ठित उत्पाद, सभी देर से निकलते हैं। लगातार विलंबता प्रबंधकों को परेशान करती है जो आमतौर पर तय करते हैं कि पूरी समस्या डेवलपर्स की कमी है। वे कहते हैं, '' तो हम और लोगों को बाहर निकाल दें, '' यह हमारी सारी समस्याओं को हल कर देगा।कभी-कभी, कोई संदेह नहीं है, डेवलपर्स की संख्या में वृद्धि से समस्या हल हो सकती है। ज्यादातर मामलों में, उनका अलगाव केवल अतिरिक्त कठिनाइयों की ओर जाता है। एक टीम में काम करने के लिए रचनात्मक लोगों को प्राप्त करना आसान नहीं है, लेकिन जितना अधिक वे एक टीम में होते हैं, उतना ही मुश्किल यह करना है। डेवलपर्स को केवल बेकार बैठने की अनुमति नहीं है - जैसे ही प्रबंधकों ने फैसला किया कि उनके पास करने के लिए कुछ भी नहीं है, वे तुरंत उनके लिए नौकरी लेकर आए।इसी तरह की एक बात पूरी तरह से बेतुके रूप में मेरे साथ हुई। हमने एक छोटी सी टीम के साथ याहू होमपेज के स्क्रैच निर्मित डिज़ाइन से एक नया विकसित किया। यह एक आदर्श परियोजना थी, हमने एक छोटे समूह में पृष्ठ वास्तुकला का एक मूल समूह तैयार किया, और किसी ने हमें परेशान नहीं किया। हमने डिज़ाइन को समाप्त कर दिया, और एक प्रोटोटाइप विकसित करना शुरू करने के लिए तैयार थे, क्योंकि हमें आठ नए डेवलपर्स आवंटित किए गए थे। इसके अलावा, हमें निर्देश दिया गया था कि ये डेवलपर्स तुरंत एक नया पेज प्रोग्रामिंग करना शुरू करें। वह दूसरा काम क्या था, क्योंकि उसके अंतिम रूप में वास्तुकला अभी तक मौजूद नहीं थी! लेकिन डेवलपर्स को बेकार नहीं छोड़ा जा सकता है, उन्हें एक परियोजना सौंपी गई है, जिसका मतलब है कि उन्हें एक कार्य दिए जाने की आवश्यकता है। चिकन और अंडे के बारे में एक क्लासिक समस्या।एक आदर्श स्थिति में, हम पहले प्रोटोटाइप आर्किटेक्चर को समाप्त करेंगे, और उसके बाद ही इसके कार्यान्वयन के लिए अतिरिक्त डेवलपर्स प्राप्त करेंगे। वास्तव में, हम फंस गए हैं। नतीजतन, मैंने एक और प्रोजेक्ट से पहले से तैयार आर्किटेक्चर का उपयोग करने का फैसला किया, उसके लिए एक सरल इंटरफ़ेस लिख रहा था जिसके माध्यम से मैं इसे एक नए के रूप में संदर्भित कर सकता था। डेवलपर्स अपना काम शुरू करने में सक्षम थे, और हम वास्तुकला के विकास को जारी रखने में सक्षम थे। यह एक भयानक समस्या का एक भयानक समाधान था जो अंततः तब काम करना बंद कर देता था जब डेवलपर्स इंटरफ़ेस के उस हिस्से को मिलता था जो अभी तक लागू नहीं हुआ था। नतीजतन, मुझे अपने प्रबंधक को बताना पड़ा कि अगर हमें नई वास्तुकला को खत्म करने के लिए समय नहीं दिया गया, तो हमारे साफ सुथरे घर जल्दी से अलग हो जाएंगे।एक टीम पर बहुत सारे डेवलपर्स एक परियोजना को बहुत जटिल कर सकते हैं। बेशक, वे एक-दूसरे से स्वतंत्र कार्यों पर काम कर सकते हैं, लेकिन, एक नियम के रूप में, किसी भी परियोजना में ऐसे कार्यों की संख्या इतनी महान नहीं है। जितने अधिक डेवलपर प्रोजेक्ट में शामिल होते हैं, उतना अधिक समय विकास पर नहीं, बल्कि योजना बनाने और टीम वर्क के संगठन पर खर्च होता है। यदि आप घर बनाने के रूपक पर लौटते हैं, तो पहले निर्माण करने से पहले आप दूसरी मंजिल का निर्माण नहीं कर सकते। अधिकांश सॉफ्टवेयर विकास कार्य बदले में सख्ती से किए जाते हैं, इसलिए अतिरिक्त संख्या में डेवलपर्स के आवंटन से विकास प्रक्रिया में तेजी नहीं आएगी। जैसा कि मेरे पूर्व सहयोगियों में से एक ने कहा, चाहे आप कितनी भी महिलाएं हों, आप नौ महीने से पहले बच्चे को जन्म नहीं दे पाएंगी (वास्तव में, फ्रेड ब्रूक्स की पुस्तक पौराणिक पुरुष-माह का प्रसिद्ध उद्धरण) ।बड़ बड़
इसलिए, हर दिन हमें जानकारी की कमी, बदलती आवश्यकताओं, समस्या क्षेत्र और हमारे विचारों का अनुमान लगाने वाले सहयोगियों की समझ की कमी का सामना करना पड़ता है। रचनात्मक लोगों के रूप में, हम यह सब केवल इसलिए करते हैं क्योंकि हमारे काम का परिणाम जीवित लोगों द्वारा उपयोग किया जाएगा। यहां डेवलपर्स का मुख्य प्रेरक है - यह विचार कि हम जिन लोगों के बारे में भी नहीं जानते हैं, उनके जीवन हमारे प्रयासों के कारण बदल जाएंगे, चाहे हम प्रति दिन एक लाख विज़िट के साथ साइट पर काम करें या एक रेस्तरां श्रृंखला के लिए बिक्री प्रणाली।मैं एक बार फिर से दोहराता हूं - डेवलपर्स "बर्न आउट" नहीं करते क्योंकि काम कठिन है, लेकिन क्योंकि निर्देश लगातार बदल रहे हैं, और रिलीज की तारीख में देरी हो रही है।
जब रिहाई में देरी होती है क्योंकि किसी ने फिर से अपना मन बदल दिया, तो हम भयानक grumblers में बदल जाते हैं। पागल ग्रंट। हमारा सपना, अंतिम उपयोगकर्ताओं के लिए हमारे प्रयासों का परिणाम लाने के लिए, फिर से एहसास होने से रोक दिया गया था - एक डिमोटीवेटर से भी बदतर नहीं। हैरानी की बात है, डेवलपर्स शायद ही कभी पूर्णतावादी हैं। हम इस बात से सहमत हैं कि सबसे अच्छाई का दुश्मन है, और हम अपने काम को धीरे-धीरे करने के लिए तैयार हैं, फिर इसे एक बड़े पूरे में मिलाने के लिए। क्यों?
क्योंकि यह हमारे काम को समय पर लोगों तक पहुंचाने का एकमात्र तरीका है।नहीं, हम समझते हैं कि देरी सॉफ्टवेयर विकास प्रक्रिया का एक अभिन्न अंग है। डेवलपर्स दस के लिए काम करने के लिए तैयार हैं, अगर केवल उनके द्वारा निर्धारित समय सीमा के लिए समय में हो। हम दिन में बारह घंटे काम करने के लिए तैयार हैं, इसे केवल एक सामान्य परिणाम की ओर ले जाएं।धन्यवाद कहो? और क्या
डेवलपर्स के रूप में, हमें ऑपरेटिंग मोड की आदत होती है जो अन्य कर्मचारियों के मोड से बिल्कुल अलग है। जब आधी रात को सर्वर या असेंबली में कुछ टूट जाता है, तो यह डिजाइनर के पास प्रबंधक के साथ नहीं है जो उठता है, लेकिन डेवलपर (हालांकि मुझे पता है कि प्रबंधकों को उन्हें जागने की आवश्यकता है)। एक दिन उन्होंने मुझे ठीक तभी बुलाया जब मैं लड़की को डेट पर छोड़ने वाला था। मेरे जोड़े ने धैर्यपूर्वक एक घंटे तक मेरी प्रतीक्षा की, जबकि मैंने समस्या को ठीक करने का असफल प्रयास किया। अंत में, उसने छोड़ दिया (मैं उसे दोष नहीं दे सकता), मुझे आईआरसी क्लाइंट में अपने काम और सहयोगियों के साथ अकेले पीड़ित होने के लिए छोड़ दिया।उसी समय, कुछ डेवलपर्स एक लंबे कार्य दिवस के बारे में बहुत शिकायत करते हैं या कि वह एक और बग के कारण रात में जाग गया था। हमारी परियोजना हमारे लिए एक बच्चे की तरह है, और हम उसकी देखभाल और देखभाल करने के लिए तैयार हैं। यदि आपको उसे सुबह दो बजे खिलाने की आवश्यकता है, तो कोई समस्या नहीं है। यदि उसे सप्ताहांत पर समय निकालने की आवश्यकता है, तो हम हमेशा उसे ढूंढते हुए, मुस्कुराते हुए कहेंगे कि हमारी रचना कैसे बढ़ती है।डेवलपर्स विशेष रूप से खुश होते हैं जब उन्हें कार्य पूरा करने का अवसर दिया जाता है। कोई भी पत्र भेजने की खुशी के साथ तुलना नहीं कर सकता है कि कार्य पूरा हो गया है और समीक्षा के माध्यम से जाने के लिए तैयार है। लेकिन उनकी खुशी तुरंत गायब हो जाती है, जब प्रतिबद्ध होने के 10 मिनट बाद, कीड़े उनके हौसले से बनाए गए ब्रेनचाइल्ड को लिखे जाते हैं।उनकी जगह खुद की कल्पना करो। आपने पूरे दिन (या सप्ताह (या महीने)) कार्य पर बिताया और इसके साथ मुकाबला किया। आप उस काम से गर्व की भावना से अभिभूत हैं जो आपके पास पहले नहीं था ज्ञान की आवश्यकता हो सकती है। आप सभी चाहते हैं कि आप वापस बैठें और अपनी उपलब्धियों की प्रशंसा करें। इससे भी बेहतर अगर कोई आपके काम के लिए आपकी तारीफ करे। और आपको क्या मिलता है? बग संदेश यह काम नहीं करता है, यह उस तरह से काम नहीं करता है, आदि। हमें निराश भावनाओं में कीड़े पर काम करना शुरू करना होगा।हम क्यों नहीं कहते हैं
उपरोक्त सभी को संक्षेप में प्रस्तुत करने के लिए, मुख्य कारणों पर प्रकाश डालते हैं कि डेवलपर्स क्यों नहीं कहते हैं (या सिर्फ गड़गड़ाहट):- विकास के बिल्कुल अंत में एक नई आवश्यकता दिखाई दी, और इसके कार्यान्वयन के लिए बिल्कुल समय नहीं है;
- नई आवश्यकता पहले की गई धारणाओं का खंडन करती है ताकि परियोजना को धीमा न किया जाए;
- नई आवश्यकता पिछले वाले से पूरी तरह विपरीत है;
- एक और तरीके से नई आवश्यकता से काम की मात्रा बढ़ जाती है, जो समय सीमा को पूरा करती है;
- हम इतने थक गए हैं कि किसी भी नई आवश्यकता को लागू करने के लिए अविश्वसनीय रूप से मुश्किल लगता है, और हम स्पष्ट रूप से इसे पूरा नहीं करना चाहते हैं।
ध्यान रखें कि इनमें से प्रत्येक समस्या, पहले के अपवाद के साथ, थोड़े समय में काम करने की स्थिति से जुड़ी है। हम सभी कार्यों को समय सीमा तक पूरा करना चाहते हैं - लेकिन यह कैसे करें जब वे हमारे काम के दौरान लगातार बदल रहे हैं? जब ऐसा होता है, तो हमारे असंतोष (और क्रोध) की कोई सीमा नहीं होती है, और सजा पूरी करने से पहले "नहीं" भी उड़ जाता है।खिला और देखभाल
तो प्रबंधक व्यवहार में इस बड़बोलेपन से कैसे निपटते हैं? आइए याद करते हैं कि कौन से डेवलपर्स ड्राइव करते हैं:- बनाने की इच्छा;
- समस्याओं को हल करने की इच्छा;
- व्यापार में हमारे काम का परिणाम देखने की इच्छा।
अब इस बारे में सोचें कि इस सूची में क्या नहीं है। मनी। बढ़ते नकद पुरस्कार शायद ही कभी डेवलपर्स को संतुष्ट करते हैं। यह एक अश्लील स्टैंप की तरह लगता है, लेकिन डेवलपर्स के लिए, सच्चाई पैसे के बारे में नहीं है। पैसा उन्हें अपनी खुशी के लिए जीने का अवसर देता है, लेकिन दिल से वे मुख्य रूप से विकास प्रक्रिया में ही रुचि रखते हैं। और सबसे अधिक मुख्य बात जो उन्हें चाहिए वह है सामान्य कामकाजी परिस्थितियों में इससे निपटने की क्षमता।तो आप डेवलपर्स के लिए सामान्य स्थिति कैसे बना सकते हैं?उनके साथ काम करें
डेवलपर्स डिजाइनरों के साथ उत्पाद प्रबंधकों के रूप में रचनात्मक हैं, इसलिए आपको उन्हें रचनात्मक प्रक्रिया में शामिल करने के लिए ध्यान रखने की आवश्यकता है। मंथन और आवश्यकताओं की चर्चा बैठकों के दौरान डेवलपर्स के पास कोई समान नहीं है। डेवलपर्स को प्रोजेक्ट टीम के साथ मिलने और सीधे उनके साथ काम करने का अवसर दें (लेकिन जरूरी नहीं कि एक ही बार में)। दूसरे शब्दों में, यथासंभव रचनात्मक प्रक्रिया में डेवलपर्स को शामिल करें। कोई भी इसे पसंद नहीं करता है जब वे इसमें स्पष्टीकरण के बिना विनिर्देशों के साथ दस्तावेज फेंकते हैं।डेवलपर्स सीमा के लिए तार्किक हैं, इसलिए शुरुआती बैठकों में उनकी उपस्थिति से उन्हें यह समझने में मदद मिलेगी कि आवश्यकताएं क्या हैं और कई समस्याओं को हल करने से पहले वे भी दिखाई देते हैं। जब डेवलपर्स को बिल्डरों की तरह व्यवहार किया जाता है, तो वे लगातार सवाल पूछते हैं, और यह विकास की प्रक्रिया को धीमा कर देता है। जब डेवलपर्स को रचनात्मक कार्यशाला में सहयोगियों की तरह व्यवहार किया जाता है, तो उनके पास कम सवाल होते हैं और विकास तेजी से होता है।यह भी महत्वपूर्ण है कि डेवलपर्स अक्सर बेहतर जानते हैं कि क्या किया जा सकता है और क्या नहीं। उदाहरण के लिए, फ्रंट-एंड डेवलपर्स बाकी के बहुत पहले एक ब्राउज़र में क्या लागू किया जा सकता है, इसके बारे में जानेंगे। इस ज्ञान को बाकी लोगों के साथ साझा करके, हम अपनी क्षमताओं के आधार पर उत्पाद को बेहतर बनाने के नए विचारों के जन्म को भड़का सकते हैं। कल्पना कीजिए कि आप फ़ोटो अपलोड करने के लिए एक साइट के साथ आते हैं और यह नहीं जानते कि आप उन्हें सीधे अपने डेस्कटॉप से ब्राउज़र में फेंक सकते हैं? यह इसके डिजाइन को कैसे प्रभावित करेगा?इसलिए, डेवलपर्स को प्रोजेक्ट की शुरुआत से ही रचनात्मक प्रक्रिया में भाग लेने का अवसर दें। परियोजना के बारे में उनकी राय सुनें और तकनीकी रूप से लागू करना संभव है। जितना कम हम सोचते हैं कि हमें बताया जाता है कि क्या करना है, उतना ही हम दूसरे लोगों की राय सुनते हैं और अपना काम बेहतर तरीके से करते हैं। इसे प्राप्त करने का एकमात्र तरीका हमें परियोजना पर रचनात्मक कार्य में भाग लेने देना है।रचनात्मक माहौल बनाएं
चलो डेवलपर्स के रूप में रचनाकारों के बारे में सोचते हैं। हमें सभी संभावनाएं देने की कोशिश करें ताकि हम अपनी रचनात्मक क्षमताओं को दिखाएं। हैकडे और हैकोटन संयोग से लोकप्रिय नहीं हैं - वे लोकप्रिय हैं क्योंकि वे डेवलपर्स को कोड और विकास के अपने प्यार को रचनात्मक रूप से पुनर्जीवित करने की अनुमति देते हैं। Hackotones पर, डेवलपर्स पूरी तरह से रचनात्मकता के लिए समर्पित होते हैं, अपने सामान्य कार्यों की सीमाओं से मुक्त होते हैं।एक बार एक चौथाई, एक हैकॉडी डेवलपर्स को खुशी देने के लिए पर्याप्त है। और चाहिए? एक विषय हैकोडी की व्यवस्था करें। सबसे रचनात्मक और व्यावहारिक समाधान, आदि के लिए पुरस्कार दें। मुख्य कार्य डेवलपर्स को बनाने देना है, ताकि, अपने सामान्य काम पर लौटकर, वे अपनी परियोजनाओं को विकसित करने और सुधारने के लिए अपने आप में ताकत महसूस करें।ध्यान रखें कि यह न केवल डेवलपर्स पर लागू होता है। हर अब और फिर वे रचनात्मक काम करना चाहते हैं। लेकिन मेरे अनुभव में, उत्पाद प्रबंधकों और डिजाइनरों के पास इसके लिए बहुत अधिक विकल्प हैं। प्रबंधकों और डिजाइनरों के लिए सभी प्रकार के प्रशिक्षण और सम्मेलन नियमित रूप से आयोजित किए जाते हैं, लेकिन डेवलपर्स अक्सर भूल जाते हैं।वैसे, हैकॉट्सन केवल रचनात्मक वातावरण बनाने का एकमात्र तरीका नहीं है, लेकिन पहले चरण के रूप में यह सबसे आसान है। आप डेवलपर्स की रचनात्मक भावना को भी सम्मेलनों में भेजकर उन्हें जागृत कर सकते हैं, उन्हें कंपनी के खर्च पर किताबें खरीदने की अनुमति दे सकते हैं, जिससे वे उन परियोजनाओं के बारे में विचार साझा कर सकते हैं, जिन पर वे काम कर रहे हैं। हर कोई जानता है, उदाहरण के लिए, Google डेवलपर्स को अपनी खुद की परियोजनाओं को विकसित करने के लिए 20% समय देता है। यह सब आपके डेवलपर्स के साथ लंबी और स्थायी दोस्ती की शुरुआत को जन्म दे सकता है।काम करते समय हम नियमित रूप से खर्च करने वाले घंटों के मानसिक प्रयासों को देखते हुए, यह स्पष्ट हो जाता है कि डेवलपर्स को ब्रेक लेने के लिए याद रखना आवश्यक है। दुर्भाग्य से, हम अपने समय की योजना बनाने में बहुत कम सफलता प्राप्त करते हैं। ऐसा होता है कि हम काम में इतने डूब जाते हैं कि हम छुट्टी के बारे में भूल जाते हैं। अपने करियर के पहले पाँच वर्षों में, मैंने कुल सात दिन की छुट्टी ली, ऐसा लगता है। मैं नहीं जानता कि क्यों, लेकिन हम नहीं जानते कि अपने तनाव को कैसे दूर किया जाए - और यह एक बड़ी समस्या है।
डेवलपर्स का बर्नआउट इस मायने में अनूठा है कि हम इस राज्य में काम करने के आदी हैं। लेकिन यह अपने चरम पर पहुंचने के लिए बर्नआउट के लायक है, और हम दूसरी नौकरी की तलाश करने के लिए छोड़ देते हैं और छोड़ देते हैं। इसके अलावा, लगभग कोई भी डेवलपर्स आपको कभी नहीं बताएगा कि उनके पास सहन करने की कोई ताकत नहीं है; उन्हें इसके लिए बहुत गर्व है। अपनी पिछली टीम में, मैंने सभी डेवलपर्स को तुरंत आने के लिए कहा, जैसे ही उन्हें लगा कि वे सभी थक गए हैं। मैं नहीं चाहता था कि उन्हें तब तक सहना पड़े जब तक कि उनके लिए एकमात्र रास्ता बर्खास्त न हो जाए। मुझे उन्हें काम छोड़ने और काम का आनंद लेने की आवश्यकता नहीं थी, और इसे प्राप्त करने का एकमात्र तरीका यह समझना है कि वे कब जलना शुरू करेंगे।
डेवलपर्स को छुट्टियां लेने के लिए प्रोत्साहित करें। आपकी कंपनी छुट्टी के लिए एक निश्चित समय प्रदान करती है - इसलिए सुनिश्चित करें कि डेवलपर्स ने इसे हर 4-5 महीनों में कम से कम एक बार लिया। यह सबसे अच्छा है अगर प्रोजेक्ट शेड्यूल की निगरानी करने वाले प्रबंधक ऐसा करते हैं।
छुट्टियों के दौरान नियमित रूप से आराम करने से डेवलपर्स को अपनी रचनात्मक शक्तियों को बहाल करने का अवसर मिलता है, जिससे उन्हें लगातार समय सीमा खत्म होने से बचाया जाता है। हां, छुट्टियों के दौरान हम शायद विकास में लगे रहेंगे, लेकिन हम अपनी परियोजनाओं में विशेष रूप से लगे रहेंगे, न कि श्रमिकों से। इस तरह के काम से हमें ऊर्जा हासिल करने और नई लड़ाई के लिए तैयार होने में मदद मिलेगी।
उन्हें विकास करने दें
जैसा कि लगता है कि विडंबना है, कई कंपनियां डेवलपर्स को किराए पर लेती हैं और फिर उन्हें विकसित होने से रोकती हैं। इसके बजाय, उनके दिन उत्पादकता को कम करने वाली बेकार बैठकों से भरे हुए हैं। सामान्य तौर पर, डेवलपर्स सबसे प्रभावी होते हैं जब वे विचलित हुए बिना कम से कम चार घंटे तक कोड पर बैठ सकते हैं।
प्रोग्रामिंग के दौरान एक अच्छा "स्ट्रीम" प्राप्त करना हमेशा मुश्किल होता है जब आप जानते हैं कि आपको कुछ घंटों में एक बैठक में होना चाहिए। विकास प्रक्रिया के लिए प्रक्रिया से अधिक अनुत्पादक कुछ भी नहीं है, जिसके दौरान आप पहले घंटे कोड लिखते हैं, फिर एक घंटे के लिए ब्रेक करते हैं, फिर घंटे कोड फिर से लिखते हैं, एक और घंटे के लिए तोड़ते हैं, आदि। प्रोग्रामिंग के लिए "सही" स्थिति पर स्विच करने के लिए डेवलपर के मस्तिष्क को कुछ समय चाहिए।
यह सुनिश्चित करने की कोशिश करें कि डेवलपर्स के पास निरंतर प्रोग्रामिंग के लिए दिन में कम से कम चार घंटे हैं। विकास को गति देने का यह एकमात्र तरीका है। यह काफी तार्किक है: यदि लोग दिन में आठ घंटे काम करते हैं, तो उन्हें इस समय का कम से कम आधा हिस्सा अपने मुख्य कार्यों पर खर्च करना चाहिए। उदाहरण के लिए, मुझे पता चला कि मेरे लिए सबसे अधिक उत्पादक अवधि दोपहर एक से पांच के बीच का समय है। अगर मैं हर दिन इस समय काम कर सकता था, तो मैं आसानी से अपने सभी कार्यों का सामना कर सकता था। जिन दिनों में यह समय बैठकों में बाधित होता है, मैं समझता हूं कि मैं आज बहुत कुछ नहीं कर पाऊंगा।
और सप्ताह में कम से कम एक दिन बिना मीटिंग के करते हैं, जिसमें दैनिक मक्खियाँ भी शामिल हैं। डेवलपर्स के पास एक दिन है जिसमें वे स्वतंत्र रूप से अपना समय वितरित कर सकते हैं और सभी मामलों से निपट सकते हैं। आप विश्वास नहीं करते कि आप एक दिन में कितना कर सकते हैं जो पूरी तरह से विक्षेपों से मुक्त है। एक समय में, मेरे प्रबंधक ने यह भी मांग की कि मैं सप्ताह में कम से कम दो दिन घर से काम करता हूं, क्योंकि कार्यालय में मैं लगातार विचलित था। परिणामस्वरूप, मैंने अविश्वसनीय गति से काम किया।
आभार व्यक्त करें
महत्वपूर्ण परिणाम प्राप्त करने के बाद अभी कुछ किया जा सकता है। मैंने पहले ही ऊपर उल्लेख किया है कि जब आप कार्य को पूरा करते हैं, तो कीड़े कैसे होते हैं, और बग्स को पहले ही लिखा जा चुका है। डेवलपर्स के पास शायद ही कभी दुबला होने और किए गए कार्यों की प्रशंसा करने का मौका होता है, न कि सुनवाई धन्यवाद का उल्लेख करने के लिए।
डेवलपर को धन्यवाद का एक छोटा पत्र जिसने अभी कार्य पूरा किया है, अविश्वसनीय सफलता प्राप्त कर सकता है, खासकर यदि कार्य कठिन था। यहां तक कि अगर आप सिर्फ कहते हैं: "सुनो, काम के लिए धन्यवाद, मैं निश्चित रूप से देखूंगा," यह उस उदास मनोदशा को दूर करने के लिए पर्याप्त होगा जो तब होता है जब बग की पहली धारा प्रकट होती है। डेवलपर्स के लिए अपने काम की सराहना करना बहुत महत्वपूर्ण है, क्योंकि उन्हें प्राप्त होने वाली अधिकांश प्रतिक्रिया नकारात्मक है - बग, समस्याएं, आदि। एक तरह के शब्द, और यह सब इतना डरावना नहीं लगता।
यह बहुत अच्छा होगा यदि आप इनाम की तरह कुछ असाइन करते हैं, जो प्रत्येक तिमाही के लिए डेवलपर को दिया जाएगा जिसने सबसे अधिक प्रयास किया है, सबसे सुधारों को लागू किया है, आदि। पुरस्कार को iPad की तरह कुछ महंगा और वांछनीय नहीं होना चाहिए (हालांकि हम इसे कृतज्ञतापूर्वक स्वीकार करते हैं), यह सिर्फ एक छोटा सा उपहार और पूरी टीम या विभाग को योग्यता की स्वीकृति का पत्र हो सकता है।
और कृपया, जब आप लोगों को किए गए काम के लिए धन्यवाद देते हैं, तो कभी भी डेवलपर्स के बारे में न भूलें। मैंने अनगिनत परियोजना बैठकों में भाग लिया जहां सभी ने प्रबंधकों या डिजाइनरों के काम की प्रशंसा की, जबकि उन डेवलपर्स के बारे में पूरी तरह से भूल गए जिनके पसीने, रक्त और आँसू ने परियोजना को जीवन में लाया। प्रत्येक परियोजना की सफलता तीन समूहों में से प्रत्येक के प्रयासों पर निर्भर करती है; कोई भी समूह अकेले इसे पूरा नहीं कर सकता है। सुनिश्चित करें कि आपकी कंपनी पूरी टीम के प्रयासों को पहचानती है, न कि इसके कुछ हिस्सों को।
निष्कर्ष
हम, डेवलपर्स, एक नियम के रूप में, बकाया लोग हैं। हम सभी निश्चित रूप से व्यक्तित्व हैं, और हम वास्तव में सर्वोत्तम संभव परिणाम प्राप्त करना चाहते हैं। यदि आप हमें गलत लड़कों की तरह व्यवहार करना बंद कर देते हैं और रचनात्मक प्रक्रिया के हिस्से के रूप में हमारा सम्मान करना शुरू करते हैं, तो आप थोड़े समय में उत्कृष्ट परिणाम प्राप्त करेंगे। जिन टीमों में मैंने काम किया, उनमें हमेशा किसी न किसी तरह का घर्षण होता था, जो डेवलपर्स की सोच और प्रेरणा के तरीके की कमी के कारण पैदा हुआ था। मुझे पूरी उम्मीद है कि यह लेख डेवलपर्स और उनके सहयोगियों के बीच बातचीत को बेहतर बनाने में मदद करेगा। यह इतना मुश्किल नहीं है - हमें बस समग्र समाधान का हिस्सा महसूस करने की आवश्यकता है, न कि एक साधारण कामकाजी मधुमक्खी।