मेरे मालिक ने हर बग रिपोर्ट में एक "व्यक्ति को दोष देने" फ़ील्ड को जोड़ने का फैसला किया। मैं उसे कैसे मना सकता हूं कि यह एक बुरा विचार है?

Question

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

इस प्रथा के खिलाफ कुछ अन्य मजबूत तर्क हैं जिनका मैं उपयोग कर सकता हूं? क्या इस विषय पर कोई लेखन है जिसे मैं टीम और बॉस के साथ साझा कर सकता हूं?

Comments

हे दोस्तों, मैं "बॉस" हूं जिसने डब्ल्यूटीएफ क्षेत्र की शुरुआत की है। यहाँ पर हमने हमारे बग ट्रैकिंग सिस्टम में "पेसन टू ब्लेम" फ़ील्ड को जोड़ा: news.ycombinator.com/item?id=4179298

— जेसन

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

— ulty4life

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

— gnat

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

— डैनी व्रॉड

); अपने मालिक "व्यक्ति इसके लिए जिम्मेदार", हमेशा अपने नाम को भरने और देखो वह कैसे इसे पसंद करती है

— dukeofgaming

Answer 1

उन्हें बताएं कि यह पेशेवरों द्वारा उपयोग किए जाने वाले रूट कॉज़ क्षेत्र के लिए केवल एक शौकिया नाम है (जब समस्या ट्रैकर के पास समर्पित क्षेत्र नहीं है, तो कोई भी उस के लिए टिप्पणियों का उपयोग कर सकता है)।

सॉफ़्टवेयर बग रूट कारण विश्लेषण जैसी किसी चीज़ के लिए वेब खोजें, इस तर्क ^{1 , 2 , 3 , 4 , ...} को सही ठहराने के लिए बहुत सारे संसाधन हैं ।

---

... एक दोष का मूल कारण हमेशा एक ही डेवलपर नहीं है (जो इस क्षेत्र का मुख्य बिंदु है) ...

यही कारण है कि "मूल कारण" पेशेवर है जबकि "व्यक्ति को दोष देना" शौकिया है। व्यक्तिगत जवाबदेही महान है, लेकिन ऐसे मामले हैं जब यह केवल देव टीम के "बाहर" देता है।

अपने मालिक को बताएँ जब वहाँ है इसके लिए जिम्मेदार एक एकल डेवलपर, मूल कारण क्षेत्र निश्चित रूप से है कि (कवर किया जाएगा "कोडिंग बॉब द्वारा बनाई गई गलती में 1234 के लिए प्रतिबद्ध, समीक्षा 567 में जिम द्वारा याद किया" )। शब्द मूल कारण का उपयोग करने का उद्देश्य ऐसे मामलों को कवर करना है, साथ ही उन मामलों के साथ जो देव टीम के दायरे से बाहर जाते हैं।

^{उदाहरण के लिए, यदि बग दोषपूर्ण हार्डवेयर के कारण हुआ है (व्यक्ति को उस टीम के बाहर किसी व्यक्ति को दोष देने के लिए जिसने इसे खरीदा और परीक्षण किया है), तो मूल कारण फ़ील्ड को कवर करने की अनुमति देता है, जबकि "दोष के लिए एकल डेवलपर" बस टूट जाएगा मुद्दा ट्रैकिंग प्रवाह।}

^{देव टीम के बाहर किसी अन्य व्यक्ति के कारण ऐसा ही होता है - परीक्षक की त्रुटियां, आवश्यकताओं में बदलाव और प्रबंधन के फैसले। कहते हैं, अगर प्रबंधन ने डिजास्टर रिकवरी हार्डवेयर में निवेश छोड़ने का फैसला किया, तो डेटासेंटर में बिजली आउटेज के लिए "एक ही डेवलपर को दोष देना" सिर्फ समझ में नहीं आएगा।}

Comments

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

— MK_Dev

+1 बॉस के विचार को कुछ और अधिक उत्पादक (हमेशा इस तरह से एक लड़ाई जीतने के लिए आसान) में

— पुनर्निर्देशित करने के लिए

"रूट कॉज़" उन मामलों को भी कवर करता है (उम्मीद के बहुमत!) जहां किसी भी व्यक्ति को दोष नहीं दिया जाता है, "विक्रेता सॉफ़्टवेयर विफलता", "एपीआई प्रलेखन त्रुटि", "उच्च मात्रा की अपेक्षा" जैसी चीजें।

