12 कारक जो प्रोग्रामर को काम करने से रोकते हैं

किसी को कंप्यूटर तक पहुंच के बिना डेवलपर को कोड लिखने की आवश्यकता नहीं होगी, लेकिन कई कंपनियों का मानना ​​है कि उसे अपनी मानसिक क्षमताओं का पूरी तरह से उपयोग करने की क्षमता के बिना किसी तरह काम करना चाहिए। और यह अवास्तविक है।



और इसलिए चलो बारह चीजों की एक सूची से गुजरते हैं जो डेवलपर्स को एक स्ट्रीम राज्य में प्रवेश करने और अधिकतम उत्पादकता देने से रोकती हैं। मैं सबसे महत्वपूर्ण चीजों से कम महत्वपूर्ण में जाने की कोशिश करूंगा। अपने विकल्पों और टिप्पणियों का सुझाव दें!

यदि किसी को संदेह है कि क्या इस पर पैसा और प्रयास खर्च करने लायक है, तो यह याद रखना पर्याप्त है कि प्रोग्रामर को कितना भुगतान किया जाता है। यहां तक ​​कि उत्पादकता में 10% की वृद्धि नकदी में बहुत कुछ है!

1) बैठकें और अन्य व्यवधान

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

“जब मैं किसी कार्य को शुरू करने की कोशिश करता हूं तो अधिक बार मैं विचलित हो जाता हूं, प्रयासों के बीच अधिक समय बीतने लगता है। अगर मुझे पूरी सुबह खींच लिया जाता है, तो आश्चर्यचकित होने की कोई बात नहीं है, यह दिन अनुत्पादक हो गया है - "Reddit के साथ बेनामी डेवलपर

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

जैसा कि पॉल ग्राहम ने कहा: "एक बैठक आधे दिन को मार सकती है: समय को दो अवधियों में विभाजित किया जाता है, जिसके लिए आप गंभीर नहीं हो सकते।"

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

2) नाइटपैकिंग

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

3) अस्पष्ट

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

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

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

4) सीगल प्रबंधक

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

5) लॉरेल्स की चोरी

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

6) सामान: शोर, आंदोलन, कार्यक्षेत्र का डिज़ाइन ...

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

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

7) ऑफसेट परियोजना की सीमाएँ

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

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

उदाहरण के लिए एक साधारण कार्य करें:

• पहला संस्करण (कार्यान्वयन से पहले): फ़ंक्शन को "डिस्प्ले लोकेशन मैप" के रूप में परिभाषित किया गया है
• दूसरा संस्करण (जब पहला पुनरावृत्ति लगभग समाप्त हो गया है): विवरण "3 डी स्थान मानचित्र प्रदर्शित करें" में बदल जाता है
• तीसरा संस्करण (जब दूसरा पुनरावृत्ति लगभग समाप्त हो गया है): विवरण "एक 3 डी स्थान मानचित्र प्रदर्शित करें जिस पर उपयोगकर्ता स्थानांतरित हो सकता है"

8) उत्पाद फ़ीचर निर्धारण प्रक्रिया

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

9) तकनीकी ऋण को नजरअंदाज करना

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

10) विभिन्न प्रकार के उपकरण और उपकरण

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

11) कैसे-कैसे प्रलेखन

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

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

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

१२) अत्यंत तंग समय सीमा

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

डेवलपर्स का मानना ​​है कि इस तरह की समय सीमा पूर्ण पागलपन है और इसे अपने भीतर रखना असंभव है; टीम में कलह है और कोई भी ध्यान केंद्रित नहीं कर सकता है।

लेकिन क्या यह केवल डेवलपर्स के बारे में है?

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

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