प्रोग्रामर डेडलाइन क्यों तोड़ते हैं

शुरू करने के बजाय

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



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

प्रबंधक (एन्जिल्स की भूमिका)

प्रोजेक्ट मैनेजर सफलता का एक महत्वपूर्ण घटक है। मैं यह भी कहूंगा कि एक बुद्धिमान प्रबंधक होने में 50% सफलता है। और ऐसे व्यक्ति की अनुपस्थिति 90% विफलता है। प्रबंधक इतना महत्वपूर्ण क्यों है? जवाब आसान है। प्रबंधक के पास संगठन में प्रोग्रामर और प्रक्रिया दोनों का प्रबंधन करने के लिए पर्याप्त शक्ति और प्रभाव है।



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



आमतौर पर, औसत दर्जे का प्रबंधक निम्नलिखित गलतियाँ कर सकता है, जिसके परिणामस्वरूप शर्तों में देरी होती है:

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

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



एक अच्छे प्रबंधक में निहित विशेषताएं: पुरुषत्व, इच्छाशक्ति, ईमानदारी, खुलेपन और समाजक्षमता, रचनात्मक आलोचना और आत्म-आलोचना, न्याय, संरक्षण।

प्रोग्रामर (किसानों की भूमिका)

मैं प्रोग्रामरों के एक समूह के रूप में "शुद्ध" सिस्टम आर्किटेक्ट भी शामिल करता हूं। यदि वास्तुकार लोगों और प्रक्रियाओं का प्रबंधन भी करता है, तो ऊपर वर्णित प्रबंधकीय आवश्यकताएं उसके लिए उन्नत हैं।



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



डेवलपर को स्वयं और दूसरों द्वारा लिखे गए कोड के लिए महत्वपूर्ण होना चाहिए, सलाह और काम के साथ सहयोगियों का समर्थन करने में सक्षम होना चाहिए, किसी और की सलाह के खिलाफ भेदभाव न करने में सक्षम होना चाहिए, भले ही यह अनुरोध न किया गया हो।



मुझे यकीन है कि कोई भी प्रबंधक प्रोग्रामर की सराहना करेगा यदि वह काम के समय के साथ समस्याओं के बारे में पहले से पहले चेतावनी दे सकता है। व्यक्तिगत रूप से, पहले तो मेरे लिए अपने बॉस को यह बताना बहुत मुश्किल था कि इस तरह के "फीचर्स" को लागू नहीं किया जाएगा, और बग्स को "निश्चित" किया जाएगा। लेकिन समय के साथ, मुझे एहसास हुआ कि इसे जल्द से जल्द किया जाना चाहिए, ताकि आप कार्यों को प्राथमिकता दे सकें। यह संभवतः अपने स्वयं के नेतृत्व के साथ समस्याओं से प्रबंधक के "गधे को ढंकने" का सबसे अच्छा तरीका है, क्योंकि जैसा कि आप जानते हैं, "चेतावनी - मतलब सशस्त्र।"



और यहाँ एक प्रोग्रामर समय सीमा के साथ क्या कर सकता है:

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

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

संचार

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



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

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

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



एक अलग लेख डेवलपर्स की एक बड़ी टीम को एक बड़े कमरे में रखने के विषय के योग्य है "ताकि वे बेहतर काम करें और अधिक बारीकी से संवाद करें।" मुझे यकीन है कि यह निर्णय प्रतिभागियों पर अत्यधिक निर्भर है। व्यक्तिगत रूप से, मैं शोर में काम नहीं कर सकता, लेकिन 10+ लोगों की टीम में, हमेशा कोई न कोई बात कर रहा होता है। इसलिए इस तरह के निर्णय लेने से पहले सावधान रहें।

प्रक्रियाएं (कानून)

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



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



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



प्रक्रिया का उल्लंघन पैदा कर सकता है:

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

ये घटनाएं प्रत्यक्ष या अप्रत्यक्ष रूप से कार्यों के निष्पादन समय को नकारात्मक तरीके से प्रभावित करती हैं।

आम उपकरण

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



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

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

कक्षा पुस्तकालय और रूपरेखा

प्रोग्रामर की भूमिका से दूर हुए बिना, मैं अन्य लोगों के कोड के साथ समस्याओं पर संपर्क करूंगा। आंगन में इक्कीसवीं सदी है और अब हम वास्तव में "साइकिलों के लेखन" (या पहियों) का स्वागत नहीं करते हैं। अधिकांश कार्यक्रमों को कूल थर्ड-पार्टी लाइब्रेरी या पूरे फ्रेमवर्क का उपयोग करके लिखा जाता है। RoR, Drupal, .NET Fw, Qt (स्वयं सूची जारी रखें) वह सब है जो हमें तुरंत एक उत्पाद लिखने में मदद करता है, न कि इसकी नींव। लेकिन एक छोटा "लेकिन" है: लोग अक्सर गलतियाँ करते हैं। सबसे खराब, अगर हमने (या किसी और ने) सॉफ़्टवेयर विकास के लिए एक उपकरण की पसंद के साथ गलती की। इस मामले में, हमें डिज़ाइन चरण और उत्पाद लेखन चरण में समय खोने के लिए मजबूर किया जाता है, अगर आप अभी भी इसे एक उपयुक्त मंच पर फिर से नहीं लिखते हैं।



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



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

प्रतिबंध

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

नोट: लेख के संदर्भ में "प्रोग्रामर" और "डेवलपर" शब्द एक दूसरे के पर्याय हैं। साथ ही साथ शब्द "प्रबंधक", "प्रबंधक", "नेता"।