— जेम्स एंडरसन

महान। यहां तक ​​कि एक अकेले जिम्मेदार व्यक्ति के लिए आपका उदाहरण दो लोगों को पेश करता है, जो पूरी तरह से व्यायाम की मूर्खता को दर्शाता है।

— उर्स रेपुके

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

— जान हुदेक

Answer 2

ऐसी नीति के लिए एक और संभावित परिणाम यह है कि लोग बग की रिपोर्ट नहीं करेंगे यदि उन्हें लगता है कि वे "दोष देने वाले व्यक्ति" हो सकते हैं, तो यह वास्तव में टीम द्वारा रिपोर्ट किए गए बग की संख्या को कम कर देगा।

Comments

खैर, मालिक खुश होगा! कम बग रिपोर्ट नहीं हो जाएगा, और इसलिए, गुणवत्ता चाहिए वृद्धि हुई है।

— निकोडेमस 13

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

— मैट विल्को

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

— जोरिस टिम्मरमन्स

बग की रिपोर्टिंग करने वाले व्यक्ति की संभावना उस व्यक्ति से नहीं होगी जो root causeइस सप्ताह के कोड लिखने के 36 घंटों के बाद अपने स्वयं के कोड में कोई त्रुटि खोजने की कोशिश करने के बारे में सोचता हूं?

— मालाची

Answer 3

मैं इसके खिलाफ मुख्य तर्क का उपयोग करने के लिए पूछ रहा हूं कि वह किस समस्या को हल करने की कोशिश कर रहा है। उसी समस्या को हल करने के लगभग निश्चित रूप से बेहतर तरीके हैं।

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

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

इससे आप स्पष्ट रूप से देख पाएंगे कि क्या एक व्यक्ति नियमित रूप से गलती पर है और इससे निपटने के लिए एक अलग समस्या हो सकती है।

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

Comments

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

— डॉक ब्राउन

@DocBrown ने विश्लेषक और प्रोग्रामर के साथ दो अलग-अलग व्यक्तियों के साथ मेरे अनुभवों को अच्छी तरह से अब तक सकारात्मक बताया है। हालांकि मेरे मामले में यह विश्लेषकों के लिए था जो प्रोग्राम लॉजिक और प्रोग्रामर को समझ सकते हैं जो विश्लेषण में भाग ले सकते हैं :)

— gnat

@gnat: आपकी टीम में प्रोग्रामर में से एक को मधुमक्खी का शिकार करने वाले IMHO परिमाण के क्रम से आपके विकास की गति और गुणवत्ता में सुधार कर सकते हैं।

— डॉक ब्राउन

यह पुस्तक आपको अपनी ज़मीन को खड़ा करने के लिए शब्दों को खोजने में मदद करेगी amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/…

— zundarz

"इसे स्वतंत्र रूप से पेश करने" का लिंक टूट गया है।

— टॉम फोबियर

Answer 4

उस क्षेत्र के साथ कम से कम तीन समस्याएं हैं।

पहला यह है कि लोगों को दोष देना मनोबल के लिए अच्छा नहीं है। ठीक। लेकिन शायद वह मनोबल की परवाह नहीं करता और बुरे डेवलपर्स को आग देना चाहता है। के खिलाफ बहस करना मुश्किल है।

दूसरा यह है कि उस क्षेत्र का अधिकार मिलना कठिन और बहुत बड़ा समय है। यह पता लगाने की तुलना में अधिक जटिल है कि खराब कोड किसने लिखा है। और किसी भी संभावित जानकारी का पता लगाना कठिन है, जिसे सैंडबैग / धोखा दिया जा सकता है। लेकिन शायद वह उस लागत का भुगतान करने और जानकारी का ऑडिट करने के लिए तैयार है। ठीक।

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

अभी तक एक और सॉफ्टवेयर मीट्रिक विफलता।

Comments

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

— बजे एक CVn

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

— जॉर्डन

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

— ptyx

Answer 5

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

गलत:

बॉब इनपुट की जांच करना भूल गया और कार्यक्रम शून्य से विभाजित हो गया।

सही:

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

Comments

