प्रबंधन को कैसे प्रदर्शित करना है कि औसत डेवलपर्स टीम को नुकसान पहुंचा रहे हैं [बंद]


82

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

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

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

हमने जोड़ी प्रोग्रामिंग की कोशिश की, कक्षाओं के लिए भुगतान करने की पेशकश की, किताबें खरीदी, कार्य दिवस के दौरान प्रशिक्षण के लिए समय आवंटित किया और यहां तक ​​कि टीम को प्रशिक्षित करने के लिए पूरे दिन का समय लिया।

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

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

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

अन्य संसाधन क्या हैं? किताबें, लेख, सामान्य सलाह कुछ भी सहायक होगी।


20
समापन पर: C'mon! पकड़ लें!
पीटर

6
मेरे पसंदीदा में इस प्रश्न को जोड़ना पर्याप्त नहीं है। मैं इसे वॉलपेपर के रूप में सेट करने के लिए मिला हूं।
मानोस दिलवाराकिस

5
अरे, मुझे मतदान करना चाहिए, लेकिन मुझे यह सवाल पसंद है :(
IAdapter

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

5
बंद करने के लिए, व्यक्तिपरक और तर्कपूर्ण। अगर लोग सिर्फ वेंट करना चाहते हैं तो सामुदायिक विकि होना चाहिए।
जो

जवाबों:


26

क्या समस्या कौशल या क्षमता की कमी, प्रोग्रामर की ओर से रवैया की समस्याओं, या एक कॉर्पोरेट संस्कृति से है जो एक अच्छा काम नैतिक को बढ़ावा नहीं देता है?

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

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

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

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

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


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

@ जेसन: यह निश्चित नहीं है कि आपके कोड की समीक्षा में क्या हुआ था, लेकिन यह लेख कुछ अंतर्दृष्टि प्रदान कर सकता है: it.toolbox.com/blogs/puramu/…
रॉबर्ट हार्वे

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

32

मजेदार किसी ने आपको नहीं बताया कि शायद आपके पास प्रबंधन कौशल की कमी है।

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

शायद आपको एक प्रशिक्षण मिलना चाहिए।

हो सकता है कि आप के बारे में एक रिपोर्ट को पढ़ना चाहिए आप

मैं यह नहीं कह रहा हूं कि तुम पर हमला करना। हर्गिज नहीं। मैं समस्या को बहुत अच्छी तरह से समझता हूं, क्योंकि मैं अतीत में भी टीमों का प्रबंधन करने में विफल रहा।

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

उस मामले में, शिकायत करना बंद करो और काम पर लग जाओ। एक कोडर के रूप में नहीं, बल्कि एक प्रबंधक के रूप में।

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


6
मुझे समझ नहीं आता कि लोगों ने आपको वोट क्यों दिया। आप उस वैध बिंदु को बढ़ाते हैं जो सामान्य इंजीनियरों से विकसित होने वाले प्रबंधकों / प्रबंधकों को लगभग खुद कभी नहीं दिया जाता है कि लोगों को कैसे प्रबंधित किया जाए। पुराने "आप एक महान इंजीनियर हैं, इसलिए आप एक महान प्रबंधक होंगे"।
एरिच मिर्बल

1
खैर, क्योंकि यह राजनीतिक रूप से किसी को यह बताने के लिए सही नहीं है कि वह मदद के लिए कहे कि शायद वह उसकी स्थिति का कारण है। मुझे कहना होगा, मुझे यह बताया जाना पसंद नहीं है कि मैं खुद हूं, लेकिन यह आमतौर पर एक उपयोगी इलेक्ट्रोस्कॉक है।
ई-सिटिस

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

1
मैंने Manager-tools.com पर कुछ बहुत अच्छे प्रबंधन के सुझाव पाए हैं। उनके पास उपयोगी विषयों में विभाजित पॉडकास्ट है। हो सकता है कि आपकी मदद के लिए आपको वहां कुछ मिल जाए।
पॉल हिल्डेब्रांड्ट

@Paul - इसके लिए धन्यवाद, मैं निश्चित रूप से इसकी जांच करूंगा!

15

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

क्या आपके पास किसी प्रकार का टाइमकीपिंग सिस्टम है? या डेवलपर्स अपना समय लॉग करते हैं? यदि वे कहते हैं कि एक समस्या उन्हें दिनों की X संख्या में ले जाएगी और X दिनों के बाद ऐसा नहीं किया जाएगा तो आप सवाल कर सकते हैं कि ऐसा क्यों नहीं किया गया।

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

आपको शुभकामनाएँ, मुझे डर है कि आप बहुत उबड़-खाबड़ सड़क पर हैं, हालांकि ... मैं वहाँ गया हूँ और यह एक लंबी खींची हुई प्रक्रिया है।


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

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

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

6

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

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

इसके अलावा, सुनिश्चित करें कि आपको नए उम्मीदवारों के साक्षात्कार में भाग लेना है।


5

मेरी सलाह यह है:

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

आप अपने पर्यवेक्षकों के लिए जरूरी नहीं है, लेकिन यह है कि क्या होना चाहिए का सार है।


2

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

वैसे हमने BugTracker.Net का उपयोग किया ।


हमारे पास एक बग ट्रैकर और एक समय ट्रैकिंग प्रणाली है लेकिन वे एकीकृत नहीं हैं। हम किसी कार्य पर बिताए गए समय को दर्ज करने के लिए इसे अलग-अलग डेवलपर के पास छोड़ देते हैं। मुझे यह देखना होगा कि क्या हम बग ट्रैकर बनाम अनुमानित समय में पूरा करने के बीच खर्च किए गए कुल समय को ट्रैक कर सकते हैं।

मैं तब सोचूंगा कि इसका नैतिकता कर्मचारियों से जारी है जिसे आपको ध्यान केंद्रित करना होगा।
नेल्सन मिरांडा

8 घंटे एक दिन बिताने के लिए एक सुंदर जगह की तरह लगता है ... नहीं! हम कब से प्रोग्रामर फैक्ट्री वर्कर बन गए! आपके संगठन में कर्मचारियों का कारोबार कैसा है और आप कितना पैसा बर्बाद करते हैं क्योंकि आप मानव स्वभाव को समायोजित नहीं कर सकते हैं! क्या वहां काम करने वाले किसी व्यक्ति को उच्च रक्तचाप होता है! केवल एक चीज जिसे आप प्रबंधित कर सकते हैं वह एक स्वेटशोप है। उनके नमक के लायक कोई भी उस वातावरण में काम नहीं करना चाहेगा। ओह, यह मेरे कॉफी ब्रेक का समय है। ;-)
सैम

