7 सप्ताह में एमवीपी। कैसा था

जब मैंने लोगों को इकट्ठा किया और कहा कि हमें 31 मई तक नई सेवा का एमवीपी (न्यूनतम व्यवहार्य उत्पाद) बनाने के लिए समय चाहिए, तो उन्होंने एक-दूसरे को देखा और कहा: "यह असंभव है।" और अब, लगभग 7 सप्ताह के विकास के बाद, हम में से प्रत्येक गर्व से कह सकता है: "हमने यह किया!"







यह लेख सामग्री " कैसे एक बकवास बनाने के लिए नहीं है? उत्पाद बनाने में व्यक्तिगत अनुभव " का एक निरंतरता है, जहां मैंने अनुसंधान और उत्पाद डिजाइन के चरणों का वर्णन किया है। अब मैं अपने व्यक्तिगत अनुभव को साझा करना चाहता हूं और इस बारे में बात करना चाहता हूं कि कैसे हम समय पर "असंभव प्रतीत होने वाली" परियोजना को लागू करने में कामयाब रहे, जो हमें बलिदान करना था और आपको दिखाएगा कि हमने क्या किया।

गुणवत्ता और MVP के बारे में कुछ गीत

हमारे आसपास कई “ग्रे” साधारण चीजें हैं। चारों ओर देख लो! फर्नीचर, कपड़े, कार, उपकरण और यहां तक ​​कि आपकी कलम भी। आपको इनमें से कौन सा सच पसंद है? क्या प्रसन्न है? क्या ध्यान आकर्षित करता है? मुझे वास्तव में सुंदर, अच्छी तरह से बनाई गई और विचारशील चीजें पसंद हैं। यह एक बोश मिक्सर, एक स्कोडा ऑक्टेविया ट्रंक या बाबेल के टॉवर की तस्वीर (पीटर ब्रूघेल द एल्डर, 1563) हो सकता है। ख़ूबसूरती नहीं?







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

हमने क्या किया है?

1. हमने बुनियादी ढांचे पर "रन बनाए" । यह अक्सर तब होता है जब एक नया प्रोजेक्ट एक नए कार्यालय के साथ शुरू होता है, और एक कार्यशील प्रोटोटाइप के साथ नहीं। इसलिए, पूरे प्रोजेक्ट के लिए, हमने केवल बुनियादी ढाँचे के कार्यों का न्यूनतम सेट किया, जिनकी "रक्त-से-नाक" की आवश्यकता थी। उदाहरण के लिए, हाल ही में, हमारे पास परियोजना के लिए सर्वर भी नहीं था, यह केवल 5 पुनरावृत्तियों पर दिखाई दिया। इससे पहले, पूरा प्रोजेक्ट लोकेल पर लोगों द्वारा किया गया था। और हमने अपनी सेवा के लिए एक परीक्षण स्टोर किया, जहां समाधान "बाहर" पहली बार 5 मिनट में एक मुफ्त मंच पर लॉन्च किया गया था, हालांकि सबसे पहले हमने अपने सर्वर पर सीएमएस में से एक को पूरी तरह से तैनात करने के विकल्प के बारे में सोचा था।



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







2. ज्यादा सोचो, कम करो। पहले सोचा था कि इस परियोजना की शुरुआत में मेरे दिमाग में आया: "दोस्तों! हम क्या कर रहे हैं, चलो कोड, अन्यथा हमारे पास समय नहीं है! ”लेकिन अभ्यास से पता चलता है कि कोड की कम पंक्तियां लिखी गई हैं, बेहतर है। हमने वास्तव में टीम के भीतर संचार करने और प्रौद्योगिकियों को चुनने में बहुत समय बिताया। इस तरह की लागत बाद की उत्पादकता और समय की बचत में भुगतान की तुलना में अधिक है। और पहले 3 पुनरावृत्तियों में संचार की दक्षता बढ़ाने के लिए, मुझे अपने ब्रायस्क विकास कार्यालय में जाना पड़ा और अगले पुनरावृत्ति के लिए हर शुक्रवार को डेमो और स्प्रिंट प्लानिंग के लिए आना पड़ा।



3. सबसे पहले, हमने साप्ताहिक पुनरावृत्तियों पर स्विच किया । यह तुरंत स्पष्ट हो गया था कि हमें विकास के लिए अपने मौजूदा दृष्टिकोण को बदलना होगा, क्योंकि एक नया उत्पाद जारी होने और पुराने के समर्थन / विकास मौलिक रूप से भिन्न थे। जब बड़ी अनिश्चितता होती है, तो परिणाम जल्दी से जल्दी प्राप्त करना चाहिए। पूर्ण कर लिया? मुझे दिखाओ! इसके अलावा, साप्ताहिक पुनरावृत्तियों की योजना बनाना आसान है, खासकर यदि कार्य अत्यधिक परस्पर जुड़े हुए हैं।