इससे भी बेहतर: कोडिंग दिशानिर्देशों / मानकों और कोड समीक्षा जाँचकर्ताओं ने इसे फिर से होने से बचाने के लिए अद्यतन किया।

— Oddthinking

तो क्या हुआ अगर कीड़े अपरिहार्य हैं? उनके लिए किसी को दोषी ठहराने में क्या गलत है? मुझे लगता है कि आपका 'गलत:' विकल्प आपके 'सही:' विकल्प से अधिक स्पष्ट है। गलत एक बहुत सरल है। 'राइट:' एक चिंताजनक है।

— एडम ब्रुक

@ अदम: मेरा उत्तर सीधे आपके सटीक प्रश्न को संबोधित नहीं करता है "किसी को दोष देने में क्या गलत है ...?"

— केविन क्लाइन

Answer 6

"व्यक्ति को दोष देना" को "प्रशंसा करने के लिए व्यक्ति" में बदलें

कीड़े को ठीक करने वाला मुख्य व्यक्ति उस पर अपना नाम प्राप्त करता है।

Comments

मुझे नहीं लगता कि यह सवाल का जवाब देता है। यह एक अच्छी भावना है, लेकिन इस तरह के क्षेत्र के खिलाफ तर्क प्रदान नहीं करता है।

— ब्रायन ओकले

इसके अलावा, आप जानते हैं कि एक आदमी सैकड़ों कीड़े "गलती से" पेश करेगा, फिर उन सभी को ठीक करें, उम्मीद है कि कुछ बेवकूफ प्रबंधक यह सोचने के लिए पर्याप्त गूंगे होंगे कि वह सबसे अच्छा बग-फिक्सर है ...

— MGOwen

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

— मझ

Answer 7

सरल उत्तर।

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

क्या अधिक महत्वपूर्ण है, किसी को एक ईमानदार गलती करने के लिए पीड़ित करना, या जितनी जल्दी हो सके समस्या को ठीक करना?

आपके बॉस को लगता है कि कीड़े आलस्य या सुस्ती का संकेत हैं। वे नहीं हैं। वे जीवन का एक तथ्य हैं। Microsoft एक वर्ष में कितने पैच आउट करता है?

Comments

+1, दोष की संस्कृति हमेशा बग के बारे में चुप रहने की संस्कृति की ओर ले जाती है और किसी और को नोटिस करने की उम्मीद नहीं करती है

— Carson63000

Answer 8

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

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

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

Comments

मैं पहले पैराग्राफ के लिए उत्थान करूंगा, लेकिन दूसरा मुझे संदिग्ध लगता है। मेरे अनुभव में जो लोग पहली बार में एक दोष क्षेत्र की तरह विचारों का सुझाव देते हैं, वे ऐसे लोग नहीं होते जो लोगों को असहज करने की चिंता करते हैं।

— गॉर्डन २ Gord

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

— कालेब

इसके अतिरिक्त, टीम अभी भी पीड़ित होगी। सिर्फ यह साबित करने के लिए कि बॉस गलत था?

— ओलेग वी। वोल्कोव

मैं हमेशा प्रबंधक का नाम वहाँ रखूँगा। "किसी भी संगठन में काम नीचे तक डूब जाता है, जबकि जिम्मेदारी शीर्ष पर तैरती है।"

— डेविड श्मिट

@ डेविड: क्रीम और मैल दोनों ऊपर तक तैरते हैं। आप अपने संगठन में क्या काम कर रहे हैं ?

— डोनल फैलो

Answer 9

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

उसने जो किया वह हमारे कागजी काम पर एक 'व्यक्ति को दोष देने' के लिए जोड़ने के बजाय उसने प्रत्येक डिजाइनर को रंगीन स्टिकर का एक सेट दिया। प्रत्येक डिज़ाइनर को एक अलग रंग का स्टिकर मिला और उसे निर्देश दिया गया कि किसी भी डिज़ाइन पर काम करने के लिए या उस स्टिकर को छूने पर भी उस डिज़ाइन के कागजी काम में जोड़ा जाना चाहिए।

"स्टिकर पहल" के लिए बॉस का घोषित लक्ष्य हमारे विभाग की सभी त्रुटियों के स्रोत (कागजी कार्रवाई, गलतफहमी, खराब कॉपी, अनिवार्य रूप से बग के प्रिंट समकक्ष) को स्थापित करना था।

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

