एक डेवलपर के रूप में, केवल सुविधाओं और उत्पादों का निर्माण शुरू करना आकर्षक हो सकता है। हालांकि, इससे पहले कि आप चीजों को कीबोर्ड पर ले जाएं, आपको इस बारे में सोचना चाहिए कि आपके उपयोगकर्ताओं को क्या चाहिए। क्या आपके पास उपयोगकर्ता की जरूरतों और दर्द बिंदुओं को समझने और प्राथमिकता देने की कोई प्रक्रिया है? उपयोगकर्ता फ़ीडबैक और उपयोगिता परीक्षण के आधार पर आप अपनी उत्पाद सुविधाओं को कैसे पिवट या पुनरावृत्त कर सकते हैं?
In ये बातएनालिटिक हेल्थ में डेटा साइंस के प्रमुख वीरले ने साझा किया कि उपयोगकर्ता केंद्रित डिजाइन के नजरिए से स्क्रैच से सॉफ्टवेयर कैसे बनाया जाए। पहले सेक्शन में टाइमस्टैम्प और दूसरे सेक्शन में ट्रांसक्रिप्शन के साथ इवेंट वीडियो ढूंढें।
[[टीओसी]]
आभासी घटना रिकॉर्डिंग
@खरोंच से सॉफ्टवेयर का निर्माण, उपयोगकर्ता केंद्रित दृष्टिकोण
- 02: 15 परिचय
- 04:54 फुर्तीली सॉफ्टवेयर विकास प्रक्रिया
- 11:07 उपयोगकर्ता-केंद्रित डिज़ाइन (यूसीडी)
- 22:44 सॉफ्टवेयर विकास के साथ चुनौतियां
- 32:18 स्पीकर का अनुभव और टिप्स
- 44:26 रैप अप
- 46:33 प्रश्न?
इवेंट ब्लॉग और ट्रांसक्रिप्शन
मेजबान: हम शुरुआत कर सकते हैं। सभी को नमस्कार, कोडमेंटर इवेंट्स में आपका स्वागत है। आप में से जो दूसरे कार्यक्रम में हमारे साथ शामिल हो रहे हैं, उनका फिर से स्वागत है। मेरा नाम मैगी है। आज फिर शामिल होने के लिए धन्यवाद। आप सभी का यहां हमारे साथ होना वास्तव में बहुत अच्छा है, और मैं अपने स्पीकर वीरले के साथ यहां आकर, उनकी बात सुनने, उनके अनुभव के बारे में और अधिक साझा करने, स्क्रैच से सॉफ्टवेयर बनाने और उपयोगकर्ता केंद्रित दृष्टिकोण के लिए वास्तव में उत्साहित हूं।
यदि पूरे आयोजन के दौरान आपके कोई प्रश्न हैं, तो बेझिझक एक आभासी हाथ उठाएं, उसे बताएं। वैकल्पिक रूप से, आप उन्हें सीधे चैट में भी टाइप कर सकते हैं और हम यह सुनिश्चित करेंगे कि हम अंत में प्रश्नोत्तर अनुभाग में उनमें से अधिक से अधिक तक पहुंचें। वीरले, मंच सब तुम्हारा है।
वीरले: हेलो सब लोग। मेरा स्वागत करने के लिए धन्यवाद मैगी। मैं आज आपको उपयोगकर्ता केंद्रित दृष्टिकोण से सॉफ्टवेयर बनाने के बारे में कुछ बताने जा रहा हूं। मुझे अपनी स्क्रीन साझा करने दें और अपनी प्रस्तुति को ऊपर खींचें।
जैसा कि मैगी ने कहा, और चैट में कहा गया है, यदि कोई प्रश्न हैं, तो बस अपना हाथ उठाएं और बेझिझक मुझे बीच में रोकें और मैं सीधे प्रश्न का उत्तर दूंगा। प्रस्तुति के बाद, हमारे पास एक प्रश्नोत्तर सत्र भी होगा। इसलिए यदि आप चैट के माध्यम से अपने प्रश्न पूछते हैं, तो हम उनका उत्तर बाद में देंगे।
वीरले: तो, आज, खरोंच से सॉफ्टवेयर का निर्माण - उपयोगकर्ता केंद्रित दृष्टिकोण। आज हम वास्तव में किस बारे में बात करने जा रहे हैं? सबसे पहले, मैं एक संक्षिप्त परिचय दूंगा। आप जानते हैं कि कौन बात कर रहा है, मेरी कंपनी के बारे में और भी कुछ और फिर हम एक चुस्त सॉफ्टवेयर विकास प्रक्रिया में जाएंगे और यह कैसा दिखता है। फिर हम उन चुनौतियों के बारे में बात करेंगे जो आपके सॉफ़्टवेयर बनाते समय अक्सर आती हैं। फिर मैं अपने अनुभवों और सीखों के बारे में बात करूंगा जो मुझे लगा कि हमारी अपनी कंपनी में है। मैं एक त्वरित रैप-अप करूंगा। और फिर जैसा कि मैंने कहा, प्रश्नोत्तर अनुभाग में, मैं आपके सभी प्रश्नों का उत्तर दूंगा। इस प्रेजेंटेशन के बाद मैं आपके साथ प्रेजेंटेशन स्लाइड्स भी शेयर करूंगा। इसलिए यदि ऐसा कुछ है जिसे आप नोट करना चाहते हैं, तो ध्यान रखें कि मैं बाद में सब कुछ साझा करूंगा।
परिचय
वीरले: तो मैं कौन हूँ? मैं वीरले हूँ। मैं आज नीदरलैंड से कॉल कर रहा हूं। मैं वहां रहता हूं और मैंने 2015 में डिल्बर्ट विश्वविद्यालय से डेटा वैज्ञानिक के रूप में स्नातक किया है। उसके बाद, मैंने विभिन्न कंपनियों में डेटा साइंटिस्ट के रूप में काम करना शुरू किया। मैंने एक बड़ी ऊर्जा कंपनी में काम किया। वह मेरा पहला काम था। और फिर 2018 में, मैं डेटा साइंटिस्ट के रूप में हेल्थकेयर सेक्टर या फार्मास्युटिकल सेक्टर में आ गया।
जब मैं वहां काम कर रहा था, तो मुझे अपनी खुद की कंपनी शुरू करने का विचार आया। इसलिए मैंने अपना खुद का व्यवसाय, हाइपब्राइट स्थापित किया, और मैंने वहां कुछ डेटा साइंस कंसल्टेंसी की। और उस दौरान मैं अपने वर्तमान व्यापार भागीदार, ग्रेग से मिला, जिसके साथ मैं अब Analytics स्वास्थ्य चला रहा हूं। मैं एक डेवलपर हूं। मैं मुख्य रूप से आर और शाइनी में विकसित होता हूं, लेकिन नोड और वीयू में भी।
यह मेरा एक बुनियादी त्वरित अवलोकन है। फिर हमारी कंपनी के बारे में थोड़ा और। इसलिए मेरे बिजनेस पार्टनर, ग्रेग और हमारे संचालन प्रमुख, जन के साथ, हम उपकरण विकसित करते हैं और वेब अनुप्रयोग स्वास्थ्य सेवा क्षेत्र के लिए। इसलिए हम डेटा से मूल्य प्राप्त करने के लिए स्वास्थ्य देखभाल डेटा एकत्र और विश्लेषण करते हैं, क्योंकि हमारा मानना है कि हम उच्च गुणवत्ता वाले डेटा स्रोतों तक पहुंच प्रदान करके स्वास्थ्य सेवा में नवाचार को गति दे सकते हैं। और स्वास्थ्य पेशेवरों को डेटा का विश्लेषण करने के लिए आवश्यक उपकरण प्रदान करके। हम खुले स्रोत डेटा स्रोतों के माध्यम से दैनिक आधार पर यूके से स्वास्थ्य संबंधी डेटा एकत्र करते हैं। और हम दवा कंपनियों के आंतरिक बिक्री डेटा का भी उपयोग करते हैं। हमारे द्वारा विकसित किए जाने वाले अधिकांश उपकरण R में विकसित किए गए हैं, उदाहरण के लिए, हमारे पास चमकदार अनुप्रयोग हैं, और हमारे पास API हैं जो R के भीतर भी हैं। इसके अलावा हमारे पास Node और Vue में अनुप्रयोग हैं।
वीरले: जैसा कि आप देख सकते हैं, हमारे पास तीन प्रकार के अनुप्रयोग हैं। हमारे पास Pharmly Analytics और Pharmly Cloud Data है, और फिर हमारे पास Pharmly पोर्टल है। Pharmly Cloud Data स्वास्थ्य देखभाल डेटा के लिए हमारा बाज़ार है, इसलिए यह वह स्थान है जहाँ आप यूके में अपने सभी उच्च गुणवत्ता वाले स्वास्थ्य देखभाल डेटा स्रोतों तक पहुँच प्राप्त कर सकते हैं। अब Pharmly Analytics उस डेटा के शीर्ष पर बनाया गया एक एप्लिकेशन है जो आपको वास्तव में डेटा अंतर्दृष्टि प्रदान करता है और Pharmly पोर्टल वह स्थान है जहां वे सभी एप्लिकेशन मूल रूप से एक साथ आते हैं। यह मूल रूप से हमारा होमपेज है, यह हमारे फार्मली नए उत्पादों में सबसे ऊपर है, हमने अपने कुछ ग्राहकों के लिए कुछ समर्पित एप्लिकेशन भी विकसित किए हैं, जो मुख्य रूप से फार्मास्युटिकल कंपनियां हैं।
चुस्त सॉफ्टवेयर विकास प्रक्रिया
आइए शुरू करते हैं चुस्त विकास प्रक्रिया. तो आप उपयोगकर्ता केंद्रित दृष्टिकोण का उपयोग करके सॉफ़्टवेयर कैसे बनाते हैं? और अब पहला सवाल जो दिमाग में आता है, हमें शुरू करने के लिए एक प्रक्रिया की आवश्यकता क्यों है? क्योंकि हम सिर्फ सॉफ्टवेयर बना सकते हैं, है ना? हम बस कूद सकते हैं, कोड करना शुरू कर सकते हैं और सुविधाओं का निर्माण कर सकते हैं, लेकिन हमें एक प्रक्रिया की आवश्यकता है क्योंकि यह प्रक्रिया आपको डेवलपर्स, आपकी टीम के सदस्यों, आपके हितधारकों या आपके उपयोगकर्ताओं के बीच अपेक्षाओं को संरेखित करने में मदद करती है, लेकिन यह आपको औपचारिक बनाने में भी मदद करती है कि आप कैसे हैं नए अनुरोधों या बगों या नए विचारों से निपटना चाहिए।
यदि आपके पास कोई प्रक्रिया या योजना है, तो यह अंत में अनावश्यक पुनर्विक्रय को रोकेगी। इसके अलावा यह आपको बजट के भीतर रहने में मदद करता है और जाहिर तौर पर एक प्रक्रिया आपको योजना बनाने में मदद करती है। इसलिए मुझे लगता है कि यदि आप अपना सॉफ़्टवेयर बना रहे हैं तो एक प्रक्रिया का होना वास्तव में एक अच्छा विचार है।
और फिर सवाल, हम एक डेवलपर के रूप में क्यों परवाह करते हैं?
वीरले: हम ऐसी प्रक्रिया की परवाह क्यों करते हैं? हम उपयोगकर्ता केंद्रित होने की परवाह क्यों करते हैं? क्योंकि आखिरकार, हम केवल एक ही काम करते हैं, वह है कोडिंग, है ना? लेकिन, संदर्भ के आधार पर, आप एक डेवलपर के रूप में वास्तव में प्रक्रिया के सभी भागों में शामिल हो सकते हैं। तो आप एक टीम का हिस्सा बन सकते हैं जैसे 20 डेवलपर्स और कुछ यूएक्स डिजाइनर और दर्जनों प्रोजेक्ट मैनेजर और वह सब। तब आपकी भूमिका स्पष्ट रूप से एक भूमिका से बहुत अलग होगी, उदाहरण के लिए, हमारी कंपनी में जहां हमारे पास केवल 1-3 डेवलपर्स की एक छोटी विकास टीम है जिसमें आप उपयोगकर्ता के बहुत करीब हैं। इसलिए एक डेवलपर के रूप में, आप जिस व्यवसाय में हैं, उसके आधार पर, आप प्रक्रिया के विभिन्न भागों में शामिल हो सकते हैं।
इसके अलावा, यदि आप प्रक्रिया के बारे में जानते हैं, और यदि आप प्रक्रिया को समझते हैं, तो रास्ते में कुछ निर्णय बदलने पर आप कम निराश भी महसूस कर सकते हैं। मुझे लगता है कि हम सभी इस भावना को पहचानते हैं कि हमने कुछ विकसित किया है, और फिर दो सप्ताह बाद इसे बदलने की जरूरत है। आप जानते हैं, आपने कुछ बनाया है, आपने उसमें प्रयास किया है। और फिर कुछ हफ़्ते बाद, फिर सब कुछ 180 डिग्री अलग होना चाहिए। यह बहुत निराशाजनक है। और विशेष रूप से यदि आप नहीं जानते कि यह कहां से आ रहा है, तो यह आपको यह समझने में मदद नहीं करता है कि आपको इसे बदलने की आवश्यकता क्यों है। तो इस प्रक्रिया में शामिल होने से आपको बड़ी तस्वीर दिखाई देती है। यह आपको समझ में आता है कि आप चीजें क्यों कर रहे थे। और आप एक निश्चित तरीके से क्यों विकास कर रहे हैं।
वीरले: तब मुझे लगता है कि आप हमेशा एक टीम के रूप में सॉफ्टवेयर वितरित करते हैं। कोई फर्क नहीं पड़ता कि वह टीम कितनी छोटी या बड़ी है, आप एक साथ एक उत्पाद बना रहे हैं। इसलिए मुझे लगता है कि यह उचित से अधिक है कि आप इस प्रक्रिया में निवेशित हैं। उस सॉफ्टवेयर उत्पाद को बनाने के लिए पूरी टीम जा रही है। और यह न केवल आपके बड़े सॉफ्टवेयर प्रोजेक्ट्स के लिए महत्वपूर्ण है या केवल जब आप किसी कंपनी में काम कर रहे हैं, बल्कि आपकी साइड प्रोजेक्ट्स को भी उचित दृष्टिकोण से फायदा हो सकता है क्योंकि आपके साइड प्रोजेक्ट्स को भी आप इस तरह से प्रबंधित कर सकते हैं कि आप डिलीवर कर सकें उन उत्पादों के अंत में जिनसे आपके उपयोगकर्ता खुश हैं।
मुझे नहीं लगता कि मैंने अभी तक उल्लेख किया है, लेकिन मैं खुद एक स्क्रम मास्टर हूं। इसलिए मुझे चुस्त कार्यप्रणाली के साथ बहुत अनुभव है और मैं ईमानदारी से इसे पसंद करता हूं और हम अपनी परियोजनाओं को कारगर बनाने के लिए इस इंटरकंपनी का उपयोग करते हैं और यदि आप सॉफ्टवेयर विकसित कर रहे हैं तो मैं निश्चित रूप से इसकी भी सिफारिश करूंगा।
वीरले: तो यह क्या है? यदि हम देख रहे हैं कि फुर्तीली सॉफ्टवेयर विकास क्या है, तो हम मूल रूप से आपके द्वारा किए जा रहे छोटे चक्रों या छोटे पुनरावृत्तियों के बारे में बात कर रहे हैं। उदाहरण के लिए, आप यहां स्क्रीन पर ऐसा पुनरावृत्ति देखते हैं। आप योजना बनाकर एक पुनरावृत्ति शुरू करते हैं और मूल रूप से यह पता लगाते हैं कि आवश्यकताएं क्या हैं। फिर आप उस फीचर को डिजाइन करना शुरू करते हैं। फिर आप कोडिंग शुरू करते हैं। फिर आप रिलीज करते हैं, आपको इस फीचर के बारे में फीडबैक मिलता है और आप यह सब फिर से करते हैं। तो छोटे पुनरावृत्तियों का यह निरंतर लूप, आम तौर पर एक चक्र में दो सप्ताह या कुछ और लगते हैं। पुनरावृत्तियों का यह छोटा लूप आपको मूल रूप से आपके उपयोगकर्ताओं और आपके हितधारकों के लिए शामिल रखता है। और यह एक शानदार तरीका है, और मूर्त सॉफ़्टवेयर प्रदान करने का एक कुशल तरीका है, जैसे कि जल्दी। क्योंकि हर दो सप्ताह में आप कुछ रिलीज करने का लक्ष्य रखते हैं, भले ही यह एक छोटे बटन की तरह हो या यह आपके ऐप की शैली में बदलाव हो या जो कुछ भी आप जितनी जल्दी हो सके रिलीज करना चाहते हैं ताकि उसकी प्रतिक्रिया प्राप्त हो सके। और यह बहुत महत्वपूर्ण है यदि आप एक उपयोगकर्ता केंद्रित सॉफ्टवेयर विकसित कर रहे हैं।
हमें चुस्त रहने की आवश्यकता क्यों है?
वीरले: जैसा कि मैंने कहा, यह जल्द से जल्द मूर्त सॉफ्टवेयर प्रदान करने का एक प्रभावी तरीका है। हर दो हफ्ते की तरह या कुछ सामान्य जैसा है। क्योंकि आप इन छोटे पुनरावृत्तियों में काम करना पसंद कर रहे हैं, जैसे हर दो सप्ताह में लगातार प्रतिक्रिया एकत्र करना, आप उपयोगकर्ता की बदलती आवश्यकताओं पर भी जल्दी से कूदने में सक्षम हैं।
और मुझे लगता है कि इस प्रकार के चक्र और उपकरण होने से आपको बहुत अधिक पारदर्शिता और निरंतर प्रतिक्रिया मिलती है, जिससे आप अपने उत्पादों में सुधार कर सकते हैं। इसके अलावा आम तौर पर इतनी साफ-सुथरी अवधि में, क्योंकि आप प्रतिक्रिया एकत्र कर रहे हैं, आप वास्तव में अपने हितधारकों और अपने उपयोगकर्ताओं के साथ जुड़ रहे हैं क्योंकि यदि आप इसे पसंद करते हैं तो आपको सॉफ़्टवेयर का परीक्षण करने की आवश्यकता है।
तो वहाँ उच्च भागीदारी है। यह उम्मीदों के लिए भी बहुत अच्छा है क्योंकि आम तौर पर, आप जानते हैं, वास्तव में, अगले दो हफ्तों में, हम यह और वह करने जा रहे हैं। और फिर आपके हितधारकों को पता है, इन दो हफ्तों के अंत में, मैं उम्मीद कर सकता हूं कि यह बटन यहां या वहां होगा जहां ये कार्यक्षमता मौजूद होगी।
वीरले: और मुझे लगता है कि बड़ी परियोजनाओं की तुलना में इस प्रकार के छोटे चक्रों में काम करना कम कठिन है। क्योंकि अगर आपके पास कोई बड़ा प्रोजेक्ट है और मान लीजिए, इस प्रोजेक्ट में आठ महीने लगेंगे, तो जाओ इसे करो, मज़े करो। मेरा मतलब है, मुझे लगता है कि यह काफी कठिन है अगर आप कहते हैं, ठीक है, आठ महीने, मुझे क्या करने की ज़रूरत है? मैं इसे कैसे व्यवस्थित करने जा रहा हूं? इसलिए इसे छोटे-छोटे टुकड़ों में काट लें। फिर चुस्त होने के बगल में। यह दूसरा सिद्धांत है कि यदि आप इसमें थोड़ा सा भी शामिल हैं, तो आप वास्तव में जानेंगे और हम इसे उपयोगकर्ता केंद्रित डिज़ाइन कहते हैं। उपयोगकर्ता केंद्रित डिजाइन चुस्त के बगल में एक अन्य पद्धति की तरह है, जो यहां इसके अनुपात के बारे में भी है।
केवल ध्यान वास्तव में उपयोगकर्ता पर है और यह आपकी सुविधाओं और कार्यक्षमता को डिजाइन करने के बारे में है ताकि यह मूल रूप से उपयोगकर्ताओं को यथासंभव सर्वोत्तम रूप से फिट कर सके। तो सबसे पहले आप देखेंगे, ठीक है, मेरे उपयोगकर्ता को क्या चाहिए? आप उनके साथ सहानुभूति रखने की कोशिश करते हैं और आप एक विशेषता या कार्यक्षमता की आवश्यकताओं की तरह परिभाषित करने जा रहे हैं जो वे इसके बारे में विचार करने या विचार करने जा रहे हैं।
यह मंथन है, फिर आप एक प्रोटोटाइप बना रहे हैं और फिर आप इसका परीक्षण करने जा रहे हैं। यह उपयोगकर्ता केंद्रित डिजाइन सिद्धांत अभी तक कोडिंग के बारे में नहीं है, लेकिन यह इस तरह है, क्या यह भविष्य है, यह मेरे उपयोगकर्ता के लिए कैसे काम करेगा? क्या वे इसे पसंद करेंगे? और मैं सबसे अच्छा डिजाइन कैसे कर सकता हूं? यहां फोकस अलग है।
उपयोगकर्ता केंद्रित डिजाइन (यूसीडी)
वीरले: हमें यूसीडी या उपयोगकर्ता केंद्रित डिज़ाइन जैसी किसी चीज़ की आवश्यकता क्यों होगी? ठीक है, क्योंकि यह मूल रूप से एक तंत्र प्रदान करके अनुमान को कम करता है जिसके खिलाफ डिजाइन निर्णय उम्र में पाए जा सकते हैं, ऐसा इसलिए है क्योंकि आप लगातार डिजाइन के साथ आ रहे हैं, जिसे आप इसे अपने उपयोगकर्ताओं के पास वापस ले जाएंगे ताकि आपके उपयोगकर्ता वास्तव में कर सकें समझना। या आप समझ सकते हैं कि आपके यूजर्स इसे पसंद करने वाले हैं या नहीं। तो अंत में, एक यूसीबी आपको एक अधिक उपयोगी और सार्थक उत्पाद प्रदान करता है। और ऐसा इसलिए है क्योंकि आपने वह सब परीक्षण किया और वह प्रतिक्रिया प्राप्त की। तो यह भी कम से कम जहां आप काम करते हैं। क्योंकि यदि आप जानते हैं कि आपके उपयोगकर्ता फीचर के बारे में क्या सोचेंगे, तो जाहिर है कि आपकी प्रतिक्रिया उम्मीद के मुताबिक होगी, वाह, यह बहुत अच्छा है। यह आपको कुछ काम बचाता है। यह गुणवत्तापूर्ण अनुभव प्रदान करने का एक तरीका प्रदान करता है। तो फिर हमने चुस्त और इस उपयोगकर्ता केंद्रित डिजाइन के बारे में बात की।
क्या फर्क पड़ता है? क्या चुस्त होना वास्तव में उपयोगकर्ता केंद्रित है?
वीरले: ईमानदारी से, हम चुस्त और यूसीडी के बीच इस पूरी चर्चा के बारे में बात करते हैं। लेकिन आज मैं आपको जो बताना चाहता हूं, वह यह है कि यदि आप उन दो दर्शनों को देखते हैं, जिन्हें आप फुर्ती से देखेंगे, तो यह सुनिश्चित करने के लिए कि आप संतुष्ट ग्राहक हैं, सामान को जल्दी से जारी करने पर ध्यान केंद्रित है और इसका यूसीडी इक्विटी बैलेंस होगा जैसे, ठीक है, हमें अपने अंतिम उपयोगकर्ताओं को बनाने या उनके बारे में सोचने की आवश्यकता है।
हमें यह सुनिश्चित करने की आवश्यकता है कि हमारे उत्पादों का उपयोग करते समय उनके पास सर्वोत्तम संभव अनुभव हो। और मुझे लगता है कि यदि आप दोनों को जोड़ सकते हैं, यदि आप चुस्त होने की पद्धति को जोड़ सकते हैं, जैसे कि लगातार प्रतिक्रिया जारी करना, मूर्त आत्म पर ध्यान केंद्रित करना। और अगर आप यूसीबी को ओके पर अत्यधिक फोकस के साथ जोड़ सकते हैं, तो जो कुछ भी मैं डिजाइन करता हूं वह मेरे उपयोगकर्ताओं के लिए सही होना चाहिए, क्योंकि वे उत्पाद का उपयोग करने जा रहे हैं।
मुझे लगता है कि अगर आप दोनों को एक कर रहे हैं, तो यह अच्छा है। और मैं यह भी उल्लेख करना चाहता हूं कि, इन दर्शनों के साथ सबसे आश्चर्यजनक बात, आपको उन्हें स्थिर देखने की आवश्यकता नहीं है। जैसे अगर फुर्तीली आपको चरण एक, दो और तीन करने के लिए कहती है, तो इसका मतलब यह नहीं है कि आपको इसे पूरी तरह से 100% पालन करने की आवश्यकता है।
यूसीबी के लिए भी यही है। आप इन सभी चरणों का पूरी तरह से पालन कर सकते हैं और अपने आप को पूरी तरह से कार्यप्रणाली में डाल सकते हैं, लेकिन यह मदद नहीं करता है। यह इसके पीछे की सोच के बारे में अधिक है। और केवल एक चीज जो चुस्त विकास चाहता है वह यह सुनिश्चित करना है कि आप अपने उपयोगकर्ता के करीब हैं, वास्तविकता के करीब हैं।
वीरले: इन छोटे चक्रों के द्वारा, मैं प्रतिक्रिया माँगने गया हूँ और यह केवल आपके दिमाग को रखने के लिए है ताकि आप दोनों को जोड़ सकें। इसलिए मैं हमेशा कहता हूं कि आपके पास यह चुस्त यूसीडी प्रक्रिया है जिसका आप अनुसरण कर सकते हैं। और यह सिर्फ प्रक्रिया है। और जैसा कि मैंने कहा, यह न देखें कि यह 100% तय है, लेकिन यह वह प्रक्रिया है जिसका आप वास्तव में स्वयं को जागरूक बनाने के लिए अनुसरण कर सकते हैं।
तो सबसे पहले आप आवश्यकताओं को इकट्ठा करके शुरू करें ताकि आपके पास स्पष्ट समझ हो। शायद यही मेरा उपयोगकर्ता चाहता है। हम यही चाहते हैं, मेरे हितधारक चाहते हैं, इसलिए हमें यही करने की जरूरत है। आपको मूल रूप से आवश्यकताओं का दस्तावेजीकरण करने के लिए खुद को एक मानकीकृत तरीका खोजने की आवश्यकता है ताकि आपकी टीम के सभी लोग यह जान सकें कि वे क्या दिखते हैं।
फिर आप हमेशा चीजों को डिजाइन करने से शुरू करते हैं। इसलिए यदि आपकी कोई आवश्यकता है, तो उस दृश्य का प्रतिनिधित्व करना हमेशा अच्छा होता है कि आवश्यकता क्या है। इसके लिए एक पूर्ण विकसित वायरफ्रेम या पूर्ण विकसित वर्कअप होने की आवश्यकता नहीं है, शायद एक छोटा सा विशेष स्केच भी हम करेंगे। जब तक आपके पास कुछ भी है जिसे आप देख सकते हैं, और इससे आपको उस दिशा में काम करने में मदद मिलेगी जिस पर आप काम कर रहे हैं।
वीरले: और भले ही आपके पास एक स्केच हो, आप उसे अपने उपयोगकर्ताओं के सामने प्रस्तुत कर सकते हैं और कह सकते हैं, अरे, आप उसके बारे में क्या सोचते हैं? आप जानते हैं, खासकर, अगर मैं अपने व्यवसाय के लिए बात कर सकता हूं, तो हमने आपके लिए एक समर्पित सॉफ्टवेयर विकसित किया है। इसलिए हम अपने यूजर्स को अच्छी तरह से जानते हैं। हम उनके साथ हर दो हफ्ते में बात करते हैं, और फिर यह बहुत आसान है।
यदि आपके पास एक स्केच है, भले ही यह उन्हें दिखाने के लिए एक त्वरित स्केच है और फिर देखें, अरे, क्या आप इसे काम करते हुए देखते हैं? या आपको यह पसंद है? और फिर जब आपके पास डिज़ाइन हो, तो आप वास्तव में कोड में खुदाई शुरू कर सकते हैं। तो आप वास्तव में निर्माण शुरू कर सकते हैं और मैं हमेशा वयस्कों को सर्वोत्तम प्रथाओं को कोड करने और आपकी टीम में कोड को सुसंगत बनाने की सलाह दूंगा।
सुनिश्चित करें कि आप जिस भी टीम में हैं, आपको नियमों का एक मानक सेट पसंद है, जिसका आप पालन कर रहे हैं, नामकरण परंपराएं, कोड स्टाइल और उस तरह की चीजें जैसी चीजें हो सकती हैं, लेकिन बस यह सुनिश्चित करें कि यह कोई फर्क नहीं पड़ता यदि व्यक्ति A या व्यक्ति B ने कोड लिखा है, लेकिन आपके पास कोड की एक धारा है।
वीरले: मुझे जेन से एक प्रश्न दिखाई देता है।
जेन: मैं अपने एक सहभागी के लिए अपना हाथ उठा रहा हूँ। तो ह्युंग, आई एम सॉरी। मुझे खेद है कि अगर मैंने आपका नाम गलत बताया, तो क्या आप अपना हाथ उठाना चाहते थे और फिर वीरले से पूछना चाहते थे? क्या कोई उसे अनम्यूट करके देख सकता है, ठीक है। तो, क्या आप मुझे अभी सुन सकते हैं?
सहभागी: हाँ। तो मेरा बस एक सवाल था। मेरा मतलब बाधित करने का नहीं है क्योंकि आप चल रहे हैं, लेकिन मैं अंत में इस बिंदु को याद नहीं करना चाहता था, अगर मैं अंत में गया था। इसलिए मैं सिर्फ आपके उपयोगकर्ता केंद्रित डिजाइन की जांच करना चाहता हूं, जो कि पूर्ण विकसित चक्र करने से पहले फीडबैक के उपयोग के दौरान प्राप्त करने के एक छोटे चक्र की तरह है।
सही? तो, क्या आपके पास अच्छी संख्या में अंतिम उपयोगकर्ताओं के लिए कोई सलाह है? 5 या 30 की तरह? मेरा मतलब है, यह कुछ ऐसा है जिससे मैं भी जूझ रहा हूं क्योंकि मैं खुद एक इंडी डेवलपर हूं। और मैं यह भी देखता हूं कि आपके पास केवल तीन की एक टीम है, इसलिए बहुत से लोगों को इकट्ठा करना तार्किक रूप से बहुत कठिन है। तो क्या आपके पास अंतिम उपयोगकर्ताओं की संख्या के लिए कोई अच्छी सलाह है?
वीरले: हाँ। तो यह भी संदर्भ पर निर्भर करता है। इसलिए, हमारे एप्लिकेशन, उदाहरण के लिए, 100 से कम उपयोगकर्ता हैं। तो इसका मतलब है कि हम 100 लोगों से उनकी प्रतिक्रिया के लिए नहीं पूछने जा रहे हैं। जैसे कि यदि आपके पास हजारों उपयोगकर्ता हैं, तो वह 100 एक उचित संख्या हो सकती है। तो यह इस बात पर निर्भर करता है कि आपका आवेदन कितना बड़ा है, कितने उपयोगकर्ता जारी करते हैं जिन्होंने पूछा कि क्या आप कर सकते हैं।
मैं आपके उपयोगकर्ता आधार के 1-5% की तर्ज पर, ठीक है, कहीं न कहीं लक्ष्य रखूंगा। और फिर नहीं, और आपको यह भी ध्यान से विचार करना चाहिए कि आप किन विशेषताओं के लिए पूर्ण विकसित शोध करने जा रहे हैं, क्योंकि कभी-कभी मौजूदा शोध लेने के लिए यह पर्याप्त हो सकता है। उदाहरण के लिए, यदि आपको बटनों के रंगों के बारे में सोचने की ज़रूरत है या बंद बटनों को कहाँ रखना है और ऐसी ही चीज़ें हैं, तो आप मौजूदा शोध पर भरोसा कर सकते हैं, और अन्यथा केवल वर्तनी, देखें कि आपको बीच संतुलन पसंद करने की ज़रूरत है, ठीक है, क्या यह सुविधा चल रही है वास्तव में बड़ा और वास्तव में महत्वपूर्ण और वास्तव में मौलिक होना? शायद मुझे अपने उपयोगकर्ता आधार का एक बड़ा नमूना पूछना चाहिए, लेकिन यह सब वास्तव में संदर्भ पर निर्भर करता है। क्या यह आपके प्रश्न का थोड़ा सा उत्तर देता है?
सहभागी: हां मुझे लगता है। मैं पूछ रहा हूं क्योंकि, मेरे लिए, मैं Instagram प्रत्यक्ष विपणन द्वारा अंतिम उपयोगकर्ताओं से संपर्क कर रहा हूं, आप जानते हैं, इसलिए कभी-कभी यह बहुत थका देने वाला और समय लेने वाला होता है, लेकिन मुझे लगता है कि यह वास्तव में निर्भर करता है। आपके उत्तर के लिए धन्यवाद।
वीरले: आपका स्वागत है। ठीक। एक अन्य हाथ।
सहभागी: मुझे खेद है, बस उस पर अनुवर्ती कार्रवाई करने के लिए। मुझे पता है कि मैं कोमेन का हिस्सा हूं, लेकिन सिर्फ एक तरह का, आपने कहा, आप जानते हैं, यह वास्तव में सुविधा पर निर्भर करता है और 1-5% की तरह, कार्यप्रणाली के संदर्भ में, क्या आप आमतौर पर उपयोग करते हैं, मान लें कि सर्वेक्षण की तरह है या करते हैं आप इसमें 5% लोगों को पसंद करने के लिए सर्वेक्षण वितरित करते हैं? मुझे नहीं पता, उस से 10% उपयोगकर्ता साक्षात्कार और इस तरह की चीजें करने के लिए।
वीरले: हाँ। इसलिए हम वास्तव में अपने उपयोगकर्ताओं के साथ बहुत भाग्यशाली हैं क्योंकि हमारे उपयोगकर्ता हमारे उत्पादों में बहुत शामिल हैं। हम सीमित संख्या में लोगों के लिए बहुत विशिष्ट उत्पाद विकसित करते हैं। इसलिए हमारे पास उनके साथ बैठकों में जाने, जो हमारे मन में है उसे प्रस्तुत करने और उनकी प्रतिक्रिया एकत्र करने की विलासिता है।
और हमें यह सब फीडबैक उनसे मिलेगा, लेकिन यह एक विलासिता है जो हमारे पास है। उदाहरण के लिए, यदि आपके पास हजारों लोगों के साथ वास्तव में एक बड़ा ऐप है, और वह ऐप स्टोर में उपलब्ध होने जा रहा है, तो यह एक अलग कहानी होगी क्योंकि उस समय लोगों से प्रतिक्रिया एकत्र करना बहुत कठिन है।
लेकिन फिर बड़े दर्शकों के लिए, मैं ए/बी परीक्षण या सर्वेक्षण स्थापित करने जैसा कुछ करूंगा। लेकिन वह, फिर से, वास्तव में संदर्भ पर निर्भर करता है कि आप सबसे अच्छा क्या कर सकते हैं।
वीरले: तो हम कहाँ थे? इसलिए मैं परीक्षण के चरण में था। यदि आपने अपनी विशेषता विकसित की है, तो यह भी स्पष्ट रूप से बहुत महत्वपूर्ण है कि आप इसका परीक्षण करें। क्योंकि आप सब कुछ उत्पादन में जारी नहीं कर सकते हैं और फिर केवल सर्वश्रेष्ठ के लिए आशा करते हैं कि आपको इसका परीक्षण करने की आवश्यकता है। आप देवों के लिए यूनिट परीक्षणों का उपयोग कर सकते हैं, लेकिन केवल कुछ उपयोगकर्ता परीक्षण भी कर सकते हैं। आप इस पर कुछ उपयोगकर्ता प्राप्त कर सकते हैं और कुछ प्रतिक्रिया एकत्र कर सकते हैं।
फिर आप रिलीज कर सकते हैं, लेकिन समझदारी से रिलीज कर सकते हैं क्योंकि ये दो सप्ताह के चक्र वास्तव में जितनी जल्दी हो सके रिलीज करने के उद्देश्य से हैं, आप जानते हैं, इसे जितनी जल्दी हो सके करें, हम अब परिणाम देखना चाहते हैं। लेकिन आपको इसे भी समझदारी से करना चाहिए। इसलिए सुनिश्चित करें कि आप जो कुछ भी जारी करते हैं वह उच्च गुणवत्ता वाला है, क्योंकि आप केवल उपयोगकर्ता केंद्रित सॉफ़्टवेयर उत्पाद वितरित कर सकते हैं, यदि आप उच्च गुणवत्ता वाला उत्पाद भी वितरित करते हैं। इसलिए सुनिश्चित करें कि आप जो कुछ भी जारी करते हैं वह वास्तव में उपयोगकर्ता पर केंद्रित है और उपयोगकर्ता को सर्वोत्तम संभव अनुभव प्रदान करता है।
और फिर स्पष्ट रूप से बहुत महत्वपूर्ण है। प्रतिक्रिया प्राप्त करने के लिए समय निकालें। मैं इन चुस्त कार्यप्रणाली में जो कुछ भी देख रहा हूं वह कहता है, हमारे पास यह विकास चक्र है। हम कुछ सुविधाएँ जारी करते हैं। अब गति के मामले में सप्ताहांत का समय है, लेकिन वास्तव में आपके द्वारा जारी की गई सुविधाओं के बारे में प्रतिक्रिया प्राप्त करने के लिए अपना समय लें ताकि आप उन पर सुधार कर सकें या अपने विकास के बाद के चक्रों में इस प्रतिक्रिया को शामिल कर सकें। तो उसके लिए समय निकालें।
सॉफ्टवेयर विकास के साथ चुनौतियां
वीरले: तो फिर, कुछ चुनौतियाँ जो आपके सामने हैं जैसे सॉफ्टवेयर विकास। उनमें से एक बहुत प्रसिद्ध अवधारणा है जिसे तकनीकी ऋण के रूप में जाना जाता है। इसे डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है। यह सॉफ्टवेयर विकास में एक अवधारणा है जो एक आसान समाधान चुनकर अतिरिक्त पुनर्विक्रय लागत की निहित लागत को दर्शाता है।
अब, एक बेहतर दृष्टिकोण के बजाय, यदि हम लेते हैं। और यह कुछ ऐसा है जो वास्तव में एक जोखिम है जब आप चुस्त विकास कर रहे होते हैं। क्योंकि जैसा कि मैंने कहा, फुर्तीली विकास का लक्ष्य अक्सर जल्द से जल्द जारी करना होता है। इसे जितनी जल्दी हो सके करें। हम उन दो हफ्तों के बाद ठोस परिणाम देखना चाहते हैं, लेकिन अक्सर डेवलपर्स को आसान विकल्प बनाने की ओर ले जाता है।
अंत में आपको इसका पछतावा होगा। क्योंकि यदि आप अभी चुनाव करते हैं और उसके ऊपर निर्माण करते हैं, तो आप अधिक से अधिक ऋणों पर निर्माण कर रहे हैं। और इसे चुकाना बहुत मुश्किल है। तो वार्ड कनिंघम, वह चुस्त घोषणापत्र के लेखकों में से एक है। उन्होंने एक बार कहा था कि कोड के साथ कुछ समस्याएं वित्तीय ऋण की तरह हैं, इसलिए जब तक आप भुगतान करते हैं, तब तक भविष्य के लिए उधार लेना ठीक है। वार्ड ने इस शब्द को एक रूपक के रूप में इस्तेमाल किया और उन्होंने इसे तकनीकी ऋण कहा और तब से गति प्राप्त की है जब से मुझे लगता है कि हर सॉफ्टवेयर डेवलपर इस अवधारणा के बारे में जानता है, और यह आज की दुनिया में अभी भी एक वास्तविक समस्या है क्योंकि हम इसे हर समय देखते हैं।
वीरले: तो क्या वास्तव में इस तकनीकी ऋण का कारण बनता है। ठीक है, उनमें से एक परिभाषा और आवश्यकताओं की तरह है, बहुत तंग समय सीमा, बहुत अधिक दबाव। जैसा कि मैंने कहा, यदि सब कुछ लक्षित और लक्षित है जितनी जल्दी हो सके, आप अधिक आसान समाधानों के लिए जा सकते हैं। और यह किसी कार्य को पूरा करने में लगने वाले समय को भी कम करके आंक रहा है।
क्योंकि यदि आप, विशेष रूप से, यदि आप इन फुर्तीले चक्रों में अग्रिम रूप से काम करते हैं, तो आप इस तरह की योजना बनाते हैं, यह कार्य मुझे ऐसे ही कई घंटे लगने वाला है। और क्या हो रहा है कि हम समय को कम आंकते हैं। और फिर अंत में, आसान समाधान के लिए हमारे द्वारा चुनी गई समय सीमा को प्राप्त करने के लिए कुछ संकट या कुछ तनाव होता है।
यह ज्ञान की कमी और परीक्षण की कमी भी है। तो वास्तव में क्या हैं, यदि आप इन सभी को संक्षेप में प्रस्तुत करते हैं, तो तकनीकी ऋणों के कारण सॉफ्टवेयर विकास प्रक्रिया के लिए हैं। यदि आप सुनिश्चित करते हैं कि आपके पास एक ठोस सॉफ्टवेयर विकास प्रक्रिया है, यदि आप इन सभी चीजों का हिसाब रखते हैं, तो आप तकनीकी ऋण की मात्रा को कम कर सकते हैं।
तकनीकी ऋण, हम सभी ने इसे देखा है। और आपके उत्पाद के शीर्ष पर सुविधाओं को बनाने में आपको केवल अधिक समय लगता है। यह आपके उत्पाद के लिए खतरनाक और हानिकारक है और आपको इसे रोकने की आवश्यकता है। और एक डेवलपर के रूप में, आप इसमें भी भूमिका निभाते हैं। आपकी बाकी टीम को शिक्षित करने की भूमिका है और तकनीकी ऋण के जोखिम को पहचानने की भी आपकी भूमिका है।
स्पीकर अनुभव और सुझाव
वीरले: इसलिए एक डेवलपर के रूप में, यदि आप किसी टीम में काम कर रहे हैं, तो कृपया जागरूक रहें। जब आप चुनाव कर रहे हों, तो अपने लिए सोचें, क्या यह आसान विकल्प है क्योंकि मैं इसे जितनी जल्दी हो सके वितरित करना चाहता हूं? या यह सबसे अच्छा विकल्प है? क्योंकि, फिर से, तकनीकी ऋण, आपके उपयोगकर्ता यह देखने जा रहे हैं क्योंकि यदि आपके उपयोगकर्ता आपके आवेदन के 'वाह' अनुभव की उम्मीद कर रहे हैं, लेकिन यह आपको पसंद है, तो मुझे नहीं पता, इस अतिरिक्त बटन को बनाने में महीनों, क्योंकि आपने एक ढांचा चुना है जो इसके लिए उपयुक्त नहीं है, तो आपके उपयोगकर्ताओं को इससे कोई फायदा नहीं होगा।
फिर एक और चुनौती जो हमारे पास अक्सर होती है जब हम चुस्त सॉफ्टवेयर विकास कर रहे होते हैं, ठीक है, यह सब अच्छा है। और यह सब उपयोगकर्ता केंद्रित दृष्टिकोण और वह कर रहा है जो उपयोगकर्ता चाहता है, लेकिन दुर्भाग्य से उपयोगकर्ता को हमेशा यह नहीं पता होता है कि उसे वास्तव में क्या चाहिए क्योंकि एक है, उपयोगकर्ताओं को क्या चाहिए बनाम उपयोगकर्ताओं को क्या चाहिए?
वीरले: तो एक उपयोगकर्ता कह सकता है, "ओह, मुझे एक्स चाहिए," लेकिन उपयोगकर्ता को एक्स की आवश्यकता नहीं हो सकती है, लेकिन वास्तव में वाई। तो कुछ साल पहले की तरह कल्पना करें, अगर आपको नहीं पता था कि आपको आईफोन की जरूरत है, लेकिन अब हम करते हैं , आप जानते हैं, यह ठीक इसी तरह काम करता है। हम नहीं जानते कि हमें क्या चाहिए और यदि आप सॉफ़्टवेयर बना रहे हैं, तो ठीक है, यह मूल रूप से आपका काम है कि आप इसका पता लगाएं।
आपको यह पता लगाने की कोशिश करने की ज़रूरत है कि उपयोगकर्ता या हितधारक को केवल रास्ते में आइटम वितरित करने के बजाय वास्तव में क्या चाहिए, क्योंकि यह बहुत आसान है, विशेष रूप से व्यावसायिक हितधारक जो उत्पादों के वास्तविक उपयोगकर्ताओं के समान नहीं हो सकते हैं, ठीक है , मुझे यह सुविधा और वह सुविधा और वह सुविधा दें।
और फिर हमारे पास एक अच्छा उत्पाद है। लेकिन हमेशा महत्वपूर्ण विचारक की तरह बनने का प्रयास करें और यह भी पूछें कि क्या यह वास्तव में हमारे उपयोगकर्ता के लिए सबसे अच्छा है। और फिर, यह वापस आता है, यदि आप उपयोगकर्ता-केंद्रित दृष्टिकोण बनाना चाहते हैं, तो आपको अपने उपयोगकर्ता को समझने की आवश्यकता है और आप यह कैसे कर सकते हैं, जबकि आप प्रश्न पूछ सकते हैं। तो वास्तव में आपके अपने प्रश्नों के प्रश्न।
वीरले: ठीक। तो आप यह चाहते हैं, आपके एपिसोड में यह बटन। क्यों, आपको वहां इसकी आवश्यकता क्यों है और यह आपके दैनिक जीवन में आपकी कैसे मदद करेगा? पसंद के बजाय, यदि आप ऑनलाइन किराने का सामान खरीदने के लिए एक ऐप डिज़ाइन कर रहे हैं, तो आप कह सकते हैं, आप किराने का सामान ऑनलाइन क्यों खरीदते हैं, लेकिन आप अन्य प्रश्न भी पूछ सकते हैं, जैसे, ठीक है, जब आप किराने का सामान ऑनलाइन खरीदते हैं तो आप क्या करते हैं?
ऑनलाइन शॉपिंग करने से पहले आप क्या करते हैं? खरीदारी करने के बाद आप क्या करते हैं? किराने का सामान खरीदते समय आपके लिए क्या काम नहीं करता है, या जब आप किराने का सामान लाइन में खरीदते हैं तो आप किसके साथ होते हैं? सलाह के लिए आप किससे सलाह लेते हैं? जैसे आप सभी प्रकार के प्रश्न पूछ सकते हैं कि वास्तव में यह समझने के लिए कि मेरे उपयोगकर्ता को शायद यही चाहिए। सिर्फ एक ऐप बनाने के बजाय जहां वे सिर्फ किराने का सामान खरीद सकते हैं।
फिर एक और चुनौती स्पष्ट रूप से सही ढांचा चुनना है क्योंकि यदि आप एक बड़ी सॉफ्टवेयर विकास परियोजना शुरू करते हैं, तो शुरुआती चरणों में, आपको पहले से ही ढांचे के लिए और यहां कौन सा ढांचा चुनना होगा।
मेरा मतलब है, क्या आप Vue के लिए जा रहे हैं या आप React के लिए जा रहे हैं? क्या आप एक चमकदार आवेदन के लिए जा रहे हैं? बहुत सारे ढांचे हैं जिन्हें आप चुन सकते हैं। तो आपको वास्तव में क्या चुनना चाहिए? क्योंकि यह अंत में आपके तकनीकी ऋण को भी निर्धारित करने वाला है। क्योंकि यदि आप शुरुआत में ढांचे को चुनने में गलती करते हैं, तो हो सकता है कि यह सबसे आसान ढांचा है या यह वह ढांचा है जिसके बारे में आपको सबसे ज्यादा जानकारी है। आप कुछ ऐसा निर्माण कर सकते हैं जो आपके लिए उपयुक्त नहीं है। तो जिन चीजों पर आप विचार करना चाहेंगे और उपयोगकर्ता केंद्रित, सॉफ्टवेयर विकास, आपके उपयोगकर्ता में सबसे महत्वपूर्ण बात। कृपया पहले इस बारे में सोचें कि आपके उपयोगकर्ता उत्पादों का उपयोग कैसे करने जा रहे हैं, वे इसे अपने पीसी पर कैसे खोलने जा रहे हैं? वे इसे मोबाइल पर कैसे देखेंगे? और उसके आधार पर, वह ढांचा चुनें जो आवश्यकताओं के अनुकूल हो।
वीरले: उदाहरण के लिए, हमने अपना फार्मली पोर्टल विकसित किया है, जो मूल रूप से सभी प्रकार की चीजों के साथ एक पोर्टल है। छोटे ऐप्स। ऐसा इसलिए है क्योंकि हमारा मॉडल या मूल्य निर्धारण मॉडल कहेगा, ठीक है, उपयोगकर्ता या ग्राहक अलग-अलग मॉड्यूल की तरह चुन सकते हैं। तो वे मॉड्यूल ए, बी और सी से जा सकते हैं, या वे केवल मॉड्यूल ए या केवल सी के लिए जा सकते हैं। तो हमने सोचा, हम सबसे अच्छा कैसे कर सकते हैं, हम कौन सा ढांचा सबसे अच्छा चुन सकते हैं? अंत में, हमने माइक्रोफोन और संरचना को चुना। और इस माइक्रोफ़ोन संरचना के साथ, हमारे पास ये सभी स्वतंत्र ऐप्स हैं, जो मूल रूप से हमारे मॉड्यूल हैं।
और फिर, ये स्टैंडअलोन मिनी ऐप्स की तरह हैं। तो कहने के लिए, और यह हमारे उपयोगकर्ताओं के लिए मूल रूप से एक पैकेज चुनना बहुत आसान बनाता है जिसमें कहने के लिए, मुझे केवल यह टुकड़ा और वह टुकड़ा और वह टुकड़ा चाहिए, और मैं इसे एक्सेस करना चाहता हूं। और इसलिए हमने अपने उपयोगकर्ताओं के साथ जाने के लिए निर्णय लिया।
संरचना, लेकिन आपके लिए, यह पूरी तरह से अलग दिख सकती है क्योंकि यह सब आपके संदर्भ और आपके उपयोगकर्ताओं पर निर्भर करता है। तो अपने उपयोगकर्ताओं के अलावा, आप स्पष्ट रूप से विकास समुदाय पर एक नज़र डालना चाहेंगे। क्या आपके द्वारा चुने जा रहे ढांचे के बारे में बहुत सी बातें हैं? क्या पर्याप्त लोग सक्रिय हैं? अगर मुझे कुछ भी पता नहीं है तो मैं स्टैक ओवरफ़्लो ब्राउज़ करना चाहता हूं।
वीरले: क्या मुझे वास्तव में स्टैक ओवरफ़्लो पर कुछ मिल सकता है? और यह फ्रेमवर्क डेवलपर्स या अन्य डेवलपर्स से समर्थन की तुलना में वास्तव में महत्वपूर्ण है, जाहिर है कि पर्याप्त तकनीकी दस्तावेज जैसी चीजें बनाए रखी जाती हैं। क्या यह समझना आसान है? क्या यह टिकाऊ है? और जाहिर है आपको अपनी टीम को देखने की जरूरत है।
आप एक ऐप बनाना और प्रतिक्रिया देना चाह सकते हैं, लेकिन आपकी टीम में किसी को भी कर्ज के बारे में पता नहीं है। फिर वह भी आपके लिए एक और ठोस विकल्प है, है ना? तो यह सब बीच संतुलन है, जबकि नापसंद है। और आज के देव समुदाय में कला ढांचे की वर्तमान स्थिति बनाम मेरे उपयोगकर्ता क्या चाहते हैं और उनके लिए सबसे उपयुक्त क्या है बनाम मैं प्रत्येक के लिए क्या कर सकता हूं?
क्या मेरे पास संसाधन नामकरण कौशल है?
हाँ। फिर मैं हमारी सीख पर आता हूं क्योंकि आपकी अपनी कंपनी होने से आप बहुत कुछ सीखते हैं। हम आपको वह बता सकते हैं। हमने सॉफ्टवेयर विकसित करने से बहुत कुछ सीखा है। हमने गलतियां करके बहुत कुछ सीखा है। हम अभी भी बहुत कुछ सीख रहे हैं और मैं बस इसी तरह की सीखों को आपके और अपने अनुभवों के साथ साझा करना चाहता हूं, ताकि आप भी इससे लाभान्वित हो सकें।
वीरले: पहला सवाल है, ठीक है, हम एक छोटी टीम हैं। हां, हम एक छोटी टीम हैं। तो क्या हम चुस्त विकास कर सकते हैं? और हाँ, आप कर सकते हैं। मेरा मतलब है, 10 या 50 लोगों की एक टीम बनने के लिए एक चुस्त कार्यप्रणाली या एक चुस्त तरीके से लागू करने के लिए आप किसी भी आकार के साथ हो सकते हैं। और जैसा कि मैंने पहले कहा था, आप अपने विशिष्ट वातावरण के लिए कार्यप्रणाली और अपनी प्रक्रियाओं को अनुकूलित कर सकते हैं क्योंकि संदर्भ मायने रखता है, आप जानते हैं, हमारी कंपनी में, लोगों, चीजों और समाधानों की अपेक्षाकृत छोटी टीम वाली स्टार्टअप कंपनी एक से अलग दिख सकती है। स्थापित कंपनी जो 25 वर्षों से है और जिसमें कई विकास दल हैं।
तो संदर्भ वास्तव में महत्वपूर्ण है। जब आप कुछ भी लागू कर रहे हैं, वास्तव में कोई भी सॉफ्टवेयर विकास प्रक्रिया जिसे आप चुन रहे हैं, लेकिन आप इसे कर सकते हैं। मैं ईमानदारी से कहूं तो इतने छोटे से वातावरण में भी मैं इसे करना पसंद करता हूं, क्योंकि यह आपको लगातार रिलीज होने के छोटे चक्रों की तरह केंद्रित रखता है और यह आपको वास्तव में वास्तविक परिणाम देखने में मदद करता है।
इसलिए मुझे यह बहुत पसंद है। हम सब कुछ छोटे चक्रों की तरह करते हैं, लेकिन स्पष्ट रूप से ऐसा नहीं है कि हम सीधे कैसे शुरू करते हैं। तो मान लीजिए कि आप किसी क्लाइंट के लिए इस बड़े प्रोजेक्ट पर अभी शुरुआत कर रहे हैं या आप नए सिरे से प्रयास कर रहे हैं। आप स्पष्ट रूप से इन छोटे स्प्रिंट चक्रों की तरह नहीं कूद रहे हैं क्योंकि हम उन्हें सीधे कहते हैं।
वीरले: हम आम तौर पर क्या करते हैं कि हम कई किकऑफ़ मीटिंग्स के साथ शुरुआत करते हैं। तो यही है, हमारे पास अभी विचार-मंथन बैठकें हैं, ठीक है, ऐप क्या करने जा रहा है? यह कैसा दिखने वाला है? हमारी बैठकें भी होती हैं, ठीक है, लंबी अवधि की योजना क्या है? क्योंकि दो सप्ताह की योजना हर बार आपको जाने की जरूरत नहीं है।
तुम्हें जानने की जरूरत है। इतने महीनों में मैं इस उत्पाद को जारी करने जा रहा हूं। या इतने महीनों में, मैं इस उत्पाद के साथ बाजार में जा रहा हूं और हमने अपने हितधारकों के साथ और उनके बिना किकऑफ बैठकें की हैं। तो यह केवल हमारी कोर टीम है। हम नई परियोजना के बारे में बात करते हैं, लेकिन अपने हितधारकों के साथ मिलकर उनके साथ विचार-मंथन करते हैं।
तब हमारे पास, जैसे, आम तौर पर हम जो करते हैं वह इस बड़े डिजाइन की तरह होता है। इसलिए हम रेखाचित्रों के साथ शुरू करते हैं और फिर हमारे पास एक UX डिज़ाइनर होता है जो कभी-कभार हमारी मदद करता है और हमने उसे वायरफ्रेम में बदलने दिया और इसलिए हमारे पास एक व्यापक डिज़ाइन था। यह वही है जो आवेदक दिखते हैं। अक्सर हम इस डिज़ाइन को अपने ग्राहकों तक भी ले जाते हैं, “अरे, हमने इसे डिज़ाइन किया है। तो आप जैसे हैं, यह वही है जो आप अलग तरह से करते हैं।" तो यह बहुत मूल्यवान है और सुनिश्चित करें कि आप उस मेक में डिज़ाइन रखते हैं, क्योंकि यदि आप रास्ते में प्रतिक्रिया एकत्र कर रहे हैं, और यदि आप अपने डिज़ाइन अपने उपयोगकर्ताओं तक ले जा रहे हैं और यदि वे कहते हैं, ठीक है, नहीं, मैं , मैं नहीं देखता कि यह कैसे काम करेगा या जो कुछ भी, विशेष रूप से।
वीरले: यदि आपके पास एक समर्पित उत्पाद है। मेरा मतलब है, हम दवा कंपनियों के लिए उत्पाद बनाते हैं जिनकी बहुत विशिष्ट जरूरतें होती हैं और दवा कंपनी दूसरी नहीं होती है। इसलिए हमारे लिए, डिजाइनों को गतिशील रखना और जैसे ही हम जाते हैं उन्हें बदलना बहुत महत्वपूर्ण है। और फिर स्पष्ट रूप से शुरू करने से पहले, आपको अपने ढांचे पर फैसला करना चाहिए और ऐसा नहीं करना चाहिए।
रातों रातों की तरह वे एक घंटे की बैठक में ऐसा करेंगे। इसके बारे में सोचो। देखें कि क्या यह समझ में आता है। सुनिश्चित करें कि आप एक बड़े तकनीकी ऋण के साथ समाप्त नहीं होते हैं क्योंकि आपने एक गलत निर्णय लिया है और अपने उपयोगकर्ताओं को भी ध्यान में रखें, जो लक्ष्य उत्पाद हैं। और स्पष्ट रूप से यह उस समय के बीच इस नाजुक संतुलन की तरह है जो आपके पास अपनी टीम में कौशल है, जो बजट आपने कहा है, ठीक है, इस ढांचे को पसंद करते समय यह सब मायने रखता है।
तो मुझे लगता है कि हमने ऐसा किया है। सामान्य पूर्व-प्रक्रिया जैसे, और हम बिलों के संबंध में जानते हैं, हम जानते हैं कि हम किस ढांचे का उपयोग करने जा रहे हैं। हम जानते हैं कि ऐसा लगेगा कि हितधारक इस विचार से खुश हैं। हर कोई पसंद है, मैं इसे शुरू करने के लिए उत्साहित हूं। फिर हम अपने स्प्रिंट चक्र शुरू करते हैं। तो हमने मूल रूप से अनुसरण किया है।
वीरले: कुछ हद तक जिन चरणों का मैंने पहले उल्लेख किया था, हमें बोर्ड पर एक आवश्यकता मिलती है, वह किसी भी प्रकार का बोर्ड हो सकता है। यह सिर्फ सोचा प्रक्रिया गिट बोर्ड या प्रोजेक्ट बोर्ड की तरह हो सकती है। हम इसके लिए धारणा का उपयोग करते हैं, लेकिन आपको JIRA या किसी अन्य प्रकार का सॉफ़्टवेयर भी पसंद आया है। फिर हम, विशेष रूप से छोटी सुविधाओं के लिए, क्योंकि यदि आपके पास अपने बड़े ऐप के लिए अपने सामान्य डिज़ाइन जैसा कुछ हो सकता है, तो आप देखेंगे कि जब भी आप छोटे ऐड-ऑन कर रहे हों या फीडबैक के आधार पर, आप अन्य सुविधाओं के बारे में सोच सकते हैं जो आप चाहते हैं अपने ऐप में लागू करने के लिए।
आप कभी-कभी डिज़ाइन की ज़रूरतों के लिए जा रहे हैं। या तो हम सभी विद्वान रचनात्मक UX डिजाइनर हमारे लिए कुछ करें, या हम त्वरित रेखाचित्र बनाते हैं, लेकिन सुनिश्चित करें कि आपके पास जो भी आवश्यकता है, जैसे कि यह स्पष्ट समझ, ठीक है, यह यहाँ जैसा दिख रहा है। तब हम वास्तव में विकसित होते हैं, जो मजेदार हिस्सा है। और फिर हम यह सुनिश्चित करने के लिए क्या करते हैं कि हमारी टीम में हमारी परियोजनाओं को कोडिंग और भेजने का एक मानकीकृत तरीका है। हमने पुस्तकालयों और पैकेजों के उपयोग को मानकीकृत करने का भी प्रयास किया, क्योंकि व्यक्ति ए को एक विशिष्ट पुस्तकालय और व्यक्ति बी और अन्य पसंद हो सकते हैं, लेकिन यह अच्छा है। यदि आप एक समान आधार पर आ सकते हैं, तो आप जानते हैं, यह कोड नहीं है जो हर बार पूरी तरह से अलग दिखता है।
और फिर हम कुछ परीक्षण भी करते हैं, जाहिर है। तो हम कार्यक्षमता का परीक्षण करते हैं। हम देखते हैं कि क्या यह एक नई सुविधा को एकीकृत करता है, कुछ और नहीं तोड़ता है। यदि आवश्यकताओं को पूरा किया जाता है, तो जाहिर है कि हम रिलीज करते हैं, जाहिर है जब कार्य गिरते हैं तो हम उत्पादन के लिए जारी करते हैं। और कभी-कभी इससे पहले कि हम वास्तव में रिलीज़ करें, हम इसे वापस रख देंगे।
वीरले: वास्तव में रिलीज़ होने से पहले हमारे उपयोगकर्ताओं से कुछ प्रतिक्रिया प्राप्त करें, क्योंकि कभी-कभी कोई विशेषता किसी विशिष्ट क्लाइंट या उपयोगकर्ता को समर्पित होती है जैसा कि हम वास्तव में उनके साथ कहते हैं। ठीक। क्या आप इससे खुश हैं? इसलिए अगर आपको वास्तव में रिलीज़ करने से पहले बदलने की ज़रूरत है, तो हम प्रतिक्रिया और रिलीज़ चरण को थोड़ा बदल सकते हैं।
तो फिर, यह आपकी स्थिति पर निर्भर है और हाँ। और इसलिए जब इसे जारी किया जाता है, तो हमें एक प्रतिक्रिया मिलती है, मूल रूप से सभी के आसपास। इसलिए हर दिन हमें अपने ऐप्स के बारे में फीडबैक मिलता है। जाहिर है, हम अपने उपयोगकर्ताओं की प्रतिक्रिया का भी स्वागत करते हैं। यदि वे कोई नया फीचर आइडिया या बग कहते हैं, तो हम उन्हें अगले चक्र में ठीक कर देते हैं।
हमारी प्रक्रिया में एक त्वरित लूप है। और फिर कुछ सीख। मैं इसे आपके साथ साझा करना चाहता हूं। मेरे पास काफी कुछ है क्योंकि हमने बहुत कुछ सीखा है। मेरी नंबर एक सीख इस तरह है, इस विशेष ढांचे या प्रक्रिया में मत फंसो। आप चुस्त कार्यप्रणाली या यूसीडी पद्धति का पालन नहीं करते हैं, जैसे चरण-दर-चरण 100%, यह काला और सफेद नहीं है।
वीरले: ठीक। आपको वह करने की ज़रूरत है जो आपकी टीम के लिए काम करता है। उदाहरण के तौर पर, आम तौर पर जब आप छोटे कार्यों के साथ फुर्ती से काम कर रहे होते हैं, तो आपकी थाली में बहुत सारे कार्य हो सकते हैं। तो आपके पास हो सकता है कि एक टीम के सदस्य को दो सप्ताह के चक्र की तरह 10 कार्यों को पूरा करना था। लेकिन वास्तव में हम अपनी टीम में इसे इतना पसंद नहीं करते थे, हम एक बड़े महाकाव्य की तरह होना अधिक पसंद करते हैं, जिसे हम मूल रूप से एक बड़ा विषय कहते हैं, जहां हम फिर काम करते हैं।
इसलिए हम इसे एक महाकाव्य कहते हैं और यह मूल रूप से एक बहुत बड़ा कार्य है, जिसमें हम सभी संबंधित कार्यों को शामिल करते हैं। इसलिए यह हमारे लिए काम करने के लिए इसे और अधिक आरामदायक बनाता है। तो आप जो कुछ भी करते हैं, जो भी प्रक्रिया आप चुनते हैं वही करते हैं जो आपके लिए काम करता है फिर भी गलती न करें। और यह मत कहो, ठीक है, मुझे पता है कि यह तकनीकी ऋणों के साथ समाप्त होने वाला है। मैंने निश्चित रूप से कवर किया है। मैं किसी भी स्वयं परियोजना को नहीं जानता जिसमें तकनीकी गहराई की कोई मात्रा नहीं है। आपके पास हमेशा थोड़ा सा रहेगा क्योंकि शुरुआत में आपने जो विकल्प चुने थे, वे आपको सेट करने वाले हैं, आप जानते हैं, वे आपके द्वारा किए गए विकल्प हैं जो यह निर्धारित करेंगे कि आप भविष्य में क्या विकल्प चुन सकते हैं। यह हमेशा मामला रहेगा, लेकिन आप इसे सीमित कर सकते हैं और इसका मिलान करने का प्रयास कर सकते हैं, लेकिन कृपया इसके बारे में हमेशा जागरूक रहें कि ऐसा होता है।
फिर आप जो भी प्रक्रिया चुनते हैं, हो सकता है कि आप अपनी प्रक्रिया का आविष्कार करें क्योंकि आप, यह आपके लिए काम करता है। मुझे परवाह नहीं है। आपको अपने हितधारकों के साथ स्पष्ट रूप से संवाद करने की आवश्यकता है। आपको यह सुनिश्चित करने की आवश्यकता है कि आपके हितधारक जानते हैं कि आप क्या कर रहे हैं और आपकी प्रक्रिया कैसी दिखती है, क्योंकि यह उनकी साइटों पर निराशा को रोकता है।
वीरले: तब मैं सुरक्षा के लिए लक्ष्य कर रहा हूं। मुझे लगता है कि बहुत से लोगों में हर चीज को परफेक्ट करने की प्रवृत्ति होती है। वे नहीं जाएंगे, लेकिन इसे करने के लिए एक ड्राइव। यह एक छोटा कदम है। इसलिए यदि आप सॉफ़्टवेयर विकसित कर रहे हैं, तो ऐसा करने का प्रयास करें, मुझे नहीं पता, पहले सुनिश्चित करें कि कार्यक्षमता है। और बाद में, आप अतिरिक्त कार्यक्षमता को अनुकूलित कर सकते हैं। उदाहरण के लिए, यदि आप एक सुविधा बनाना चाहते हैं, जिसमें आप खरीदारी की सूचियाँ या कुछ और जोड़ सकते हैं, तो पहले सुनिश्चित करें कि सूची जोड़ने के लिए और उनमें से कुछ के लिए कार्यक्षमता है। और फिर शायद आप पर ध्यान केंद्रित कर सकते हैं वास्तव में आइकन या रंग या सूची से बाहर, आप जानते हैं, इन और अधिक वैयक्तिकृत परिवर्तन करना पसंद करते हैं।
इसलिए जल्दी से कम से कम कुछ जारी करने पर ध्यान केंद्रित करें ताकि आप प्रतिक्रिया प्राप्त कर सकें और फिर आप रास्ता सही कर सकें, क्योंकि यदि आप सीधे पूर्णता के लिए लक्ष्य कर रहे हैं, तो आप कुछ ऐसा विकसित कर सकते हैं जो आपके उपयोगकर्ता वास्तव में यह सब नहीं चाहते हैं, आप जानते हैं और जैसा कि मैंने पहले कहा था, हितधारक आवश्यकताओं पर ध्यान केंद्रित करने और लाइन प्रेरणा में केवल एक इच्छा सूची पर ध्यान केंद्रित करने के बजाय, क्योंकि अंत में हितधारकों में, मैं आपको उत्पाद के लिए खुद को विकसित करने के लिए कहूंगा।
उन्होंने आपसे कुछ विकसित करने के लिए कहा क्योंकि आपके पास सॉफ्टवेयर विकसित करने में विशेषज्ञता है। तो वे कह रहे हैं कि वे अपनी सूची में ए, बी और सी चाहते हैं, इसका मतलब यह नहीं है कि वे सबसे अच्छा जानते हैं। इसका मतलब यह नहीं है कि एबीसी वास्तव में सबसे अच्छी चीज है। इसलिए मैं हमेशा उस अंतर्निहित प्रेरणा को प्राप्त करने की कोशिश कर रहा हूं ताकि आप वास्तव में उत्पाद को बेहतर उत्पाद बनाने या बनाने में उनकी मदद कर सकें।
वीरले: फिर एक और बात: हमारे शोध को कम मत समझो। लेकिन शक्तिशाली, मौजूदा शोध को भी कम मत समझो। आपको पहिया को फिर से शुरू करने की आवश्यकता नहीं है। आप चीजों को सर्वोत्तम तरीके से कैसे कर सकते हैं, इस पर बहुत सारे यूएक्स शोध किए गए हैं। आप भी सोच सकते हैं, देख सकते हैं, आप अपना खुद का शोध करते हैं, इसी तरह के ऐप्स। उन्हें देखें, देखें कि वे कैसे काम करते हैं।
जरूरी नहीं कि उन्हें खरोंच से ही सब कुछ करने की जरूरत है। तब मुझे लगता है कि हर परियोजना के साथ, किसी कंपनी के लिए छोटा या बड़ा पक्ष परियोजना या परियोजना या योजना के लिए काम करना महत्वपूर्ण है। यदि आप बस चक्कर लगा रहे हैं, जैसा कि मैं कहूंगा, और बस यहां और वहां सुविधाओं का निर्माण करें, और कृपया अपनी तरह से जाएं। और यह आपको डिफॉल्ट नहीं देगा।
वितरण या उपयोगकर्ता केंद्रित सॉफ्टवेयर। और फिर भी, यदि आप इस चुस्त सॉफ्टवेयर विकास प्रक्रिया को चुन रहे हैं जिसमें हमारे पास हैं, इन छोटे चक्रों की तरह, ये पुनरावृत्तियां इस दो सप्ताह की दृष्टि में फंस नहीं जाती हैं, क्योंकि कभी-कभी जब आप एक चुस्त परियोजना में काम कर रहे होते हैं, यदि मेरे टीम, दो सप्ताह, यह इस समय का समय है कि आपके पास दो सप्ताह हैं जो कुछ भी है।
और फिर यह सब फिर से शुरू हो जाता है। लेकिन बड़ी, बड़ी तस्वीर का ट्रैक न खोएं, हमेशा जानें कि आप किस दिशा में काम कर रहे हैं, और यह आपके उपयोगकर्ता के लिए सबसे अच्छा आत्म प्रतिनिधि संभव है। तो इसे मत भूलना। और फिर यदि आप तकनीकी ऋण जैसी चीजों को रोकना चाहते हैं, और यदि आप बहुत जल्दी निर्णय लेने से रोकना चाहते हैं, क्योंकि समय के लिए, कृपया सुनिश्चित करें कि यदि आप किसी सुविधा या कार्यक्षमता के लिए डिज़ाइन का अनुमान लगा रहे हैं जिसे आप अतिरिक्त शामिल करते हैं।
वीरले: तो अगर आप कहते हैं, ठीक है, इस दोनों में मुझे इसे लगाने में 10 घंटे लगेंगे। मुझे नहीं पता कि यह 50% या कुछ और है, शायद 15, क्योंकि, आप कम आंकते हैं। और हमने सीखा है कि जो कानून हम अभी भी करते हैं, हम अभी भी कम करके आंकते हैं, जिसमें समय लगता है। और फिर भी, जैसा कि मैंने कहा, हमेशा अपनी विशेषताओं को डिज़ाइन करें।
यहां तक कि अगर यह केवल एक त्वरित खरोंच है, तो आपको एक पूर्ण विकसित वायरफ्रेम या जो कुछ भी होने की आवश्यकता नहीं है, विशेष रूप से एक यूएक्स डिजाइनर को इस प्रकार की चीजों को करने की आवश्यकता नहीं है, भले ही आप स्वयं हों और विकास कर रहे हों अपने दम पर एक परियोजना, सुनिश्चित करें कि आप एक त्वरित स्केच करते हैं ताकि आप जान सकें कि आप किसके माध्यम से काम कर रहे हैं।
लपेटें
फिर एक त्वरित समापन, लेकिन प्रश्नों पर जाने से पहले मैंने आज आपको बता दिया। मुझे लगता है कि इस प्रस्तुति से आपके पास जो मुख्य उपाय हो सकता है, वह है सीधे कोड में न कूदें। आप वास्तव में कोडिंग में कूदने से पहले जानते हैं, सोचते हैं, योजना बनाते हैं, आवश्यकताएं प्राप्त करते हैं। और हम सभी इसे डेवलपर्स के रूप में करना पसंद करते हैं।
मुझे पता है, लेकिन वे पीछे हट गए हैं और इस बात पर ध्यान केंद्रित करते हैं कि यहां आपके लिए सबसे अच्छा क्या हो सकता है। और इससे कोई फर्क नहीं पड़ता कि वह प्रोजेक्ट छोटा है या बड़ा। हम सभी को एक प्रक्रिया की जरूरत है। हम सभी को डिजाइन करने की जरूरत है और हम सभी को उपयोगकर्ता केंद्रित होने की जरूरत है। अगर हम वास्तव में सफल होने के लिए अपना सॉफ्टवेयर बनना चाहते हैं। और फिर आत्म अधिकार का निर्माण, क्या एक टीम प्रयास है, आप जानते हैं?
वीरले: एक डेवलपर के रूप में बहुत अलग मत बनो। मैंने लोगों को ऐसी बातें कहते सुना है, हाँ, मैं एक डेवलपर हूँ। मुझे इसके बारे में कुछ भी जानने की जरूरत नहीं है। ओह, मैं एक डेवलपर हूं। मुझे कुछ भी जानने की जरूरत नहीं है, मुझे नहीं पता, चीजें कैसे काम करती हैं, यूजर इंटरफेस कैसा दिखता है, मैं सिर्फ कोड करता हूं। लेकिन मुझे लगता है कि आप केवल विषम सॉफ़्टवेयर का निर्माण कर सकते हैं यदि आप समझते हैं जिसके लिए आप स्वयं का निर्माण कर रहे हैं जहां आपके उपयोगकर्ता के लिए एक नाम है, और यदि आप पूरी प्रक्रिया को समझते हैं, और यदि आप इसे एक टीम के रूप में करते हैं, जैसे टीम एक कारण के लिए हैं , विषय हैं, वह जाता है, वे अच्छी तरह से काम करते हैं।
और क्योंकि टीम में व्यक्ति, सुनिश्चित करें कि अकेले टीम के प्रत्येक सदस्य से अधिक विफलता है। इसलिए टीमें हैं। तो कृपया, डेवलपर्स के रूप में, एक टीम प्रयास के रूप में एक सॉफ्टवेयर बनाएं और न केवल अपने कोच पर ध्यान केंद्रित करें, बल्कि अपने उपयोगकर्ता को भी समझने का प्रयास करें। और यह वास्तव में मदद करेगा।
वीरले: और फिर यह सही है। जैसे, फिर से करो। प्रतिक्रिया हासिल करें। देखें कि आप क्या सुधार कर सकते हैं क्योंकि सॉफ्टवेयर कभी समाप्त नहीं होता है। आपके पास फिनिश की परिभाषा हो सकती है। आपके पास किया की परिभाषा हो सकती है। आपके पास पहली रिलीज़ की परिभाषा हो सकती है, लेकिन सॉफ़्टवेयर कभी समाप्त नहीं हुआ है। सुधार करने के लिए हमेशा चीजें होती हैं।
इसलिए यदि आप उस पर पुनरावृति करते हैं, तो आप वास्तव में प्रत्येक चरण में बेहतर और बेहतर होते जाएंगे। और वह मेरा मुख्य रैप अप है। क्या कोई सवाल हैं? मुझे लगता है कि चैट में बहुत कुछ हो रहा है, जिसे मैं नहीं पढ़ रहा हूं, लेकिन मैं इसे खींचूंगा। तो मुझे देखने दो कि हमारे पास क्या है।
क्यू एंड ए
मेजबान: तो मेरा मानना है कि पहला सवाल वेन से है। वेन, क्या आप स्वयं को अनम्यूट करना चाहते हैं और स्वयं प्रश्न पूछना चाहते हैं?
वेन: हाय, सब कैसे हैं? आपका बहुत बहुत धन्यवाद। सबसे पहले तो यह वास्तव में बहुत अच्छी प्रस्तुति है। बस एक त्वरित प्रश्न, वास्तव में। मैं चरणबद्ध दृष्टिकोण के बारे में चिंतित हूं जो आपने डिज़ाइन चरण के आसपास अपनी पिछली स्लाइड में दिखाया था। और मैं यह जानने के लिए उत्सुक हूं कि आप इसका परीक्षण कैसे करते हैं?
परीक्षण चरण क्या आप छोटे परीक्षणों की तरह ही कर रहे हैं? क्या आप डिजाइनों का उपयोग कर रहे हैं? क्या आपके पास एक क्यूए है जो इसे देखता है, और आप इसे अपने एसी में कैसे बनाते हैं?
वीरले: तो जैसा कि मैंने बताया, हम बहुत छोटी टीम हैं, इसलिए हमारे पास पूर्ण विकसित टीम नहीं है। हम सीधे अपने ग्राहकों के पास जाकर डिजाइन का परीक्षण करते हैं, जिसे करने के लिए हम काफी भाग्यशाली हैं।
वे हमारे उपयोगकर्ता भी हैं। हम भाग्यशाली हैं कि हमारे पास ऐसे समर्पित उपयोगकर्ता हैं जो हमारे उत्पादों को बनाने में हमारी मदद करते हैं। तो हम उनके पास जाते हैं और यह सब इस तरह से उपजा है कि यह डिज़ाइन है। क्या आपको यह पसंद है? क्या आप कोई बदलाव आदि देखना चाहते हैं? यदि आप बड़े दर्शकों के लिए काम कर रहे हैं, तो मैं निश्चित रूप से एबी परीक्षण के साथ कुछ करूंगा।
इसलिए यदि आप जल्दी से पता लगाना चाहते हैं, यदि आपका डिज़ाइन लोगों के एक निश्चित समूह के लिए काम करता है, तो बस सबसेट करें, मूल रूप से आपके बड़े दर्शकों को एक छोटे बार में, फिर उन्हें ऐप का एक संस्करण या ऐप का दूसरा संस्करण दिखाएं और करें उस पर कुछ परीक्षण। और फिर जाहिर है, क्योंकि यह आपके डिजाइन का परीक्षण कर रहा है, इसमें समय लगता है। वास्तव में विकसित होने से पहले आपको वह चक्र करना चाहिए। तो वास्तव में विकास चक्रों से पहले हमेशा डिजाइन आवश्यकताओं को चक्र लंबा चक्र होता है। क्योंकि यदि आपका विकास, यदि आप विकास कर रहे हैं, तो आपको पहले से ही यह जानना होगा कि यह आठ होने जा रहा है। मैं यही कहूंगा। क्या इससे आपके प्रश्न का उत्तर मिलता है?
सहभागी: हाँ। हाँ, नहीं, यह ठीक है। यह ठीक है। मुझे पता है कि इसका कोई स्पष्ट उत्तर नहीं है कभी-कभी मुझे लगता है कि आप बिल्कुल सही हैं। आप निश्चित रूप से उपयोगकर्ता आधार के साथ पुष्टि कर रहे हैं और जब आपने एक पुनरावृत्ति की है, तो आपको प्रतिक्रिया मिलने वाली है। हाँ, बहुत-बहुत धन्यवाद। शुक्रिया।
मेजबान: तो अगर किसी और के पास कोई सवाल है, तो बेझिझक अपना आभासी हाथ उठाएं और फिर वीरले जान सकते हैं। अगले प्रश्न के लिए, वह एक सॉफ्टवेयर उत्पाद के निर्माण में पूछ रहा था, क्या रूपरेखा का चुनाव वास्तव में महत्वपूर्ण है? ढांचे का उपयोग करते समय भी, सबसे अच्छा वास्तुशिल्प दृष्टिकोण क्या है? कभी-कभी कोई प्रोजेक्ट बड़ा हो जाता है जब वह आकार में बड़ा हो जाता है। उदाहरण के लिए, संरचना का एक अच्छा घटक होना। आपसे सुनना अच्छा लगेगा और आप इसे कैसे संभालेंगे।
वीरले: क्या रूपरेखा का चुनाव महत्वपूर्ण है? हां, ऐसा इसलिए है, क्योंकि हर ढांचा उन चीजों के लिए उपयुक्त नहीं है जो आप करना चाहते हैं। उदाहरण के लिए, जैसा कि मैंने कहा, कुछ चीजें जो हम अपने शाइनी में विकसित करते हैं, अन्य जिन्हें हम Vue में विकसित करते हैं और इसका एक कारण यह है कि, Vue एप्लिकेशन एक CRM प्रकार का सिस्टम है, जो वास्तव में एक शाइनी एप्लिकेशन के लिए उपयुक्त नहीं है। जबकि हमारे चमकदार एप्लिकेशन टीमों की तरह अधिक डैशबोर्ड शैली के हैं।
तो हाँ, आपके द्वारा चुना गया ढांचा निश्चित रूप से सीमित कर सकता है कि आप किसी एप्लिकेशन के साथ क्या कर सकते हैं। तो यह महत्वपूर्ण है। और जाहिर है जब कोई प्रोजेक्ट बढ़ता है और बड़ा और बड़ा हो जाता है, तो यह बहुत भारी हो सकता है और इससे कोई फर्क नहीं पड़ता कि आप किस ढांचे का उपयोग कर रहे हैं। लेकिन अगर आपकी परियोजना बढ़ती है, तो आपको यह सुनिश्चित करने की ज़रूरत है कि आप घटकों के भीतर करते हैं, कि आप अपने आप को दोहराते नहीं हैं, शुष्क सिद्धांत, और आप इसे यथासंभव प्रबंधनीय और कुशल बनाते हैं।
इसलिए यदि आप शाइनी चुनते हैं, यदि आप Vue चुनते हैं, यदि आप नोट चुनते हैं, तो इसे घटकों में करने का प्रयास करें, इसे वास्तव में प्रबंधनीय बनाने के लिए इसे छोटे टुकड़ों में विभाजित करने का प्रयास करें। घटक संरचना। हां। मैं निश्चित रूप से इसकी सिफारिश करूंगा। और मुझे लगता है कि आजकल हर ढांचा उस तरह की संरचना का समर्थन करता है। तो मुझे आशा है कि यह प्रश्न का उत्तर देगा।
मेजबान: ठीक। इसका उत्तर देने के लिए धन्यवाद। तो हमारे पास डोनजंग से कुछ और प्रश्न हैं, क्या आप स्वयं को म्यूट करना चाहते हैं या। मुझे लगता है, ठीक है। मुझे लगता है कि उन्होंने चैट में कहा कि वह चाहेंगे कि मैं उनकी ओर से सवाल पूछूं। तो यह सवाल यह है कि आप कैसे सुनिश्चित करते हैं कि उपयोगकर्ता हमेशा सहयोग करने और प्रतिक्रिया देने के लिए प्रेरित हों, खासकर यदि वे पहली बार उपयोगकर्ता हैं? क्या आप मुआवजा प्रदान करते हैं? यदि हां। फीडबैक प्राप्त करने के लिए अपने अंतिम उपयोगकर्ताओं को प्रेरित करने के लिए आपको क्या सलाह देनी होगी?
वीरले: क्या हम मुआवजा देते हैं? नहीं, हम नहीं। आपको हमारे साथ एक प्यारी सी चैट मिलती है। वह मुआवजा है और आपको बाद में एक उत्पाद मिलेगा। तो मुझे लगता है कि यह बहुत अच्छी प्रेरणा है, लेकिन फिर, हमारे पास एक बहुत ही समर्पित उपयोगकर्ता आधार है। यदि आप प्रतिभाओं के लिए या व्यक्तियों के लिए विकास कर रहे हैं तो ऐसा नहीं है। तो कहने के लिए, यदि आप सर्वेक्षण जैसी चीजें कर रहे हैं तो मैं क्या करूंगा, मुझे लगता है कि यह हमेशा काम करता है यदि आपको सर्वेक्षण के लिए किसी प्रकार का मुआवजा पसंद है, भले ही यह आपके बचत खाते में अतिरिक्त अंक हो, या, शायद यह एक अतिरिक्त सुविधा की तरह है जिसे अनलॉक किया जा रहा है या एक छोटा सा धन्यवाद। आप क्या कर सकते हैं, भले ही आप ग्राहकों के साथ बात कर रहे हों, कुछ सरल करें, उन्हें स्टारबक्स कॉफी दें, आप जानते हैं, आपके पास ये ऑनलाइन वाउचर हैं जो आप कर सकते हैं। बस उन्हें धन्यवाद दें। कहें कि आप वास्तव में उनकी प्रतिक्रिया को महत्व देते हैं। और एक सर्वे फंड बनाकर लोगों को प्रेरित करने का भी प्रयास करें, आप जानते हैं, मजेदार तरीके से फीडबैक दें।
आप अक्सर इस तरह की चीजें देखते हैं कि आप एक स्माइली चेहरा या एक बहुत ही पागल चेहरा दे सकते हैं। वे चीजें करें जिन्हें करने के लिए लोगों में उत्सुकता है, उन्हें 7 अरब प्रश्नों की तरह न पूछें और आवश्यकताओं को पूरा न करें। आपका टेक्स्ट 300 चार्टर्स पर लागू होना चाहिए। कोई भी इसे यथासंभव एक टन बनाने वाला नहीं है। और मुझे उम्मीद है कि यह लोगों को वास्तव में आपकी मदद करने के लिए प्रेरित करेगा। और लोगों को यह भी बताएं कि आपने उस प्रतिक्रिया के साथ क्या किया, क्योंकि उपयोगकर्ता के लिए इससे अधिक प्रेरक कुछ नहीं है यदि आपने कहा, ठीक है, मैं यह सुविधा देखना चाहता हूं कि यदि आप कुछ हफ़्ते बाद कह सकते हैं, अरे, हमने बनाया है ये तुम्हारे लिए। जाओ इसकी जांच करो। इसलिए इस बात पर नज़र रखने की कोशिश करें कि आपको वास्तव में वह प्रतिक्रिया किसने प्रदान की। उसे वापस देने का प्रयास करें। मेरे विचार से यह बहुत अच्छा तरीका है।
वीरले: उनका एक अनुवर्ती प्रश्न भी था। मूल रूप से यूसीडी दृष्टिकोण का उपयोग करके किए गए हमारे प्रयोग आपको एक पूर्ण डिज़ाइन या डिज़ाइन के दो विशिष्ट टुकड़ों से डिज़ाइन दिशा पर बेहतर परिणाम स्पष्टता प्रदान करते हैं। हमें यह समझना होगा कि हमारे उपयोगकर्ताओं में रोगी शेड्यूल के साथ उस ध्यान, शक्ति की कमी हो सकती है।
यह निश्चित रूप से सच है। ठीक है, फिर से, वास्तव में संदर्भ पर निर्भर करता है, आप जानते हैं, आप एक ही उपयोगकर्ता को 3, 4, 5 अलग-अलग विकल्प दिखाना चाहते हैं कि डिज़ाइन कैसा दिख सकता है, जो स्पष्ट रूप से उपयोगकर्ता पर बहुत भारी है क्योंकि इसमें बहुत कुछ लगता है समय के साथ या आप अपने उपयोगकर्ता आधार को उम्मीद के मुताबिक अच्छी तरह से विभाजित करने जा रहे हैं, ग्राफिक रूप से उसी तरह के नमूने, जो आप केवल डिज़ाइन ए, बी, सी, डीई के साथ प्रदान करते हैं जिसे आप जानते हैं। यदि आप सांख्यिकीय रूप से ठोस आधार पर ऋण करते हैं, तो आपको वह उत्तर मिल सकता है जिसकी आपको तलाश है।
लेकिन चूंकि यह वास्तव में संदर्भ पर निर्भर करता है कि आप इसे सर्वोत्तम तरीके से कैसे प्रबंधित कर सकते हैं। यदि कोई अनुवर्ती प्रश्न हैं, तो बस मुझे बताएं, फिर स्टीव से एक और प्रश्न जो मुझे भेजा गया था। प्रश्न: वायरफ्रेम या स्केचिंग के लिए आप किन उपकरणों की सलाह देते हैं?
मुझे लगता है कि वायरफ्रेम स्केचिंग है। फिगमा लिख रहा है। अच्छा। और आपके पास मॉक-अप भी हैं, फिगमा। मुझे लगता है कि अगर आप UX डिज़ाइनर नहीं हैं, तो शायद यह समझना थोड़ा और मुश्किल है, यह कठिन नहीं है, लेकिन इसके लिए थोड़े से कौशल और मॉक-अप की आवश्यकता होती है, हर कोई वास्तव में ऐसा कर सकता है। और अगर आपके पास मॉकअप या फिगमा तक पहुंच नहीं है, तो आप बस स्टफिंग कम्फर्ट या कुछ और भी कर सकते हैं, आप जानते हैं?
जब तक आपके पास एक सामान्य विचार है, तब तक इसे पूर्ण होने की आवश्यकता नहीं है। 100% सटीक होने की आवश्यकता नहीं है। जब तक आपके पास एक सामान्य विचार है कि यह कैसा दिखने वाला है।
सवाल: फिर एक सवाल। एक व्यावसायिक पक्ष व्यक्ति के रूप में, हम डेवलपर द्वारा उपयोग किए जाने वाले उचित ढांचे को कैसे सुनिश्चित कर सकते हैं?
ठीक है, मुझे नहीं पता कि क्या एक व्यवसायी व्यक्ति को आवश्यक रूप से पता है कि क्या यह सबसे अच्छा ढांचा है, एक व्यवसायी व्यक्ति। यह इस बात पर निर्भर करता है कि किस तरह का बिजनेस साइड पर्सन है और वह है। मुझे लगता है कि आपको पसंद के ढांचे को उन लोगों पर छोड़ देना चाहिए जिनके पास वास्तव में ढांचे के साथ सबसे अधिक अनुभव है। मैं डेवलपर्स कहूंगा, लेकिन फिर, यह एक टीम प्रयास है। और एक टीम के रूप में, आपको रूपरेखा पर निर्णय लेने की आवश्यकता है। पूरी टीम के एक व्यक्ति को यह न कहने दें, ठीक है, यह वह ढांचा होगा जिसकी आपको आवश्यकता है कि आप सभी उस ढांचे पर सहमत हों जिसका आप उपयोग करने जा रहे हैं।
और आप जिस ढांचे का उपयोग करने जा रहे हैं, वह बहुत सी चीजों पर निर्भर करता है, टीम कौशल जो डेटा रखता है, सभी चीजें, जैसा कि मैंने उल्लेख किया है, आप जानते हैं। इसे एक व्यक्ति का निर्णय न बनने दें। और मैं, हम लगभग दृष्टि से बाहर हैं। मैं देखता हूं कि क्या हम समय से बाहर हैं। मेरे पास एक प्रश्न के लिए समय है। एक आखिरी प्रश्न।
सवाल: मैं एक सॉफ्टवेयर डेवलपर हूं जिसने कुछ तकनीकी गहराई जमा की है, मैं लोगों के साथ काम करने के लिए कैसे ढूंढूं?
आप लोगों के साथ काम करने के लिए कैसे ढूंढ सकते हैं? आप पूछ सकते हैं, जैसे फ्रीलांसरों के लिए जो आपकी मदद करना चाहते हैं, आप ढूंढ सकते हैं, देख सकते हैं कि क्या आप कर सकते हैं, जैसे, मुझे नहीं पता, कनेक्शन या कोडमेंटर तक पहुंच सकते हैं, शायद।
कोडमेंटर पर, आपके पास बहुत से डेवलपर हैं जो आपकी मदद कर सकते हैं या आपकी परियोजनाओं में आपकी सहायता कर सकते हैं। अगर उसके पास सोशल नेटवर्किंग के माध्यम से लिंक्डइन था, तो वहां बहुत सारे डेवलपर्स हैं और वे डेवलपर्स जो वास्तव में आपके साथ मिलकर काम कर सकते हैं। इसलिए हम निश्चित रूप से ऋण के लिए इस प्रकार के प्लेटफॉर्म पर एक नजर डालते हैं।
यही बात है। जो मैं आपके साथ साझा करना चाहता हूं। एक आखिरी बात है, मेरा लिंक्डइन। कृपया मेरे साथ संपर्क में रहें। मुझे एक कनेक्शन अनुरोध भेजें या मुझे फॉलो करें। मैं कभी-कभी अपनी प्रोग्रामिंग भाषा के बारे में बातें साझा करता हूं, लेकिन सॉफ्टवेयर विकास और हम अपनी कंपनी में कैसे काम करते हैं, इसके बारे में भी।
इसलिए यदि आपको लगता है कि यह दिलचस्प है, तो कृपया वहां पहुंचें और फिर आपके समय और आपके सभी प्रश्नों के लिए बहुत-बहुत धन्यवाद। और यदि आपके कोई और प्रश्न हैं जो आप मुझसे पूछना चाहते हैं, जिसका उत्तर मैं यहां नहीं दे सकता, तो आप हमेशा लिंक्डइन पर मुझसे संपर्क कर सकते हैं। शुक्रिया।
मेजबान: बहुत बढ़िया। इस अद्भुत वार्ता के लिए बहुत-बहुत धन्यवाद, वीरले। जहां तक हर किसी के सवालों और चीजों का जवाब देने के लिए समय निकालने की बात है। अद्भुत बात। और मैंने व्यक्तिगत रूप से इससे बहुत कुछ सीखा। तो फिर से धन्यवाद, हमारे कार्यक्रम में शामिल होने के लिए सभी का और हमारे स्पीकर को बहुत-बहुत धन्यवाद, वास्तव में आज यह भाषण देने के लिए। इसलिए मुझे उम्मीद है कि सभी ने इसका आनंद लिया और हमारे अगले कार्यक्रम के लिए बने रहें, जिसका शीर्षक है टेक में इम्पोस्टर सिंड्रोम को कैसे दूर किया जाए। यह अगले सप्ताह तीसरे दिसंबर को हो रहा है, अगर हर कोई इसमें शामिल होने में रुचि रखता है और मुझे वहां सभी को देखने की उम्मीद है, तो हमने उस चैट में कुछ जानकारी पोस्ट की है।
डेवलपर वर्चुअल इवेंट के बारे में अधिक जानकारी
इस इवेंट को कोडमेंटर इवेंट्स, एक डेवलपर कम्युनिटी और वर्चुअल इवेंट प्लेटफॉर्म द्वारा होस्ट किया गया था ताकि नए टूल्स और कॉन्सेप्ट्स को साझा किया जा सके और सीखा जा सके। के बारे में और अधिक जानकारी प्राप्त करें कोडमेंटर इवेंट यहाँ ->
- &
- 10
- 100
- 7
- a
- About
- में तेजी लाने के
- पहुँच
- लेखा
- सही
- के पार
- सक्रिय
- अतिरिक्त
- वयस्कों
- सलाह
- के खिलाफ
- चुस्त
- एमिंग
- सब
- पहले ही
- हमेशा
- अद्भुत
- राशि
- राशियाँ
- विश्लेषिकी
- विश्लेषण करें
- अन्य
- जवाब
- किसी
- एपीआई
- अनुप्रयोग
- app की दुकान
- आवेदन
- अनुप्रयोगों
- लागू
- दृष्टिकोण
- क्षुधा
- वास्तु
- चारों ओर
- कला
- ध्यान
- दर्शक
- दर्शकों
- लेखकों
- उपलब्ध
- मूल रूप से
- आधार
- क्योंकि
- से पहले
- शुरू
- जा रहा है
- लाभ
- BEST
- सर्वोत्तम प्रथाओं
- के बीच
- बड़े चित्र
- बड़ा
- बिलियन
- विधेयकों
- बिट
- काली
- ब्लॉग
- मंडल
- बजट
- कीड़े
- निर्माण
- इमारत
- व्यापार
- खरीदने के लिए
- क्रय
- कॉल
- पा सकते हैं
- कौन
- का कारण बनता है
- कुछ
- चुनौती
- चुनौतियों
- परिवर्तन
- चुनाव
- विकल्प
- चुनें
- करने के लिए चुना
- ग्राहकों
- बादल
- कोड
- कोडन
- कॉफी
- सहयोग
- कैसे
- अ रहे है
- सामान्य
- संवाद
- समुदाय
- कंपनियों
- कंपनी
- तुलना
- मुआवजा
- पूरा
- पूरी तरह से
- अंग
- घटकों
- संकल्पना
- संबंध
- विचार करना
- संगत
- निरंतर
- परामर्श
- मूल
- लागत
- सका
- युगल
- बनाना
- क्रिएटिव
- संकट
- महत्वपूर्ण
- सीआरएम
- वर्तमान
- वर्तमान स्थिति
- ग्राहक
- चक्र
- दैनिक
- डैशबोर्ड
- तिथि
- डेटा विज्ञान
- आँकड़े वाला वैज्ञानिक
- दिन
- सौदा
- ऋण
- निर्णय
- समर्पित
- पहुंचाने
- निर्भर
- निर्भर करता है
- निर्भर करता है
- डिज़ाइन
- बनाया गया
- डिज़ाइन बनाना
- डिजाइन
- विस्तार
- निर्धारित करना
- देव
- विकसित करना
- विकसित
- डेवलपर
- डेवलपर्स
- विकासशील
- विकास
- के घटनाक्रम
- devs
- डीआईडी
- अंतर
- विभिन्न
- मुश्किल
- प्रत्यक्ष
- सीधे
- ड्राइव
- दौरान
- गतिशील
- शीघ्र
- शिक्षित
- कुशल
- प्रयास
- ऊर्जा
- वातावरण
- इक्विटी
- विशेष रूप से
- स्थापित
- आदि
- कार्यक्रम
- घटनाओं
- हर कोई
- सब कुछ
- ठीक ठीक
- उदाहरण
- उत्तेजित
- मौजूदा
- उम्मीद
- उम्मीदों
- अनुभव
- अनुभव
- विशेषज्ञता
- चरम
- चेहरा
- विफलता
- निष्पक्ष
- फास्ट
- Feature
- विशेषताएं
- प्रतिक्रिया
- आकृति
- वित्तीय
- खोज
- अंत
- प्रथम
- पहली बार
- फिक्स
- तय
- फोकस
- ध्यान केंद्रित
- ध्यान केंद्रित
- का पालन करें
- पाया
- स्थापित
- ढांचा
- चौखटे
- मुक्त
- से
- पूर्ण
- मज़ा
- कार्यक्षमता
- कोष
- मौलिक
- भविष्य
- सभा
- सामान्य जानकारी
- जाना
- देते
- लक्ष्यों
- जा
- अच्छा
- महान
- समूह
- संभालना
- खुश
- होने
- सिर
- स्वास्थ्य
- स्वास्थ्य सेवा
- सुना
- मदद
- मदद करता है
- यहाँ उत्पन्न करें
- हाई
- रखती है
- होमपेज
- मेजबानी
- कैसे
- How To
- तथापि
- HTTPS
- विशाल
- नायक
- विचार
- विचारों
- लागू करने के
- कार्यान्वयन
- अस्पष्ट
- महत्वपूर्ण
- में सुधार
- व्यक्ति
- व्यक्तियों
- करें-
- नवोन्मेष
- अंतर्दृष्टि
- इंस्टाग्राम
- रुचि
- इंटरफेस
- साक्षात्कार
- निवेश
- शामिल
- iPhone
- मुद्दों
- IT
- खुद
- काम
- छलांग
- रखना
- कुंजी
- जानना
- ज्ञान
- जानने वाला
- भाषा
- बड़ा
- बड़ा
- कानून
- बिक्रीसूत्र
- जानें
- सीखा
- सीख रहा हूँ
- छोड़ना
- पुस्तकालय
- सीमित
- लाइन
- पंक्तियां
- लिंक्डइन
- सूची
- सूचियाँ
- थोड़ा
- जीना
- लंबा
- देखिए
- देख
- मोहब्बत
- बनाया गया
- बनाना
- बनाता है
- निर्माण
- प्रबंधन
- प्रबंधक
- बाजार
- विपणन (मार्केटिंग)
- बाजार
- मैच
- बात
- मैटर्स
- सार्थक
- साधन
- बैठक
- बैठकों
- सदस्य
- सदस्य
- उल्लेख किया
- के तरीके
- हो सकता है
- मन
- गलतियां
- मोबाइल
- आदर्श
- गति
- महीने
- अधिक
- अधिकांश
- विभिन्न
- नामकरण
- अनिवार्य रूप से
- की जरूरत है
- नीदरलैंड्स
- शुद्ध कार्यशील
- नए उत्पादों
- साधारण
- सामान्य रूप से
- नोट्स
- संख्या
- ठीक है
- चल रहे
- ऑनलाइन
- ऑनलाइन खरीदारी
- खुला
- खुला स्रोत
- संचालन
- ऑप्टिमाइज़ करें
- ऑप्शंस
- आदेश
- अन्य
- अन्यथा
- अपना
- पैकेज
- दर्द
- भाग
- विशेष
- साथी
- वेतन
- पीसी
- स्टाफ़
- उत्तम
- व्यक्ति
- निजीकृत
- परिप्रेक्ष्य
- फार्मास्युटिकल
- चरण
- दर्शन
- चित्र
- टुकड़ा
- टुकड़े
- प्रधान आधार
- की योजना बना
- मंच
- प्लेटफार्म
- प्ले
- बिन्दु
- अंक
- द्वार
- संभव
- बिजली
- शक्तिशाली
- वर्तमान
- प्रदर्शन
- दबाव
- सुंदर
- कीमत निर्धारण
- सिद्धांत
- मुसीबत
- समस्याओं
- प्रक्रिया
- प्रक्रियाओं
- एस्ट्रो मॉल
- उत्पादन
- उत्पाद
- पेशेवरों
- प्रोग्रामिंग
- परियोजना
- परियोजनाओं
- सुरक्षा
- प्रदान करना
- बशर्ते
- प्रदान करता है
- प्रदान कर
- क्यू एंड ए
- गुणवत्ता
- प्रश्न
- त्वरित
- जल्दी से
- उठाना
- को ऊपर उठाने
- RE
- पहुंच
- प्रतिक्रिया
- पढ़ना
- वास्तविकता
- उचित
- पहचान
- की सिफारिश
- दर्शाता है
- खेद
- और
- रिहा
- का प्रतिनिधित्व
- का अनुरोध
- अनुरोधों
- आवश्यकताएँ
- की आवश्यकता होती है
- अनुसंधान
- संसाधन
- बाकी
- परिणाम
- जोखिम
- भूमिका
- दौर
- नियम
- दौड़ना
- कहा
- विक्रय
- वही
- विज्ञान
- वैज्ञानिक
- वैज्ञानिकों
- स्क्रीन
- सेक्टर
- भावना
- सेट
- की स्थापना
- Share
- साझा
- पाली
- खरीदारी
- कम
- समान
- सरल
- के बाद से
- साइटें
- आकार
- कौशल
- छोटा
- So
- सोशल मीडिया
- सामाजिक नेटवर्किंग
- सॉफ्टवेयर
- सॉफ्टवेयर विकास
- ठोस
- समाधान
- समाधान ढूंढे
- कुछ
- कोई
- कुछ
- कहीं न कहीं
- वक्ता
- विशेषीकृत
- विशिष्ट
- गति
- बिताना
- विभाजित
- पूरे वेग से दौड़ना
- धुआँरा
- ट्रेनिंग
- चरणों
- स्टैंडअलोन
- मानक
- स्टारबक्स
- प्रारंभ
- शुरू
- शुरू होता है
- स्टार्टअप
- राज्य
- रहना
- फिर भी
- की दुकान
- धारा
- सुवीही
- तनाव
- प्रयास करना
- अंदाज
- विषय
- सफलता
- समर्थन
- समर्थन करता है
- सर्वेक्षण
- स्थायी
- प्रणाली
- ले जा
- प्रतिभा
- बातचीत
- में बात कर
- लक्षित
- कार्य
- टीम
- तकनीक
- तकनीकी
- शर्तों
- परीक्षण
- परीक्षण
- परीक्षण
- RSI
- नीदरलैंड
- बात
- चीज़ें
- विचारधारा
- हजारों
- तीन
- यहाँ
- भर
- पहर
- बहुत समय लगेगा
- सुझावों
- आज
- एक साथ
- टन
- उपकरण
- ऊपर का
- स्पर्श
- की ओर
- ट्रैक
- ट्रांसपेरेंसी
- Uk
- के अंतर्गत
- समझना
- समझ
- विश्वविद्यालय
- us
- प्रयोज्य
- उपयोग
- उपयोगकर्ताओं
- आमतौर पर
- ux
- मूल्य
- विभिन्न
- संस्करण
- बनाम
- वीडियो
- वास्तविक
- दृष्टि
- जरूरत है
- सप्ताह
- में आपका स्वागत है
- क्या
- एचएमबी क्या है?
- पहिया
- या
- जब
- कौन
- अंदर
- बिना
- अद्भुत
- काम
- काम किया
- काम कर रहे
- कार्य
- विश्व
- होगा
- लिख रहे हैं
- X
- साल
- आपका
- यूट्यूब