किसी डेवलपर को नियुक्त करने से पहले किसी सॉफ़्टवेयर प्रोजेक्ट का दायरा कैसे बढ़ाया जाए

सॉफ़्टवेयर प्रोजेक्ट बजट से अधिक होने का #1 कारण:विकास शुरू होने से पहले दायरा परिभाषित नहीं किया गया था।बुरे डेवलपर्स नहीं. ग़लत तकनीक नहीं. अस्पष्ट दायरा. 2024 पीएमआई अध्ययन में पाया गया कि 52% परियोजनाओं में गुंजाइश कम हो गई है, और वे परियोजनाएं औसतन 27% बजट से अधिक चलती हैं।

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

यहां वह ढांचा है जिसका उपयोग हम Savi में ग्राहकों के साथ प्रोजेक्ट स्कोपिंग सत्र चलाते समय करते हैं। इसे आप खुद 2-4 घंटे में कर सकते हैं.

एक स्कोप दस्तावेज़ में क्या शामिल होना चाहिए

एक अच्छे सॉफ्टवेयर प्रोजेक्ट का दायरा पांच क्षेत्रों को कवर करता है। उनमें से किसी एक को भी छोड़ दें, और आपको ऐसे उद्धरण मिलेंगे जो वास्तविकता से मेल नहीं खाते।

1. उपयोगकर्ता भूमिकाएँ.सिस्टम का उपयोग कौन करता है? एक भूमिका वाले ग्राहक-सामना वाले ऐप की लागत पांच भूमिकाओं (ग्राहक, विक्रेता, व्यवस्थापक, सहायता एजेंट, सुपर-एडमिन) वाले प्लेटफ़ॉर्म से बहुत कम है। प्रत्येक भूमिका को अपने स्वयं के विचारों, अनुमतियों और डेटा एक्सेस नियमों की आवश्यकता होती है। प्रत्येक भूमिका की सूची बनाएं, यहां तक ​​कि वे भूमिकाएं भी जिन्हें आप स्पष्ट मानते हैं। "व्यवस्थापक" स्पष्ट नहीं है; इसका मतलब 10 अलग-अलग अनुमति स्तर हो सकते हैं।

2. प्रति भूमिका सुविधाएँ।प्रत्येक उपयोगकर्ता भूमिका के लिए, उन विशिष्ट कार्रवाइयों की सूची बनाएं जो वे कर सकते हैं। "व्यवस्थापक उपयोगकर्ताओं को प्रबंधित कर सकता है" बहुत अस्पष्ट है। "व्यवस्थापक सभी उपयोगकर्ताओं को देख सकता है, खातों को निष्क्रिय कर सकता है, पासवर्ड रीसेट कर सकता है, और उपयोगकर्ता डेटा को सीएसवी के रूप में निर्यात कर सकता है" अनुमान लगाने के लिए पर्याप्त विशिष्ट है।

3. एकीकरण.आपका उत्पाद जिस भी बाहरी सिस्टम को छूता है: भुगतान गेटवे, ईमेल प्रदाता, एसएमएस एपीआई, एनालिटिक्स टूल, सीआरएम सिस्टम, अकाउंटिंग सॉफ्टवेयर। प्रत्येक एकीकरण एपीआई गुणवत्ता और जटिलता के आधार पर एक परियोजना में $1,000-$4,000 जोड़ता है।

4. डेटा मॉडल स्केच.आपको डेटाबेस स्कीमा की आवश्यकता नहीं है. आपको अपने मूल डेटा ऑब्जेक्ट और वे कैसे संबंधित हैं, इसका सरल भाषा में विवरण चाहिए। "एक ग्राहक के पास कई ऑर्डर होते हैं। एक ऑर्डर में कई लाइन आइटम होते हैं। प्रत्येक लाइन आइटम एक उत्पाद का संदर्भ देता है। एक उत्पाद एक श्रेणी से संबंधित होता है।" इसमें 20 मिनट लगते हैं और प्रोजेक्ट के बीच में 20 घंटे की ग़लतफहमियों से बचा जा सकता है।