[ब्लेम] बॉक्स में अपना नाम न लिखें, सभी का नाम टीम / प्रोजेक्ट पर रखें और सुनिश्चित करें कि पूरी टीम ऐसा ही करती है।

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

Comments

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

— एविक जेम्स

Answer 10

यह उनके सबसे विपुल प्रोग्रामर को सजा देगा। ऑड हैं, एक या दो लोग सबसे अच्छे कर्मचारी हो सकते हैं जिन्होंने सबसे अधिक प्रोजेक्ट्स पर काम किया है। यदि आपके पास 10-व्यक्ति विभाग में, एक कोडर जो केवल आउटपुट का एक फव्वारा है और उसने 60% इंटरफ़ेस कोड लिखा है, तो 60% बग उसके कोड में होंगे।

बता दें कि इस प्रणाली से ऐसा लगेगा कि जो व्यक्ति सबसे अधिक कोड लिखता है वह सबसे खराब प्रोग्रामर है, और जो व्यक्ति सबसे कम कोड लिखता है वह सबसे अच्छा प्रोग्रामर होता है।

Answer 11

ऐसा लगता है जब स्कॉट एडम्स ने एक बग बाउंटी के असफल ज्ञान को इंगित किया जब दिलबर्ट में पॉइन्टी हेयरड बॉस। वैली ने घोषणा की कि वह जाने वाला था और 'उसे एक नया मिनी वैन लिखो'।

दिलबर्ट कॉमिक स्ट्रिप 11/13/1995 के लिए आधिकारिक दिलबर्ट कॉमिक स्ट्रिप्स संग्रह से।

मुझे एक बार याद आया जब स्नो स्कीइंग कि किसी ने इशारा किया कि 'नहीं गिरना' एक अच्छे स्कीयर का संकेत नहीं था, लेकिन अक्सर एक का संकेत जो कुछ भी करने की कोशिश नहीं करता (या वास्तव में स्की नहीं करता है)।

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

ऐसा लगता है कि आपके बॉस दोषों की संख्या से निराश हो सकते हैं। क्या आपके समूह के लोग गुणवत्ता के बारे में भावुक हैं? Field कौन ’क्षेत्र के बजाय 'क्या’ क्षेत्र का निर्माण अधिक उत्पादक हो सकता है। Ex: रिक्वायरमेंट्स चेंज, डिज़ाइन फ़्लाव, इम्प्लीमेंटेशन फ़्लो इत्यादि, यहाँ तक कि यह तब तक विफल रहेगा जब तक प्रोडक्ट की क्वालिटी को बेहतर बनाने के लिए कोई ग्रुप बाय-इन न हो।

Answer 12

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

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

कुछ बिंदु पर एक प्रबंधक को पता होना चाहिए कि कौन अपना काम कर रहा है और कौन नहीं, साथ ही यह कौन बेहतर करता है क्योंकि बाकी टीम करती है।

Answer 13

यह अजीब है कि इससे पहले किसी ने इसका उल्लेख नहीं किया था: बग ट्रैकर के लिए इस तरह की कार्यक्षमता को जोड़ने से कर्मचारियों को सिस्टम को गेम करने की कोशिश करने के लिए प्रेरित किया जाएगा ।

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

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

Answer 14

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

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

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

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

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

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

या शायद यह नहीं है कि यह नीचे कैसे जाएगा। यह मेरे लिए बिल्कुल भी समझ में नहीं आता है इसलिए मेरे लिए यह अनुमान लगाना कठिन है कि यह कब काम करेगा, लेकिन मैंने इसे तब देखा है जब ऐसा लगता था कि ऐसा कोई व्यवसाय नहीं कर रहा है (कार्यस्थल में, केवल रीगन उदाहरण नहीं)।

Comments

+1 को केवल एक विचार पर हमला करने के बजाय, सूचना कार्यकर्ताओं को कैसे प्रबंधित किया जाए, यह समझाने के लिए।

— Oddthinking

Answer 15

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

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

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

एक कार्य वातावरण, कोई फर्क नहीं पड़ता कि यह किस प्रकार का है, या किस उद्देश्य से कार्य करता है, एक प्रणाली है। एक प्रणाली व्यक्तिगत घटकों से बनी है, अगर ठीक से "धुन" में, कुल सद्भाव में काम करता है - या इस तरह के कुछ झलक।

