विकास में निरंतर डिजाइन: कार्यप्रणाली और सिद्धांत

व्यवहार में, ऐसा होता है कि आपने एक उत्पाद विकसित किया है, और लॉन्च के बाद, ग्राहक इसका उपयोग नहीं करते हैं। फिर यह पता चला कि उपयोगकर्ता के कार्य अलग-अलग हैं, और वे योजनाबद्ध उत्पाद विकास और परियोजना के आपके दृष्टिकोण के लिए काउंटर चलाते हैं। क्यों?

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

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

प्रिय और संदिग्ध आईटी अराजकता

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

एक ज्वलंत प्रमाण मोबाइल विकास बाजार है, जिसमें औसत दर्जे के संकेतक हैं। हालांकि सर्वोत्तम प्रथाएं यहां केंद्रित हैं, आंकड़े वांछित होने के लिए बहुत कुछ छोड़ देते हैं: 2017 में, एनालिटिकल कंपनी लोकलिटिक्स ने एक एसक्यूएल अध्ययन प्रकाशित किया, जिसमें से यह माना जाता है कि 24% एप्लिकेशन केवल एक बार उपयोगकर्ताओं द्वारा खोले जाते हैं।

यह इस तथ्य को ध्यान में रख रहा है कि 10 बार से कम एप्लिकेशन खोलने वाले उपयोगकर्ताओं का प्रतिशत 63% से अधिक नहीं है । यदि हम आँकड़ों की "स्थिरता" को ध्यान में रखते हैं, तो यह स्पष्ट हो जाता है कि इससे कोई निष्कर्ष नहीं निकाला गया है। लोग जानते हैं कि कैसे विकास करना है, लेकिन वे इस पहलू को याद करते हैं कि उत्पाद किसी व्यक्ति के जीवन में कैसे प्रवेश करता है, अर्थात वे मानव-केंद्रित मॉडल का उपयोग नहीं करते हैं। उत्तरार्द्ध में ग्राहक के साथ दीर्घकालिक बातचीत शामिल है; आमतौर पर कई वर्षों के लिए।

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

संचालन और डिजाइन से परिचयात्मक

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

डिज़ाइन वह सब है जो उपभोक्ता के लिए उत्पाद पैक करने के कार्यों, निर्माण विधियों और तरीकों को परिभाषित करने में शामिल है। आमतौर पर हम किसी समस्या के समाधान के रूप में डिजाइन का रुख करते हैं। यदि हम समस्या का सार समझते हैं, तो हम सही समाधान की पेशकश कर सकते हैं।

यह एक पारंपरिक दृष्टिकोण है।

4 परिस्थितियां जो पारंपरिक दृष्टिकोण को ध्यान में नहीं रखती हैं

लेकिन जब डिजाइन और संचालन को मिलाते हैं, तो 4 कारक सामने आते हैं जो पहले टीमों के लिए अलग से काम करते थे। और इन पहलुओं के लिए, निरंतर डिजाइन समाधान बन जाता है:

# 1 समस्या को पूरी तरह से समझा नहीं जा सकता है।

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

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

# २ उत्पाद उपभोक्ता को बदलता है

उत्पाद के साथ सक्रिय अनुभव उपयोगकर्ता को बदलता है। और यह उस समस्या को बदल देता है जो उत्पाद हल करता है, जो आपके और ग्राहक के लिए नई कठिनाइयों का निर्माण करता है।

याद रखें कि हमने 5-6 साल पहले एक टैक्सी का आदेश कैसे दिया: तार के दूसरे छोर पर ऑपरेटर ने आदेश को स्वीकार किया और कहा कि कार को 20-30 मिनट में सेवा दी जाएगी। और हम इंतजार करने के लिए तैयार थे। Uber, Gett और Yandex.Taxi जैसी सेवाओं के लॉन्च के साथ, हमारी धारणा बदल गई है: 2018 में, कार देने के लिए इष्टतम समय हमारे लिए 2-3 मिनट है। यदि हम अधिक समय तक प्रतीक्षा करते हैं, तो यह कष्टप्रद होने लगता है। और बात डिजिटलाइजेशन या ऑबेराइजेशन में नहीं है, बल्कि हमारे उपभोग मॉडल को बदलने में है।

# 3 मूल्य एक साथ बनाई गई चीज है

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

AppStore को याद करें, जो Apple के मूल्य की धारणा के विपरीत दिखाई दिया। 2007 में, स्टीव जॉब्स ने आईफोन को शब्दों के साथ प्रस्तुत किया: “आपको प्रोग्राम लिखने की आवश्यकता नहीं है। यह बेकार है: आपके पास html5 है। " यह उपयोगकर्ताओं को रोक नहीं पाया: उन्होंने उपकरणों को हैक किया और अपने सॉफ्टवेयर को लिखा, सिडिया सॉफ्टवेयर एप्लिकेशन के माध्यम से वितरित किया गया। यह मार्च 2008 में शुरू किया गया था, और पहले से ही उसी वर्ष 10 जून को, क्यूपर्टिनो के लोगों ने सफल अनुभव अपनाया और ऐपस्टोर को लॉन्च किया, स्थिति को अपने पक्ष में बदल दिया और मोबाइल बाजार पर खिलाड़ी नंबर 1 बन गया।

यह थीसिस हमें इस निष्कर्ष पर पहुंचाती है कि डेवलपर और उपभोक्ता समस्या और समाधान का हिस्सा हैं।

# ४ नियंत्रण खत्म करने में कठिनाई

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

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

डिजिटलाइजेशन सॉफ्टवेयर

आइपॉड के विकास को देखो

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

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

ब्रांड वादे से दूर संवाद की ओर बढ़ता है

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

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

आईटी निरंतर संवाद का वातावरण बन जाता है

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

सतत डिजाइन प्रतिमान

और डिजाइन के लिए आकर्षक संवाद बनने के लिए, 4 सिफारिशें हैं:

# 1 संपर्क के बिंदुओं पर ग्राहक-कर्मचारी की सहभागिता डिज़ाइन करें

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

# २ विलंब को कम करें, फीडबैक अधिकतम करें

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

# 3 कीड़े के लिए डिजाइन। पढ़ाई करते हैं

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

अंत में, बग्स के साथ काम करने की संस्कृति और इसे बनाने वाले उपकरण बनते हैं: जैसे कि कैओस बंदर या ब्लेमलेस पोस्ट मॉर्टम।

# ४ "किया" की अवधारणा मौजूद नहीं है

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

निरंतर डिजाइन प्रतिमान में काम करना आपको गलतियों का तुरंत जवाब देना सिखाता है, इससे संबंधित होना आसान है और बेकार काम नहीं करना है। इसका लाभ यह है कि कदम दर कदम, अधिक से अधिक ग्राहक कार्य बंद हो जाते हैं, जो अतिरिक्त लाभ लाता है और व्यापार पर लाभकारी प्रभाव डालता है।

ps इस सामग्री का लेखन जेफ सेस्ना के प्रदर्शन से प्रेरित था।