संक्षेप में जवाब
पैकेज की अवधि ठेकेदार का काम बताती है, आपकी लॉन्च तारीख़ नहीं। निर्णय, टेक्स्ट, एक्सेस और स्वीकृति उसमें क्या जोड़ते हैं, और Product Build हफ़्तों में क्यों गिना जाता है जबकि बाक़ी कार्यदिवसों में।
अवधि किन हिस्सों से बनी है: छोटा जवाब
अवधि चार खंडों को सिरे से सिरे तक जोड़कर बनती है: ठेकेदार की निर्माण अवधि, आपके निर्णय, आपकी सामग्री और स्वीकृति। कोड लिखना कैलेंडर का उतना हिस्सा नहीं घेरता जितना उस सवाल का इंतज़ार, जिसे उठाने के लिए अभी कोई राज़ी नहीं हुआ।
VITON13 का डेवलपमेंट पेज ठोस अवधियाँ बताता है: 1-2 कार्यदिवस, 2 कार्यदिवस, 3-5 कार्यदिवस, 2-3 सप्ताह और एक मासिक चक्र। इनमें से हर एक ठेकेदार का काम बताती है। लॉन्च की तारीख़ तब बनती है जब आपके अपने अंतराल जुड़ते हैं।
इसीलिए एक ही पैकेज दो ग्राहकों के लिए दो अलग तारीख़ें देता है। निर्माण एक जैसा है, पर मंज़ूरी की कतार, टेक्स्ट की तैयारी और एक्सेस सौंपने की गति एक जैसी नहीं — और यही फ़र्क़ कैलेंडर हिलाता है।
आगे बताया गया है कि हर अवधि के पीछे क्या है, आपके कौन-से क़दम उसे थामे रखते हैं, और Product Build हफ़्तों में क्यों गिना जाता है जबकि बाक़ी पैकेज कार्यदिवसों में। यह अंतर सजावटी नहीं है।
हर पैकेज असल में क्या घोषित करता है
Site Fix Pack $70 का है और 1-2 कार्यदिवस लेता है: अधिकतम पाँच सहमत सुधार, मोबाइल और डेस्कटॉप की जाँच, और हैंडओवर पर «पहले/बाद» की सूची। एक राउंड संशोधन। नए पेज, रीडिज़ाइन और माइग्रेशन पैकेज से बाहर रहते हैं।
Launch Site $380 का है और 3-5 कार्यदिवस लेता है: रिस्पॉन्सिव बिल्ड, बुनियादी CMS या डेटा कनेक्शन और डिप्लॉयमेंट सेटअप। लॉन्च से पहले दो राउंड। कंटेंट और अनुवाद ग्राहक देता है, क्योंकि ठेकेदार उन्हें नहीं लिखता।
Launch Site Express $520 का है और 2 कार्यदिवस लेता है: वही दायरा प्राथमिक कतार में, रोज़ाना बिल्ड, लॉन्च चेकलिस्ट और हैंडओवर कॉल के साथ। पहली पूरी बिल्ड के बाद एक राउंड। कंटेंट, फ़ोटोग्राफ़ी और आगे का सपोर्ट बाहर हैं।
Product Build $880 का है और 2-3 सप्ताह लेता है: फ़ीचर डिलीवरी, स्टेट और रूट लॉजिक, टेस्टिंग और हार्डनिंग। हर सौंपी गई फ़ीचर पर दो राउंड। नेटिव मोबाइल ऐप और भुगतान लाइसेंसिंग बाहर हैं। Ongoing Dev Support $290/माह, मासिक चक्र पर, रोकने के लिए 30 दिन की सूचना।
Product Build हफ़्तों में क्यों गिना जाता है
जहाँ दायरा पहले से पता हो, वहाँ कार्यदिवस ईमानदार इकाई है। पाँच सुधार, या एक रिस्पॉन्सिव बिल्ड, सूची की तरह लिखे जा सकते हैं — इसलिए अवधि काम शुरू होने से पहले बताई जा सकती है और फिर बिना दोबारा बातचीत के थामी जा सकती है।
फ़ीचर डिलीवरी ख़ुद को इस तरह बयान नहीं करती। स्टेट और रूट लॉजिक बनते-बनते खुलती है: एक स्क्रीन दूसरी की माँग करती है, और किनारे के मामले जाँचना काम को एक क़दम पीछे भेज देता है। हफ़्ता इन वापसियों को सोख लेता है, दिन नहीं।
टेस्टिंग और हार्डनिंग इन्हीं 2-3 हफ़्तों के भीतर रहते हैं। वे पैकेज का नामित हिस्सा हैं, न कि वह समय जो फ़ीचर कंपाइल होने लगने के बाद बचता है, और वे उतनी दोबारा-मेहनत पैदा करते हैं जिसे दैनिक ग्रिड नहीं संभाल सकती।
व्यावहारिक नतीजा सरल है: 2-3 सप्ताह को चुपचाप दस या पंद्रह कार्यदिवसों में बदलकर उस ग्रिड पर योजना मत बनाइए। हफ़्तों वाली भाषा जान-बूझकर चुनी गई है, और उसे अपने पत्राचार में ज्यों का त्यों रखना बेहतर है।
निर्णय: बिना लिए गए फ़ैसलों की क़तार
कैलेंडर कोड की पंक्तियों से नहीं, बिना ज़िम्मेदार वाले सवालों से ख़र्च होता है। मुखपृष्ठ की दो दिशाओं में से कौन-सी लें, मेन्यू में कितने स्तर हों, फ़ॉर्म भेजने के बाद क्या होता है — हर सवाल किसी के बंद करने का इंतज़ार करता है।
जब तक सवाल खुला है, काम रुकता नहीं; वह विवादित हिस्से के इर्द-गिर्द घूमकर निकल जाता है। यह चक्कर दो बार समय लेता है — एक बार अस्थायी फ़ैसले पर, दूसरी बार जब वह अस्थायी फ़ैसला असली जवाब से बदला जाता है।
मदद तेज़ जवाब से नहीं, नामित व्यक्ति से मिलती है। अंतिम फ़ैसले के हक़ वाला एक स्वीकृतिकर्ता चक्र को उस बड़े समूह से ज़्यादा भरोसे के साथ छोटा करता है जहाँ सब टिप्पणी करते हैं, कोई सवाल बंद नहीं करता और चर्चा घूमकर लौट आती है।
पहले से तय करें कि सवाल किस चैनल से आएँगे और कितनी जल्दी उनका जवाब मिलेगा। यह अंतराल लॉन्च तारीख़ के आपके हिस्से का है, और वह निर्माण जितना ही योजना का ध्यान माँगता है।
कंटेंट और अनुवाद ग्राहक से आते हैं
Launch Site साफ़ कहता है: कंटेंट और अनुवाद ग्राहक देता है। Express वही पंक्ति दोहराता है और फ़ोटोग्राफ़ी जोड़ देता है। VITON13 आपके टेक्स्ट न लिखता है न उनका अनुवाद करता है, और यह सेवा की सीमा है, कोई बारीक अक्षर नहीं।
इससे शुरुआत की रेखा तय होती है। तीन से पाँच कार्यदिवस हस्ताक्षर पर नहीं, सामग्री मौजूद होने पर शुरू होते हैं। ख़ाली ब्लॉक बाद में भरे नहीं जा सकते — उसके लिए लेआउट पर दूसरा दौर और दूसरी समीक्षा चाहिए।
अगर पेजों की संरचना पहले तय कर दी जाए तो टेक्स्ट निर्माण के समांतर लिखा जा सकता है। लेखक को ब्लॉकों की सूची और लंबाई की सीमा दीजिए, और सामग्री ठीक उसी बिंदु पर पहुँचेगी जहाँ निर्माण को उसकी ज़रूरत है।
बहुभाषी लॉन्च की अपनी योजना चाहिए: अनुवाद तब शुरू होता है जब स्रोत टेक्स्ट बदलना बंद कर दे। स्रोत भाषा में एक वाक्य बदलना हर भाषा संस्करण को क़तार में वापस भेज देता है, सिर्फ़ एक को नहीं।
समीक्षा के राउंड कैलेंडर घेरते हैं
संशोधन राउंड पैकेज दर पैकेज अलग हैं, और यह अंतर कैलेंडर पर उतरता है। Fix Pack में एक राउंड। Launch Site में लॉन्च से पहले दो राउंड। Express में पहली पूरी बिल्ड के बाद एक राउंड। Product Build में हर सौंपी गई फ़ीचर पर दो राउंड।
राउंड यानी इकट्ठा की गई सूची, अलग-अलग संदेशों की धारा नहीं। एक दस्तावेज़ में भेजी गई बीस टिप्पणियाँ एक दौर की क़ीमत माँगती हैं; वही बीस टिप्पणियाँ हफ़्ते भर एक-एक करके भेजी जाएँ तो पूरा हफ़्ता ले लेती हैं।
Ongoing Dev Support के लिए संशोधन की कोई संख्या घोषित ही नहीं है। इसके बजाय घोषित है कि मात्रा हर चक्र की शुरुआत में तय होती है। किसी दूसरे पैकेज से संख्या मत ढोइए, क्योंकि पैकेज की शर्तें स्थानांतरित नहीं होतीं।
स्वीकृति की खिड़की को बैठक की तरह बुक करें: कौन समीक्षा करेगा, किन उपकरणों पर, और किस समय तक सूची भेजी जाएगी। इसके बिना राउंड ठीक उतना खिंचता है जितना आपकी टीम के भीतर राय जुटाने में लगता है।
एक्सेस, खाते और बाहरी पक्ष
डिप्लॉयमेंट सेटअप Launch Site का हिस्सा है, पर वह इस पर निर्भर है कि आप क्या सौंपते हैं: डोमेन, DNS, होस्टिंग और खातों के विवरण। जब तक एक्सेस नहीं है, काम पूरा हो सकता है जबकि लॉन्च व्यवहार में हुआ ही नहीं।
इनमें से कुछ एक्सेस बाहरी संगठन अपनी गति से जारी करते हैं। रजिस्ट्रार, बैंक, भुगतान प्रदाता या कंपनी का आईटी विभाग अपने कार्यक्रम पर जवाब देता है, और कोई ठेकेदार उस कार्यक्रम को आपके लिए दबा नहीं सकता।
एक्सेस लॉन्च के दिन नहीं, पहले दिन इकट्ठा करें। सूची छोटी है और पहले से पता है, इसलिए वह निर्माण के साथ आराम से चलती है और जब तक आप एक-एक बिंदु निपटाते हैं, किसी को नहीं रोकती।
भुगतान लाइसेंसिंग Product Build से बाहर है। जहाँ उत्पाद को भुगतान लेना है, वहाँ क़ानूनी पक्ष और प्रदाता के साथ काम आपकी तरफ़ रहता है और डेवलपमेंट के 2-3 हफ़्तों से अलग योजना में आता है।
दायरे की सीमाएँ: अवधि को क्या थामता है और क्या हिलाता है
अवधि को सूची थामे रखती है। «अधिकतम पाँच सहमत सुधार» वही सूची है, और इसी वजह से 1-2 कार्यदिवस एक यथार्थवादी वादा बना रहता है। छठा सुधार पैकेज को खींचता नहीं; वह अलग काम बन जाता है।
Fix Pack नए पेज, रीडिज़ाइन और माइग्रेशन को बाहर रखता है। यह औपचारिकता नहीं है: डेटा हटाना-लाना और लेआउट दोबारा गढ़ना समय की दूसरी इकाई में रहते हैं, और उन्हें दो दिन की खिड़की में ठूँसना ख़ुद खिड़की तोड़ देता है।
Product Build नेटिव मोबाइल ऐप को बाहर रखता है। वेब बिल्ड और नेटिव ऐप काम के दो अलग पिंड हैं, और एक की जगह दूसरा रख देना सेवा की संरचना बदल देता है, उसकी समाप्ति तिथि नहीं।
दायरे की भाषा बीच में नहीं, शुरू होने से पहले जाँचें। «यह शामिल है या नहीं» सवाल शुरुआत में एक मिनट लेता है और निर्माण चलने तथा कार्यक्रम तय होने के बाद कई दिन।
टेस्टिंग, परफ़ॉर्मेंस और सुलभता
टेस्टिंग और हार्डनिंग Product Build के भीतर नामित हैं, यानी उन्हीं 2-3 हफ़्तों के भीतर नामित हैं। कैलेंडर में उनकी अपनी जगह है, वह बचा हुआ समय नहीं जो फ़ीचर लिखे और सौंपे जाने के बाद बचे।
परफ़ॉर्मेंस अनुभव से नहीं, माप से जाँची जाती है। MDN Web Docs की परफ़ॉर्मेंस सामग्री बताती है कि ब्राउज़र क्या दिखाता है और लोडिंग के कौन-से चरण देखने लायक़ हैं; इन जाँचों में घंटे लगते हैं, और वे घंटे योजना में होने चाहिए।
सुलभता भी इसी तरह काम करती है। W3C की WCAG 2.2 त्वरित संदर्भिका उन सफलता मानदंडों को सूचीबद्ध करती है जिनके ख़िलाफ़ इंटरफ़ेस जाँचा जाता है, और उस सूची से गुज़रना प्रकाशन से पहले की आख़िरी नज़र नहीं, नियोजित काम है।
दोनों जाँचें लॉन्च के बाद की तुलना में पहले सस्ती पड़ती हैं। निर्माण के दौरान मिली चीज़ राउंड के भीतर ठीक होती है; वही चीज़ लॉन्च के बाद मिले तो अलग काम बनकर आती है और पैकेज से अलग चुकाई जाती है।
कार्यदिवस बनाम कैलेंडर दिन
1-2 कार्यदिवस, 2 कार्यदिवस और 3-5 कार्यदिवस ठीक कार्यदिवसों में बताए गए हैं। 3-5 कार्यदिवस की खिड़की गुरुवार को शुरू हो तो समाप्ति सप्ताहांत के पार चली जाती है, और यह भाषा के भीतर का अंकगणित है, ठेकेदार की तरफ़ की देरी नहीं।
Product Build के 2-3 सप्ताह अलग तरह से, हफ़्तों में बताए गए हैं। उन्हें बदलने की ज़रूरत नहीं: इकाई काम के स्वभाव से मेल खाने के लिए चुनी गई है, साझा प्रोजेक्ट स्प्रेडशीट की सुविधा के लिए नहीं।
आपके देश की और ठेकेदार के देश की छुट्टियाँ मेल न खा सकती हैं। उन्हें शुरू होने से पहले बता दीजिए, क्योंकि यह उस क्षण अंतर समझाने से सस्ता है जब बाज़ार से तारीख़ का वादा हो चुका हो।
लॉन्च की तारीख़ पाने के लिए तीन अंतराल जोड़ें: पैकेज की अवधि, निर्णयों तथा सामग्री के आपके अपने अंतराल, और स्वीकृति की खिड़की। यही जोड़ वह तारीख़ है जिसे आप प्रोजेक्ट टीम के बाहर सुरक्षित रूप से दोहरा सकते हैं।
Express: क़तार में जगह ख़रीदना
Launch Site Express $520 का है, जबकि सामान्य Launch Site $380 का, और यह 2 कार्यदिवस लेता है, जबकि वह 3-5। क़ीमत का अंतर प्राथमिक कतार ख़रीदता है, अलग किस्म का काम नहीं।
Express रोज़ाना बिल्ड, लॉन्च चेकलिस्ट और हैंडओवर कॉल जोड़ता है। रोज़ाना बिल्ड का मतलब है कि आपकी टिप्पणियाँ हर दिन एक चलती हुई प्रति पर उतरती हैं, और इससे प्रोजेक्ट के दोनों पक्षों के बीच फ़ीडबैक का चक्र कसता है।
यहाँ एक राउंड संशोधन है, और वह पहली पूरी बिल्ड के बाद आता है। इससे आपकी तैयारी बदलती है: टिप्पणियाँ तय समय तक एक ही दस्तावेज़ में जानी चाहिए, वरना दो कार्यदिवसों की खिड़की का मक़सद ही ख़त्म हो जाता है।
Express से कंटेंट, फ़ोटोग्राफ़ी और आगे का सपोर्ट बाहर हैं। प्राथमिक कतार ठेकेदार को तेज़ करती है, आपके अपने टेक्स्ट लिखने को नहीं — इसलिए सामग्री खिड़की खुलने से पहले ही मौजूद होनी चाहिए।
लॉन्च के बाद: तारीख़ के बजाय मासिक चक्र
Ongoing Dev Support $290/माह का है और मासिक चक्र पर चलता है, रोकने के लिए 30 दिन की सूचना के साथ। यहाँ इकाई न कोई काम है न कोई दिन, बल्कि एक चक्र — और योजना तारीख़ों के बजाय चक्रों के हिसाब से बनती है।
पैकेज में प्राथमिक अपडेट, साप्ताहिक रिलीज़ लय और तकनीकी रखरखाव शामिल हैं। साप्ताहिक लय पूर्वानुमेयता ख़रीदती है: बदलाव अगली रिलीज़ में जाता है, इस नई बातचीत का इंतज़ार नहीं करता कि वह कब निकलेगा।
सपोर्ट के लिए संशोधन की संख्या घोषित नहीं है। इसके बजाय घोषित है कि मात्रा हर चक्र की शुरुआत में तय होती है। योजना का तंत्र यही है: आप महीने की सामग्री तय करते हैं, दोबारा-काम का कोटा नहीं।
नई बिल्ड या रीडिज़ाइन सपोर्ट से बाहर है और अलग से आँका जाता है। यह बँटवारा उपयोगी है: मासिक चक्र चलती हुई साइट संभालता है, जबकि बड़े काम को अपनी अलग खिड़की और अपने राउंड मिलते हैं।
व्यावहारिक चेकलिस्ट
- अंतिम फ़ैसले के हक़ वाला एक ही स्वीकृतिकर्ता नियुक्त करें और सवालों के जवाब की गति तय करें।
- डोमेन, DNS, होस्टिंग और खातों के एक्सेस पहले दिन इकट्ठा करें, लॉन्च के दिन नहीं।
- लेखक के लिखना शुरू करने से पहले पेजों की संरचना तय कर लें।
- टिप्पणियाँ एक दस्तावेज़ में इकट्ठा करें और तय समय पर एक ही राउंड में भेजें।
- पैकेज के बहिष्करण जाँचें: नए पेज, माइग्रेशन, नेटिव मोबाइल ऐप, भुगतान लाइसेंसिंग।
- पैकेज की अवधि को दोनों पक्षों के सप्ताहांत और छुट्टियों के साथ कैलेंडर तारीख़ में बदलें।
सवाल और जवाब
लॉन्च वेबसाइट बनाने में कितना समय लगता है?
Launch Site $380 का है और 3-5 कार्यदिवस लेता है। इस अवधि में रिस्पॉन्सिव बिल्ड, बुनियादी CMS या डेटा कनेक्शन, डिप्लॉयमेंट सेटअप और लॉन्च से पहले दो राउंड संशोधन शामिल हैं। कंटेंट और अनुवाद ग्राहक देता है।
Product Build कार्यदिवसों के बजाय हफ़्तों में क्यों गिना जाता है?
पैकेज $880 का है और 2-3 सप्ताह में घोषित है, क्योंकि इसमें फ़ीचर डिलीवरी, स्टेट और रूट लॉजिक तथा टेस्टिंग और हार्डनिंग शामिल हैं। यह काम बनते-बनते खुलता है, इसलिए साप्ताहिक इकाई जान-बूझकर है और उसे दिनों में बदलने की ज़रूरत नहीं।
क्या ज़्यादा पैसे देकर लॉन्च तेज़ किया जा सकता है?
आंशिक रूप से। Launch Site Express $520 का है और 2 कार्यदिवस लेता है: वही दायरा प्राथमिक कतार में, रोज़ाना बिल्ड, लॉन्च चेकलिस्ट और हैंडओवर कॉल के साथ। एक राउंड संशोधन पहली पूरी बिल्ड के बाद आता है, और कंटेंट, फ़ोटोग्राफ़ी तथा आगे का सपोर्ट बाहर हैं।
Site Fix Pack में क्या है और किस अवधि में?
$70 और 1-2 कार्यदिवस: अधिकतम पाँच सहमत सुधार, मोबाइल और डेस्कटॉप जाँच, हैंडओवर पर «पहले/बाद» सूची और एक राउंड संशोधन। नए पेज, रीडिज़ाइन और माइग्रेशन इस पैकेज का हिस्सा नहीं।
तकनीकी सपोर्ट की अवधि कैसे गिनी जाती है?
Ongoing Dev Support $290/माह का है और मासिक चक्र पर चलता है, रोकने के लिए 30 दिन की सूचना के साथ। इसके लिए संशोधन राउंड की संख्या घोषित नहीं है; घोषित यह है कि मात्रा हर चक्र की शुरुआत में तय होती है। नई बिल्ड या रीडिज़ाइन का अनुमान अलग लगता है।