अपने मालिक के हिस्से पर सुझाव पढ़ना: अत्यधिक प्रभावी लोगों की 7 आदतें

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

आपके हिस्से पर सुझाव पढ़ने और / या अनुसंधान:

5 में देखें क्यों विश्लेषण, मूल कारण विश्लेषण ... कोई भी चीज जो आपको समाधान की पेशकश करने के लिए बेहतर स्थिति में रखती है , समस्या नहीं । और आपके बॉस के साथ आपकी असहमति, बस एक समस्या है, समाधान नहीं। उसे कुछ बेहतर प्रदान करें, कुछ ऐसा जो समझ में आता है, और यहां तक ​​कि उसे विचार का श्रेय लेने की अनुमति देने के लिए तैयार रहें।

अभी ऐसा नहीं लगता है कि वह कुछ भी ठीक करने के लिए तैयार है, क्योंकि उसे इस बात की पक्की समझ नहीं है कि क्या टूटा है, अगर कुछ भी टूटा हुआ है - तो उसकी "मैं मालिक हूँ" मानसिकता से इतर।

शुभ लाभ! मुझे आशा है कि आप इस माध्यम से प्राप्त करने का प्रबंधन करेंगे, इस तरह से सभी के लिए स्वीकार्य है, विशेष रूप से इन समयों में।

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

Comments

"आपको समाधान की पेशकश करने के लिए बेहतर स्थिति में रखता है, समस्या नहीं है।" - हाँ, जो इस पोस्ट का मुख्य बिंदु है। मुझे उम्मीद नहीं थी कि यह उस तरह से उड़ जाएगा।

— MK_Dev

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

— ताहवोस १३'१२ को

Answer 16

जवाबदेही के लिए मुझे एक person to blameक्षेत्र नहीं चाहिए , मैं एक Person who knows the codeक्षेत्र या एक person who can fixक्षेत्र चाहता हूं , ताकि मुझे पता चले कि समर्थन टिकट कहां भेजना है।

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

Answer 17

उसे बताओ "दोष" नकारात्मक है। इसे "व्यक्ति को ठीक करने के लिए" बदलें फिर कम से कम इसे सकारात्मक तरीके से तैयार किया जाता है, और वही काम अभी भी हो जाता है। कैसे लोग काम कर सकते हैं यदि उन्हें "दोषी ठहराया जा रहा है" ?!

Comments

आप "एक व्यक्ति को ठीक नहीं कर सकते" ...

— सैंडरॉक

हमारे पास "व्यक्ति को ठीक करने के लिए" क्षेत्र है। यह पर्याप्त नहीं है

— MK_Dev

Answer 18

यदि मेरे बॉस ने यह किया कि निम्नलिखित सही क्रम में होगा:

1) मैं तुरंत एक नई नौकरी की तलाश शुरू करूंगा।

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

एक साइड नोट के रूप में: प्रत्येक अच्छा विकास प्रबंधक इस बात से अवगत है कि मैंने ऊपर क्या लिखा है। और फुर्तीली रणनीतियों का मतलब बॉस या उसके दब्बूओं को इंगित करना है कि देव क्यों धीमा हो रहा है: देखो, हम अपना 50% समय फिक्सिंग बग्स में बिता रहे हैं। उन्हें कम करने के लिए रणनीतियों को देखें ताकि हम बग को ठीक करने में 40% समय व्यतीत कर सकें, और फिर इस समस्या को 30% तक फिर से प्राप्त कर सकें। आदि।

दुर्भाग्य से ऐसा लगता है कि आपके पास क्षेत्र के कारण एक अच्छा प्रबंधक नहीं है। इसलिए मैं सुझाव देता हूं कि (1) और इसे प्रबंधक तक न लाएं (आपके बाहर निकलने के साक्षात्कार को छोड़कर)

Answer 19

ऐसा लगता है कि आपके बॉस को सॉफ्टवेयर की गहरी समझ नहीं है और हो सकता है कि उसका इरादा भी न हो। तो उसकी एक अलग भाषा है, एक अलग संस्कृति है।

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

चूँकि वह हमारी भाषा नहीं जानता है, और वह बॉस है, यहाँ पहला कदम उसकी भाषा में उससे बात करने का होगा। मुझे भाषा से क्या मतलब है? चलो एक साथ सोचते हैं:

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

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

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