5. सफलता के मापदंड.आप कैसे जानते हैं कि परियोजना पूरी हो गई है? नहीं "यह पूर्ण लगता है।" मापने योग्य परिणाम. "एक ग्राहक एक खाता बना सकता है, उत्पाद ब्राउज़ कर सकता है, कार्ट में आइटम जोड़ सकता है, स्ट्राइप के साथ चेक आउट कर सकता है और भुगतान के 3 सेकंड के भीतर ऑर्डर पुष्टिकरण ईमेल प्राप्त कर सकता है।" वह परीक्षण योग्य है. वह एक दायरा सीमा है.

एक स्कोप दस्तावेज़ में क्या शामिल नहीं होना चाहिए?

संस्थापक अक्सर गलत क्षेत्रों में अति-निर्दिष्ट करते हैं। एक स्कोप दस्तावेज़ कोई तकनीकी विशिष्टता नहीं है। इन्हें छोड़ें:

तकनीकी स्टैक निर्णय.यह निर्दिष्ट न करें कि "Redis कैशिंग के साथ PostgreSQL का उपयोग करें और AWS पर परिनियोजन करें।" वह डेवलपर का काम है। आप परिभाषित करते हैं कि सिस्टम क्या करता है; वे निर्णय लेते हैं कि यह यह कैसे करता है। यदि आप इंजीनियरिंग संदर्भ के बिना प्रौद्योगिकी विकल्पों को निर्देशित करते हैं, तो आप या तो अपने विकल्पों को सीमित कर देंगे या उस स्टैक के लिए भुगतान करेंगे जो समस्या में फिट नहीं बैठता है।

डेटाबेस स्कीमा.आपका डेटा मॉडल स्केच सरल भाषा में संबंधों का वर्णन करता है। डेवलपर उसे तालिकाओं, स्तंभों और अनुक्रमणिकाओं में अनुवादित करता है। एक इंजीनियर को काम पर रखने से पहले एक स्कीमा लिखना एक आर्किटेक्ट को काम पर रखने से पहले ब्लूप्रिंट बनाने जैसा है।

पिक्सेल-परिपूर्ण यूआई मॉकअप।वायरफ्रेम और रफ लेआउट उपयोगी होते हैं। स्कोपिंग से पहले पिक्सेल-परफेक्ट फिग्मा फ़ाइलें समयपूर्व हैं। एक बार जब आप उपयोगकर्ता प्रवाह को क्रियान्वित होते देखेंगे तो आप अपनी 40% स्क्रीन को फिर से डिज़ाइन कर देंगे। स्कोपिंग के बाद विस्तृत डिज़ाइन में निवेश करें, पहले नहीं।

उपयोगकर्ता भूमिकाएँ और प्रवाह कैसे परिभाषित करें

अपने सॉफ़्टवेयर आवश्यकताओं दस्तावेज़ में प्रत्येक सुविधा के लिए इस टेम्पलेट का उपयोग करें:

उदाहरण:

• के तौर परग्राहक, मैं उत्पादों को श्रेणी और मूल्य सीमा के आधार पर फ़िल्टर कर सकता हूं ताकि मुझे 10 सेकंड से कम समय में वह मिल जाए जिसकी मुझे आवश्यकता है।
• एक के रूप मेंव्यवस्थापक, मैं पिछले 30 दिनों के सभी ऑर्डर को सीएसवी के रूप में निर्यात कर सकता हूं ताकि मैं अपने अकाउंटिंग सॉफ्टवेयर के साथ सामंजस्य स्थापित कर सकूं।
• के तौर परविक्रेता, मैं अपने स्वयं के उत्पाद की कीमतें और इन्वेंट्री गणना निर्धारित कर सकता हूं ताकि मैं समर्थन से संपर्क किए बिना अपने स्टोरफ्रंट को नियंत्रित कर सकूं।

