कैसे "गुणवत्ता का पंथ" बनाने के लिए [बंद]


21

DeMarco और Lister (Peopleware) का सुझाव है कि आप अपनी प्रोग्रामिंग टीम के भीतर "गुणवत्ता का पंथ" बनाएं। निराशा की बात है कि वे सुझाव नहीं देते हैं कि आप ऐसा कैसे करते हैं!

किसी को भी यह कैसे पूरा करने पर कोई विचार मिला?


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

1
@WesleyWerner: अच्छी बात है। लेकिन मुझे लगता है कि एक 'गुणवत्ता के पंथ' को भी तकनीकी ऋण का ध्यान रखना चाहिए, जो आपके द्वारा बताई गई बॉस समस्या का समाधान करेगा।
टेलोनक्स

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

जवाबों:


37

मेरा अनुभव है कि विकास दल (लेकिन सामान्य तौर पर, किसी भी टीम) में 3 प्रकार के लोग होते हैं:

  • गुणवत्ता के लिए एक अंतर्निहित ड्राइव के साथ,
  • जो केवल पैसे के लिए इसमें हैं (बीयर / लड़कियों / जो कुछ भी) और कम देखभाल नहीं कर सकते हैं लेकिन आप उन्हें प्रेरित करने की कोशिश करते हैं:
  • "औसत दर्जे" वाले (बेहतर शब्द की कमी के लिए)।

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

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

[अपडेट 2] एल्ब के उत्तर पर प्रतिबिंबित करते हुए : आईएमओ को गुणवत्ता डेवलपर्स के लिए टीम के भीतर स्पष्ट बहुमत में होने की कोई आवश्यकता नहीं है (हालांकि यह चोट नहीं पहुंचाता है :-)। एक "ट्रेंड सेटिंग थ्रेसहोल्ड" है , जिसके ऊपर एक समुदाय के भीतर उपसमूह के विचार और व्यवहार जल्दी से "मुख्यधारा" बन सकते हैं , इसलिए अन्य लोग नोटिस लेते हैं और पालन करना शुरू करते हैं। आप इसे हर समय बड़े समाज में काम में देख सकते हैं (जैसे (गैर) धूम्रपान करने की आदतें, स्वास्थ्य और आहार, पॉप फैड्स, जैविक भोजन)। मेरा बहुत मोटा अनुमान है कि यह लगभग 25-30% हो सकता है, लेकिन यह बहुत सारे कारकों पर निर्भर करता है। यह वह जगह है जहाँ बुरे लोग बहुत चोट पहुँचा सकते हैं। यहां तक ​​कि आपकी टीम में कुछ बुरे लोग भी उस सीमा को काफी बढ़ा सकते हैं। [/ Update2]

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

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

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

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

अद्यतन करें

@ माचादो ने अपनी टिप्पणी में प्रश्न को एक नया मोड़ दिया (मेरे लिए कम से कम):

मैं, एक टीम के सदस्य के रूप में, एक प्रबंधक के रूप में, अपनी टीम की कोड गुणवत्ता में सुधार करने के लिए क्या कर सकता हूं?

कुछ विचार:

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

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

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


4
एक खतरनाक सलाह। क्या होगा यदि ओपी 2/3 के समूह के साथ है? ;)

1
महान जवाब, मैं इस तरह के बारे में कभी नहीं सोचा था, लेकिन यह इतना समझ में आता है।
Alb

9
@Developer अगर वे थे, वे DeMarco और लिस्टर को पढ़ने या यहाँ सवाल पूछ नहीं होगा।
एल्ब

मुझे लगा कि सवाल टीम के सदस्य के दृष्टिकोण से अधिक निर्देशित था। यदि प्रबंधन वास्तव में गुणवत्ता चाहता है, तो वे अपने शीर्ष / कोर डेवलपर्स को सुनेंगे। मैं, एक टीम के सदस्य के रूप में, एक प्रबंधक के रूप में, अपनी टीम की कोड गुणवत्ता में सुधार करने के लिए क्या कर सकता हूं?
मचाडो

1
@ Thorbjørn, उत्कृष्ट प्रश्न! मैं मानता हूं कि मैं अब तक अपने अधिकांश कार्यस्थलों में इसे याद कर रहा हूं। बहुत आत्म-उग्रता की आवाज़ नहीं करने की उम्मीद करते हुए, मैं हमेशा टीम के साथियों को ढूंढने और उनसे सीखने की कोशिश करता रहा हूं, लेकिन मैंने उन्हें शायद ही कभी पाया। इसलिए मैंने किताबों और इंटरनेट का रुख किया। जितना संभव है, मुझे मार्टिन फाउलर, अंकल बॉब मार्टिन एट अल में रोल मॉडल मिले। और हाल ही में एसओ समुदाय में! यह सीखने के लिए एक शानदार जगह है। इसके अलावा एक शक्तिशाली "रियलिटी चेक प्रदाता"। विनम्र अनुभव किसी के ज्ञान की सीमा और अंतराल को प्रकट करने के लिए कठिन हो सकता है, लेकिन मेरे लिए बहुत स्वस्थ हैं।
Péter Török

2

Péter Török का शानदार जवाब, इस बात पर प्रकाश डालने के लिए कि आप केवल अच्छे लोगों के बहुमत से इसे प्रबंधित करेंगे। एक बार जब आपके पास अच्छे लोग होते हैं, तो आपको छड़ी के बजाय गाजर के दृष्टिकोण के लिए अधिक लक्ष्य बनाने की आवश्यकता होती है। डेवलपर्स को सशक्त करें, उन्हें परियोजनाओं / कार्यों का स्वामित्व लेने दें और गुणवत्ता के मामले में प्रतिस्पर्धा को प्रोत्साहित करें, हो सकता है कि लोगों ने परियोजनाओं में qaulity में सुधार कैसे किया जाए, इस पर छोटी प्रस्तुतियां दी हैं। अच्छे डेवलपर्स को अपने साथियों को प्रभावित करने के लिए प्रेरित किया जाएगा।


+1 प्रेरणा के बारे में अच्छे अंक। मैं स्पष्ट रूप से बहुमत के बारे में गलत समझा गया था; मैंने अपना उत्तर स्पष्ट करने के लिए अद्यतन किया।
Péter Török

2

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

अधिक विशेष रूप से:

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

1

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

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

  • संबंधित के लिए एक ठोस समुदाय प्रदान करें।
  • एक ऐसा वातावरण दें जहां कर्मचारी बेझिझक गलतियाँ करता है ताकि वे उपलब्धि हासिल करने के लिए सम्मान का निर्माण कर सकें।
  • अपने डेवलपर्स को बागडोर सौंपें ताकि वे आत्म-प्राप्ति के लिए महत्वपूर्ण निर्णय ले सकें

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

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