अपनी चाल चलें, उसकी भाषा में बात करें। सॉफ्टवेयर कंपनी के लिए बग्स महान हैं, समस्या नहीं है। वे हमें जीविका बनाते हैं।

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

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

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

Comments

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

— लैरी कोलेमन

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

— नैट सीके

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

— हैनयसिन

जाहिर है अगर छोड़ने के लिए मैं करना चाहता था, यह पद मौजूद नहीं होगा। इसके साथ ही, @hasanyasin, पोस्ट के लिए धन्यवाद - दिलचस्प परिप्रेक्ष्य। हालाँकि, बॉस एक टेक / सॉफ्टवेयर / डेवलपर व्यक्ति है, जो केवल इस समस्या को और अधिक समस्याग्रस्त बनाता है।

— MK_Dev

बग की अच्छाई के बारे में @hasanyasin - यह बहुत अच्छा है! मुझे दुःख है कि मैं दो अपवित्र नहीं कर सकता हूँ! मैं खुद भी इसका इस्तेमाल करूँगा!

— गैंगनस

Answer 20

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

मैंने दिन में वापस टाइपिंग की, यहाँ इस पर मेरा टेक है।

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

एक चुस्त वातावरण में यह QA व्यक्तियों की त्रुटियों (बग्स) को पकड़ने की जिम्मेदारी है और यह उत्पाद मालिकों की जिम्मेदारी है कि वे चीजों को स्वीकार न करें जो कि सही नहीं हैं। यह प्रूफ रीडर्स के दो स्तर हैं जो डेवलपर्स को जारी होने वाली चीजों से इंसुलेट करना चाहिए, जो कि एकमात्र तरीका है कि किसी भी चीज को फुर्तीले वातावरण में बग के रूप में वर्गीकृत किया जाना चाहिए ।

Comments

मामलों को बदतर बनाने के लिए, देवता अब क्यूए के भी हैं। मुझे पता है ...

— MK_Dev

कितना परेशान करने वाला रवैया।

— पीडीआर

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

— 14:46 पर Sgoettschkes

@Sgoettschkes सैद्धांतिक रूप से मैं आपके साथ 100% सहमत हूं, एक पूरी टीम के रूप में उत्पादित उत्पाद के लिए जिम्मेदार है। लेकिन अगर आप किसी विशिष्ट व्यक्ति को बाहर निकालने की कोशिश कर रहे हैं, तो काम की जाँच करने वाले लोग इसके माध्यम से पर्ची देने के लिए अधिक जिम्मेदार हैं।

Answer 21

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

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

परिणाम यह है कि डेवलपर्स अधिक स्वामित्व लेंगे, अधिक आत्मविश्वास महसूस करेंगे, और उत्पादन कोड में कम कीड़े होंगे।

Comments

मैं आपके पहले कथन से सहमत हूँ १००%। जब मैंने इस मुद्दे के बारे में बात की थी, तो वे मेरे शब्द थे।

— MK_Dev

Answer 22

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

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

Answer 23

बॉस को कुछ श्रेय देने के लिए, "दोष असाइनमेंट" की अवधारणा पहले से ही SVN जैसे टूल में बेक की गई है , और डेटा का उचित उपयोग डेवलपर्स के लिए रचनात्मक हो सकता है "डिबगिंग करते समय" किससे बात करें "जैसे: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

हालांकि मैं ऊपर दिए गए ज्ञान के जवाब से सहमत हूं कि रूट कॉज़ फ़ील्ड एक अच्छी बात है, यह एक ही जानकारी नहीं है, और प्रभावित स्रोत के लिए कभी-कभी पिछले डेवलपर नाम (ओं) को असाइन करने के लिए फ़ील्ड को "असंबद्ध" करना और कभी-कभी एक है तकनीकी विवरण (उदाहरण के लिए "10000 उपयोगकर्ताओं को स्केल नहीं किया गया") बस पानी को मैला कर देगा। मैं एक मूल कारण रखने की वकालत करूँगाफ़ील्ड को स्पष्ट रूप से एक तकनीकी विवरण (उदाहरण के लिए जब एक स्पष्ट प्रोग्रामर त्रुटि, जैसे कि यह विवरणों को कैप्चर करता है जैसे "indexOutOfRange अपवाद जब fooData = 999") यह संभावित रूप से कुछ उपयोगी प्रतिक्रिया प्रदान कर सकता है जब एन मसाज की समीक्षा की जाती है, और कुछ सुधारात्मक कार्रवाइयों की अनुमति दी जाती है। वास्तु या रूपरेखा परिवर्तन के साथ मुद्दों की संपूर्ण कक्षाओं को हल करने के लिए (जैसे कस्टम कंटेनर कक्षाओं में सुधार, शीर्ष-स्तरीय अपवाद सौंपना)

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