यह प्रारूप विशिष्टता को बल देता है. "एक व्यवस्थापक के रूप में, मैं उत्पादों का प्रबंधन कर सकता हूं" किसी डेवलपर को कुछ नहीं बताता। "एक व्यवस्थापक के रूप में, मैं छवियों, विवरणों, कीमतों और इन्वेंट्री गणना के साथ उत्पाद बना सकता हूं, संपादित कर सकता हूं, संग्रहीत कर सकता हूं और हटा सकता हूं" उन्हें बताता है कि वास्तव में क्या बनाना है।

इनमें से 10-30 कथन लिखिए। वह आपकी फीचर सूची है. कोटेशन मांगते समय आप डेवलपर्स को यही भेजते हैं।

सुविधाओं को प्राथमिकता कैसे दें: MoSCoW विधि

आप सब कुछ एक ही बार में नहीं बनाएंगे. आपको नहीं करना चाहिए. MoSCoW विधि आपकी फीचर सूची को चार बकेट में विभाजित करती है:

होना आवश्यक है:इनके बिना उत्पाद काम नहीं करता. यदि आप एक ईकॉमर्स स्टोर बना रहे हैं, तो चेकआउट अनिवार्य है। उपयोगकर्ता प्रमाणीकरण आवश्यक है. उत्पाद सूचीकरण आवश्यक है।

होना चाहिए:महत्वपूर्ण है लेकिन उत्पाद उनके बिना लॉन्च हो सकता है। ऑर्डर ट्रैकिंग, ईमेल सूचनाएं, इन्वेंट्री अलर्ट। वे अनुभव को बेहतर बनाते हैं, लेकिन ग्राहक अभी भी उनके बिना चीजें खरीद सकते हैं।

हो सकता था:यदि समय और बजट अनुमति दे तो इसे पाकर अच्छा लगा। इच्छा सूचियाँ, उत्पाद समीक्षाएँ, रेफरल कार्यक्रम। ये सुविधाएँ जुड़ाव बढ़ाती हैं लेकिन मुख्य कार्यक्षमता को प्रभावित नहीं करती हैं।

नहीं होगा (यह दौर):आपने जिन सुविधाओं को बाद के चरण के लिए स्थगित करने का निर्णय लिया है। मोबाइल ऐप, बहुभाषी समर्थन, बाज़ार मॉडल। इन्हें लिखना महत्वपूर्ण है; यह सीमा को स्पष्ट बनाकर स्कोप रेंगने से रोकता है।

एक अच्छी तरह से दायरे वाले एमवीपी में केवल जरूरी चीजें और 1-2 उच्च प्रभाव वाली चीजें शामिल होती हैं। बाकी सब कुछ चरण 2 में चला जाता है। यह दृष्टिकोण आपके पहले निर्माण को बजट के अंतर्गत रखता है और आपको तेजी से बाजार में ले जाता है, ताकि आप अधिक निर्माण करने से पहले वास्तविक उपयोगकर्ता प्रतिक्रिया एकत्र कर सकें।

एकीकरण को कैसे संभालें

एकीकरण सॉफ्टवेयर प्रोजेक्ट प्लानिंग का सबसे आम तौर पर कम दायरे वाला हिस्सा है। आपका उत्पाद जिस भी बाहरी सिस्टम से जुड़ता है वह जटिलता, लागत और संभावित विफलता बिंदु जोड़ता है।

प्रत्येक एकीकरण के लिए, तीन विशिष्ट दस्तावेज तैयार करें:

• कौन सी प्रणाली:स्ट्राइप, सेंडग्रिड, ट्विलियो, गूगल एनालिटिक्स, क्विकबुक आदि।
• कौन सा डेटा कहां प्रवाहित होता है:"ग्राहक भुगतान की जानकारी स्ट्राइप के पास जाती है। स्ट्राइप भुगतान की पुष्टि के लिए एक वेबहुक वापस भेजता है। हमारा सिस्टम ऑर्डर की स्थिति को अपडेट करता है और सेंडग्रिड के माध्यम से एक पुष्टिकरण ईमेल ट्रिगर करता है।"
• जब यह विफल हो जाता है तो क्या होता है:"यदि स्ट्राइप डाउन है, तो ग्राहक को एक त्रुटि संदेश दिखाएं और उनकी कार्ट सहेजें। 5 मिनट में भुगतान का पुनः प्रयास करें।"