2

मुझे आश्चर्य है कि इन लोगों को पहली जगह में कंपनी में कैसे मिला:

इन डेवलपर्स के पास न केवल प्रोग्रामिंग अवधारणाओं के साथ कौशल की कमी है, बल्कि आमतौर पर कोड में एक समस्या का समाधान तैयार करने की क्षमता है।

लूप लिखने जैसी सरल बातें उनके लिए कठिन हैं ...

आपको कंपनी की आवश्यकता है, इसमें कोई संदेह नहीं है, कार्यबल की भर्ती में अधिक समय और प्रयास का निवेश करें, क्योंकि पुरानी कहावत है: जल्दबाजी बेकार कर देती है।

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


3
डेवलपमेंट स्टाफ को हायरिंग प्रक्रिया में शामिल नहीं किया गया था, इस तरह वे अंदर आ गए।

2

मैंने प्रोग्रामर को सर्वश्रेष्ठ बनने के लिए प्रोत्साहित करने के बारे में कुछ समय पहले पढ़ा था।

नर्ड हेरिंग


अद्भुत लेख। अच्छा लिंकिंग +1
स्मॉलटाउन 2

अच्छी तरह से बाधा को नहीं अवसर को पहचानने के लिए किया।
सैम

1

आपने उल्लेख किया है कि आपकी टीम के लिए आप "उनके प्रदर्शन पर प्रतिक्रिया प्रदान करते हैं"।

