सात-प्रॉम्प्ट की दीवार: शिप करने में वास्तव में कितने प्रॉम्प्ट लगते हैं

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

ये चारों आंकड़े बार-बार एक ही पैटर्न बताते हैं: बिल्ड्स जल्दी फंक्शनल हो जाते हैं, फिर अपनी बाकी की ज़्यादातर ज़िंदगी दोबारा बनने के बजाय उनके बारे में बातें होने में बिताते हैं।

दीवार वहां नहीं है जहां आप उम्मीद करेंगे

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

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

"पूरा हो गया" रुकने का बिंदु क्यों नहीं लगता

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

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

देर से आने वाले प्रॉम्प्ट्स असल में क्या बदलते हैं

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

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

बीस बनाम तीस के फर्क से असल में क्या पता चलता है

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

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

इससे व्यावहारिक रूप से क्या सीख मिलती है

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