अधिकांश संस्थापक पहले दो को सूचीबद्ध करते हैं और तीसरे को छोड़ देते हैं। एकीकरण कार्य में 20-30% त्रुटि प्रबंधन के कारण होती है। यदि आप इसे स्कोपिंग में परिभाषित नहीं करते हैं, तो डेवलपर या तो इसे छोड़ देता है (खराब) या अनुमान लगाता है कि आप क्या चाहते हैं (खराब भी)।

सफलता के मानदंड निर्धारित करना

"प्रोजेक्ट तब पूरा होता है जब वह काम करता है" सफलता का मानदंड नहीं है। यह अंतहीन संशोधनों का एक नुस्खा है। विकास शुरू होने से पहले मापने योग्य परिणामों को परिभाषित करें:

• एक नया उपयोगकर्ता साइन अप कर सकता है और अपनी पहली खरीदारी 3 मिनट के अंदर पूरी कर सकता है।
• एडमिन डैशबोर्ड पिछले 90 दिनों के सभी ऑर्डर को 2 सेकंड के अंदर लोड करता है।
• सिस्टम 1 सेकंड से अधिक प्रतिक्रिया समय के बिना 500 समवर्ती उपयोगकर्ताओं को संभालता है।
• सभी भुगतान लेनदेन टाइमस्टैम्प के साथ लॉग किए जाते हैं और ऑडिटिंग के लिए निर्यात किए जा सकते हैं।
• प्रदर्शन और पहुंच के लिए ऐप को Google लाइटहाउस पर 90+ स्कोर मिलता है।

ये मानदंड आपको और आपके डेवलपर दोनों को एक स्पष्ट समाप्ति रेखा प्रदान करते हैं। जब इस सूची का प्रत्येक आइटम पास हो जाता है, तो प्रोजेक्ट पूरा हो जाता है। कोई बटन "सही लगता है" के बारे में कोई व्यक्तिपरक बहस नहीं। मापने योग्य परिणाम, भावनाएँ नहीं।

सामान्य स्कोपिंग गलतियाँ

सैकड़ों प्रोजेक्ट स्कोपिंग सत्र चलाने के बाद, ये ऐसे पैटर्न हैं जो लगातार बजट ओवररन का कारण बनते हैं:

चेकलिस्ट के बजाय उपन्यास लिखना।40 पेज का आवश्यकता दस्तावेज़ किसी प्रोजेक्ट को स्पष्ट नहीं बनाता है। इससे अनुमान लगाना कठिन हो जाता है। डेवलपर्स लंबे दस्तावेज़ों को स्किम करते हैं। वे चेकलिस्ट पढ़ते हैं। अपने स्कोप दस्तावेज़ को बुलेट बिंदुओं, उपयोगकर्ता कहानियों और प्राथमिकता वाली फीचर सूची के साथ 5 पृष्ठों के अंतर्गत रखें।

प्रवाह से पहले यूआई निर्दिष्ट करना।"मुझे एक साइडबार और तीन चार्ट वाला डैशबोर्ड चाहिए" एक स्क्रीन का वर्णन करता है, किसी फ़ंक्शन का नहीं। उपयोगकर्ता प्रवाह से प्रारंभ करें: व्यवस्थापक को क्या पूरा करने की आवश्यकता है? फिर तय करें कि कौन सा यूआई उन प्रवाहों का समर्थन करता है। स्क्रीन प्रवाह से आती हैं, दूसरे तरीके से नहीं।

व्यवस्थापक और बैकएंड आवश्यकताओं को भूल जाना।संस्थापक ग्राहक-सामना के अनुभव के प्रति आसक्त रहते हैं और भूल जाते हैं कि किसी को इसे प्रबंधित करने की आवश्यकता है। सामग्री प्रबंधन, उपयोगकर्ता मॉडरेशन, ऑर्डर पूर्ति, एनालिटिक्स डैशबोर्ड, समर्थन उपकरण। व्यवस्थापक पैनल अक्सर कुल विकास समय का 30-40% लेता है। यदि आपका दायरा दस्तावेज़ केवल ग्राहक अनुभव का वर्णन करता है, तो आपका उद्धरण 30-40% बहुत कम होगा।

