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

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

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

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

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

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

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

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

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

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

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

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

2. जोखिम और निर्भरताओं की पहचान करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सही फ्रीलांसर केवल “अब उपलब्ध” नहीं है। पहले तकनीकी फिट की जांच करें। यदि प्रोजेक्ट Vue में बनाया गया है, तो फ्रीलांसर के पास वास्तविक Vue अनुभव होना चाहिए, न कि केवल 2021 से एक लैंडिंग पृष्ठ। यदि साइट लारवेल, वू-कॉमर्स, या एक कस्टम API पर निर्भर करती है, तो सटीक उदाहरण मांगें।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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