सीखें कि ऐप स्पेक्स में प्रतिबंध और गैर‑लक्ष्य कैसे लिखें ताकि दोबारा काम जल्दी घटे। फिक्स्ड स्टैक, बजट, डेडलाइन और क्या बदल सकता है—एक सरल फॉर्मेट का उपयोग करें।

दोबारा काम तब होता है जब आप कुछ ऐसा बना लेते हैं जो काम तो करता है, पर प्रोजेक्ट के लिए गलत होता है। टीमें स्क्रीन दुबारा बनाती हैं, लॉजिक फिर से लिखती हैं, डेटा माइग्रेट करती हैं, या किसी फीचर को फिर से बनाती हैं क्योंकि एक महत्वपूर्ण निर्णय बाद में सामने आता है।
यह अक्सर परिचित तरीकों से सामने आता है: किसी फ्लो को फिर से बनाया जाता है क्योंकि गलत यूजर रोल मान लिए गए; स्क्रीन फिर से डिज़ाइन होती हैं क्योंकि मोबाइल सपोर्ट अपेक्षित था पर स्पष्ट नहीं किया गया; डेटा मॉडल बदलता है क्योंकि "हमें ऑडिट हिस्ट्री चाहिए" वर्जन वन के बाद ही कहा जाता है; कोई इंटीग्रेशन बदला जाता है क्योंकि क्लाइंट तीसरे पक्ष की सेवा उपयोग नहीं कर सकता; या अनुपालन/क्षेत्र नियमों की वजह से होस्टिंग बदलनी पड़ती है।
जब प्रतिबंध गायब होते हैं तो बाद में आश्चर्यजनक निर्णय आते हैं। जब एक स्पेक कहता है "CRM बनाएं," तो वह दर्जनों सवाल खुला छोड़ देता है: कौन इसका उपयोग करेगा, किन प्लेटफ़ॉर्म्स की परवाह है, कौन से सुरक्षा नियम लागू होंगे, क्या स्कोप से बाहर रखना है, और बजट व समयरेखा क्या हैं। अगर इन उत्तरों का पता कोड बनने के बाद चलता है, तो प्रोजेक्ट को दो बार भुगतान करना पड़ता है: एक बार बनाने के लिए, और फिर उसे उलटने के लिए।
एक साधारण उदाहरण: एक संस्थापक कहता है "appointments + reminders." पहले हफ्ते ईमेल रिमाइंडर शिप होता है। दूसरे हफ्ते वे कहते हैं कि उन्हें SMS चाहिए, लेकिन SMS उनके देश में अनुमति नहीं है या यह बजट तोड़ देता है। अब रिमाइंडर सिस्टम फिर से डिज़ाइन होता है, स्क्रीन बदलती हैं, और टेस्टिंग फिर से शुरू होती है। यह दोबारा काम खराब कोडिंग की वजह से नहीं हुआ—यह देर से आए प्रतिबंध की वजह से हुआ।
लक्ष्य यह है कि किसी भी कोड को लिखने या जनरेट करने से पहले बैक-एंड-फर्थ कम हो। चाहे आप हाथ से कोड करें या चैट-आधारित बिल्डर उपयोग करें, आउटपुट केवल उन्हीं नियमों का पालन कर सकता है जो आप देते हैं। अगर नियम देर से आते हैं, तो काम हिलता है और आपको उसे फिर से करना पड़ता है।
यह लंबा दस्तावेज़ लिखने के बारे में नहीं है। एक हल्का स्पेक भी जहाँ मायने रखता है, सख्त हो सकता है। शुरुआती चरण में इसे जवाब देना चाहिए:
जब प्रतिबंध और गैर-लक्ष्य पहले लिखे जाते हैं, तो वे गार्डरेल की तरह काम करते हैं। आप कम आश्चर्य पाते हैं, कम रीबिल्ड होते हैं, और पहले दिन से ही स्पष्ट निर्णय मिलते हैं।
प्रतिबंध वे फिक्स निर्णय हैं जिनके साथ आपका प्रोजेक्ट जीना होगा। उन्हें नज़रअंदाज़ करें और आप दो बार काम करेंगे, क्योंकि आपने उस दिशा में बनाया जो शिप नहीं कर सकती।
गैर-लक्ष्य स्पष्ट चुनौतियाँ हैं जिन्हें आप नहीं बना रहे। इन्हें छोड़ दें और स्पेक चुपचाप बढ़ता है क्योंकि लोग "छोटे" एक्स्ट्रा जोड़ते जाते हैं। इसी तरह आप स्क्रीन, फ्लो और डेटा मॉडल फिर से बना सकते हैं।
एक तेज नियम: प्रतिबंध यह सीमित करते हैं कि आप कैसे बनाते हैं; गैर-लक्ष्य यह सीमित करते हैं कि आप क्या बनाते हैं।
एक प्रतिबंध वह अनिवार्य है जो बिना वास्तविक निर्णय (और ट्रेड-ऑफ) बदला नहीं जा सकता।
उदाहरण:
जब कोई प्रतिबंध असली होता है, इसे ऐसे वाक्य में लिखें जिसपर बहस न हो सके। अगर कोई कहे "शायद," तो वह अभी प्रतिबंध नहीं है।
गैर-लक्ष्य एक स्पष्ट "हम यह नहीं कर रहे" है, भले ही वह उपयोगी लगे। यह पहली रिलीज़ की रक्षा करता है।
उदाहरण:
गैर-लक्ष्य नकारात्मकता नहीं हैं। वे महँगी भटकावों को रोकते हैं। उदाहरण के लिए, "v1 में कस्टम रोल नहीं" कई परमिशन एज केसों को बचा सकता है जो डेटाबेस और UI री‑डिज़ाइन करते।
बारीकियों के पन्ने लिखने से पहले एक वाक्य लिखें जो प्रोजेक्ट को दीवार पर पिन कर दे। यह बयानों के सामने आते समय सभी को संरेखित रखता है।
एक अच्छा एक-लाइनर बताता है: यह किसके लिए है, और मुख्य काम क्या करना चाहिए?
उदाहरण एक-लाइनर:
फिर एक छोटा सफलता परिभाषा जोड़ें: 3 से 5 परिणाम जो एक वास्तविक उपयोगकर्ता प्रोजेक्ट पूरा होने पर हासिल कर सके। इन्हें फीचर के रूप में नहीं, यूजर परिणाम के रूप में लिखें।
ट्यूटर बुकिंग उदाहरण के लिए:
यदि आपके पास अभी मीट्रिक नहीं हैं, तो शब्दों में सफलता बताएँ। “तेज़” अस्पष्ट है, पर “फोन पर तेज़ महसूस हो” उपयोगी है। “आसान” अस्पष्ट है, पर “कोई सेटअप कॉल की जरूरत नहीं” स्पष्ट है। आप बाद में संख्याएँ जोड़ सकते हैं।
इस सेक्शन को छोटा रखें। यह आगे आने वाली हर चीज़ का संदर्भ बन जाता है: क्या सत्य होना चाहिए, क्या नहीं होना चाहिए, और क्या बदल सकता है।
रीवर्क अक्सर तब शुरू होता है जब शेड्यूल और निर्णय प्रक्रिया केवल किसी के सिर में रहती है। स्पेक में स्क्रीन और फीचर्स बताने से पहले प्रोजेक्ट प्रतिबंध लिखें।
इन्हें साफ़, परखे जाने योग्य बयानों में लिखें:
एक सरल उदाहरण:
“पहली रिलीज़ 30 मई तक शिप होनी चाहिए। इसमें लॉगिन, एक बेसिक कस्टमर सूची, और एक मासिक रिपोर्ट शामिल है। v1 में कोई इंटीग्रेशन नहीं। बजट $8,000 पर कैप है जिसमें पहले महीने की होस्टिंग शामिल है। समीक्षाएँ वर्कडे में 24 घंटे के भीतर होती हैं। प्रोडक्ट ओनर Sam हैं, जो स्कोप परिवर्तनों को अप्रूव करते हैं।”
फीडबैक की स्पीड को अपना अलग लाइन दें क्योंकि यह नियंत्रित करता है कि आप कितनी सुरक्षित रूप से आगे बढ़ सकते हैं। अगर स्टेकहोल्डर्स केवल सप्ताह में एक बार समीक्षा कर पाते हैं, तो स्पेक को छोटे रिलीज़ और कम एज केस वाले बनाना चाहिए।
एक ऐसी समीक्षा कैडेंस चुनें जो वास्तविकता से मेल खाए: उसी दिन फ़ीडबैक, वर्कडे में 24–48 घंटे, साप्ताहिक बैठक, या (दुर्लभ रूप से) “कोई फीडबैक जरूरी नहीं।”
अगर आप तकनीकी प्रतिबंध जल्दी नहीं लिखते, लोग अनुमान भर देते हैं। इससे टीमें स्क्रीन, माइग्रेशन, या इंटीग्रेशन फिर से करने लगती हैं जब काम शुरू हो चुका होता है।
शुरू में यह बताएं क्या लॉक है और क्या केवल प्राथमिकता है। “Prefer React” और “must be React” अलग हैं—पहला विकल्प बताता है, दूसरा बताता है कि इन‑हाउस कंपोनेंट लाइब्रेरी पर निर्भरता की वजह से बदला नहीं जा सकता। एक निर्णय प्रति वाक्य काफी है।
पूरे ऐप में स्पष्ट रहें: वेब, बैकएंड, डेटाबेस और मोबाइल। अगर कोई हिस्सा लचीला है तो कहें और सीमा जोड़ें (उदा. “v1 में मोबाइल वेब‑ओनली है”)।
एक सरल तरीका:
फिर उन इंटीग्रेशनों की सूची बनाएं जिन्हें आप टाल नहीं सकते। सिस्टम का नाम लिखें (पेमेंट्स, ईमेल, analytics, CRM) और हार्ड लिमिट नोट करें। उदाहरण: “बिलिंग के लिए Stripe उपयोग करना चाहिए,” “ईमेल हमारे मौजूदा प्रोवाइडर के जरिए भेजें,” “Analytics व्यक्तिगत डेटा ट्रैक नहीं करना चाहिए।” अगर ऑथेंटिकेशन फिक्स है (SSO, Google login, पासवर्डलेस), तो उसे भी स्पष्ट करें।
होस्टिंग के चुनाव वास्तुकला बदल देते हैं। लिखें कि ऐप कहाँ चलना चाहिए और क्यों: “Germany में चलना चाहिए,” “डेटा EU में रहना चाहिए,” या “ग्लोबलली चल सकता है।”
यदि आपके पास अनुपालन की ज़रूरतें हैं, तो उन्हें ठोस रखें: रिटेंशन पीरियड, डिलीशन नियम, और ऑडिट जरूरतें।
उदाहरण: “रिकॉर्ड 7 साल तक रखें, सत्यापित अनुरोध पर 30 दिनों के भीतर हटाएँ, रिकॉर्ड देखने वाले का ऑडिट लॉग रखें, और केवल उस देश में डिप्लॉय करें जहाँ मरीज रहते हैं।” ये लाइनें शिपिंग के समय पर होने वाले देर से आश्चर्यों को रोकेंगी।
गैर-लक्ष्य स्पेक के गार्डरेल हैं। वे बताते हैं कि आप क्या नहीं बना रहे, क्या सपोर्ट नहीं कर रहे, या पहली रिलीज़ में क्या परफेक्ट करने की कोशिश नहीं कर रहे। यह आश्चर्य कम करने के सबसे तेज़ तरीकों में से एक है, क्योंकि कई “छोटे” अनुरोध बाद में आते हैं और चुपचाप पूरी योजना बदल देते हैं।
एक अच्छा गैर-लक्ष्य इतना विशिष्ट होना चाहिए कि एक टीममेट एक वाक्य में स्कोप क्रिप पहचान सके। यह समय-सीमाबद्ध भी होना चाहिए। “v1 में नहीं” “हम यह नहीं करेंगे” से अधिक स्पष्ट है।
लोग अक्सर किन फीचर्स को शामिल मान लेते हैं उन्हें यहाँ शुरू करें। एक सरल बुकिंग ऐप के लिए यह कुछ ऐसा दिख सकता है:
ये फीचर्स बुरे नहीं हैं। वे महँगे हैं। इन्हें लिखने से पहली रिलीज़ फोकस्ड रहती है।
छोटी‑छोटी डिटेल आइटम भी लिखें जो बड़े नॉक‑ऑन काम का कारण बनते हैं: रोल्स, परमिशंस, और एज‑केस वर्कफ्लोज़। "कोई कस्टम रोल नहीं। केवल दो रोल: Owner और Member." यह एक लाइन हफ्तों बचा सकती है।
टीम अक्सर उन गैर‑लक्ष्यों को भूल जाती है जो फीचर नहीं हैं। वे बाद में दर्दनाक रीवर्क के रूप में सामने आते हैं।
निर्धारित करें कि आप किसके लिए ऑप्टिमाइज़ नहीं करेंगे। उदाहरण: “हम 1M उपयोगकर्ताओं के लिए ट्यून नहीं करेंगे। v1 में हम 500 साप्ताहिक सक्रिय उपयोगकर्ताओं तक मानते हैं।”
यह भी नोट करें कि आप क्या सपोर्ट नहीं करेंगे, ताकि टेस्टिंग यथार्थवादी रहे: “कोई Internet Explorer समर्थन नहीं,” “कोई टैबलेट‑विशेष लेआउट नहीं,” या “लॉगिन केवल ईमेल और पासवर्ड के जरिए (कोई SSO, कोई मैजिक लिंक नहीं)।”
जब एक स्पेक छोटा निर्णय विकसित करने की गुंजाइश देता है तो वह सुरक्षित लगता है। अगर आप केवल फिक्स्ड चीजें लिखते हैं, तो हर नया विचार बहस बन जाता है। एक छोटा “बदल सकता है” सूची लोगों को बिना पूरी योजना फिर से खोलें उत्पाद सुधारने की जगह देती है।
व्यावहारिक रहें। जो चीज़ें आप वर्किंग वर्ज़न देखकर सीखने की उम्मीद करते हैं, उन्हें कवर करें—ना कि बड़े नए फीचर्स। आम लचीले आइटम: UI टेक्स्ट, छोटे फ्लो ट्वीक, रिपोर्टिंग कॉलम, नामकरण (रोल्स, स्टेटस, केटेगरी), और बुनियादी लेआउट विकल्प।
फिर तय करें कि बदलाव कैसे स्वीकृत होंगे। बिना एक सरल अनुमोदन नियम के, “तेज़ ट्वीक” धीरे‑धीरे स्कोप क्रिप बन जाते हैं।
एक सरल वर्कफ़्लो जो अधिकांश छोटी टीम्स के लिए काम करता है:
मुख्य नियम: लचीले बदलाव फिक्स्ड प्रतिबंधों को तोड़ नहीं सकते। अगर आपका स्टैक React + Go + PostgreSQL है, तो “बदल सकता है” अनुरोध बैकएंड बदलकर “आइए बैकएंड बदलें” नहीं बन सकता। अगर डेडलाइन फिक्स है, तो “बदल सकता है” का मतलब दो सप्ताह ज़रूरत वाला नया मॉड्यूल जोड़ना नहीं हो सकता।
एक ट्रेड‑ऑफ नोट जोड़ें जिस पर सभी सहमत हों। उदाहरण: “अगर हम कस्टम परमिशन के साथ नया यूजर रोल जोड़ते हैं, तो हम उन्नत रिपोर्टिंग को फेज 2 तक टाल देंगे।”
एक अच्छा स्पेक विकल्प सीमित करके शुरू होता है, न कि बढ़ाकर। यह फॉर्मेट जब किसी ने बनाना शुरू नहीं किया होता तो नियम लिखने के लिए मजबूर करता है।
दस्तावेज़ के हेडर में यह रूप रखें:
SPEC v0.1 (date)
Owner:
Reviewers:
1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]
2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]
3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]
4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]
5) Open questions
- Q: [question]
Owner: [name]
Due: [date]
6) Lock rule
- After review: changes require: [what approval looks like]
(ऊपर का कोड‑ब्लॉक उसी रूप में रखें — इसे अनुवादित न करें।)
अधिकांश आश्चर्य बदकिस्मती नहीं होते। वे इसलिए होते हैं क्योंकि स्पेक विभिन्न अर्थों के लिए जगह छोड़ देता है।
एक सामान्य जाल है लक्ष्यों और समाधानों को मिलाना। टीमें स्क्रीन और वर्कफ़्लो पर सीधे कूद जाती हैं बिना यह लिखे कि क्या फिक्स्ड है (डेडलाइन, बजट, टेक स्टैक) और क्या स्कोप से बाहर है। नतीजा एक सुंदर UI योजना है जो प्रतिबंधों के भीतर फिट नहीं बैठती।
एक और जाल अस्पष्ट गैर‑लक्ष्य हैं। “कोई अतिरिक्त फीचर नहीं” कड़क लगता है, पर यह उस समय काम नहीं आता जब कोई “सिर्फ एक रिपोर्ट” या “एक त्वरित एडमिन पैनल” मांगता है। अच्छे गैर‑लक्ष्य विशिष्ट और परखे जाने वाले होते हैं।
छिपा हुआ बजट या "सॉफ्ट" डेडलाइन भी स्कोप बम हैं। अगर असली बजट $5k है और स्पेक $50k जैसा दिखता है, टीम गलत चीज़ बनाएगी। असहज संख्याएँ पन्ने पर रखें।
इंटीग्रेशन्स और डेटा ओनरशिप भी चुपके से आश्चर्य पैदा करती हैं। अगर आप कहते हैं “Stripe से कनेक्ट करें” पर यह परिभाषित नहीं करते कि कौन से इवेंट, कौन से फील्ड, और डेटा किसका है, तो आप बार‑बार वही निर्णय दोहराएंगे।
अंतिम जाल है बिल्ड के दौरान प्रतिबंधों को बदलना बिना ट्रेड‑ऑफ नामित किए। "वेब केवल" से "वेब + मोबाइल" पर स्विच करना, या "Postgres उपयोग करें" से "जो सस्ता हो वही उपयोग करें" करना योजना बदल देता है। आप बदल सकते हैं, पर स्कोप, समयरेखा, या गुणवत्ता अपेक्षाएँ अपडेट करनी होंगी।
अपने स्पेक में एक छोटा नोट जोड़ें जो पाँच बिंदुओं का उत्तर दे:
किसी ने भी निर्माण शुरू करने से पहले आपको “क्या फिक्स है?” प्रश्नों का उत्तर बिना लंबी दस्तावेज़ में खोए देने में सक्षम होना चाहिए।
तेज़ चेक:
अगर इनमें से किसी का उत्तर नहीं है, तो पहली बिल्ड तो होगी, पर दूसरी बिल्ड ही असली होगी।
आगे के कदम जो बुरी निर्णयों में आपको लॉक किए बिना गति बनाए रखें:
यदि आप Koder.ai (koder.ai) उपयोग कर रहे हैं, तो “Planning Mode” और एक स्पष्ट प्रतिबंध तथा गैर‑लक्ष्य सेक्शन प्लेटफ़ॉर्म को ऐसा पहला ड्राफ्ट जनरेट करने में मदद करता है जो आपके स्टैक, होस्टिंग रीजन और स्कोप से मेल खाता है। और अगर प्राथमिकताएँ बदलती हैं, तो स्नैपशॉट और रोलबैक बदलाव टेस्ट करने में मदद करते हैं बिना स्थिर बेसलाइन खोए।
जब ये नियम जल्दी लिखे जाते हैं, तो फीचर चर्चाएँ आसान हो जाती हैं क्योंकि सभी जानते हैं कि क्या फिक्स्ड रहना चाहिए और क्या हिल सकता है।
दोबारा काम तब होता है जब आप कुछ ऐसा बना लेते हैं जो तकनीकी रूप से काम करता है, पर वह प्रोजेक्ट के लिए गलत होता है—किसी देर से आए हुए निर्णय की वजह से नियम बदल जाते हैं। अक्सर स्पेक्स में महत्वपूर्ण प्रतिबंधों का अभाव होता है, इसलिए टीम ने जो मानकर काम किया वह बाद में गलत निकला।
सबसे पहले उन चीज़ों को लिखें जो असल में बदल नहीं सकतीं बिना किसी वास्तविक ट्रेड-ऑफ के—जैसे डेडलाइन, बजट कैप, होस्टिंग का क्षेत्र, ज़रूरी स्टैक और अनुपालन नियम। इसके बाद एक छोटा non-goals सेक्शन जोड़ें ताकि लोग "छोटे" अतिरिक्त मांगों के साथ चुपचाप स्कोप न बढ़ाएँ।
कठोरता के रूप में सोचें: एक प्रतिबंध यह सीमित करता है कि आप कैसे बनाते हैं—उदाहरण: “EU में चलना चाहिए” या “React और PostgreSQL होना चाहिए।” गैर-लक्ष्य यह सीमित करते हैं कि आप क्या बनाएँ—उदाहरण: “v1 में मोबाइल ऐप नहीं” या “लॉन्च पर कस्टम रोल नहीं।”
इसे ऐसी वाक्यरचना में लिखें जिसे परखा जा सके—प्रेफ़रेंस नहीं। अगर कोई आसानी से “शायद” कह सकता है और कोई इसे लागू नहीं कर सकता, तो यह असली प्रतिबंध नहीं है और इसे खुले प्रश्न की तरह रखें।
पहले रिलीज़ के लिए 3–5 यूजर आउटकम चुनें जो बताएँ कि सफलता कैसी दिखती है। इन्हें फीचर के रूप में न लिखें बल्कि यूजर के परिणाम के रूप में लिखें—यह टीम को पहले रिलीज़ के लक्ष्यों पर केंद्रित रखता है और अनावश्यक फीचर्स को न कहने में मदद करता है।
आम छिपे हुए प्रतिबंध जो बाद में सरप्राइज़ देते हैं: मोबाइल सपोर्ट, रोल्स और परमिशन, ऑडिट हिस्ट्री, डेटा रेजिडेंसी, और ऐसे इंटीग्रेशन जिनका क्लाइंट उपयोग नहीं कर सकता। इन्हें पहले सतह पर लाएँ तो स्क्रीन, डेटा मॉडल या प्रदाता बदलने की जरूरत नहीं पड़ेगी।
स्पष्ट और समय-सीमाबद्ध बनें—जैसे “v1 में नहीं” या “हम टैबलेट सपोर्ट नहीं करेंगे।” "कोई अतिरिक्त फीचर नहीं" जैसा अस्पष्ट non-goal स्कोप क्रिप को नहीं रोकेगा क्योंकि वह किसी विशिष्ट अनुरोध को स्पष्ट रूप से ब्लॉक नहीं करता।
यह बताएँ कि बदलाव किस तरह स्वीकृत होंगे, कितनी जल्दी समीक्षा होगी, और किसके पास अंतिम स्वीकृति होगी। धीमी प्रतिक्रिया असल में एक प्रतिबंध है क्योंकि यह आपके इटरेशन की रफ्तार और सहनीय अनिश्चितता को प्रभावित करती है।
उन अनजानों को खुले प्रश्नों में लिखें, एक मालिक और एक ड्यू डेट के साथ, और संबंधित हिस्से का निर्माण तब तक न शुरू करें जब तक उत्तर लॉक न हो। अगर आपको शुरू करना ही है, तो स्पष्ट रूप से वह अनुमान लिखें जिस पर आप काम कर रहे हैं ताकि बाद में भ्रम न हो।
Planning में प्रतिबंध और गैर-लक्ष्य लॉक करके पहला ड्राफ्ट आपके स्टैक, क्षेत्र और स्कोप से मेल खाएगा। यदि प्राथमिकताएँ बदलती हैं तो स्नैपशॉट और रोलबैक जैसी सुविधाएँ बिना स्थिर बेसलाइन खोए परिवर्तन टेस्ट करने में मदद करती हैं, और सोर्स कोड एक्सपोर्ट तब काम आता है जब आपको काम कहीं और ट्रांसफर करना हो।
नोट: Koder.ai और koder.ai का उल्लेख उसी रूप में रखें।