एक वेब स्टूडियो से एक फ्रीलांसर के लिए प्रोजेक्ट कैसे माइग्रेट करें

एक वेब स्टूडियो से एक फ्रीलांसर के लिए प्रोजेक्ट कैसे माइग्रेट करें

एक वेब स्टूडियो से एक फ्रीलांसर को प्रोजेक्ट सौंपना सरल लगता है जब तक कि पहला गायब पासवर्ड सामने नहीं आता। तब समयसीमा बदल जाती है। यदि साइट में एक CMS, एक कस्टम बैकएंड, और 14 अधूरे कार्य हैं, तो हैंडऑफ को संरचना की आवश्यकता होती है, न कि आशावाद की।

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

1. वर्तमान प्रोजेक्ट स्थिति का आकलन करें

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

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

होस्टिंग भी महत्वपूर्ण है। होस्ट, सर्वर प्रकार, DNS प्रदाता, SSL स्रोत, ईमेल सेटअप, और क्रॉन जॉब्स की पहचान करें। एक अकेला भूला हुआ DNS रिकॉर्ड ट्रैफ़िक को गलत स्थान पर भेज सकता है। एक गायब बैकअप एक छोटे अपडेट को एक पैनिक कॉल में बदल सकता है।

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

डिज़ाइन फ़ाइलें परियोजना की स्थिति का हिस्सा हैं, कोई साइड नोट नहीं। फ़िग्मा लिंक, स्रोत फ़ाइलें, निर्यात फ़ोल्डर, फ़ॉन्ट और स्वीकृत दृश्य प्रणाली एकत्र करें। यदि लोगो केवल एक चैट थ्रेड में या किसी के लैपटॉप पर मौजूद है, तो उसे दस्तावेज़ करें। एक गायब फ़ॉन्ट लाइसेंस पूरे माइग्रेशन को धीमा कर सकता है।

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

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

2. जोखिम और निर्भरताएँ पहचानें

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

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

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

पहले पहुँच प्रतिबंधों को मानचित्रित किया जाना चाहिए। जांचें कि क्या होस्टिंग पैनल कई प्रशासकों की अनुमति देता है, क्या रिपॉजिटरी संगठन अनुमतियों का उपयोग करती है, और क्या एनालिटिक्स खाता सुरक्षित रूप से साझा किया जा सकता है। यदि स्टूडियो कहता है “हम स्क्रीनशॉट भेज सकते हैं,” तो यह पहुँच नहीं है। यह एक देरी है।

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

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

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

3. हैंडऑफ चेकलिस्ट तैयार करें

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

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

क्रेडेंशियल्स अगली चीज़ हैं। होस्टिंग, CMS, डोमेन रजिस्ट्रार, डेटाबेस, ईमेल, FTP या SFTP, एनालिटिक्स, टैग प्रबंधक, और किसी भी तीसरे पक्ष के उपकरणों के लिए लॉगिन नामों की सूची बनाएं। पासवर्ड को सामान्य संदेश थ्रेड में न डालें। उपलब्ध सबसे सुरक्षित स्वीकृत विधि का उपयोग करें, और जो साझा किया गया है उसे रिकॉर्ड करें।

ब्रांड संपत्तियाँ पूरी होनी चाहिए। इसका मतलब है कि लोगो, आइकन, छवि पुस्तकालय, फ़ॉन्ट फ़ाइलें, कॉपी डेक, टोन दिशानिर्देश, और स्वीकृत रंग संदर्भ। यदि स्टूडियो केवल निर्यातित PNGs देता है, तो कार्यशील फ़ाइलें गायब हैं। एक फ्रीलांसर तब तेजी से काम कर सकता है जब मूल संपत्तियाँ मौजूद हों।

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

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

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

4. सही फ्रीलांसर चुनें

सही फ्रीलांसर केवल "अब उपलब्ध" नहीं है। पहले तकनीकी फिट की जांच करें। यदि प्रोजेक्ट Vue में बनाया गया है, तो फ्रीलांसर के पास वास्तविक Vue अनुभव होना चाहिए, केवल 2021 का एक लैंडिंग पेज नहीं। यदि साइट Laravel, WooCommerce, या एक कस्टम API पर निर्भर करती है, तो सटीक उदाहरण मांगें।

उपलब्धता लगभग उतनी ही महत्वपूर्ण है। एक फ्रीलांसर जो उत्कृष्ट है लेकिन 3 सप्ताह के लिए व्यस्त है, उस क्षण पर प्रोजेक्ट को फंसा सकता है जब स्टूडियो पीछे हटता है। वास्तविक प्रारंभ तिथि, प्रतिक्रिया विंडो, और साप्ताहिक क्षमता लिखित में मांगें।

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

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

पहले 72 घंटों के बारे में पूछें। एक अच्छे फ्रीलांसर को पहले चेक नामित करने में सक्षम होना चाहिए: साइट को स्थानीय रूप से चलाना, त्रुटियों का निरीक्षण करना, लॉगिन प्रवाह का परीक्षण करना, डिप्लॉयमेंट एक्सेस की समीक्षा करना, और वर्तमान बैकलॉग को पढ़ना। यदि उत्तर केवल "मैं एक नज़र डालूंगा" है, तो यह पर्याप्त नहीं है।

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

एक फ्रीलांसर जिसने पर काम किया है डिजाइनरों के लिए फ्रीलांस परियोजनाएँ यह भी समझ सकता है कि एक स्थानांतरण के दौरान दृश्य निरंतरता को कैसे सुरक्षित रखा जाए। यह तब महत्वपूर्ण होता है जब साइट डिज़ाइन स्वीकृति और लॉन्च के बीच आधे रास्ते पर होती है।

5. पहुँच और दस्तावेज़ स्थानांतरण

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

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

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

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

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

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

6. फ्रीलांसर की प्रारंभिक कार्य योजना सेट करें

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

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

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

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

फ्रीलांसर से कहें कि वह किसी भी काम को चिह्नित करे जो स्टूडियो के शेष इनपुट पर निर्भर करता है। एक फॉर्म को सामग्री निर्णय की आवश्यकता हो सकती है; एक भुगतान गेटवे को व्यापारी की पुष्टि की आवश्यकता हो सकती है; एक माइग्रेशन स्क्रिप्ट को पुराने डेवलपर के स्पष्टीकरण की आवश्यकता हो सकती है। ये निर्भरताएँ दिन 1 पर स्पष्ट होनी चाहिए, दिन 7 पर नहीं खोजी जानी चाहिए।

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

7. संक्रमण की निगरानी करें और स्टूडियो को बंद करें

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

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

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

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

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