इसे बग फ़ील्ड / संभावित मीट्रिक के रूप में जोड़ने में समस्याएँ शुरू करना आसान है:

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

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

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

Answer 24

बस जाने दो। आपके बॉस को अपने आप पता चल जाएगा कि यह एक समस्या का कारण बनता है, अगर यह करता है।

चलो कुंद हो, तुम एक राय है और वह करता है। वह आपका प्रबंधक है और उसकी राय वह है जो जीतता है।

हां आप इस मुद्दे पर युद्ध करने जा सकते हैं, लेकिन क्या यह वास्तव में इसके लायक है? मुझे संदेह है कि यह 3 महीने से अधिक समय तक रहता है जब तक कि यह डिसेब्यूशन में गिर जाता है।

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

उस समय, जब यह वास्तव में गिना जाता है कि आप npt चाहते हैं तो बॉस को याद रखना चाहिए कि आप वह व्यक्ति थे जिसने "व्यक्ति को दोष देने" के लिए अपने विचार को सक्रिय रूप से तोड़ दिया था।

निर्णय का सम्मान न करने पर भी कार्यालय का सम्मान करें।

बहुत लंबे समय तक चलने वाले फैसलों के लिए तनाव और टेबल को बचाओ।

Comments

+1 एक समझदार समाधान के लिए (भले ही मैंने अपना खुद का उत्तर जोड़ा हो) :-)

— होमर 6

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

— गंगानुस

Answer 25

अपने बॉस को बताएं कि एक टीम में विकसित होने के लिए सामाजिक कौशल की आवश्यकता होती है। वह भी सिर हिला सकता है।

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

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

कोड समीक्षाओं के साथ भी शुरू करें ताकि आप एक दूसरे से सीख सकें। यह दोष बाद में लगता है।

Comments

उसे याद दिलाएं कि ज्यादातर मामलों में वह दोषी व्यक्ति हो सकता है। समय का दबाव, टीम का सदस्य, प्राथमिकताओं का प्रबंधन, चयनित / अनुमोदित उपकरण ...

— बिलथोर

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

— हकरे

-1 सुझाव देने के लिए developer == no social skills। दो पूरी तरह से असंबंधित हैं। आप एक या दोनों में अच्छे हो सकते हैं, और एक, या दोनों में बुरे हो सकते हैं, और कोई संबंध नहीं है।

— डेनिथ

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

— हक्रे

@ खाकरे: यदि यह मामला है जहां वह काम करता है, तो यह केवल इसलिए है क्योंकि प्रबंधन के कारण अधिकाधिक लोगों ने कंपनी को छोड़ दिया है

— डेंथ

Answer 26

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

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

Answer 27

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

मेरे बॉस ने फैसला किया कि हमारे बग ट्रैकिंग टेम्प्लेट में "पर्सन टू ब्लेम" फील्ड को जोड़ने से जवाबदेही बढ़ेगी

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

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

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

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

Answer 28

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

एक विकास के दृष्टिकोण से, 'दोषारोपण' पहले से ही मुख्यधारा के उपकरण जैसे SVN में शामिल है, इसलिए मुझे वास्तव में "जॉन जाने में कोई नुकसान नहीं होता है, कृपया आपने जो बकवास लिखा है, उसे ठीक करें" और इसके आगे एक नाम रखा यह। JIRA एक व्यक्ति का नाम भी शामिल करता है जब आप एक बग दर्ज करते हैं (हालांकि यह क्षेत्र वास्तव में उस व्यक्ति के लिए नहीं है जो इसके लिए जिम्मेदार है, यह बहुत ज्यादा है ताकि कोई इसे ठीक कर दे)।

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

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