परंपरागत विनिर्देश क्यों विफल होता है
पारंपरिक विनिर्देश में एक संरचनात्मक दोष है: यह वास्तविक कार्य के बजाय कल्पित उपकरण का वर्णन करता है। इसमें स्क्रीन, बटन और आवश्यकताएँ सूचीबद्ध की जाती हैं ("सिस्टम को यह करने की अनुमति देनी चाहिए…") इससे पहले कि एकमात्र महत्वपूर्ण बात तय की जाए: कौन-सा डेटा मौजूद है, वह कैसे जुड़ता है, उसे जीवित कौन रखता है।
हर आईटी परियोजना का जाना-पहचाना नतीजा: सौंपा गया उपकरण दस्तावेज़ के अनुरूप तो होता है पर व्यवहार में अनुपयुक्त — क्योंकि दस्तावेज़ स्वयं एक कल्पना था। और इसे लिखने में हफ़्ते लगे, जिनसे कोई सॉफ़्टवेयर नहीं बना।
एक पृष्ठ की संरचना: चार खंड
एक प्रबंधन एप्लिकेशन पूरी तरह चार खंडों से वर्णित होता है। यही वह संरचना है जिसका उपयोग अनुभवी डिज़ाइनर करते हैं — और ठीक वही जिसे Blueprint Maker आपके विवरण से निकालकर एप्लिकेशन की योजना बनाता है।
- चीज़ें (इकाइयाँ): जिन्हें आप ट्रैक करते हैं — ग्राहक, साइट, वस्तुएँ, कार्य। 3 से 8 नामों की सूची, प्रत्येक अपनी प्रमुख जानकारी (फ़ील्ड) के साथ।
- कड़ियाँ (संबंध): चीज़ें आपस में कैसे जुड़ती हैं — "एक साइट एक ग्राहक की है", "एक कार्य एक उपकरण से संबंधित है"। प्रत्येक कड़ी के लिए एक वाक्य।
- अवस्थाएँ (स्थितियाँ): आपकी वस्तुओं का जीवन-चक्र — "कोटेशन, हस्ताक्षरित, प्रगति पर, पूर्ण, बिल किया गया"। आपके अपने शब्द, वास्तविक क्रम में।
- आँकड़े (संकेतक): जो आप हर सुबह देखना चाहते हैं — बिल की जाने वाली रकम, विलंबित मामले, सीमा से नीचे स्टॉक। तीन से छह संकेतक।
पूर्ण उदाहरण: एक पृष्ठ ही काफ़ी है
"बाड़ लगाने वाली कंपनी, 4 लोग। चीज़ें: ग्राहक (नाम, पता, फ़ोन), साइट (पता, बाड़ का प्रकार, लंबाई, कोटेशन राशि, नियोजित तिथि), कार्य (तिथि, लगाए गए घंटे, टीम), सामग्री (संदर्भ, स्टॉक)। कड़ियाँ: एक साइट एक ग्राहक की है; एक कार्य एक साइट पर होता है; सामग्री प्रति साइट खपत होती है। साइट की अवस्थाएँ: कोटेशन भेजा गया, हस्ताक्षरित, अनुसूचित, प्रगति पर, पूर्ण, बिल किया गया, चुकता। आँकड़े: चालू साइटें, महीने की लगाई गई लंबाई, बिल की जाने वाली राशि, सीमा से नीचे सामग्री।"
इस पृष्ठ में एप्लिकेशन बनाने के लिए आवश्यक सब कुछ है — चाहे डेवलपर द्वारा हो या जनरेटर द्वारा। जो इसमें नहीं है वह भी उतना ही सार्थक है: कोई स्क्रीन विवरण नहीं, कोई तकनीकी चयन नहीं, कोई क्रमांकित आवश्यकता नहीं। स्क्रीनें संरचना से निकलती हैं।
लेखन के तीन जाल
जाल 1 — मौजूदा उपकरण का वर्णन करना: "मुझे मेरी स्प्रेडशीट के A से R तक के कॉलम चाहिए"। स्प्रेडशीट जानकारी का स्रोत है, लक्ष्य नहीं: उसमें से चीज़ें और कड़ियाँ निकालें, न कि उसका ढाँचा।
जाल 2 — ज़रूरत से बड़ा दायरा: नियमानुसार बिलिंग, वेतन, लेखांकन तक को समेटना चाहना। इन विनियमित क्षेत्रों के अपने उपकरण हैं; आपका एप्लिकेशन वहीं रुक जाता है जहाँ वे शुरू होते हैं, और आपकी परिचालन ट्रैकिंग में उत्कृष्ट रहता है।
जाल 3 — विशेष मामले पहले: "और जब कोई ग्राहक आपूर्तिकर्ता भी हो तो?"। पहले वह सामान्य प्रवाह बताएँ जो 90 % दिनों को समेटता है; विशेष मामले बाद में, एक स्वस्थ संरचना पर जोड़े जाते हैं।
पृष्ठ से एप्लिकेशन तक: दो रास्ते
परंपरागत रास्ता: पृष्ठ एक डेवलपर या एजेंसी के लिए ब्रीफ का काम करता है — यह गलतफ़हमी का जोखिम और बिल किए गए विश्लेषण के समय को भारी रूप से घटाता है।
सीधा रास्ता: पृष्ठ ही प्रॉम्प्ट है। Blueprint Maker को सौंपे जाने पर, यह एक संरचित एप्लिकेशन योजना बन जाता है — इकाइयाँ, संबंध, स्थितियाँ, संकेतक — जिसे आप जनरेशन से पहले सत्यापित करते हैं। एप्लिकेशन तैनात होकर, डेमो डेटा के साथ आता है: आपका विनिर्देश असली स्क्रीनों पर परखा जाता है, स्वीकृति बैठकों में नहीं। और यदि बाद में कोई डेवलपर जुड़ता है, तो वह खाली पन्ने के बजाय जनरेट किए गए कोड (ZIP निर्यात, GitHub पुश) से शुरू करता है।
नकल करने के लिए टेम्पलेट
इन चार पंक्तियों को लें और अपने शब्दों से भरें: "मेरा कार्य: … ट्रैक की जाने वाली चीज़ें (अपनी प्रमुख जानकारी के साथ): … उनके बीच की कड़ियाँ: … जिन अवस्थाओं से वे गुज़रती हैं: … हर सुबह देखने वाले आँकड़े: …" दस पंक्तियाँ काफ़ी हैं; Discovery योजना (0 €) से तुरंत परखा जा सकता है कि आपका पृष्ठ कैसा एप्लिकेशन बनाता है।