इसलिए:

  1. अपनी टीम के साथ बैठो।
  2. उन्हें इस पृष्ठ के प्रिंटआउट सौंपें, और उन्हें बताएं कि आपने उनके बारे में पोस्ट किया है।
  3. उन्हें इसे पढ़ने दें।
  4. समस्या को हल करने में उनकी मदद करने के लिए कहें।
  5. इसे सुनो और लिखो।
  6. उसे अपनी प्रबंधन टीम में ले जाएं।

1

Peopleware एक और पुस्तक है जो आपकी सूची में शामिल होनी चाहिए।

हालांकि, जब मैंने इसे पढ़ा तो मुझे यह व्यावहारिक नहीं लगा, क्योंकि कंपनी में कोई भी इसकी सिफारिशों की कोशिश नहीं करना चाहता था।


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

0

लगता है कि आप सही रास्ते पर हैं।

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

प्रत्येक व्यक्ति कितने समय तक कोड का उत्पादन करता है, इसका विवरण रखें।

ऊपरी प्रबंधन को संख्या दिखाएं, उन्हें अब आश्वस्त होना चाहिए।


0

किताब

कोड पूरा: स्टीव मैककोनेल द्वारा सॉफ्टवेयर निर्माण की एक व्यावहारिक पुस्तिका

एक अच्छा स्रोत है जो सर्वोत्तम प्रथाओं को सीखने में मदद कर सकता है।

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

फिर दिखाएं कि कैसे बेहतर डेवलपर्स की टीम ROI में सुधार कर सकती है।


ओपी पहले से ही बताता है कि वह कोड कम्प्लीट का उपयोग करता है। कोई और अच्छी किताबें?
अया बीबीबीबी

0

रिपोर्ट को संक्षिप्त रखें। इसे चिंताजनक न बनाएं। इसे इस बात पर रखें कि वे इस पर कितना पैसा खो रहे हैं।


0

हमारे पास अब एक उपकरण है जो हमारे कोड मॉड्यूल की जटिलता को मापता है। यह हमारे पीएल / एसक्यूएल मॉड्यूल पर चलता है, लेकिन मेरा मानना ​​है कि अन्य वातावरण पर उपलब्ध उपकरण हैं।

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

हमने एक नकली विश्लेषण उपकरण के साथ संयुक्त किया जो डुप्लिकेट कार्यक्षमता को उजागर करने में मदद करता है, और 'तकनीकी ऋण' के मूल्यांकन के रूप में यह सब पैक किया गया है।

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

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


0

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


0

एक विचार है।

मुझे लगता है कि आप एसवीएन जैसे स्रोत संस्करण नियंत्रण प्रणाली का उपयोग करते हैं। इसलिए बुरे लोगों की समीक्षा करने और उन्हें खारिज करने की नीति बनाएं। फिर बस अस्वीकार किए गए अन्य प्रबंधकों के आंकड़े दिखाते हैं कि यह साबित करने के लिए कि औसत डेवलपर्स कंपनी के लिए बहुत महंगे हैं।


0

यहाँ आपके लिए एक और विचार है: वे जो तोड़ते हैं उसे ठीक न करें। किसी ईमेल में पुन: कार्य के लिए उन्हें यह बताकर भेजें कि क्या गलत है और कैसे ठीक किया जाए (केवल सामान्य शब्दों में) और cc प्रबंध। प्रबंधन की समझ पर ध्यान देना सुनिश्चित करें कि यह आपकी अंतिम समय सीमा को कैसे प्रभावित करेगा। यह आपके लिए प्रदर्शन समस्याओं का दस्तावेज़ीकरण बनाता है और उनमें से कुछ खराब हो सकते हैं जब उन्हें अपने स्वयं के गड़बड़ को ठीक करना होगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.