प्रॉम्प्ट गाइड
Claude से प्रोजेक्ट प्रपोज़ल कैसे लिखवाएँ
जो प्रपोज़ल मंज़ूर होता है वह ठोस होता है। जो नज़रअंदाज़ होता है वह धुंधला होता है।
Anthropic के Claude एक कच्चे प्रोजेक्ट आइडिया को समस्या विवरण, दायरे, टाइमलाइन, और उस तरह के ठोस विवरण के साथ संरचित प्रपोज़ल में बदलने में माहिर है जो किसी हितधारक को वास्तव में हाँ कहने पर मजबूर करता है। Claude को जो नहीं पता वह है आपका बजट, आपकी टीम की वास्तविक क्षमता, या आपके संगठन की राजनीति, जब तक आप उसे न बताएँ, इसीलिए "X के लिए प्रोजेक्ट प्रपोज़ल लिखो" अक्सर इतना सामान्य आता है कि वह किसी भी कंपनी का हो सकता है। समाधान है Claude को असली सीमाएँ देना: प्रपोज़ल किसके लिए है, आपके पास वास्तव में काम करने के लिए क्या है, और आपको उस व्यक्ति से किस निर्णय की ज़रूरत है।
Claude से प्रोजेक्ट प्रपोज़ल लिखवाने के लिए, वह समस्या बताएँ जिसे आप हल कर रहे हैं, प्रपोज़ल किसके लिए है और आपको उनसे कौन सा निर्णय चाहिए, अपनी असली सीमाएँ (टीम का आकार, अनुमानित टाइमलाइन, बजट की सीमा), और ड्राफ्ट को समस्या विवरण, प्रस्तावित तरीका, दायरा, टाइमलाइन, और सफलता के मानकों के रूप में संरचित करने का निर्देश दें। आपके पास मौजूद कोई भी संदर्भ सामग्री, पिछले प्रपोज़ल, या नोट्स पेस्ट करें, और Claude से उन बातों को चिह्नित करने को कहें जो एक ठोस योजना बनाने के लिए बहुत धुंधली हैं।
प्रकाशित
मुफ़्त पाठ · खाते की ज़रूरत नहींClaude से मिलेंClaude क्यों?6 मि॰मुफ़्त पाठ शुरू करेंमुख्य बातें
- बताएँ कि प्रपोज़ल किसके लिए है और आपको उनसे कौन सा निर्णय चाहिए। आपकी अपनी टीम की योजना बनाने के लिए प्रपोज़ल किसी अधिकारी से बजट मंज़ूर करवाने वाले प्रपोज़ल से अलग पढ़ा जाता है।
- Claude को अपनी असली सीमाएँ दें: टीम का आकार, अनुमानित टाइमलाइन, बजट की सीमा। बनावटी सीमाओं पर बनी योजना को उस पल दोबारा लिखना पड़ता है जब असली आँकड़े जानने वाला कोई इसे पढ़ता है।
- काम के विवरण के बजाय खासतौर पर सफलता के मानक माँगें। जो प्रपोज़ल यह नहीं बताता कि आप कैसे जानेंगे कि यह काम कर गया, उसे मंज़ूर करना कठिन है और बाद में जाँचना भी कठिन है।
- अपने पास मौजूद संदर्भ सामग्री पेस्ट करें: पिछले प्रपोज़ल, मीटिंग के नोट्स, कच्ची रूपरेखा। Claude जो आप देते हैं उसे व्यवस्थित और तेज़ करता है; यह आपके विशेष प्रोजेक्ट के पीछे का संदर्भ बना नहीं सकता।
- भेजने से पहले दायरे वाले हिस्से को विशेष ध्यान से पढ़ें। आपके असली इरादे से ज़्यादा धुंधला या व्यापक दायरा वह सबसे सामान्य वजह है जिससे प्रपोज़ल बाद में समस्या पैदा करता है।
कॉपी करें और पेस्ट करें
आज ही इस्तेमाल करने लायक प्रॉम्प्ट
एक कच्चे आइडिया से पहला पूरा ड्राफ्ट
मैं [एक या दो वाक्यों में अपना प्रोजेक्ट आइडिया बताएँ] प्रस्तावित करना चाहता हूँ। यह [प्रपोज़ल किसके लिए है और आपको उनसे कौन सा निर्णय चाहिए] के लिए है। यह है जो मेरे पास वास्तव में काम करने के लिए है: टीम [आकार], टाइमलाइन लगभग [समय सीमा], बजट लगभग [सीमा, या 'अभी तय नहीं हुआ']। समस्या विवरण, प्रस्तावित तरीका, दायरा (जिसमें स्पष्ट रूप से दायरे से बाहर क्या है शामिल हो), एक अनुमानित टाइमलाइन, और सफलता के मानकों के साथ एक प्रपोज़ल ड्राफ्ट लिखो। जो भी तुम्हें अनुमान लगाना पड़ा क्योंकि मैंने पर्याप्त विवरण नहीं दिया, उसे चिह्नित करो।
बजट जैसी चीज़ों के बारे में जो आप अभी नहीं जानते उसके बारे में ईमानदार होना, खाली जगह भरने के लिए एक नंबर बनाने से ज़्यादा उपयोगी ड्राफ्ट देता है।
बिखरी हुई सोच को समस्या विवरण में बदलना
यह एक समस्या के बारे में मेरे कच्चे, असंगठित नोट्स हैं जिसे मैं हल करना चाहता हूँ: [अपने नोट्स पेस्ट करें]। इसे एक संक्षिप्त, दो से तीन वाक्यों के समस्या विवरण में बदलो जो बताए कि यह क्यों मायने रखता है और इससे कौन प्रभावित होता है, अभी समाधान का वर्णन किए बिना। मैं चाहता हूँ कि समाधान प्रस्तावित करने से पहले समस्या स्पष्ट रूप से परिभाषित हो।
समस्या विवरण को समाधान से अलग रखें; सीधे समाधान पर कूदने वाला प्रपोज़ल अक्सर उस पाठक को खो देता है जो अभी यह नहीं मानता कि हल करने लायक कोई समस्या है।
दायरा परिभाषित करना, जिसमें बाहर क्या है शामिल हो
यह मेरा प्रस्तावित प्रोजेक्ट है: [इसका वर्णन करें]। एक दायरे वाला हिस्सा लिखो जो स्पष्ट रूप से बताए कि यह प्रोजेक्ट क्या शामिल करेगा और क्या नहीं, जिसमें कम से कम तीन विशेष चीज़ें स्पष्ट रूप से दायरे से बाहर बताई गई हों। मैं प्रपोज़ल को मेरे इरादे से ज़्यादा व्यापक रूप से पढ़े जाने से बचना चाहता हूँ।
दायरे से बाहर क्या है इसकी स्पष्ट सूची अक्सर प्रपोज़ल का वह हिस्सा होता है जो बाद में सबसे ज़्यादा भ्रम रोकता है।
भेजने से पहले प्रपोज़ल का तनाव परीक्षण
इस प्रपोज़ल ड्राफ्ट को उस हितधारक की तरह पढ़ो जो यह तय कर रहा है कि इसे मंज़ूर करना है या नहीं: [अपना ड्राफ्ट पेस्ट करें]। इसे मंज़ूर करने से पहले तुम्हारे पास क्या सवाल होंगे? टाइमलाइन, दायरा, या सफलता का मानक कहाँ अवास्तविक या अस्पष्ट लगता है? यह बताओ कि क्या कमी है, सिर्फ़ क्या गलत है यह नहीं।
यह प्रपोज़ल भेजने से ठीक पहले सबसे अच्छा काम करता है, शुरुआती ड्राफ्ट चरण के बजाय आख़िरी जाँच के रूप में।
एक अलग दर्शक के लिए प्रपोज़ल के लहजे को समायोजित करना
यह एक प्रोजेक्ट प्रपोज़ल है जो मैंने अपनी टीम के लिए लिखा: [अपना ड्राफ्ट पेस्ट करें]। इसे उस कार्यकारी दर्शक के लिए फिर से लिखो जिसे बजट मंज़ूर करना है: बिज़नेस केस और लागत से शुरू करो, तकनीकी विवरण छोटा रखो, और किसी भी कार्यान्वयन विवरण को आख़िर में एक परिशिष्ट हिस्से में ले जाओ।
एक ही प्रोजेक्ट को अक्सर दो अलग-अलग संस्करणों की ज़रूरत होती है, यह इस पर निर्भर करता है कि कौन पढ़ रहा है और उस व्यक्ति को क्या तय करना है।
संरचना
प्रपोज़ल प्रॉम्प्ट को चाहिए पाँच हिस्से
ये पाँच तत्व धुंधले आइडिया को ऐसी चीज़ में बदल देते हैं जिस पर हितधारक वास्तव में कार्य कर सकता है।
समाधान से पहले समस्या विवरण
समाधान बताने से पहले समस्या बताएँ और वह क्यों मायने रखती है। जो पाठक अभी यह नहीं मानता कि समस्या है, वह उसके लिए प्रस्तावित समाधान को गंभीरता से नहीं लेगा।
दायरा, जिसमें स्पष्ट रूप से बाहर क्या है शामिल हो
बताएँ कि प्रोजेक्ट क्या करेगा और, बराबर महत्व के साथ, क्या नहीं करेगा। परिभाषित दायरे के बिना प्रपोज़ल हर किसी के दिमाग में उस चीज़ तक बढ़ता जाता है जो उन्होंने मान लिया था इसका मतलब है।
असली सीमाएँ, बनावटी नहीं
Claude को अपनी असली टीम का आकार, अनुमानित टाइमलाइन, और बजट की सीमा दें, भले ही इसमें से कुछ अभी अनिश्चित हो। बनावटी आँकड़ों पर बनी योजना को असली आँकड़े सामने आने पर फिर से बनाना पड़ता है।
स्पष्ट रूप से बताए गए सफलता के मानक
बताएँ कि आप कैसे जानेंगे कि प्रोजेक्ट ने काम किया। सफलता के मानक के बिना प्रपोज़ल मंज़ूर करना कठिन है, और अगर फिर भी मंज़ूर हो जाए, तो छह महीने बाद जाँचना कठिन है।
अपने पाठक को जानें
एक ही प्रोजेक्ट को अलग दर्शक के लिए अलग प्रपोज़ल की ज़रूरत होती है
आपकी अपनी टीम को योजना बनाने के लिए लिखा गया प्रपोज़ल और किसी अधिकारी से बजट मंज़ूरी पाने के लिए लिखा गया प्रपोज़ल अलग-अलग काम करते हैं, भले ही वे एक ही प्रोजेक्ट का वर्णन करें। टीम वाला संस्करण कार्यान्वयन विवरण में गहराई तक जा सकता है क्योंकि पाठक को पहले से उसकी परवाह है। कार्यकारी संस्करण को बिज़नेस केस और लागत से शुरू करना चाहिए, क्योंकि यही वह असली निर्णय है जो उस पाठक को लेना है, और अनावश्यक विवरण सिर्फ़ उस निर्णय को देर करता है जो आप माँग रहे हैं।
Claude को स्पष्ट रूप से बताएँ कि कौन पढ़ रहा है और आपको उस व्यक्ति से कौन सा निर्णय चाहिए। "यह मेरी टीम के लिए अगली तिमाही की योजना बनाने के लिए है" और "इसे ऐसे वीपी से बजट मंज़ूरी चाहिए जो तकनीकी विवरण नहीं जानते" Claude को एक ही प्रोजेक्ट के लिए भी दो अलग-अलग ड्राफ्ट की ओर ले जाते हैं, और पहले से दर्शक का नाम लेना आपको एक संस्करण लिखने और बाद में यह पता लगाने से बचाता है कि यह असली पाठक के लिए गलत था।
अगर आपको वास्तव में दोनों संस्करणों की ज़रूरत है, तो अक्सर दोनों को शुरू से लिखने के बजाय पहले विस्तृत टीम संस्करण लिखना और फिर Claude से कार्यकारी दर्शकों के लिए उसे समायोजित करने को कहना तेज़ होता है। अंतर्निहित तथ्य नहीं बदलते; केवल क्या ज़ोर दिया जाता है और क्या परिशिष्ट में जाता है, यह बदलता है।
सामान्य गलतियाँ
क्या प्रपोज़ल को मंज़ूर होने के बजाय अटका देता है
ये वे कमियाँ हैं जो एक उचित आइडिया को ऐसे प्रपोज़ल में बदल देती हैं जो बिना जवाब के रह जाता है।
आपके असली इरादे से ज़्यादा व्यापक दायरा
अगर आप यह नहीं बताते कि क्या दायरे से बाहर है, तो पाठक उस खाली जगह को अपनी धारणाओं से भरते हैं, जो अक्सर आपके प्रस्तावित से बड़ी होती हैं। स्पष्ट रूप से बताएँ कि यह प्रोजेक्ट क्या शामिल नहीं करेगा।
पाठक के लिए कोई बताया गया निर्णय नहीं
जो प्रपोज़ल यह नहीं बताता कि आप वास्तव में क्या माँग रहे हैं, मंज़ूरी, बजट, कर्मचारी, शुरू करने की हरी झंडी, वह पाठक को यह अनिश्चित छोड़ देता है कि उसे कौन सा जवाब चाहिए।
असली सीमाओं के बजाय बनावटी आँकड़े
एक टाइमलाइन या बजट जिसे Claude ने अनुमान लगाया क्योंकि आपने एक नहीं दिया, भरोसेमंद लगेगा भले ही वह काल्पनिक हो, और असली आँकड़े जानने वाला कोई नोटिस करेगा कि प्रपोज़ल वास्तविकता से मेल नहीं खाता।
बाद में यह जानने का कोई तरीका नहीं कि यह काम कर गया
सफलता के मानकों के बिना प्रपोज़ल को आत्मविश्वास से मंज़ूर करना कठिन है, और अगर फिर भी मंज़ूर हो जाए, तो छह महीने बाद यह जाँचने का कोई सहमत तरीका नहीं है कि प्रोजेक्ट ने परिणाम दिया या नहीं।
आपके पास जो है उसका उपयोग करना
शुरुआत से करने के बजाय अपनी संदर्भ सामग्री पेस्ट करें
अगर आपके पास किसी समान चीज़ के लिए पहले का प्रपोज़ल है, समस्या के बारे में कच्चे मीटिंग नोट्स हैं, या आधी बनी रूपरेखा भी है, तो उसे पेस्ट करें बजाय इसके कि आप प्रोजेक्ट को याददाश्त से शुरू से वर्णित करें। Claude आपके पास मौजूद सामग्री को व्यवस्थित और तेज़ करने में, एक-वाक्य विवरण से आपके असली प्रोजेक्ट के विशेष संदर्भ, इतिहास, और सीमाओं को बनाने की तुलना में कहीं ज़्यादा भरोसेमंद है।
यह खासतौर पर समस्या विवरण के लिए मायने रखता है। अगर समस्या किसी मीटिंग में, किसी ग्राहक की शिकायत में, या किसी समान चीज़ के पहले के असफल प्रयास में सामने आई, तो वह संदर्भ प्रॉम्प्ट में शामिल होना चाहिए। एक समस्या विवरण जो सिर्फ़ मुद्दे के आपके वर्तमान सारांश से बना है, अक्सर वह विशेष विवरण खो देता है जो समस्या को वास्तविक और हल करने लायक बनाता है।
सीमाओं के लिए भी यही लागू होता है। अगर आपके संगठन के पास पहले से एक मानक प्रपोज़ल टेम्पलेट है, इस तरह के प्रोजेक्ट के लिए एक सामान्य बजट सीमा है, या एक सामान्य टाइमलाइन परंपरा है, तो इसे सामान्य संरचना पर वापस जाने देने के बजाय सीधे Claude को दें। जो प्रपोज़ल पहले से आपके संगठन की अपेक्षा के अनुरूप है, वह किसी और जगह के टेम्पलेट जैसा लगने वाले प्रपोज़ल से ज़्यादा गंभीरता से पढ़ा जाता है।
अपने संगठन में मंज़ूर हुए प्रस्तावों का एक लगातार अपडेट होने वाला फ़ोल्डर रखना फ़ायदेमंद है, चाहे वह मंज़ूरी औपचारिक न रही हो, और जब हो सके तो किसी सफल प्रस्ताव को अपने ड्राफ़्ट के साथ चिपका लें। Claude यह पैटर्न पकड़ सकता है कि आम तौर पर क्या चलता है, जैसे औपचारिकता का कोई खास स्तर, लंबे के बजाय छोटे पैराग्राफ़ की पसंद, या जोखिम कम करने की बात से शुरुआत करने की आदत, और उसी पैटर्न को आपके मौजूदा ड्राफ़्ट पर लागू कर सकता है, बजाय किसी सामान्य ढांचे पर निर्भर रहने के जो आपके कार्यस्थल पर वास्तव में काम करने वाली चीज़ों से मेल नहीं खाता।
भेजने से पहले
प्रपोज़ल पाठक तक पहुँचने से पहले क्या जाँचना चाहिए
दायरे वाले हिस्से को पहले पढ़ें और खुद से पूछें कि क्या यह ठीक वही बताता है जो आप करने का इरादा रखते हैं, न ज़्यादा न कम। यह वह हिस्सा है जो बाद में समस्या पैदा करने की सबसे ज़्यादा संभावना रखता है अगर यह आपके असली इरादे से ज़्यादा धुंधला या व्यापक है, क्योंकि यह वह बिंदु बन जाता है जिस पर सब कुछ चलने के बाद हर कोई वापस इशारा करता है।
हर आँकड़े को वास्तविकता के साथ जाँचें: टाइमलाइन, टीम का आकार, बजट। एक योजना जो भरोसेमंद लगती है लेकिन अनुमानित आँकड़े पर बनी है, एक ईमानदार "टाइमलाइन अभी अंतिम नहीं" से बुरी है, क्योंकि पहली को कोई पढ़ते ही एक प्रतिबद्धता माना जाता है।
यहाँ की संरचना आपको जल्दी एक मज़बूत ड्राफ्ट देती है; आपका संगठन और आपका पाठक इस विशेष प्रपोज़ल के लिए वास्तव में क्या चाहते हैं, इसका फ़ैसला इसके भेजे जाने से पहले अब भी आपका है।
स्पष्ट प्रपोज़ल पढ़ा जाता है। धुंधला प्रपोज़ल नज़रअंदाज़ होता है।
यह संरचना इसके बाद हर प्रपोज़ल के लिए फिर से इस्तेमाल की जा सकती है। Nightschool AI के मुफ़्त पाठ दायरे और दर्शकों के बारे में फ़ैसलों सहित Claude के साथ असली कार्यस्थल लेखन कार्यों से गुज़रते हैं।
अक्सर पूछे जाने वाले प्रश्न
Claude के प्रपोज़ल तैयार करने से पहले उसे बताने के लिए सबसे ज़रूरी बात क्या है?
प्रपोज़ल किसके लिए है और आपको उनसे कौन सा निर्णय चाहिए। आपकी अपनी टीम की योजना के लिए प्रपोज़ल और किसी अधिकारी से बजट मंज़ूरी माँगने वाले प्रपोज़ल को एक ही प्रोजेक्ट के लिए भी अलग-अलग फ्रेमिंग चाहिए।
अगर मेरे पास अभी बजट का आँकड़ा नहीं है तो क्या मुझे Claude को एक देना चाहिए?
नहीं। Claude को अनुमान लगाने देने के बजाय बताएँ कि बजट अभी अंतिम नहीं है। भरोसेमंद लगने वाला बनावटी आँकड़ा असली आँकड़े जानने वाले किसी के देखते ही एक प्रतिबद्धता माना जाता है।
प्रपोज़ल को दायरे से बाहर क्या है इसका स्पष्ट हिस्सा क्यों चाहिए?
इसके बिना, पाठक प्रोजेक्ट में क्या शामिल है इसकी अपनी धारणाओं से खाली जगह भरते हैं, जो अक्सर आपके असली इरादे से व्यापक होती हैं। क्या बाहर है यह स्पष्ट रूप से बताना उस भटकाव को रोकता है।
मैं ऐसा प्रपोज़ल कैसे लिखूँ जो मेरी टीम और किसी अधिकारी दोनों के लिए काम करे?
पहले अपनी टीम के लिए विस्तृत संस्करण लिखें, फिर Claude से इसे कार्यकारी पाठक के लिए समायोजित करने को कहें: बिज़नेस केस और लागत से शुरू करें, तकनीकी विवरण कम करें, और कार्यान्वयन विशेष बातों को परिशिष्ट में ले जाएँ।
क्या मैं शुरुआत से करने के बजाय पहले के प्रपोज़ल या मीटिंग के नोट्स का उपयोग कर सकता हूँ?
हाँ, और आपको करना चाहिए। अपने पास मौजूद संदर्भ सामग्री पेस्ट करें। Claude असली सामग्री को व्यवस्थित और तेज़ करने में, शुरुआत से आपके प्रोजेक्ट के विशेष संदर्भ को बनाने की तुलना में कहीं बेहतर है।
प्रपोज़ल को सफलता के मानक क्यों चाहिए?
सफलता को मापने का कोई बताया गया तरीका न होने पर, प्रपोज़ल को आत्मविश्वास से मंज़ूर करना कठिन है, और बाद में यह जाँचने का कोई सहमत तरीका नहीं है कि प्रोजेक्ट ने वास्तव में वादा किया हुआ दिया या नहीं।
किसी हितधारक को भेजने से पहले मुझे ड्राफ्ट कैसे जाँचना चाहिए?
Claude से इसे हितधारक की तरह पढ़ने और उन सवालों को सूचीबद्ध करने को कहें जो उन्हें मंज़ूर करने से पहले होंगे। फिर भेजने से पहले ड्राफ्ट के हर आँकड़े को अपनी असली सीमाओं के साथ अलग से जाँचें।
अगर मेरे संगठन के पास पहले से मानक प्रपोज़ल टेम्पलेट है तो क्या करें?
ड्राफ्ट को सामान्य संरचना पर वापस जाने देने के बजाय इसे सीधे Claude को दें। जो प्रपोज़ल पहले से आपके संगठन के अपेक्षित प्रारूप से मेल खाता है, वह न मेल खाने वाले प्रपोज़ल से ज़्यादा गंभीरता से पढ़ा जाता है।
मंज़ूर होने वाला प्रपोज़ल असली सीमाओं से शुरू होता है
यह संरचना हर बार फिर से इस्तेमाल की जा सकती है। अनुमान के बजाय ईमानदार आँकड़े देना वह हिस्सा है जिसे सही करना फ़ायदेमंद है।