उत्पाद विकास के दौरान विफलताओं से बचना: धोखेबाज़ से 10 युक्तियाँ

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

1. प्रक्रिया को भूल जाओ, परिणाम के लिए काम करें

उत्पाद विकसित करते समय, कंपनियां अक्सर अपना सारा ध्यान और संसाधन निर्माण और उत्पादन की प्रक्रिया में लगाती हैं। भले ही काम के प्रत्येक चरण को "प्रौद्योगिकी के अनुसार कड़ाई" के साथ किया जाता है, लेकिन परिणाम शुरुआत में जैसा लग रहा था वैसा रस्सा नहीं हो सकता है।

केस का अध्ययन

तीन महीने पहले, रूकी टीम ने एक परिष्कृत प्रणाली विश्लेषण प्रक्रिया शुरू की। विश्लेषक को विपणन अनुसंधान का अनुरोध करना और इकट्ठा करना, समाधान के विकल्प तैयार करना, वित्तीय गणनाओं का अनुरोध करना, एल्गोरिदम को डिजाइन करना, यूएक्स के लिए कार्य निर्धारित करना, व्यावसायिक आवश्यकताओं को निर्धारित करना, अपने निर्णयों की रक्षा करना, बिछाने के बाद परिणाम को ट्रैक करना, ऑपरेशन को स्थानांतरित करना आदि शामिल हैं। एक विश्लेषक पर लोड प्रति दिन 15 कार्य तक पहुंच सकता है। शारीरिक रूप से, एक विशेषज्ञ प्रतिदिन इतने विविध कार्यों से नहीं गुजर सकता है। यह आश्चर्य की बात नहीं है कि इस तरह की मात्रा के साथ, विश्लेषक का काम आम समस्याओं को हल करने में एक संकीर्ण गर्दन था। दक्षता में सुधार करने के लिए, कई चीजें घूम गईं। नतीजतन, कंपनी ने ऐसी जटिल प्रक्रिया को छोड़ दिया और मौलिक रूप से इसे सरल बनाया, विभिन्न विशेषज्ञों के बीच जिम्मेदारियों को वितरित किया। दक्षता बढ़ गई है, और एनालिटिक्स प्रक्रिया तेजी से होने लगी है।

कैसे बचें?

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

2. कमांड सिंक हाई रखें

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

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

केस का अध्ययन

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

कैसे बचें?

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

3. उपयोगकर्ता द्वारा आवश्यक उत्पाद उन्नयन से बचें।

नए उत्पादों ने ऑपरेशन के दौरान समस्याओं की पहचान की है। यह कोई रहस्य नहीं है कि परियोजनाओं में कुछ सुधार उन उपयोगकर्ताओं द्वारा शुरू किए गए थे जिन्होंने समर्थन सेवा से संपर्क किया था। कोई भी तर्क नहीं देता है: उत्पादों को सुधारने की आवश्यकता है, लेकिन "पैच अप छेद" करने से पहले, आपको समस्याओं के मूल कारण की तलाश करनी चाहिए।



कैसे बचें?

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

4. परियोजना और डिजाइन कार्यों पर चर्चा करने के लिए डेवलपर्स को आमंत्रित करें

अक्सर, ग्राहकों की व्यावसायिक आवश्यकताओं को प्राप्त करने के बाद, डिजाइनर कार्यों के तर्क का वर्णन करने के लिए आगे बढ़ता है। यदि आप सिस्टम की तकनीकी विशेषताओं को ध्यान में नहीं रखते हैं, तो आपको एक समाधान मिल सकता है जिसके परिणामस्वरूप 3 महीने का विकास होगा।

केस का अध्ययन

एक बार रूकी में , एक स्थिति उत्पन्न हुई। उन्होंने उस इंटरफ़ेस को आकर्षित किया जिसमें उत्पादों में से एक में एक प्रोजेक्ट बनाने के लिए एक विज़ार्ड था: पहले चरण में, उपयोगकर्ता इससे (यैंडेक्सडायरेक्ट में) जानकारी प्राप्त करने के लिए किसी अन्य सेवा में लॉग इन करता है। दूसरे चरण में, कार्य के लिए मापदंडों की एक सूची का चयन किया जाता है। पहले चरण में निर्दिष्ट टोकन के लिए अनुरोध निष्पादित करके पैरामीटर प्राप्त किए गए थे।
डेवलपर्स को भेजा गया इंटरफ़ेस ग्राहकों को दिखाया गया, सहमत हुआ। जब डेवलपर्स ने यह देखा, तो उन्होंने कहा: “यहाँ आपको एक फिल्म दिखानी है, क्योंकि यदि उपयोगकर्ता के पास बहुत अधिक डेटा है, तो वह बहुत लंबे समय तक प्रतीक्षा कर सकता है। इसके अलावा, यह फ्रंट-एंड समाधान उपयोगकर्ता के अनुकूल नहीं है। ”
नतीजतन, मुझे प्रोग्रामरों से प्रतिक्रिया देते हुए, सब कुछ फिर से करना पड़ा।

