तीन हफ्ते पहले मैं रात के ढाई बजे एक Notion पेज को देख रहा था। एक क्लाइंट ने एक कस्टम बुकिंग प्लेटफॉर्म के लिए एक ब्रीफ भेजा था। ब्रीफ चार बुलेट पॉइंट्स और एक इमोजी थे। शब्दशः: "Calendly जैसा लेकिन डॉग ग्रूमर्स के लिए 🐶"। बस इतना ही। कोई यूज़र फ्लो नहीं। कोई एज केस नहीं। कोई अंदाज़ा नहीं कि क्या वे SaaS चाहते हैं या वन-टेनेंट इंस्टॉल। और उन्हें शुक्रवार तक स्पेक चाहिए था।
मैं उन पलों से डरता था। अब मैं उनका इंतज़ार करना लगभग पसंद करता हूँ।
क्योंकि मैंने Claude के चारों ओर एक वर्कफ़्लो बनाया है जो इस तरह की अराजकता को एक संरचित, रक्षणीय स्पेक में बदल देता है मात्र कुछ घंटों में। मैंने इसे पिछले डेढ़ साल में Seahawk पर 40-ओड प्रोजेक्ट्स में परिष्कृत किया है, और इसने मुझे कम से कम तीन "लेकिन मैंने सोचा था कि यह X करेगा" रीराइट्स से बचाया है जो वास्तविक पैसे खर्च करते।
मैं आपको इसे ठीक से समझाता हूँ।
---
एक अस्पष्ट ब्रीफ असल में एक अच्छा शुरुआती बिंदु क्यों है
अस्पष्ट ब्रीफ के बारे में यह बात है: वे संकेत रखते हैं। डॉग ग्रूमर Calendly वाली चीज़ आपको इंडस्ट्री, तुलना उत्पाद, और निहित पैमाना (छोटा व्यवसाय, एंटरप्राइज़ नहीं) बताती है। यह कुछ नहीं है।
जो गलती मैं करता था वह तुरंत ब्रीफ को खुद फ़्लेश करना था। मैं मान्यताएँ बनाता था, उन्हें एक दस्तावेज़ में शामिल करता था, और फिर एक क्लाइंट कुछ पर हस्ताक्षर करता था जो 40% मेरे अनुमान था। यह एक आपदा के लिए खतरे का इंतज़ार है।
Claude को वह समस्या नहीं है। यह पूछता है। या बल्कि, जब आप इसे सही तरीके से प्रॉम्प्ट करते हैं, तो यह वे प्रश्न उत्पन्न करता है जो आपको पूछने चाहिए थे।
किसी भी नई प्रोजेक्ट पर मेरा पहला कदम कच्चे ब्रीफ को Claude में पेस्ट करना और इसे सभी मान्यताओं की पहचान करने के लिए कहना है जो आपको चीज़ को बनाने के लिए करनी होंगी। सुविधाएँ नहीं। मान्यताएँ। आउटपुट आमतौर पर 15-25 सवाल होते हैं, और इनमें से लगभग एक तिहाई वे होते हैं जिन्हें मैं नज़रअंदाज़ करता।
डॉग ग्रूमर प्रोजेक्ट के लिए, Claude ने ऐसी चीज़ें सामने लाईं: क्या ग्रूमर के पास कई स्टाफ सदस्य हैं, या यह एक अकेली ऑपरेशन है? क्या बुकिंग को पालतू जानवर के आकार को ध्यान में रखना चाहिए जो नियुक्ति की लंबाई को प्रभावित करता है? क्या बुकिंग के समय कोई जमा या भुगतान कैप्चर है? मैंने पालतू जानवर के आकार की चीज़ के बारे में बिल्कुल नहीं सोचा था। न ही क्लाइंट ने सोचा था, जैसा कि यह निकला। हमने स्प्रिंट तीन के बजाय खोज कॉल में इसे पकड़ा।
---
प्रॉम्प्ट संरचना जो वास्तव में काम करती है
मैंने स्पेक वर्क के लिए प्रॉम्प्ट करने के कई अलग-अलग तरीके आजमाए हैं। "बुकिंग ऐप डिज़ाइन करने में मुझे मदद करें" जैसी सामान्य चीज़ें आपको सामान्य कचरा देती हैं। जो काम करता है वह एक संरचित इनपुट है जो Claude को अपने आउटपुट को सीमित करने के लिए पर्याप्त संदर्भ देता है।
यह वह मोटा टेम्पलेट है जो मैं अब उपयोग करता हूँ:
- भूमिका परिभाषा। मैं Claude को बताता हूँ कि यह एक वरिष्ठ उत्पाद प्रबंधक के रूप में काम कर रहा है जिसने B2B SaaS शिप किया है और स्कोप क्रीप से एलर्जी है।
- कच्चा ब्रीफ। इसे शब्दशः पेस्ट करें, भले ही यह कितना भी रूखा हो।
- बाधाएँ। बजट रेंज, टेक स्टैक अगर जाना जाता है (हम अधिकांश क्लाइंट साइटों के लिए WordPress/WooCommerce को डिफ़ॉल्ट करते हैं, कुछ भी भारी के लिए कस्टम Laravel), समयरेखा, टीम का आकार।
- आउटपुट प्रारूप। मैं विशिष्ट अनुभागों के साथ एक संरचित दस्तावेज़ के लिए कहता हूँ: समस्या कथन, यूज़र पर्सोना, मुख्य यूज़र फ्लो, सुविधा सूची (MVP बनाम पोस्ट-लॉन्च), खुले प्रश्न, और जोखिम।
बाधाएँ वाला हिस्सा वह है जो ज़्यादातर लोग छोड़ते हैं। यह अत्यंत महत्वपूर्ण है। "बजट: £8,000, समयरेखा: 8 सप्ताह, दो डेवलपर्स और एक अंशकालिक डिज़ाइनर" एक ही ब्रीफ को कोई बाधाएँ न होने के साथ एक बहुत अलग स्पेक देता है। उनके बिना, Claude खुशी से एक उत्पाद निर्दिष्ट करेगा जिसे बनाने में छह महीने और £60k लगेंगे। जो पढ़ने के लिए मज़ेदार है और शिप करने के लिए बेकार है।
---
प्रतिकूल प्रॉम्प्टिंग के साथ स्पेक पर पुनरावृत्ति
पहला ड्राफ्ट स्पेक निकालना आसान हिस्सा है। असली वैल्यू इटरेशन में है।
Claude जब शुरुआती डॉक्यूमेंट तैयार कर देता है, तो मैं जो कुछ "adversarial pass" कहता हूँ वह करता हूँ। मैं सीधे इससे पूछता हूँ: "अब इस spec के खिलाफ तर्क दो। Scope creep कहाँ होने की सबसे ज्यादा संभावना है? किन चीजों को हमने कम आंका है? इस लिस्ट का कौन सा फीचर 12 महीने में सबसे ज्यादा technical debt पैदा करेगा?"
Seahawk के पास 2022 में एक fintech क्लायंट था जो micro-investment portfolios ट्रैक करने के लिए एक डैशबोर्ड चाहता था। पहला spec अच्छा दिख रहा था। Adversarial pass ने flagged किया कि MVP में "real-time price updates" feature बहुत सारा काम कर रहा था और शायद WebSocket architecture की जरूरत पड़ेगी जिसके लिए हमारे पास न तो timeline में जगह थी न बजट में। हमने इसे पकड़ा। हमने इसे MVP के लिए हर 60 सेकंड में polling के लिए scope किया, real-time को phase two फीचर के तौर पर रखा। क्लायंट को ठीक था। क्या हमने इसे adversarial pass के बिना पकड़ा होता? शायद। लेकिन संभवतः तब तक नहीं जब तक कोई तीन हफ्ते build में न चला गया होता।
Adversarial step प्रक्रिया में शायद 20 मिनट और जोड़ता है। यह हर बार काबिल है।
---
Spec को User Stories में बदलना
एक बार जब spec इतना ठोस हो जाता है कि मैं इससे शर्माऊँ नहीं, तो मैं user story generation में चला जाता हूँ। यह वह जगह है जहाँ Claude सच में चमकता है, क्योंकि अच्छी user stories लिखना थकाऊ है और इसे खराब तरीके से करना आसान है।
मैं spec को Claude को वापस देता हूँ और standard format में user stories माँगता हूँ: "एक [role] के रूप में, मैं [action] चाहता हूँ ताकि [outcome] हो।" मैं इससे यह भी माँगता हूँ कि वह किसी भी non-trivial चीज़ के लिए acceptance criteria को flag करे, क्योंकि "एक groomer के रूप में मैं holiday time को block आउट करना चाहता हूँ" के surprising सारे edge cases हैं (recurring blocks? कौन सा timezone? क्या यह existing bookings वाले क्लायंट्स को notify करता है?)।
कुछ चीजें मैं पर जोर देता हूँ:
- Stories को एक specific persona के लिए लिखा जाना चाहिए, generic "user" के लिए नहीं
- हर story को एक rough complexity estimate मिलता है (S/M/L, इस स्टेज पर इससे ज्यादा granular कुछ नहीं)
- "L" bucket में कुछ भी Jira में जाने से पहले further decomposition के लिए flag किया जाता है
यह आखिरी बिंदु मायने रखता है। Sprint planning meeting में एक L story basically एक grenade है। Claude को इन्हें जल्दी surface करवाना मतलब है कि हमारे पास कोई बातचीत होती है इससे पहले कि कोई build करना शुरू करे।
---
मैं Claude के साथ कहाँ Line खींचता हूँ
मैं इस बारे में सच्चा होना चाहता हूँ, क्योंकि मैं बहुत सारे breathless takes देखता हूँ कि AI अब सब कुछ कर रहा है।
Claude decisions लेने में अच्छा नहीं है। Options और trade-offs को lay out करना excellent है, लेकिन असली decision कि custom notification system build करना है या Novu use करना है (जिसे हमने तीन projects पर use किया है और recommend करेंगे) को अभी भी किसी ऐसे की जरूरत है जो project, क्लायंट, और team की capabilities को जानता है।
मुझे यह specific library versions या niche API behaviours सहित कुछ भी करने में unreliable भी मिला है। Broad architecture discussions के लिए ठीक है। "क्या WPGraphQL का यह specific version इस specific query pattern को load के तहत handle करेगा," इसके लिए मैं test करना बेहतर मानता हूँ trust करने से।
और honestly? Prompting खुद skill लेती है। मेरी टीम के एक junior ने एक ही workflow use करने की कोशिश की और mediocre specs वापस पाए, क्योंकि constraint और role framing काफी tight नहीं था। Tool whoever's using it को amplify करता है। यह आलोचना नहीं है, बस realistic होने लायक है।
---
Output को एक Living Document में Organize करना
वह spec जो Claude produces करता है वह final artefact नहीं है। यह input है।
मेरी actual deliverable एक क्लायंट को Notion document होती है जो Claude output से build होती है लेकिन एक ऐसे format में reorganize होती है जो sign-off के लिए sense बनाता है। आमतौर पर:
- Executive summary (3-4 sentences, कोई jargon नहीं)
- Scope (क्या अंदर है, क्या explicitly बाहर है)
- User personas (2-3 max, इससे ज्यादा इस स्टेज पर noise है)
- कोर फ़्लो (गद्य नहीं, क्रमांकित चरणों के रूप में लिखा गया)
- फीचर टेबल (कॉलम: फीचर, MVP या फेज 2, मोटा प्रयास, मालिक)
- खुले सवाल (कुछ भी जो किसी निर्णय को रोकता है, उत्तरदायी व्यक्ति का नाम के साथ)
- जोखिम और जोखिम कम करने के तरीके
वह खुले सवाल वाला सेक्शन कुछ ऐसा है जो मैंने 2020 के एक प्रोजेक्ट के बाद शुरू किया था जब सब कुछ गलत हो गया था क्योंकि हर कोई यह मान रहे थे कि किसी और ने डेटा रिटेंशन पॉलिसी का पता लगा दिया है। हर खुले सवाल के साथ एक व्यक्ति का नाम रखने से यह अनिश्चित काल तक बस वहीं नहीं बैठता।
Notion डॉक को क्लाइंट के साथ शेयर किया जाता है, वे सीधे उसमें कमेंट करते हैं, और हम 45 मिनट की कॉल करते हैं इसे समझाने के लिए। डेवलपर तक कुछ भी नहीं जाता जब तक हर खुले सवाल का जवाब न मिल जाए।
---
The Actual Time Savings, Honestly Stated
इस वर्कफ़्लो से पहले, माध्यम जटिलता वाले प्रोजेक्ट के लिए एक स्पेक (मान लीजिए, एक मेंबरशिप पोर्टल या कस्टम ई-कॉमर्स बिल्ड) को मुझे डेढ़ दिन लगते थे। लिखना, दोबारा सोचना, फिर से लिखना। किसी सहयोगी को ड्राफ्ट भेजना, कमेंट पाना, उन्हें शामिल करना।
अब Claude की सहायता वाले ड्राफ्ट के लिए लगभग दो से तीन घंटे हैं, फिर शायद एक घंटा और मानवीय संपादन और क्लाइंट के लिए पॉलिश करने का। कुल मिलाकर तीन से चार घंटे कहिए।
यह एक साल भर में नगण्य बचत नहीं है। Seahawk में हम शायद महीने में दो या तीन प्रोजेक्ट पर स्पेक डिलीवर कर रहे हैं। रूढ़िवादी अनुमान के अनुसार भी, यह 50-70 घंटे प्रति साल है जो मैं शुरुआती स्पेक स्क्रैच से लिखने में बिता नहीं रहा हूँ।
लेकिन बड़ी जीत, ईमानदारी से कहूँ तो, गुणवत्ता है। विरोधी पास विशेष रूप से उन चीजों को पकड़ता है जिन्हें मैं छोड़ देता। शुरुआत में मान्यता सतह पर लाना का मतलब है कि डिस्कवरी कॉल अधिक उत्पादक होते हैं क्योंकि हम वास्तविक निर्णयों पर चर्चा कर रहे होते हैं, न कि मैं अंतराल भरने के लिए संघर्ष कर रहा होता हूँ जो मैंने देखे भी नहीं थे।
---
FAQ
क्या यह वर्कफ़्लो आंतरिक टूल्स के लिए भी क्लाइंट प्रोजेक्ट जितना अच्छी तरह काम करता है?
हाँ, और कभी-कभी यह आंतरिक चीजों के लिए बेहतर काम करता है क्योंकि आप यूजर को किसी भी क्लाइंट ब्रीफ की तुलना में बेहतर जानते हैं। मैंने अनिवार्य रूप से एक जैसी प्रक्रिया का उपयोग तब किया था जब हम पिछले साल Seahawk के अपने आंतरिक टाइम-ट्रैकिंग टूल को स्पेक कर रहे थे। कॉन्सट्रेंट इनपुट आसान था क्योंकि मैं बजट जानता था (बाहरी खर्च में £0, एक डेवलपर, तीन सप्ताह) और पर्सोना शाब्दिक रूप से कार्यालय में लोग थे।
क्या एक गैर-तकनीकी संस्थापक बिना डेवलपर के इसका उपयोग कर सकता है?
हद तक। मान्यता-सतह पर लाना और यूजर स्टोरी के चरण तकनीकी ज्ञान के बिना ठीक काम करते हैं। जहाँ यह मुश्किल हो जाता है वह विरोधी पास और प्रयास अनुमान है। आपको यह जानने के लिए कुछ अनुभव की जरूरत है कि Claude जटिलता को कम आंक रहा है या नहीं। यदि आप गैर-तकनीकी हैं, तो उस चरण को किसी के साथ करें जिसने सॉफ्टवेयर शिप किया है, भले ही यह सिर्फ एक घंटे की कॉल हो।
Claude का उपयोग करते समय आप गोपनीय क्लाइंट जानकारी को कैसे संभालते हैं?
मैं प्रॉम्प्ट में जाने से पहले कुछ भी संवेदनशील को अनाम कर देता हूँ। क्लाइंट के नाम "[Client]" बन जाते हैं, कोई भी व्यक्तिगत रूप से पहचाने जाने योग्य डेटा को हटा दिया जाता है। मैं भी Claude का उपयोग API के माध्यम से करता हूँ कुछ भी वास्तव में संवेदनशील के लिए, जहाँ Anthropic की एंटरप्राइज डेटा हैंडलिंग शर्तें लागू होती हैं, उपभोक्ता उत्पाद के बजाय। अपने संदर्भ के लिए क्या उपयुक्त है यह तय करने से पहले Anthropic की उपयोग नीति पढ़ना लायक है।
क्या स्पेक हमेशा डेवलपर्स के साथ पहली बातचीत को सहन करता है?
नहीं। और यह नहीं करना चाहिए। स्पेक सही बातचीत जल्दी करने के लिए एक जबरदस्ती वाला तंत्र है, सोच को जमाने वाला एक अनुबंध नहीं। जो मैं क्लाइंट को बताता हूँ वह यह है: स्पेक आज हम जो बना रहे हैं उसकी साझी समझ है। यह बदलेगा। जो यह करता है वह है उन परिवर्तनों को दृश्यमान और जानबूझकर बनाना, आकस्मिक के बजाय।
---
स्पेक एक दस्तावेज नहीं है। यह एक तर्क है। आप तर्क दे रहे हैं कि आप समस्या को इतनी अच्छी तरह समझते हैं कि कुछ ऐसा बना सकें जो बनाने लायक है। Claude वह तर्क आपके लिए नहीं बनाता। लेकिन यह एक असाधारण उपयोगी स्पैरिंग पार्टनर है जबकि आप यह समझते हैं कि आप वास्तव में क्या कहना चाहते हैं।
यह किसी के दो घंटों की कीमत है।