योजना पढ़ना (और उसे बदलना)

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

गलती एक: बिना जांचे मंज़ूरी दे देना

यह सबसे आम गलती है। स्केलेटन सही दिखता है, अप्रूव पर क्लिक करो, आगे बढ़ो — मैंने हफ्तों तक ऐसा किया जब तक इसने मुझे नुकसान नहीं पहुँचाया। जिस बिल्ड ने आखिरकार यह आदत तोड़ी वह एक स्टैटिक साइट में जोड़े गए Stripe चेकआउट के साथ वापस आया, जबकि उस साइट में Stripe को जिस अकाउंट स्टेट की ज़रूरत थी उसके लिए कोई जगह ही नहीं थी। प्लान में साफ शब्दों में लिखा था product type: static site, ठीक कार्ड पर, और मैं जल्दी में पेज लिस्ट सही देखकर आगे बढ़ गया।

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

गलती दो: दूसरे राउंड से बचने के लिए अति-विस्तार में जाना

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

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

सादी भाषा के एडिट जो वाकई काम करते हैं, छोटे होते हैं:

• "Blog हटाओ, pricing page जोड़ो" — पेज लिस्ट को साफ-सुथरे तरीके से बदल देता है।
• "इसे सिंगल-प्लेयर की बजाय टू-प्लेयर बनाओ" — यह सुनने से बड़ा असर डालता है। यह डेटा मॉडल को छू सकता है, अब एक की बजाय दो प्रतिभागियों को ट्रैक करते हुए, और रिवाइज़्ड प्लान इस असर को छिपाने की बजाय दिखाएगा।
• "इसे यूज़र अकाउंट्स चाहिए" — अगर मौजूदा प्लान स्टैटिक साइट है, तो यही वाक्य product-type वाला सवाल सीधे खड़ा कर देता है।

गलती तीन: product type को एक लचीला फील्ड मानना

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

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

लोग इसे दो तरीकों से गलत करते हैं। पहला, वे अपने खुद के प्रॉम्प्ट को फील्ड से चेक नहीं करते — अगर आपके प्रॉम्प्ट में "accounts," "login," "save," "dashboard that updates," "payments," या "multiple users editing the same thing" है, और कार्ड server-backed नहीं कहता, तो यही वह एक एडिट है जो अप्रूव करने से पहले करना चाहिए, कोई अपवाद नहीं। दूसरा, वे installable app और framework build को उलझा देते हैं, क्योंकि दोनों बातचीत में "एक ऐप" जैसे लगते हैं। ये आपस में बदले नहीं जा सकते: installable app उस टूल के लिए है जहाँ सारा स्टेट यूज़र की डिवाइस पर रहता है — एक tip कैलकुलेटर, एक वर्कआउट टाइमर। Framework build का मतलब है ज़्यादा इंटरैक्टिविटी और कंपोनेंट स्ट्रक्चर लेकिन फिर भी सेशंस या डिवाइस के पार सर्वर-साइड पर कुछ भी स्थायी न रहना। इनमें से कोई भी "एक ऐप" उस अर्थ में नहीं है जहाँ अकाउंट्स और डेटा हो जो आपके साथ डिवाइस के पार चलता है — केवल server-backed ही ऐसा है। और "क्या पता" सोचकर server-backed पर ओवर-प्रोविज़न करना एक पोर्टफोलियो साइट या डॉक्यूमेंटेशन पेज के लिए भी सुरक्षित विकल्प नहीं है; बाद में डाउनग्रेड करना भी उतना ही रीबिल्ड है जितना अपग्रेड करना होता।

जब आप वे तीन काम करना बंद कर देते हैं तो जो बचता है

जब आप product-type वाली लाइन को सरसरी तौर पर नहीं देख रहे, प्लान स्टेज पर स्पेक नहीं लिख रहे, और अपने प्रॉम्प्ट में account/data/payment भाषा को सौदेबाज़ी योग्य नहीं मान रहे, तब जो बचता है वह एक तेज़, संकीर्ण जांच है:

1. Product type पढ़ें।
2. इसे अपने प्रॉम्प्ट से क्रॉस-चेक करें।
3. अनुमानित-फीचर्स लिस्ट को सरसरी तौर पर देखें कि कोई ऐसी चीज़ तो नहीं जिसे आप देखते ही रिजेक्ट कर देंगे।

यह लिस्ट ठीक इसलिए मौजूद है क्योंकि "hair salons के लिए scheduling tool" जैसा प्रॉम्प्ट ऐसी चीज़ें खींच लाता है जो आपने टाइप नहीं की थीं — कैलेंडर व्यू और SMS रिमाइंडर और एक क्लाइंट लिस्ट, जिनमें से कुछ आपका मतलब था और कुछ scope creep है जो मॉडल ने जोड़ा क्योंकि ये फीचर्स सांख्यिकीय रूप से साथ चलते हैं। जो चीज़ फिट नहीं बैठती उसे यहीं एक वाक्य में हटाएं, बिल्ड होने के बाद नहीं।

बाकी सब कुछ — कॉपी, स्पेसिंग, एक्सेंट कलर की कौन-सी शेड, बटन "Get Started" कहे या "Try It Free" — जानबूझकर कार्ड पर बिल्कुल नहीं होता। इन्हें एक काम करते बिल्ड पर देखना और ठीक करना सस्ता है, इसलिए कार्ड आपका ध्यान इन पर बर्बाद नहीं करता, और न ही आपको करना चाहिए। यह उस तीस सेकंड में असली जजमेंट के शायद पंद्रह सेकंड हैं जो इसे पढ़ने में लगते हैं।