वेब ऐप विकास: MVP से लॉन्च तक, चरण दर चरण
एक वेब एप्लिकेशन या सास बनाना निर्णयों की एक श्रृंखला है, एकल कूद नहीं। यह गाइड आपको उत्पाद खोज और एक लीन एमवीपी से लेकर स्टैक, सुरक्षा, लॉन्च और उस चेकलिस्ट तक ले जाती है जो आपको बताती है कि आप कब तैयार हैं।
वेबसाइट या वेब ऐप? जानें कि आप क्या बना रहे हैं
हर बाद के निर्णय को आकार देने वाले भेद से शुरू करें। एक वेबसाइट जानकारी प्रस्तुत करती है — लोग इसे पढ़ते हैं, शायद एक फॉर्म जमा करते हैं, और चले जाते हैं। एक वेब एप्लिकेशन काम करता है: उपयोगकर्ता साइन इन करते हैं, डेटा बनाते और बदलते हैं, और अगले दिन वापस आते हैं जहाँ उन्होंने छोड़ा था। एक सासउत्पाद एक वेब एप्लिकेशन है जिसे आप एक साथ कई ग्राहकों को किराए पर देते हैं, जिसमें अलग-अलग खाते और आवर्ती बिलिंग होती है।
यह एक अर्थशास्त्र का खेल नहीं है। लेबल आपके बजट, आपकी समयसीमा, और आपके जोखिम को निर्धारित करता है। एक ब्रोशर साइट दो हफ्तों में लाइव हो सकती है। एक उत्पाद जिसमें प्रमाणीकरण, भूमिकाएँ, एक डेटाबेस है जो कभी भी रिकॉर्ड नहीं खोना चाहिए, और भुगतान जो कभी भी डबल-चार्ज नहीं होना चाहिए, पूरी तरह से एक अलग मामला है।
त्वरित परीक्षण: आपको कौन सा चाहिए?
- यदि मुख्य मूल्य है पढ़ना सामग्री, तो आपको एक वेबसाइट की आवश्यकता है।
- यदि मुख्य मूल्य है करना कुछ — ट्रैकिंग, गणना, प्रबंधन, सहयोग — तो आपको एक वेब ऐप की आवश्यकता है।
- यदि आप उस ही उपकरण के लिए कई ग्राहकों से सदस्यता शुल्क लेने की योजना बना रहे हैं, तो आप SaaS बना रहे हैं।
अधिकांश संस्थापक यह पता लगाते हैं कि उन्हें एक वेब ऐप की आवश्यकता है जब वे कहते हैं "और फिर उपयोगकर्ता इसे सहेज सकता है और वापस आ सकता है।" यह एक वाक्य खाते, भंडारण, अनुमतियों और एक समर्थन बोझ का संकेत देता है जो एक स्थिर पृष्ठ कभी नहीं उठाता। जब आप इसे अंत से अंत तक बनवाना चाहते हैं, तो एक पूर्ण-चक्र विकास टीमआपको पांच फ्रीलांसरों को एक साथ जोड़ने से बचाता है जो प्रत्येक एक टुकड़ा रखते हैं।
उत्पाद खोज और एक तकनीकी विशिष्टता जो लाभ देती है
कोई भी कोड की एक पंक्ति लिखने से पहले, आपको यह स्पष्टता होनी चाहिए कि उपयोगकर्ता कौन है, वे आपके उत्पाद को किस काम के लिए नियुक्त करते हैं, और आप कैसे जानेंगे कि यह काम किया। इस चरण को कहा जाता है उत्पाद खोज, और इसे छोड़ना सॉफ़्टवेयर में सबसे महंगा शॉर्टकट है।
खोज स्पष्ट प्रश्नों के उत्तर देती है। आज किसके पास समस्या है, और वे इसके बजाय क्या उपयोग करते हैं? वह एक कार्यप्रवाह क्या है जो, यदि यह तेज और विश्वसनीय होता, तो उन्हें स्विच करने के लिए प्रेरित करता? उनके भुगतान करने के लिए क्या सच होना चाहिए? उत्तर लिखें। अस्पष्ट लक्ष्य अस्पष्ट सॉफ़्टवेयर उत्पन्न करते हैं।
एक अच्छे तकनीकी स्पेक में वास्तव में क्या होता है
एक तकनीकी विनिर्देशएक उपन्यास नहीं है। यह एक कार्यकारी समझौता है। उपयोगी वाले वर्णन करते हैं:
- उपयोगकर्ता भूमिकाएँ और प्रत्येक को क्या देखने और करने की अनुमति है;
- मुख्य स्क्रीन और प्रत्येक पर उपलब्ध क्रियाएँ;
- आपके द्वारा संग्रहीत डेटा, और नियम जो इसे मान्य रखते हैं;
- बाहरी सेवाएँ जिन पर आप निर्भर हैं — भुगतान, ईमेल, मानचित्र;
- गैर-परक्राम्य — कानूनी, सुरक्षा, प्रदर्शन — मापनीय शर्तों के रूप में stated।
यह नोट करें कि क्या गायब है: पिक्सेल-स्तरीय डिज़ाइन और ढांचे के विकल्प। एक स्पेक ठीक करता है इरादा, कार्यान्वयन नहीं। यह दो अलग-अलग टीमों को लगभग समान उत्पाद बनाने की अनुमति देनी चाहिए, और आपको ईमानदारी से यह कहने देना चाहिए कि क्या एक विशेषता पूरी हो गई है।
खोज को एक निवेश के रूप में मानें, न कि एक औपचारिकता के रूप में। एक अस्पष्ट वाक्य को हटाने में बिताया गया एक अपराह्न गलत चीज़ बनाने में एक सप्ताह बचा सकता है।
MVP दायरा: सही चीजों को काटने की कला
एक एमवीपी — न्यूनतम व्यावसायिक उत्पाद — एक सस्ता उत्पाद या टूटा हुआ उत्पाद नहीं है। यह सबसे छोटा संस्करण है जो एक वास्तविक उपयोगकर्ता को वास्तविक मूल्य प्रदान करता है और आपको कुछ सिखाता है जो आप स्लाइड डेक से नहीं सीख सकते।
कठिन हिस्सा विशेषताएँ जोड़ना नहीं है। यह उन्हें काटना है। हर विशेषता जो आप भेजते हैं, एक विशेषता है जिसे आपको डिज़ाइन, परीक्षण, सुरक्षा, दस्तावेज़ और हमेशा समर्थन करना होगा। इसलिए प्रत्येक आइटम के लिए प्रश्न स्पष्ट है: यदि हम इसे हटा दें, तो क्या एक प्रारंभिक उपयोगकर्ता अभी भी मुख्य मूल्य प्राप्त करेगा? यदि हाँ, तो इसे काटें, या इसे बाद में ले जाएँ।
स्कोप करने का एक सरल तरीका
- उस एकल कार्यप्रवाह का नाम बताएं जो आपके अस्तित्व का कारण है। इसकी रक्षा करें।
- बाकी सब कुछ सूचीबद्ध करें। "उस कार्यप्रवाह के लिए आवश्यक" और "रखने के लिए अच्छा" में वर्गीकृत करें।
- पहली सूची भेजें। दूसरी को एक बैकलॉग में पार्क करें जिसे आप अनदेखा करने की अनुमति रखते हैं।
पहली रिलीज़ से काटने के लिए सामान्य चीजें: दो भूमिकाओं से परे भूमिका पदानुक्रम, ऐप में संदेश, व्यापक सेटिंग स्क्रीन, मूल मोबाइल ऐप, और ग्राहक के लिए विश्लेषण डैशबोर्ड। आप प्रत्येक को तब जोड़ सकते हैं जब मांग सिद्ध हो जाए।
जब हमने प्रारंभिक रिलीज़ का स्कोप किया जैसे कि हमारा काम एक लिंक-प्रबंधन उपकरण, अनुशासन वही था: एक काम जो अच्छी तरह से किया गया है, वह दस कामों से बेहतर है जो आधे-अधूरे किए गए हैं। एक तंग MVP कोडबेस को इतना छोटा रखता है कि आप जल्दी दिशा बदल सकते हैं, जिसे आपको करने की आवश्यकता होगी।
स्टैक का चयन: फ्रंटएंड, बैकएंड, डेटाबेस, ऑथ, भुगतान
सर्वश्रेष्ठ स्टैक वह नीरस है जिसे आपकी टीम शिप और बनाए रख सकती है। नवीनता एक कर है जो आप 3 बजे जब कुछ टूटता है, तब चुकाते हैं। फिर भी, कुछ सिद्धांत आपको सही ढंग से चुनने में मदद करते हैं।
फ्रंटेंड
एक ऐप के लिए जिसमें बहुत सारी इंटरैक्टिव स्थिति है - डैशबोर्ड, संपादक, वास्तविक समय के अपडेट - एक घटक ढांचा अपनी कीमत वसूल करता है। सामग्री-भारी उत्पादों के लिए, सर्वर-रेंडर किए गए पृष्ठ तेजी से लोड होते हैं और बेहतर रैंक करते हैं। कई टीमें एक ऐसे ढांचे पर पहुंचती हैं जो दोनों करती है, सर्वर पर रेंडर करना और जहां ऐप को इसकी आवश्यकता होती है, वहां इंटरैक्टिव बनाना।
बैकेंड और डेटाबेस
एक बैकेंड भाषा चुनें जिसे आपकी टीम पहले से जानती है। एक संबंधात्मक डेटाबेस सुरक्षित डिफ़ॉल्ट है: यह संरचना को लागू करता है, लेनदेन का समर्थन करता है, और उस रिकॉर्ड को खोने से मना करता है जिसे आप खोने का जोखिम नहीं उठा सकते। केवल तभी अन्य स्टोर्स की ओर बढ़ें जब एक ठोस आवश्यकता प्रकट हो - कैशिंग, खोज, कतारें।
प्रमाणीकरण और भुगतान
प्रमाणन या कार्ड हैंडलिंग को हाथ से न करें। एक सिद्ध पहचान प्रदाता या एक अच्छी तरह से ऑडिट की गई लाइब्रेरी का उपयोग करें auth के लिए, और पैसे के लिए एक स्थापित प्रोसेसर का उपयोग करें। उन्होंने किनारे के मामलों को हल कर लिया है - पासवर्ड रीसेट, धोखाधड़ी, चार्जबैक, कर - जो अन्यथा आपके रोडमैप को खा जाएंगे। आपका काम सावधानी से एकीकृत करना है, विश्वास को फिर से आविष्कार करना नहीं।
एक व्यावहारिक नियम: उन तकनीकों के सबसे छोटे सेट का चयन करें जो आज की आवश्यकताओं को कवर करती हैं और कल के लिए जगह छोड़ती हैं। हर अतिरिक्त उपकरण एक और चीज है जिसे पैच, मॉनिटर और इसके लिए भर्ती करना है।
आर्किटेक्चर और स्केलेबिलिटी, साधारण भाषा में
आर्किटेक्चर केवल उन निर्णयों का सेट है जो बाद में बदलने के लिए महंगे होते हैं। कुछ बड़े निर्णय सही करें और बाकी लचीला रहता है।
एक मॉड्यूलर मोनोलिथ से शुरू करें - एक अच्छी तरह से संगठित एप्लिकेशन - न कि माइक्रोसर्विसेज़ के बेड़े से। माइक्रोसर्विसेज़ संगठनात्मक स्केलिंग समस्याओं को हल करती हैं जो अधिकांश प्रारंभिक उत्पादों में अभी तक नहीं हैं, और वे पहले दिन से नेटवर्क विफलताओं, तैनाती की जटिलता और डिबगिंग दर्द को जोड़ती हैं। आप बाद में एक सेवा को विभाजित कर सकते हैं, जब एक वास्तविक बाधा आपको बताएगी कि कहाँ।
"स्केलेबल" का वास्तव में क्या मतलब है
स्केलेबिलिटी कोई रहस्यमय गुण नहीं है जिसे आप पहले से खरीदते हैं। यह बिना किसी पुनर्लेखन के अधिक लोड संभालने की क्षमता है। व्यावहारिक रूप से, यह कुछ आदतों से आती है:
- ऐप्लिकेशन को स्टेटलेसरखें ताकि आप लोड बैलेंसर के पीछे कई प्रतियां चला सकें;
- धीमी कार्यों को - ईमेल भेजना, रिपोर्ट बनाना - बैकग्राउंड जॉब्स में डालें;
- महंगे चीजों को कैश करें जो शायद ही कभी बदलती हैं;
- सर्वर जोड़ने से पहले डेटाबेस इंडेक्स जोड़ें।
एडटेक और मार्केटप्लेस इसे स्पष्ट बनाते हैं। प्लेटफार्म जैसे एक विज्ञापन-नेटवर्क बनाते हैंपहले मापकर और उस एक क्वेरी को अनुकूलित करके ट्रैफ़िक के विस्फोट को अवशोषित करें जो वास्तव में नुकसान पहुंचाता है, न कि सब कुछ फिर से बनाकर। पूर्व-समय पर स्केलिंग एक समस्या पर पैसे खर्च करने का एक और तरीका है जो आपके पास अभी नहीं है।
डैशबोर्ड, खातों और दैनिक उपयोग के लिए UX
उपभोक्ता साइटें पहले क्लिक के लिए लड़ती हैं। उत्पाद सौवें के लिए लड़ते हैं। आपके उपयोगकर्ता ऐप के अंदर रहेंगे, इसलिए जो अनुभव मायने रखता है वह नीरस, दोहराया हुआ है: लॉग इन करें, चीज़ खोजें, कार्य करें, परिणाम पर भरोसा करें।
वापस आने वाले उपयोगकर्ता के लिए डिज़ाइन करें
- हर स्क्रीन पर प्राथमिक क्रिया को स्पष्ट और एकल बनाएं।
- राज्य को स्पष्ट रूप से दिखाएं - क्या सहेजा गया है, क्या लंबित है, क्या विफल हुआ है और इसे कैसे ठीक करें।
- खाली स्थिति का सम्मान करें: एक नया खाता सिखाना चाहिए, न कि खाली नजर से घूरना।
- नेविगेशन को स्थिर रखें ताकि मांसपेशियों की याददाश्त बन सके।
डैशबोर्ड टीमें हर संख्या को एक स्क्रीन पर भरने के लिए ललचाते हैं। इसका विरोध करें। एक अच्छा डैशबोर्ड एक नज़र में एक प्रश्न का उत्तर देता है और उपयोगकर्ता को बाकी के लिए गहराई में जाने देता है। यदि सब कुछ हाइलाइट किया गया है, तो कुछ भी नहीं है।
खाता और बिलिंग प्रवाह को विशेष देखभाल की आवश्यकता होती है क्योंकि वे पैसे और विश्वास को छूते हैं। मार्केटप्लेस जैसे एक फ्रीलांस प्लेटफॉर्मइस पर निर्भर करता है कि उपयोगकर्ता अपने बैलेंस, अपने चालान और अपनी अनुमतियों को बिना समर्थन को ईमेल किए समझ सकते हैं या नहीं। वहां स्पष्टता सजावट नहीं है; यह बनाए रखने का एक तरीका है।
सुरक्षा और डेटा जिसे आप गलत नहीं कर सकते
सुरक्षा एक विशेषता नहीं है जिसे आप अंत में जोड़ते हैं। यह उन डिफ़ॉल्ट सेटों का एक समूह है जो आप पहले कमिट से रखते हैं। अच्छी खबर: अधिकांश उल्लंघन कुछ बचने योग्य गलतियों की छोटी सूची से आते हैं।
- इनपुट पर कभी भरोसा न करें। हमेशा सर्वर पर मान्य करें, भले ही ब्राउज़र ने पहले ही जांच की हो।
- पैरामीटराइज्ड क्वेरीज़ का उपयोग करें ताकि उपयोगकर्ता का पाठ कभी भी एक कमांड में न बदल सके।
- पासवर्ड केवल मजबूत हैश के रूप में स्टोर करें - कभी भी स्पष्ट पाठ में, कभी भी उलटने योग्य नहीं।
- हर क्रिया को एक प्राधिकरण जांच के पीछे रखें - लॉग इन होना अनुमति प्राप्त करने के समान नहीं है।
- सब कुछ HTTPS के माध्यम से सेवा करें और निर्भरताओं को पैच रखें।
डेटा को एक जिम्मेदारी के रूप में मानें
आपको जितना कम से कम चाहिए, उतना ही इकट्ठा करें। डेटा जिसे आप कभी स्टोर नहीं करते, वह लीक नहीं हो सकता। जो आप रखते हैं, जानें कि यह कहां है, कौन इसे पहुंच सकता है, और यदि कोई उपयोगकर्ता पूछता है तो आप इसे कैसे हटाएंगे। नियमित रूप से बैकअप लें और - यह वह हिस्सा है जिसे लोग छोड़ देते हैं - वास्तव में परीक्षण करें कि आप इसे पुनर्स्थापित कर सकते हैं। एक बैकअप जिसे आपने कभी पुनर्स्थापित नहीं किया है, एक आशा है, योजना नहीं।
यदि आप भुगतान या व्यक्तिगत डेटा का प्रबंधन करते हैं, तो गोपनीयता और क्षेत्रीय नियम लागू होते हैं। उनके लिए जल्दी से डिज़ाइन करें; सहमति, डेटा निर्यात, और हटाने को एक परिपक्व उत्पाद में जोड़ना दर्दनाक और महंगा है।
इंटीग्रेशन और APIs: आपका उत्पाद एक द्वीप नहीं है
आधुनिक उत्पाद उतने ही असेंबल किए जाते हैं जितने कि बनाए जाते हैं। भुगतान, ईमेल, खोज, मानचित्र, विश्लेषण, चैट - प्रत्येक एक सेवा है जिसे कोई और इस वर्ष आपसे बेहतर चला रहा है। आपकी मूल्य वह कार्यप्रवाह है जो उन्हें जोड़ता है, न कि प्रत्येक का पुनः कार्यान्वयन।
इंटीग्रेशन का सावधानीपूर्वक उपभोग करें
हर बाहरी सेवा, अंततः, धीमी या बंद होगी। इसके लिए योजना बनाएं। टाइमआउट सेट करें, सावधानी से पुनः प्रयास करें, और एक तरीके से विफल हों जिसे उपयोगकर्ता समझता है। कभी भी तीसरे पक्ष की आउटेज को चुपचाप आपके डेटा को भ्रष्ट या आपके ऐप को फ्रीज करने न दें।
अपना खुद का एपीआई डिज़ाइन करना
जल्द या बाद में आप एक API — एक मोबाइल क्लाइंट, एक भागीदार, या आपके अपने फ्रंटेंड के लिए। कुछ आदतें इसे संतुलित रखती हैं:
- नामकरण, संरचना, और त्रुटियों में निरंतरता बनाए रखें ताकि कॉल करने वाले अगला एंडपॉइंट सही तरीके से अनुमान लगा सकें;
- इसे शुरू से ही संस्करणित करें ताकि आप बिना उपयोगकर्ताओं को तोड़े विकसित हो सकें;
- हर मार्ग को प्रमाणित करें और दर-सीमा निर्धारित करें;
- इसे बनाते समय दस्तावेज़ित करें, बाद में नहीं।
अपने डेटा मॉडल को एक अनुबंध के रूप में सोचें। एक बार जब कोई अन्य प्रणाली एक फ़ील्ड पर निर्भर हो जाती है, तो इसे बदलना एक बातचीत बन जाता है। यह सतह को छोटा और जानबूझकर रखने का एक अच्छा कारण है।
टेस्टिंग और QA जो समस्याओं को उपयोगकर्ताओं से पहले पकड़ लेती है
परीक्षण का मतलब कोड को सही साबित करना नहीं है। इसका मतलब है कि आप इसे कल बिना डर के बदल सकें। यही आत्मविश्वास एक छोटे से टीम को वर्षों तक महीनों के बजाय तेजी से आगे बढ़ने की अनुमति देता है।
एक समझदारी से बनाया गया परीक्षण पिरामिड
- कई तेज़यूनिट परीक्षणउस तर्क के लिए जो सही होना चाहिए — मूल्य निर्धारण, अनुमतियाँ, गणनाएँ।
- कम एकीकरण परीक्षण जो यह जांचते हैं कि आपके भाग एक साथ काम करते हैं — ऐप डेटाबेस और भुगतान सैंडबॉक्स से सही तरीके से बात करता है।
- कुछ अंत-से-अंत परीक्षण जो उन महत्वपूर्ण यात्राओं के माध्यम से चलते हैं जो एक उपयोगकर्ता वास्तव में करता है: साइन अप करें, मुख्य कार्य करें, भुगतान करें।
जो आप अन्यथा हाथ से दोहराएंगे उसे स्वचालित करें। मैनुअल QA अभी भी महत्वपूर्ण है, लेकिन मानव ध्यान को निर्णय के लिए सुरक्षित रखें — क्या यह सही लगता है, क्या कॉपी स्पष्ट है — न कि पचासवीं बार उसी लॉगिन फॉर्म पर क्लिक करने के लिए।
हर बार एक परीक्षण जोड़ें जब एक बग उत्पादन में escapes हो। बग परिवारों में यात्रा करते हैं; जिसे आपने अभी ठीक किया है उसके रिश्तेदार हैं। एक परीक्षण यह सुनिश्चित करने का तरीका है कि वही विफलता कभी भी दो बार न हो, और यह प्रणाली के व्यवहार का सबसे सस्ता दस्तावेज है।
लॉन्च और एनालिटिक्स: बिना अंधेरे में गए लाइव होना
एक लॉन्च एक एकल नाटकीय क्षण नहीं है; यह एक नियंत्रित अनुक्रम है। पहले अपने लिए शिप करें, फिर कुछ मित्रवत उपयोगकर्ताओं के लिए, फिर एक व्यापक समूह के लिए। प्रत्येक कदम आपको वास्तविक फीडबैक देता है जबकि किसी भी गलती का विस्फोटक क्षेत्र छोटा रहता है।
आप लॉन्च करने से पहले उपकरण स्थापित करें, बाद में नहीं।
आप उस पर सुधार नहीं कर सकते जिसे आप नहीं देख सकते। असली उपयोगकर्ताओं के आने से पहले, तीन प्रकार की आँखें स्थापित करें:
- उत्पाद विश्लेषण — कौन से फीचर्स का उपयोग होता है, लोग कहाँ छोड़ते हैं, सक्रियण पथ कैसा दिखता है।
- त्रुटि निगरानी — ताकि एक टूटी हुई पृष्ठ आपको सूचित करे, न कि एक ट्वीट करने वाला ग्राहक।
- प्रदर्शन मेट्रिक्स — असली उपयोगकर्ताओं के लिए असली लोड समय, न कि एक प्रयोगशाला संख्या।
आप मापते समय गोपनीयता का सम्मान करें: वह जानकारी इकट्ठा करें जो निर्णय को सूचित करती है, न कि सब कुछ जो आप तकनीकी रूप से कर सकते हैं। फिर, पहले से सहमत हों, उन एक या दो संख्याओं पर जो इस रिलीज के लिए सफलता को परिभाषित करती हैं — सक्रियण, बनाए रखना, रूपांतरण — ताकि आप संकेत द्वारा मार्गदर्शन कर सकें न कि वाइब्स के बारे में बहस करके।
लॉन्च के अगले दिन से उत्पाद वास्तव में शुरू होता है। देखें, उपयोगकर्ताओं से बात करें, और कुछ नया जोड़ने से पहले शीर्ष घर्षण को ठीक करें।
लागत, समयसीमा, और वे गलतियाँ जो दोनों को बढ़ाती हैं
पहले दो ईमानदार उत्तर: कोई भी एक-लाइन विचार से उत्पाद की सटीक कीमत नहीं लगा सकता, और संख्या "कितने फीचर्स" से कम "कितनी अनिश्चितता और जोखिम" द्वारा संचालित होती है।कितनी अनिश्चितता और जोखिमप्रत्येक विशेषता का मूल्य। एक मानक लॉगिन की लागत थोड़ी होती है; एक अनुकूलित बिलिंग इंजन जिसमें प्रोरशन और कर शामिल हैं, उसकी लागत अधिक होती है।
वास्तव में लागत और समय को क्या चलाता है
- दायरा स्पष्टता — अस्पष्ट आवश्यकताएँ सबसे बड़ा छिपा हुआ खर्च हैं।
- चिंतित तीसरे पक्षों के साथ एकीकरण और उनकी स्वीकृति प्रक्रियाएँ।
- गैर-कार्यात्मक मांगें: उच्च उपलब्धता, सख्त अनुपालन, भारी लोड।
- डिज़ाइन की महत्वाकांक्षा — अनुकूलित इंटरफेस की लागत साफ, पारंपरिक इंटरफेस से अधिक होती है।
- टीम निरंतरता — पुनः आरंभ और हस्तांतरण चुपचाप बजट को जलाते हैं।
गलतियाँ जो दोनों को बढ़ाती हैं
क्लासिक्स हर परियोजना में दोहराते हैं। पहले दिन एक मिलियन उपयोगकर्ताओं के लिए निर्माण करना। ऐसे फीचर्स जोड़ना जिनकी किसी ने मांग नहीं की जबकि मूल rough रहता है। खोज को छोड़ना, फिर इसके लिए पुनः कार्य में भुगतान करना। एक रिज्यूमे के लिए विदेशी तकनीक चुनना, उत्पाद के लिए नहीं। और सुरक्षा और परीक्षण को "बाद में" टालना, एक तारीख जो कभी नहीं आती।
यदि आप एक अनुमान के बजाय एक ठोस अनुमान चाहते हैं, तो सबसे तेज़ रास्ता एक संक्षिप्त स्कोपिंग बातचीत है। हमें वह एक कार्यप्रवाह बताएं जो महत्वपूर्ण है, और हम एक वास्तविक बजट और समयरेखा का मानचित्रण कर सकते हैंइसके चारों ओर।
आपकी MVP लॉन्च चेकलिस्ट
लॉन्च से पहले इसे अंतिम पास के रूप में उपयोग करें। यदि आप ईमानदारी से हर लाइन को टिक कर सकते हैं, तो आप तैयार हैं। यदि नहीं, तो आपने अपनी अगली कार्य सूची पा ली है।
लॉन्च से पहले
- एक मुख्य कार्यप्रवाह अंत से अंत तक काम करता है, धीमे फोन पर भी और तेज़ लैपटॉप पर भी।
- साइन-अप, लॉगिन, पासवर्ड रीसेट, और लॉगआउट सभी सही तरीके से कार्य करते हैं।
- भुगतान वास्तविक किनारे के मामलों के खिलाफ परीक्षण किए जाते हैं: अस्वीकृतियाँ, पुनः प्रयास, रिफंड।
- हर मार्ग दोनों प्रमाणीकरण और प्राधिकरण की जांच करता है।
- इनपुट सर्वर पर मान्य किया जाता है; क्वेरीज़ पैरामीटरयुक्त होती हैं।
- HTTPS लागू किया गया है और रहस्य कोडबेस से बाहर हैं।
- बैकअप स्वचालित रूप से चलते हैं और आपने एक सफलतापूर्वक पुनर्स्थापित किया है।
- त्रुटि निगरानी, उत्पाद विश्लेषण, और अपटाइम जांच सक्रिय हैं।
- खाली स्थिति एक नए उपयोगकर्ता को पहले क्या करना है, यह सिखाती है।
- आप जानते हैं कि इस सप्ताह आप कौन सा सफलता मीट्रिक देखेंगे।
लॉन्च के तुरंत बाद
- पहले दो हफ्तों के लिए दैनिक त्रुटियों और प्रदर्शन पर नज़र रखें।
- अपने पहले उपयोगकर्ताओं से बात करें और उनके सटीक शब्दों को लिखें।
- कुछ नया बनाने से पहले शीर्ष घर्षण बिंदु को ठीक करें।
- एक छोटा, निर्दयी बैकलॉग रखें और कोर की रक्षा करें।
पहला रिलीज एक शुरुआत है, स्मारक नहीं। सबसे छोटा ईमानदार संस्करण भेजें, वास्तविक उपयोग से सीखें, और उत्पाद को अपनी अगली विशेषता कमाने दें। वह लूप — बनाना, मापना, सीखना, दोहराना — यही है कि टिकाऊ सॉफ़्टवेयर वास्तव में कैसे बनाया जाता है।
अक्सर पूछे जाने वाले प्रश्न
एक वेबसाइट, एक वेब ऐप, और SaaS में क्या अंतर है?
एक वेबसाइट मुख्य रूप से लोगों के पढ़ने के लिए जानकारी प्रस्तुत करती है। एक वेब एप्लिकेशन काम करता है — उपयोगकर्ता लॉग इन करते हैं, डेटा बनाते और बदलते हैं, और समय के साथ वापस आते हैं। SaaS एक वेब एप्लिकेशन है जो कई ग्राहकों को एक सदस्यता पर बेचा जाता है, जिसमें अलग-अलग खाते और आवर्ती बिलिंग होती है। जितना अधिक आपके उपयोगकर्ता 'करते' हैं बजाय 'पढ़ने' के, उतना ही अधिक आपको एक ऐप की आवश्यकता होती है।
एक MVP बनाने में कितना समय लगता है?
कोई सार्वभौमिक संख्या नहीं है, लेकिन एक केंद्रित MVP जो एक मुख्य कार्यप्रवाह के चारों ओर बनाया गया है, सप्ताहों से लेकर कुछ महीनों में मापा जाता है, वर्षों में नहीं। समयरेखा उपयोगकर्ता भूमिकाओं, एकीकरणों, और अनुपालन जैसी गैर-कार्यात्मक मांगों की संख्या के साथ बढ़ती है। निर्दयी दायरा गति पर सबसे बड़ा लीवर है।
वेब ऐप विकास की लागत कितनी है?
लागत अनिश्चितता और जोखिम द्वारा संचालित होती है, कच्ची विशेषता संख्या द्वारा नहीं। एक मानक लॉगिन सस्ता है; एक अनुकूलित बिलिंग इंजन जिसमें प्रोरशन और कर शामिल हैं, ऐसा नहीं है। अस्पष्ट आवश्यकताएँ, जटिल एकीकरण, उच्च-उपलब्धता की मांगें, और कस्टम डिज़ाइन सभी संख्या को बढ़ाते हैं। एक संक्षिप्त स्कोपिंग वार्ता किसी भी ऑनलाइन कैलकुलेटर की तुलना में एक अधिक ईमानदार आंकड़ा देती है।
क्या मुझे विकास से पहले वास्तव में एक तकनीकी विशिष्टता की आवश्यकता है?
हाँ, हालांकि यह एक भारी दस्तावेज़ नहीं होना चाहिए। एक उपयोगी तकनीकी विशिष्टता इरादे को ठीक करती है: उपयोगकर्ता भूमिकाएँ, प्रमुख स्क्रीन, आप जो डेटा संग्रहीत करते हैं और उसके नियम, बाहरी निर्भरताएँ, और मापने योग्य गैर-परक्राम्य। यह एक टीम को सही चीज़ बनाने देती है और आपको ईमानदारी से यह आंकने देती है कि एक विशेषता कब पूरी होती है। यह इसकी लागत से कहीं अधिक समय बचाती है।
SaaS उत्पाद के लिए कौन सा तकनीकी स्टैक सबसे अच्छा है?
सबसे अच्छा स्टैक वह है जिसे आपकी टीम शिप और बनाए रख सके, न कि सबसे नया। एक घटक फ्रंटेंड ढांचा इंटरएक्टिव डैशबोर्ड के लिए उपयुक्त है; सर्वर रेंडरिंग सामग्री के लिए उपयुक्त है। एक संबंधपरक डेटाबेस एक सुरक्षित डिफ़ॉल्ट है। ऑथ के लिए एक सिद्ध पहचान प्रदाता और भुगतान के लिए एक स्थापित प्रोसेसर का उपयोग करें, बजाय इसके कि आप खुद से कोई भी बनाएं।
क्या मुझे पहले मोबाइल ऐप बनाना चाहिए या वेब ऐप?
अधिकांश उत्पादों के लिए, वेब पर शुरू करें। एक उत्तरदायी वेब ऐप एक कोडबेस से हर डिवाइस तक पहुंचता है, तेजी से शिप होता है, और ऐप-स्टोर समीक्षा के बिना तुरंत अपडेट होता है। एक मूल मोबाइल ऐप तब बनाएं जब आपके पास सिद्ध मांग हो और ऐसी क्षमताओं की आवश्यकता हो जो वेब प्रदान नहीं कर सकता, जैसे गहरे डिवाइस एकीकरण या ऑफ़लाइन-प्रथम उपयोग।