कैसे बचें?

डेवलपर्स को परियोजनाओं की चर्चा में भाग लेने, आवश्यकताओं को प्रारूपित करने के लिए आमंत्रित करें, उन्हें डिजाइन में शामिल करें। शुरुआती चरणों में डेवलपर्स को काम में शामिल करके, आप एक परियोजना बनाने में लगने वाले समय को काफी कम कर सकते हैं, अनावश्यक rework लागत से बच सकते हैं, और एक चूक की समय सीमा के बिना अतिरिक्त भूरे बालों के बिना कर सकते हैं।

5. सरलीकरण करें। शानदार, जब प्रभावी

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

केस का अध्ययन

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

कैसे बचें?

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

6. आवश्यकताओं की अस्पष्ट व्याख्या से बचें

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



कैसे बचें?

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

7. लक्षित दर्शकों को याद रखें।

अजीब तरह से, ऐसे लोग हैं जो मानते हैं: जितना संभव हो उतने उपयोगकर्ताओं को आकर्षित करना बेहतर है, और उनमें से निश्चित रूप से उत्पाद का एक लक्षित दर्शक होगा। ऐसा नहीं है। आपके पास एक विशिष्ट उत्पाद हो सकता है जिसके उपभोक्ता उपयोगकर्ताओं के एक विशिष्ट खंड हैं।

केस का अध्ययन

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

कैसे बचें?

प्रारंभ में, लक्षित ट्रैफ़िक को आकर्षित करने और विज्ञापन अभियानों और स्थिति में समायोजन करने के लिए अपने प्रयासों पर ध्यान केंद्रित करना बेहतर होता है यदि साइट आगंतुक निश्चित रूप से आपके संभावित ग्राहक नहीं हैं।

8. परिकल्पना का परीक्षण करते समय विभाजित परीक्षणों के प्रतिच्छेदन से बचें

इस तरह की समस्या उत्पन्न हो सकती है यदि परिकल्पनाएं खराब नियोजित हैं या विश्लेषक खराब रूप से योग्य हैं।

केस का अध्ययन

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

कैसे बचें?

ए / बी परीक्षण करते समय, विभाजन को विभाजित करने की अनुमति न दें। उपयोगकर्ताओं को अलग करने का प्रयास करें ताकि एक व्यक्ति केवल एक प्रयोग में भाग ले। यदि अचानक आप अभी भी एक साथ दो परीक्षण चलाते हैं, तो 4 समूहों का मूल्यांकन करें:

• लैंडिंग का पहला संस्करण + भुगतान क्षेत्र पर पहला विकल्प;

• लैंडिंग का पहला संस्करण + भुगतान क्षेत्र में दूसरा विकल्प;

• भुगतान क्षेत्र में दूसरा लैंडिंग विकल्प + पहला विकल्प;

• भुगतान क्षेत्र में दूसरा लैंडिंग विकल्प + दूसरा विकल्प।

9. उपयोगकर्ता की राय के साथ अपनी राय को भ्रमित न करें

उपयोगकर्ता की राय के लिए विशिष्ट गलतियों में से एक को अपनाना है। यदि आप किसी उत्पाद, उसके डिज़ाइन और उपयोगशीलता को पसंद करते हैं, तो आप समझते हैं कि इसके साथ बातचीत कैसे करें, इस तथ्य से नहीं कि उपयोगकर्ता आपके उत्साह को साझा करेगा।



कैसे बचें?

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

10. अधिकतम करने के लिए ईवेंट लॉग करें

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

कैसे बचें?

घटनाओं को अधिकतम करने के लिए लॉग इन करें। इसका मतलब यह नहीं है कि आपको हर छोटे विवरण को लॉगिंग शुरू करने की आवश्यकता है, जैसे कि माउस के साथ एक उपयोगकर्ता आंदोलन, लेकिन ऑब्जेक्ट के साथ होने वाली मूल जानकारी दर्ज की जानी चाहिए।

निष्कर्ष

नए उत्पादों को विकसित करते समय कोई भी कंपनी समस्याओं का सामना कर सकती है। मुख्य बात यह है कि गलतियों को स्वीकार करना, निष्कर्ष निकालना और उपाय करना ताकि भविष्य में फिर से ऐसा न हो।
और आपके विकास अभ्यास में, विफलताएं हुईं और आपने उनके साथ कैसे व्यवहार किया? अपने अनुभव के बारे में हमें कमेंट में बताएं।

Ekaterina Hindikainen, लीड सिस्टम विश्लेषक, रूकी सेवा द्वारा पोस्ट किया गया