तस्वीरों में डायग्नोस्टिक्स: हम टेबल और ग्राफ़ का उपयोग करके उत्पाद की स्थिति को समझते हैं

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

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

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

मैं कट के तहत और टिप्पणियों में इच्छुक व्यक्तियों से पूछता हूं। मैं किसी भी प्रश्न का उत्तर दूंगा।

लेख ओम्स्क में QASib सम्मेलन में एक भाषण पर आधारित है।



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

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

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

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

ठीक है, अब सीधे डेटा और ग्राफ़ पर।

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

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

अब आइए जानें कि टीम को क्या करना होगा: नई सुविधाओं का परीक्षण करना - 2200 घंटे, बग्स की जांच करना - 350 घंटे, रिग्रेसन परीक्षण, रिलीज़ के अंत में - 600 घंटे, स्वचालन - 500 घंटे, छुट्टियां - 160 घंटे (आप उन्हें टीम की क्षमता से घटा सकते हैं, और आप इसे यहाँ रख सकते हैं, जैसा कि आप चाहते हैं), जोखिम - २०० घंटे (लोगों की बीमारियाँ, नई विशेषताएँ जो "चिह्न" चिह्न के साथ अप्रत्याशित रूप से आती हैं, अन्य टीमों के कारण देरी, आदि आमतौर पर यहां आती हैं)। कुल 3800 घंटे। ऐसा लगता है कि हम सब कुछ करने का प्रबंधन करते हैं और उचित गुणवत्ता की रिहाई सुनिश्चित करते हैं।

या नहीं?

लेकिन क्या होगा अगर हमारी टीम की उत्पादकता उस काम की मात्रा से काफी कम है जो किया जाना बाकी है?

कई विकल्प हैं:

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

यह सुनिश्चित करने के लिए सुनिश्चित करें कि आपकी टीम को पचाने वाले काम की मात्रा के साथ सहसंबंधी कार्य करने की आवश्यकता है। खैर, या आपके पास एक स्पष्ट योजना थी कि इस समस्या को कैसे हल किया जाए।

आपके अनुमान रिलीज बर्न चार्ट की नींव रखेंगे।

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

अब स्लाइड होगी।


उदाहरण के लिए, तीन महीने तक चलने वाली रिलीज़ के लिए QA टीम के कार्य शेड्यूल पर विचार करें।

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

ग्राफ से पता चलता है कि:

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

यदि हमारे पास जोखिमों में यह अंतर्निहित है - उत्कृष्ट, यदि नहीं - तो हमें यह तय करने की आवश्यकता है कि स्थिति को सुधारने के लिए क्या करना है।

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

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

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

अक्सर हमारे पास सवाल होते हैं: क्या हम इसे ठीक करते हैं? क्या हमारे पास समय है? यहां उत्तर को रिलीज पर खुली बग की संख्या, प्राथमिकता के आधार पर समूहीकृत करके जानकारी दी जा सकती है।

प्रत्येक बग के लिए, हमने p0 से p4 तक प्राथमिकता तय की, जहाँ:

• P0 - ASAP द्वारा मरम्मत की जानी चाहिए
• पी 1 - पुनरावृत्ति / स्प्रिंट के अंत से पहले तय किया जाना चाहिए
• P2 - रिलीज के अंत से पहले तय किया जाना चाहिए
• पी 3 - अगर समय है तो मरम्मत करें
• पी 4 - बाकी सब कुछ, जिसके बिना आप निश्चित रूप से रह सकते हैं

एक उदाहरण के रूप में, निम्नलिखित ग्राफ पर विचार करें।


हरे रंग की रेखा खुले बग p0-p1 की संख्या को दर्शाती है, ग्राफ से देखते हुए, हम मान सकते हैं कि 4 और 8 सप्ताह पुनरावृत्तियों के अंत हैं, जब सभी बग p0-p1 की मरम्मत की जाती है। यह एक पुनरावृत्ति को बंद करने के मानदंडों में से एक है।

लाल रेखा, क्रमशः खुले बग p0-P2 की संख्या को दर्शाती है, और नीली रेखा रिलीज होने पर खुले बग की कुल संख्या दिखाती है।

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

