वेब स्टूडियो से फ़्रीलांसर को प्रोजेक्ट कैसे दें

किसी प्रोजेक्ट को वेब स्टूडियो से फ़्रीलांसर के पास कैसे स्थानांतरित करें

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

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

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

शुरुआत दायरे से करें। मौजूदा टास्क लिस्ट, साइन किया हुआ ब्रीफ़, नवीनतम क्लाइंट नोट्स और आख़िरी स्वीकृत माइलस्टोन माँगें। अगर ये दस्तावेज़ आपस में मेल नहीं खाते, तो उस असंगति को दर्ज करें। जो प्रोजेक्ट “लगभग पूरा” दिखता है, उसमें भी 9 खुले बग और 3 भूले हुए पेज छिपे हो सकते हैं।

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

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

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

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

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

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

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

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

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

वेंडर-विशिष्ट टूल प्रोजेक्ट को वहीं रोक सकते हैं। कुछ स्टूडियो अपने deployment scripts, custom content sync tools, या private staging systems के साथ काम करते हैं। फ़्रीलांसर इन टूल्स के साथ तभी काम कर सकता है जब उसे पहुँच और निर्देश मिले हों। वरना हर रिलीज़ के लिए प्रोजेक्ट स्टूडियो पर निर्भर हो जाएगा, जो असली हैंडऑफ़ के ठीक उलट है।

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

छिपी हुई निर्भरताओं में लोग भी शामिल हैं। एक अकाउंट मैनेजर क्लाइंट की अप्रूवल शैली जानता हो सकता है, जबकि एक डेवलपर उस checkout bug को जानता हो सकता है जो coupon codes दो बार लगाने पर ही दिखता है। स्टूडियो उपलब्ध रहते हुए ये तथ्य लिख लें। अगर ज्ञान सिर्फ़ याददाश्त में है, तो उसे दस्तावेज़ित करें।

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

वही अनुशासन अपनाएँ जो आप फ़्रीलांसर को सुरक्षित तरीके से नियुक्त करने में रखते हैं। बात डर की नहीं है। बात यह है कि चौंकाने वाली चीज़ों की संख्या इतनी कम हो जाए कि इंसान उसे संभाल सके।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. एक्सेस और दस्तावेज़ीकरण ट्रांसफ़र करें

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

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

दस्तावेज़ीकरण भी एक्सेस के साथ जाना चाहिए। फ़्रीलांसर को सेटअप निर्देश, डिप्लॉयमेंट नोट्स, environment variables, error logs, approval history, और स्टूडियो द्वारा लिखे गए प्रक्रिया नोट्स चाहिए। अगर दस्तावेज़ सिर्फ़ चैट लॉग्स में हैं, तो उन्हें export करें या कमी को नोट करें।

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

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

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

6. फ़्रीलांसर की शुरुआती कार्य-योजना तय करें

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

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

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

माइलस्टोन लिखित रूप में तय तारीखों के साथ होने चाहिए। “जल्द” या “जितनी जल्दी हो सके” जैसी धुंधली भाषा से बचें। अगर पहला माइलस्टोन admin access बहाल करना है, तो सटीक चरण और सटीक मालिक लिखें। शुरुआती 3 tasks जितनी स्पष्ट होंगी, status calls में उतना कम समय नष्ट होगा।

फ़्रीलांसर से कहें कि वह ऐसे किसी भी काम को चिन्हित करे जो स्टूडियो के बचे हुए इनपुट पर निर्भर है। किसी फ़ॉर्म को content decision चाहिए हो सकता है; किसी payment gateway को merchant confirmation चाहिए हो सकती है; किसी migration script को पुराने डेवलपर की व्याख्या चाहिए हो सकती है। ये निर्भरताएँ पहले दिन ही दिखनी चाहिए, सातवें दिन नहीं।

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

7. ट्रांज़िशन की निगरानी करें और स्टूडियो को औपचारिक रूप से बंद करें

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

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

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

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

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