सॉफ्टवेयर विकास प्रक्रियाओं के बारे में किसी भी चर्चा को आधुनिक सॉफ्टवेयर बनाने के कुछ क्लासिक दृष्टिकोणों पर आधारित किया जाना चाहिए. हमें बाजार की जरूरतों को ध्यान में रखते हुए अपेक्षित आवृत्ति के साथ उत्पादों को वितरित करने के लिए कुछ रुझान स्थापित करने की जरूरत है. एक पुनरावृत्ति की लंबाई को उत्पाद बैकलॉग परिवर्तनों के लिए आवश्यक अनुकूलन की गति को प्रतिबिंबित करना चाहिए. टीमों को प्रत्येक पुनरावृत्ति के लिए तैयारी करनी चाहिए और बैकलॉग आइटम को सुसज्जित करना चाहिए. और निश्चित रूप से, प्राथमिकताएं होनी चाहिए. ऐसा लगता है कि प्राथमिकता प्रबंधन दृष्टिकोण बिल्कुल सहज है और आपको अपने सॉफ्टवेयर विकास में इसका उपयोग करने के लिए मानकीकरण में गहराई से समझने की आवश्यकता नहीं है. फिर भी, किसी भी प्रक्रिया को स्थापित करना प्रत्येक टीम के सदस्य के लिए सामान्य सिद्धांतों की घोषणा का मतलब है. और यहां जटिलताएं हैं: किसी भी टीम के सदस्य को समझाने के लिए कि कार्य या उत्पाद बग के बगल में कुछ आंकड़ा या शब्द क्या मतलब है? विशेष रूप से कई टीमों वाले परियोजनाओं में। यह हमेशा अपने स्वयं के प्राथमिकता प्रणाली का आविष्कार करना संभव है, लेकिन यह प्रत्येक नए टीम के सदस्य के लिए अपने सिस्टम के सिद्धांतों की व्याख्या करने की आवश्यकता का कारण बनता है. यदि परियोजना बड़ी है और आपके पास कई नए सहयोगी हैं, तो यह एक समस्या है. इसलिए कुछ समय से परीक्षण किए गए अंतरराष्ट्रीय मानकों या दृष्टिकोणों का उपयोग करना आसान है. इस लेख में मैं उत्पाद विकास में प्राथमिकता निर्धारण के लिए MoSCoW विधि का उपयोग करने के बारे में चर्चा करना चाहता हूं, जो त्वरित और मापने योग्य परिणाम प्रदान करने वाले पुनरावृत्ति के दौरान काम को सरल बनाने के लिए सबसे आम तरीके के रूप में। एक उदाहरण के रूप में, मैं अनुकूलित प्राथमिकताकरण विधि और समस्याओं का एक उदाहरण प्रदान करूंगा जिन्हें मैंने इस दृष्टिकोण के साथ सामना किया था. फिर हम लाइव उदाहरणों के साथ प्रत्येक प्राथमिकता पर विचार करने के लिए MoSCoW विधि के विघटन में डुबोने जा रहे हैं। एक लेख उत्पाद प्रबंधकों या किसी भी व्यक्ति के लिए उपयोगी हो सकता है जो अच्छी तरह से काम करने वाले उत्पाद विकास प्रक्रिया का पीछा करता है। वस्तु प्राथमिकता के बारे में अनुकूलित दृष्टिकोण के साथ मजा करना बहुत लंबे समय पहले, एक उत्पाद टीम में, हम अपने विकास चक्रों में आइटम प्राथमिकताओं के साथ एक समस्या को हल करने की कोशिश कर रहे थे। प्रक्रिया स्वयं अत्यधिक अपर्याप्त थी: कार्यान्वयन की समय सीमाएं अक्सर उल्लंघन की गई थीं, टीम को अतिरिक्त समय पर काम करना पड़ा, और उत्पाद रिलीज संतुष्ट गुणवत्ता के थे। उस क्षण में हमने संख्यात्मक प्राथमिकताओं 1-2-3-4 का उपयोग किया और वे बिल्कुल भी मदद नहीं करते थे। फिर हमने टीम के सदस्यों के बीच संचार को सरल बनाने का फैसला किया और एक अतिरिक्त प्राथमिकता "5" की पेशकश की। यह प्राथमिकता सबसे अधिक प्राथमिकता बन जाएगी, "1" से अधिक महत्वपूर्ण है, और इसका मतलब है "showstopper" - टिकट या आइटम जो एएसएपी द्वारा लागू किया जाना Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. बेशक, प्राथमिकताकरण विधि इस प्रक्रिया में सामान्य समस्या नहीं थी. योजना, जोखिम प्रबंधन और रणनीति के बारे में दृष्टिकोण में मौलिक मुद्दे थे. लेकिन यदि आपके टेबल पर कई चुनौतियां हैं, तो अपने स्वयं के अस्पष्ट विधि का आविष्कार सबसे अच्छा निर्णय नहीं दिखता है. इस प्रकार, मैं सॉफ्टवेयर विकास में कार्य प्राथमिकताकरण में मानकों का उपयोग करने के लिए चिकनी रूप से आगे बढ़ना चाहता हूं. "MoSCoW" दृष्टिकोण का परिचय कुछ मानकों को आईईटीएफ या आईईईईई जैसे संगठनों से अंतर्राष्ट्रीय सर्वोत्तम प्रथाओं के आरएफसी में सख्त रूप से संदर्भित किया गया है, जबकि अन्य अपने आप में मानकों बन गए हैं. जो मैं पेश करना चाहता हूं वह आखिरी श्रेणी में पड़ता है. MoSCoW तरीका कार्यों को प्राथमिकता देने का एकमात्र दृष्टिकोण नहीं है, लेकिन चीजों को सही तरीके से करना शुरू करने के लिए सबसे कुशल और सार्वभौमिक तरीकों में से एक है. इस दृष्टिकोण को पुस्तक में डाई क्लेग द्वारा प्रस्तावित किया गया था “ ” (1994) और बहुत लोकप्रिय हो गया. नाम “मोस्कोड” के पास उत्तरी राजधानी से कोई संबंध नहीं है और प्राथमिकता श्रेणियों का एक संक्षिप्त रूप के रूप में बनाया गया था: मुँह है, हो सकता है, ओलंपिक है, इन श्रेणियों को संख्यात्मक प्राथमिकताओं 1-2-3-4 से जुड़ाया जा सकता है और उत्पाद विकास पुनरावृत्ति में कार्यों या आइटमों की अनुक्रम को स्पष्ट रूप से निर्धारित करने में मदद करता है। प्रत्येक श्रेणी का स्पष्ट उद्देश्य इस विधि को एक ऐसा गहना बनाता है, और इस लेख के दौरान, मैं एजिल विकास में उदाहरणों के साथ प्रत्येक प्राथमिकता को कवर करना चाहता हूं। Case Method Fast-Track: एक RAD दृष्टिकोण M S Co W सबसे पहले, दृष्टिकोण का उपयोग करने के लिए एक उदाहरण परिदृश्य स्थापित करना आवश्यक है। मान लीजिए कि हम एक उत्पाद टीम के सदस्य हैं जो एक बी 2 बी उत्पाद विकसित कर रहा है. इस उत्पाद में, हमारे ग्राहक अपने परियोजनाओं के लिए फ़ाइलों को संग्रहीत और विनिमय कर सकते हैं. इसे सरल रखने के लिए, हमारी टीम कुछ बुनियादी सुविधाओं को जोड़ देगी, जैसे कि "उपयोगी निमंत्रण" - परियोजना में एक नए प्रतिभागियों को जोड़ने की कार्यक्षमता. हमने अपने ग्राहकों को वादा किया कि हम एक निश्चित तारीख तक इस सुविधा को लागू करेंगे; हमारे पास एक प्रतिबद्धता है. अब, टीम को कंपनी की प्रतिष्ठा बनाए रखने के लिए समय सीमा से पहले उत्पाद की नई संस्करण जारी करने के लिए अगली पुनरावृत्ति की योजना बनानी होगी. टीम की क्षमता है - उपलब्ध समय स्लॉट जो विकास के लिए इस्तेमाल किया जा सकता है. इस उदाहरण में, हम विशेषज्ञता (डीवी, डेवओप्स, क्यूए) के अनुसार टीम के सदस्यों को विभाजित नहीं करेंगे, और हमारे टीम को एक कैनॉनिक सार्वभौमिक स्क्रूम टीम के रूप में कल्पना करेंगे। उपयोगकर्ता निमंत्रण परिदृश्य में तकनीकी आवश्यकताओं, UX / UI को तैयार किया गया है. सुविधा पहले से ही सार्थक वस्तुओं में विभाजित की गई थी जो समझ में आती हैं, और इन सभी वस्तुओं का अनुमान लगाया गया था. हम जानते हैं कि हमें इस सुविधा में कितने संसाधनों का निवेश करना चाहिए. यह एक प्राथमिकताकरण दृष्टिकोण का उपयोग करने का उच्च समय है, और बिना किसी और चिंता के, आइए इन वस्तुओं को वर्गीकृत करें। होना चाहिए - 1 Must Have "1" प्राथमिकता कार्यों, सुविधाओं, उत्पाद बैकलॉग आइटम, उपयोगकर्ता कहानियों या त्रुटियों के लिए उपयोग की जाती है जिन्हें अगले विकास पुनरावृत्ति में शामिल किया जाना चाहिए. उदाहरण के लिए, योजना के दौरान हमने महसूस किया कि कुछ कार्यों को ग्राहकों के साथ समझौतों के माध्यम से विकसित किया जाना चाहिए या वे किसी अन्य कारण से व्यवसाय महत्वपूर्ण हैं। मुख्य विचार यह है कि ये आइटम महत्वपूर्ण और गैर-अनुबंधित हैं. टीम को उन्हें अनुमान लगाना होगा, जोखिम उठाना होगा और उन्हें योजना बनाना होगा. यदि अनुमान उपलब्ध समय से अधिक है, तो आइटम को तब तक तोड़ दिया जाना चाहिए जब तक कि न्यूनतम मूल्य उत्पाद (MVP) पुनरावृत्ति के दौरान बनाया जा सके. एक नए उत्पाद सुविधा के उदाहरण के आधार पर, मान लीजिए कि हम एक "एक परियोजना में एक नए उपयोगकर्ता को आमंत्रित करें" सुविधा लागू करना चाहते हैं. "मैं होना चाहिए" श्रेणी एमवीपी कार्यों को प्रतिबिंबित करती है और बुनियादी कार्यक्षमता बनाती है. पुनरावृत्ति का परिणाम "1" प्राथमिकता के लिए एक सार्थक परिदृश्य और उपयुक्त कार्य प्रदान करना चाहिए: Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. होना चाहिए - 2 दूसरा श्रेणी "मुझे होना चाहिए" के करीब है, लेकिन यह कुछ ऐसा है जिसे हम बाद में देरी कर सकते हैं या वितरित कर सकते हैं। यदि हमारे पास उपयोगकर्ता निमंत्रण के बारे में क्लाइंट के साथ समझौते हैं, तो एमवीपी फ़ंक्शन प्राथमिकता "1" में अनिवार्य विकल्प के रूप में जारी किए जाएंगे. हालांकि, हमेशा कई सुधार हैं जो लागू करने के लिए आवश्यक हैं, लेकिन उन्हें घोषित सीमा में छोड़ दिया जा सकता है. विकास चरण के दौरान, टीम को "मुझे होना चाहिए" कार्यों के साथ कुछ जोखिमों का सामना करना पड़ सकता है, और दूसरी प्राथमिकता फ़ंक्शन को स्थगित किया जाना चाहिए क्योंकि वे एमवीपी का हिस्सा नहीं हैं. उदाहरण के लिए, "उपयोगी निमंत्रण" फ़ंक्शन में, उत्पाद को नए उपयोगकर्ताओं को प्रवेश करने में मदद करनी चाहिए। "मुझे होना चाहिए" प्राथमिकता में, टीम रचना और निमंत्रण के महत्वपूर्ण परिदृश्य को विकसित करेगी। लेकिन यह भी महत्वपूर्ण है कि आमंत्रित प्रबंधक को प्रतिक्रिया भेजें कि एक नया उपयोगकर्ता सफल रूप से लॉग इन हो गया है। यह इस प्रतिक्रिया के बिना फ़ंक्शन का उपयोग करना संभव है, लेकिन इस नोटिस के साथ, उत्पाद निश्चित रूप से बेहतर है और प्रबंधक जान जाएगा कि सब कुछ ठीक है। एक "आपके पास होना चाहिए" उत्पाद त्रुटि ऐसी चीज है जो परिदृश्य को तोड़ती है, लेकिन कुछ उचित समाधान है, जो एक साधारण और गैर तकनीकी उपयोगकर्ता के लिए उपलब्ध है. यह हमेशा पुनरावृत्ति के दौरान इन त्रुटिओं को ठीक करना बेहतर है, लेकिन उन्हें समय सीमा के करीब बातचीत की जा सकती है, क्योंकि उनके साथ जारी करना अभी भी संभव है। हो सकता है - 3 यह श्रेणी उन सुधारों या छोटे दृश्य दोषों के बारे में है जो सामान्य रूप से एक अंतर बनाते हैं और उत्पाद की समग्र भावना को बढ़ा सकते हैं, लेकिन वे वर्तमान में महत्वपूर्ण नहीं हैं या दृश्य के लिए गहराई से वैकल्पिक नहीं हैं। यह इन चीजों को विकसित करना अच्छा होगा, केवल यदि "मुझे होना चाहिए" या "मुझे होना चाहिए" प्राथमिकताओं के जोखिम को कम किया जाता है। योजना के दौरान, उत्पाद टीम को इस तरह के "मुझे होना चाहिए" वस्तुओं के बारे में सोचना चाहिए: पहला प्राथमिकता किया जाना चाहिए। हम दूसरे प्राथमिकता को वितरित करने के लिए अधिकतम प्रयास करना चाहिए. यदि सब कुछ ठीक हो रहा है, तो हम तीसरे प्राथमिकता वस्तुओं को विकसित करने की उम्मीद कर रहे हैं, लेकिन अगर हम विफल रहे हैं, तो यह व्यवसाय को प्रभावित नहीं करना चाहिए। "उपयोगी निमंत्रण" फ़ंक्शन के मामले में, तीसरा प्राथमिकता उपयोगकर्ता निमंत्रण फार्म में कुछ अतिरिक्त सुधार है. तीसरा प्राथमिकता फ़ंक्शन के रूप में, व्यवस्थापक स्वचालित सूचनाएं सेट कर सकता है यदि एक उपयोगकर्ता अगले तीन दिनों के दौरान लॉग इन नहीं किया है. परियोजना व्यवस्थापक इस याद दिलाने को मैन्युअल रूप से भेज सकता है यदि वे एक दूसरी प्राथमिकता सूचना की अनुपस्थिति को नोटिस करते हैं, लेकिन यह शुरुआत में स्वचालित याद दिलाने को लागू करना एक अच्छा स्पर्श होगा। एक उत्पाद बग के रूप में एक "कुछ हो सकता है" प्राथमिकता दुर्लभ विशेषताओं या विज़ुअल बगों के बारे में है जो कुछ असामान्य वातावरणों में पुनरावृत्ति की जाती हैं. इन बगों को ठीक किया जा सकता है यदि हमारे पास अन्य श्रेणियों के अपूर्ण विशेषताओं या उत्पाद बग नहीं हैं. तीसरे प्राथमिकता बगों को लंबे वार्ता के बिना अगले पुनरावृत्ति में स्थानांतरित किया जा सकता है, क्योंकि वे उत्पाद रिलीज को अवरुद्ध नहीं कर रहे हैं. उदाहरण के लिए, हमारे अधिकांश ग्राहक बेस एक विशिष्ट इंजन पर वेब ब्राउज़र का उपयोग करते हैं और हमारे पास एक अप्रिय लोकप्रिय इंजन में एक अनिश्चित दोष है. इस बग को ठीक करना अच्छा होगा, लेकिन यदि हर कोई अधिक महत्वपूर्ण कार्यों के साथ व्यस्त है नहीं मिलेगा - 4 एक उपयोगी श्रेणी जो वस्तुओं को दिखाती है जो निश्चित रूप से पुनरावृत्ति के दौरान जारी नहीं किए जाएंगे. हालांकि, यदि कुछ क्षमता बाकी है तो उन्हें रखना महत्वपूर्ण है. उत्पाद टीम पुनरावृत्ति और सेगमेंट कार्यों और बग को पहले, दूसरे और तीसरे प्राथमिकता के रूप में योजना बना सकती है. और ऐसा होता है कि कार्य योजना से आसान होते हैं. डेवलपर्स के पास अतिरिक्त समय होगा जो चौथे प्राथमिकता के लिए इस्तेमाल किया जा सकता है. ये वस्तुएं हमेशा शाखाओं में विकसित की जाती हैं और वर्तमान पुनरावृत्ति में कभी भी एकीकृत नहीं की जाती हैं, लेकिन यह अगले पुनरावृत्ति के लिए चीजों को आसान बनाता है. किस तरह के कार्य एक "नहीं" बैकपॉग के रूप में उपयुक्त हैं? सबसे पहले, वहाँ तकनीकी ऋण कार्य हैं. अत्यधिक महत्वपूर्ण उनमें से "मुझे होना चाहिए" या "मुझे होना चाहिए" प्राथमिकता भी हो सकता है, लेकिन कोडबेस रखरखाव के लिए नियमित कोड सुधार चौथे प्राथमिकता का एक शानदार उदाहरण हैं. डेवलपर्स के पास व्यवसाय महत्वपूर्ण कार्यों के बाद कोड में सुधार करने का अवसर है और अगले पुनरावृत्ति में इन सुधारों का उपयोग करने का अवसर है. यदि कुछ परिवर्तन टूट रहे हैं और गैर-सामान्य क्यूए निष्पादन की आवश्यकता होती है, तो नए पुनरावृत्ति से पहले सुधार करने के लिए भी समय पर क्यूमिंग का अवसर प्रदान करता है. इसके अलावा, यह कुछ वस्तुओं को "नहीं" प्राथमिकता के रूप में जोड़ने के लिए उपयोगी है जो अगले पुनरावृत्ति में पहले "मुझे होना चाहिए" प्राथमिकता होगी. हम जानते हैं कि बुनियादी उपयोगकर्ता निमंत्रण के बाद, हमें इस परिदृश्य में विस्तृत उपयोगकर्ता अनुमति सेटिंग्स को एकीकृत करना चाहिए, व्यवस्थापक प्रवाह को सरल बनाने के लिए। यह सुविधा अगले पुनरावृत्ति का एमवीपी होगी. यदि हमारे पास कुछ क्षमता है, तो इसे चौथा प्राथमिकता के रूप में विकसित करना शुरू करना अच्छा है; जो भविष्य में जोखिम को कम करेगा. अगले पुनरावृत्ति की योजना के दौरान, इस वस्तु का प्राथमिकता "मुझे होना चाहिए" में अपडेट किया जाएगा. यह बेहतर है कि चौथे प्राथमिकता के उत्पाद त्रुटियां न हों, क्योंकि यह श्रेणी दिखाती है कि त्रुटियों को पुनरावृत्ति के दौरान ठीक नहीं किया जाएगा और यह केवल बैकपॉक बोर्ड पर अतिरिक्त गड़बड़ी पैदा करेगा। फिर भी, प्राथमिकता उन त्रुटियों के लिए उपयोग की जा सकती है जिनके लिए वास्तुकला परिवर्तन की आवश्यकता होती है जो वर्तमान पुनरावृत्ति के लिए खतरनाक हैं और उनके परीक्षण को अगले में योजनाबद्ध किया जाना चाहिए। प्राथमिकता दृष्टिकोण का उपयोग करने के फायदे इस लेख की शुरुआत में मैंने चार श्रेणियों के साथ अनुकूलित प्राथमिकता दृष्टिकोण का एक उदाहरण दिया, जिसे कोई नहीं समझता था और टीम को सबसे महत्वपूर्ण कार्यों के लिए पांचवें प्राथमिकता का परिचय करना पड़ता है। ये नियम एक टीम संदर्भ के रूप में भी कार्य करते हैं और टीम योजना दृष्टिकोण में समस्याओं को दिखाने में मदद करते हैं। उदाहरण के लिए, यदि टीम पहले "मुझे होना चाहिए" प्राथमिकता के सभी योजनाबद्ध बिंदुओं को विकसित नहीं कर सकती है, अन्य प्राथमिकताओं के बारे में नहीं कहने के लिए, यह प्रक्रिया में गहरे मुद्दों को प्रदर्शित करता है: विशेषता आवश्यकताएं इतनी अच्छी और स्पष्ट नहीं थीं। विघटन में गलती हुई है। टीम ने किसी तरह से कार्यों की जटिलता को कम कर दिया। किसी ने पुनरावृत्ति के दौरान विचार बदलने का फैसला किया। टीम को पुनरावृत्ति प्रदान करना होगा और इसे समस्या के स्रोत का पता लगाना होगा और टूटे हुए विकास प्रक्रिया को ठीक करने के लिए समाधान खोजना होगा। एक ही समय में तीसरे और चौथे प्राथमिकताओं का स्थिर पूरा करना भी इतना अच्छा नहीं है. इसका मतलब है कि हम अनुमान लगाने और जोखिम प्रबंधन में अच्छे हैं, लेकिन यह भी दिखाता है कि टीम काफी आरामदायक या अवरोधित है. शायद हम "मुझे होना चाहिए" या "मुझे होना चाहिए" प्राथमिकताओं के अतिरिक्त वस्तुओं की योजना बना सकते हैं. विकास प्रक्रिया को सभी टीम के सदस्यों को तेज रखने और सुधारों की तलाश करने के लिए संतुलन और कुछ चुनौतियों की आवश्यकता होती है. दृष्टिकोण के नुकसान उपरोक्त उदाहरण में, कार्यों को एक विशिष्ट पुनरावृत्ति के लिए प्राथमिकता के अनुसार वर्गीकृत किया गया था, लेकिन इसका मतलब कंपनी के व्यवसाय के अनुसार समग्र प्राथमिकता नहीं है. कार्य जो वर्तमान पुनरावृत्ति में "केवल" के रूप में टैग किए गए हैं, अगले पुनरावृत्ति में "मुझे होना चाहिए" हो सकता है, और इन परिवर्तनों को पुनरावृत्ति प्रबंधक के लिए प्रत्येक योजना सत्र के दौरान अतिरिक्त समय की आवश्यकता होती है. इसके अलावा, दृष्टिकोण में अभी भी एक श्रेणी में कार्यों की अनुक्रम के साथ एक समस्या है. यदि पुनरावृत्ति में कुछ "मुझे होना चाहिए" आइटम होते हैं, तो उनमें से कौन से को पहले विकसित किया जाना चाहिए? इस अनुक्रम को अभी भी पुनरावृत्ति योजना के माध्यम से चर्चा और विशिष्ट सॉफ्टवेयर के माध्यम से समन्वय किया जाना चाहिए. पूरे विकास प्रक्रिया के लिए चांदी की गोली नहीं है, लेकिन MoSCoW जैसे दृष्टिकोणों का उपयोग बुनियादी प्रक्रियाओं को सरल बनाने में मदद करता है। निष्कर्ष प्राथमिकता देने के लिए कई तरीके और दृष्टिकोण हैं. हालांकि, मुझे लगता है कि मोएसकोड दृष्टिकोण सॉफ्टवेयर विकास प्रक्रिया के सामान्य सुधारों के साथ शुरू करने के लिए सबसे आसान में से एक है. यह दृष्टिकोण स्पष्ट रूप से परिभाषित कार्यों और दृष्टि के साथ बी 2 बी बाजार उत्पादों और उत्पाद विकास के लिए अधिक उपयुक्त है. इस दृष्टिकोण को सही ढंग से उपयोग करने के लिए बाद के पुनरावृत्ति के लिए एक योजना बनाना आवश्यक है. एक अराजक और तेजी से बदलते हुए वातावरण में यह दृष्टिकोण असफल हो सकता है और बहुत सारे उच्च प्राथमिकता कार्य पैदा कर सकता है, जो रिलीज की पूर्वानुमान को प्रभावित करेगा. एक ही समस्या उचित योजना और अनुमान प्रक्रियाओं के बिना हो सकती है. लेकिन फिर भी, इस दृष्टिकोण का उपयोग