रिलीज के अंत की ओर, यह एक ही चार्ट में एक और लाइन जोड़ने के लिए समझ में आता है। बैंगनी रेखा उन बगों की संख्या दर्शाती है जिन्हें डेवलपर्स की एक टीम ठीक कर सकती है। यही है, अगर हमारी रिहाई 19 वें सप्ताह की शुरुआत में होनी चाहिए, तो 18 वें सप्ताह में डेवलपर्स 38 कीड़े को ठीक कर पाएंगे, 17 वें और 18 वें सप्ताह में - 79 कीड़े, 16-17-18 वें सप्ताह में - 147 कीड़े, और इतने पर।
इस तरह की अनुसूची आपको ऐसी स्थिति की भविष्यवाणी करने की अनुमति देती है जब डेवलपर्स की एक टीम उन सभी बगों को ठीक करने में सक्षम नहीं होती है जो रिलीज के अंत से पहले तय होनी चाहिए। यह आपको पहले से कुछ कार्य करने की अनुमति देगा:

• क्रमबद्ध p1-P2 बग उन्हें फिर से प्राथमिकता देने के लिए, विकास केवल उन बगों पर ध्यान केंद्रित करता है जिन्हें वास्तव में ठीक करने की आवश्यकता होती है, और p3-p4 बग और p1-P2 छद्म कीड़े पर समय बर्बाद न करें
• बग फिक्सिंग के लिए अतिरिक्त संसाधन आकर्षित करें
• रिलीज की तारीख को बाद के समय में स्थानांतरित करें, आदि।

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

तस्वीर तीन पुनरावृत्तियों की रिहाई का एक उदाहरण दिखाती है, जहां दो पुनरावृत्तियों नई सुविधाओं का विकास है और एक उत्पाद का स्थिरीकरण है।


यदि हम इस ग्राफ को पहले पुनरावृत्तियों में से एक पर काम के समय देखते हैं, तो यह हमें उन सुविधाओं की गुणवत्ता की निगरानी करने की अनुमति देता है जो वर्तमान में काम कर रहे हैं। उदाहरण के लिए, यदि हमें 6 वें सप्ताह में 37 बगों के बजाय 60 कीड़े मिले, तो यह हमारे लिए यह संकेत होगा कि क्यों हम इस पुनरावृत्ति के सामान्य चरण की तुलना में 2 गुना अधिक समस्याएं पाए गए।

मोटे तौर पर यही बात बग फिक्सिंग पर भी लागू होती है। उदाहरण के लिए, यदि 4 वें और 8 वें सप्ताह में सामान्य से कम कीड़े की मरम्मत की गई थी, तो आपको यह समझने की आवश्यकता है कि क्यों। क्या कीड़े अधिक जटिल हैं? या प्रत्याशित की तुलना में बग फिक्सिंग के लिए कम समय आवंटित किया गया है?

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

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


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

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


ऐसा करने के लिए, हमारे पास कीड़े के लिए एक विशेष क्षेत्र "अंडर अंडर कंडीशन" है, जो निम्न मान ले सकता है:

• ग्राहक - हम पिछले संस्करणों में से एक में एक बग से चूक गए, और कस्टम टीम ने इसे पाया और इसे हमारे साथ पंजीकृत किया
• प्रतिगमन - पिछले संस्करणों में काम करने वाली कार्यक्षमता वर्तमान में टूट गई थी
• फ्रेश लुक - हमने पिछले संस्करणों से बेहतर और अधिक और बग का परीक्षण करना शुरू कर दिया, जो हमने पहले याद किया था
• नई टीसी - हमें वर्तमान रिलीज़ की नई सुविधाओं में एक बग मिला
• और अन्य ...

इन श्रेणियों द्वारा बग को कैसे पाया जाता है, इसे समझने से हमें कई उपयोगी जानकारी मिलती है, जिन्हें इतनी आसानी से बताई गई तालिका में यहाँ प्रस्तुत किया जा सकता है।

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

जानकारी का एक अन्य उपयोगी स्रोत घटक द्वारा बग का वितरण है, यह हमें इस सवाल का जवाब देगा कि आपके उत्पाद का कौन सा घटक घुटनों में कमजोर है।


इसे गंभीरता वितरण के साथ जोड़कर, आप इस समय सबसे समस्याग्रस्त घटकों को उजागर कर सकते हैं और यह समझने की कोशिश कर सकते हैं कि ऐसा क्यों हो रहा है और इसे कैसे ठीक किया जाए।

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

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

यह अनुमति देगा:

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

एक और शक्तिशाली उपकरण पिछले रिलीज के साथ वर्तमान स्थिति की तुलना करना है।


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

वर्तमान रिलीज़ स्थिति का विश्लेषण करते समय और क्या ध्यान देने योग्य है:

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

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

विशेष रूप से, हाल ही में जारी समानताएं Plesk पैनल 11 विकसित करते समय, उन्होंने अनुमति दी।
स्पलैश 11 में क्यूए एक वास्तविक सफलता बन गई है, इसकी एक सूची होनी चाहिए। बेशक, अगर हम इसके बारे में ज़ोर से बात कर सकते हैं।

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