4. "Nafig" - हमारा पसंदीदा वाक्यांश बन गया है। हमारे उत्पाद की प्रमुख विशेषताओं को छोड़कर लगभग सब कुछ सिस्टम से बाहर फेंक दिया गया था। उन्होंने केवल उन संभावनाओं को छोड़ दिया, जो परिकल्पनाओं का परीक्षण करने की अनुमति देगा या जिसके बिना उत्पाद सिद्धांत रूप में उपयोग नहीं किया जा सकता है। लेकिन जो बचा था वह अच्छी तरह से किया गया था! एक साधारण उदाहरण। हमारी सेवा में सामानों की खरीद के कुछ दिनों बाद ग्राहकों को अनुवर्ती पत्र भेजने की कार्यक्षमता है। यहां बताया गया है कि हमने कैसे तर्क दिए और संभावनाओं को काट दिया:

• पत्र के विषय और पाठ को बदलने की क्षमता nafig है, क्योंकि डिफ़ॉल्ट विकल्प काफी अच्छा है और इकाइयां वास्तव में कुछ बदल देंगी।
• प्रेषक के नाम और ईमेल को निर्दिष्ट करने की क्षमता nafig है, क्योंकि कई खरीदार प्रेषक के ईमेल पर ध्यान नहीं देंगे और सेवा के कम ग्राहक भी इस ईमेल को कॉन्फ़िगर करेंगे।
• पत्र टेम्पलेट को पूरी तरह से अनुकूलित करने की क्षमता nafig है, क्योंकि वर्तमान परियोजना के अनुभव से पता चला है कि 1% से भी कम ग्राहक ऐसा कर रहे हैं। इसके अलावा, हमारे टेम्पलेट को पेशेवर रूप से विभिन्न उपकरणों और ईमेल क्लाइंट के लिए डिज़ाइन और अनुकूलित किया गया है।
• ब्रांडिंग (आसान) की संभावना - छोड़ दिया ताकि दुकानदारों को डर न हो।
• पत्र भेजने की अवधि निर्धारित करने की क्षमता बची हुई थी, क्योंकि विभिन्न उत्पाद श्रेणियों के स्टोरों को अलग-अलग विलंबता वाले ईमेल भेजने चाहिए।

5. बेहतर सरल है। ट्रिमिंग के बाद शेष क्षमताएं, हमने यथासंभव सरल और प्रभावी रूप से लागू करने का प्रयास किया। उदाहरण के लिए, हमने समीक्षा विजेट की उपस्थिति को केवल एक पैरामीटर - बटन और तत्वों के रंग को अनुकूलित करने की क्षमता को सरल बनाया। और हमारे ग्राहकों के पहले कार्यान्वयन ने दिखाया कि यह पर्याप्त है!







हमने माध्यमिक चीजें न करने की भी कोशिश की। यदि 31 मई तक एमवीपी बनाने के लक्ष्य के लिए कुछ कार्यक्षमता हमें सीधे नहीं ले जाती है, तो हमने बस नहीं किया। उदाहरण के लिए, हमें केवल 6 पुनरावृत्तियों में पासवर्ड पुनर्प्राप्ति की संभावना का एहसास हुआ, जब यह स्पष्ट हो गया कि हम इसे बर्दाश्त कर सकते हैं। यदि हमारे पास समय नहीं है, तो हम इसे वैसे ही छोड़ देंगे। अगर किसी चीज़ को लागू करने की आवश्यकता या व्यवहार्यता के बारे में संदेह था - मेरा जवाब तुरंत है "Nafig।"

परिणाम

हमारा MVP आरंभिक से कुछ अलग है जिसे हमने UserStory पर लेआउट को काटने के चरण में करने की योजना बनाई है। नीचे दी गई तस्वीर में लाल रेखा अमेरिका को चिह्नित करती है जिसे हमने बनाने की योजना बनाई थी, और नीले रंग से पता चलता है कि अंत में क्या हुआ था। आप हमारे एमवीपी को इस परीक्षण बेंच पर रह सकते हैं।







टीम में 3 पेशेवर डेवलपर्स + 1 उत्पाद स्वामी शामिल थे। परियोजना के दौरान, डेवलपर्स में से एक 1 सप्ताह के लिए छुट्टी पर चला गया। टीम में कोई समर्पित डिजाइनर और न ही कोडर है। विकास को गति देने के लिए, हमने खरीदे हुए लेआउट का उपयोग किया। उन्होंने रातों और सप्ताहांत में काम नहीं किया, लेकिन काम के घंटों के दौरान कड़ी मेहनत की।



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