त्रुटि स्थितियों को परिभाषित नहीं किया जा रहा है.जब भुगतान विफल हो जाता है तो क्या होता है? जब कोई उपयोगकर्ता अमान्य ईमेल दर्ज करता है? फ़ाइल अपलोड 10एमबी से अधिक होने पर? जब एपीआई 500 त्रुटि लौटाता है? प्रत्येक त्रुटि स्थिति को एक परिभाषित व्यवहार की आवश्यकता होती है। इन्हें अपरिभाषित छोड़ने से समय की बचत नहीं होती; यह ऐसे बग बनाता है जिन्हें लॉन्च के बाद ठीक करने में अधिक लागत आती है।

एक सरल स्कोपिंग टेम्पलेट

अपने अगले प्रोजेक्ट के लिए सॉफ़्टवेयर आवश्यकताएँ लिखते समय इस चेकलिस्ट को अपने शुरुआती बिंदु के रूप में उपयोग करें:

स्कोपिंग के बाद क्या होता है

एक बार जब आपका स्कोप दस्तावेज़ पूरा हो जाए, तो आप उद्धरण प्राप्त करने के लिए तैयार हैं। एक ही दस्तावेज़ 2-4 एजेंसियों या डेवलपर्स को भेजें। एक स्पष्ट दायरा आपको सेब-से-सेब के आधार पर प्रस्तावों की तुलना करने देता है। यदि एक एजेंसी समान दायरे के लिए $8,000 और दूसरी एजेंसी $25,000 उद्धृत करती है, तो आप क्यों के बारे में विशिष्ट प्रश्न पूछ सकते हैं।

यहाँ विशिष्ट अनुक्रम है:

1. अपना दायरा दस्तावेज़ भेजेंशॉर्टलिस्ट की गई एजेंसियों या फ्रीलांसरों को। यदि आपके पास अपनी समयरेखा और बजट सीमा है तो उसे शामिल करें। पारदर्शिता प्रक्रिया को गति देती है।

2. प्रस्तावों की समीक्षा करें.तीन आयामों पर तुलना करें: कीमत, समयरेखा, और काम कौन करता है। 4 सप्ताह में जहाज़ भेजने वाले एक वरिष्ठ इंजीनियर की 10,000 डॉलर की बोली, 12 सप्ताहों में जहाज़ भेजने वाली एक जूनियर टीम की 7,000 डॉलर की बोली से अधिक है। हमारी मार्गदर्शिका में मूल्यांकन करने वाली एजेंसियों के बारे में और पढ़ेंएक विकास एजेंसी को कैसे नियुक्त करें.

3. धारणाओं को स्पष्ट करें.प्रत्येक प्रस्ताव में धारणाएँ होती हैं। "भुगतान के लिए स्ट्राइप मानता है।" "डिज़ाइन के लिए 3 पुनरीक्षण दौर तक का अनुमान है।" "मान लिया गया है कि ग्राहक उत्पाद फोटोग्राफी प्रदान करता है।" हस्ताक्षर करने से पहले इन्हें सामने रखें। अघोषित धारणाएँ बाद में विवाद बन जाती हैं।

4. विकास प्रारंभ करें.स्पष्ट दायरे और सहमत प्रस्ताव के साथ, विकास ठोस आधार पर शुरू होता है। परिवर्तन अभी भी होंगे, लेकिन वे छोटे समायोजन होंगे, न कि मौलिक दिशा परिवर्तन जो बजट को बिगाड़ देंगे।

समझना चाहते हैं कि परियोजना का दायरा मूल्य निर्धारण को कैसे प्रभावित करता है? हमारा विवरण पढ़ेंकस्टम सॉफ़्टवेयर विकास लागत. यदि आप संपूर्ण उत्पाद आवश्यकताओं का दस्तावेज़ लिखने के लिए तैयार हैं, तो हमारी जाँच करेंपीआरडी टेम्पलेट गाइड.

अक्सर पूछे जाने वाले प्रश्नों