कई आज परियोजना के बहुत शुरुआत में प्रोटोटाइप प्रोटोटाइप विकसित कर रहे हैं। यह सर्वविदित है कि इस स्तर पर एक गलती को ठीक करना बाद के चरणों की तुलना में कई गुना सस्ता है।
हालांकि, विकास में एक और चरण है, जो बहुत बड़ी भूमिका निभाता है, लेकिन जिस पर कम ध्यान दिया जाता है। और यह चरण इंटरफ़ेस सहित सिर में परियोजना का मॉडल है। और अगर अन्य सभी चरणों में त्रुटियां दिखाई देती हैं और पता लगाना आसान है, तो परियोजना के माध्यम से सोचने की प्रक्रिया में सोच प्रक्रिया की त्रुटि और इसका इंटरफ़ेस बहुत अंत में ही समझ में आता है - जब परियोजना पहले से ही मुकाबला स्थितियों में परीक्षण कर रही है।
इस तरह की त्रुटियों को कैसे ढूंढें, उनके साथ व्यवहार करें, और वास्तविक अभ्यास से एक उदाहरण, अंदर पढ़ें।
त्रुटि का सार सरल है। एक व्यक्ति दुनिया के किसी भी पहलू के विचार को ध्यान में रखता है, और मानता है कि वास्तव में ऐसा होगा। वास्तव में, सिर और वास्तविकता में तस्वीर के बीच का अंतर विभिन्न विशेषज्ञों द्वारा सैकड़ों हजारों रूबल और दसियों घंटे काम में बदल जाता है जो कहीं नहीं जा रहे हैं।
पहले आपको यह महसूस करने की आवश्यकता है कि त्रुटि स्वयं मौजूद है।
आमतौर पर एक व्यक्ति को यकीन है कि वह इंटरफ़ेस को ठीक उसी तरह से डिज़ाइन कर सकता है जैसे वह बहुत ही अंत में होगा, "सब कुछ ठीक है" और "इसे सोचें"। लेकिन ऐसा सोचना एक पतन है।
सबसे पहले, सब कुछ बदल जाएगा - यह किसी भी उत्पादों के विकास में कानून है। इसलिए, प्रक्रिया जितनी आसान होगी, उतना बेहतर होगा। इसलिए नियम - किसी भी स्तर पर न्यूनतम आवश्यक मात्रा बनाने के लिए, कहते हैं, एक दिन में पुनरावृत्ति - ताकि यदि गलत किया जाता है, तो इसे फेंकने और इसे पहले करने के लिए दया नहीं होगी।
उसी समय, उत्पाद के अंतिम उपयोगकर्ताओं पर निष्ठा या बेवफाई का सत्यापन होना चाहिए, उत्पाद में लाइव (और परीक्षण नहीं) डेटा होना चाहिए, सब कुछ वास्तविक होना चाहिए।
दूसरे, प्रारंभिक चरण में कोई 100% नहीं सोच सकता है। इसे एक स्वयंसिद्ध के रूप में लिया जा सकता है - यदि दुर्लभ मामला नहीं है जब इंटरफ़ेस डिजाइनर या प्रोजेक्ट अवधारणा के डेवलपर को परियोजना क्षेत्र में गहरा अनुभव है, तो 99% मामलों में सभी जटिल चिप्स द्वारा पारित किया जाएगा।
एकमात्र संभव विकल्प अंतिम उपयोगकर्ता की भूमिका के लिए उपयोग किया जाता है (आप एकाउंटेंट के लिए सॉफ़्टवेयर बनाते हैं - एक अकाउंटेंट बनें और एक अकाउंटेंट के रूप में सॉफ़्टवेयर को देखें, एक एकाउंटेंट के दृष्टिकोण से समस्याओं को कैसे हल करें, और इसी तरह)। लेकिन इसके लिए बहुत अनुभव और महान कौशल की आवश्यकता होती है, और अक्सर समय, जो हमेशा संभव नहीं होता है।
इसलिए, विशिष्ट उपयोगकर्ताओं के होंठों से पुनरावृत्ति के लिए मुख्य कार्यों की पहचान करने का प्रयास करना उचित है (उसी समय, समस्याओं को स्वयं से अलग करें कि उपयोगकर्ता समाधान कैसे देखते हैं - आखिरकार, उपयोगकर्ता पेशेवर नहीं हैं, आपके विपरीत, परियोजना विकास में)।
और पुनरावृत्तियों को यथासंभव यथासंभव कम किया जाना चाहिए और लाइव उपयोगकर्ताओं के साथ काम करने के लिए जितना संभव हो उतना करीब होना चाहिए, उन्हें एक परियोजना के साथ आपूर्ति करना, भले ही केवल आंशिक रूप से लाइव डेटा के साथ काम करना, और सावधानीपूर्वक प्रतिक्रिया एकत्र करना, उनका अवलोकन करना।
एक उदाहरण के रूप में, मानव संसाधन विभाग के स्वचालन पर विचार करें, जो अब मैं एक कंपनी में काम करता हूं, उत्कृष्ट पेशेवरों की एक टीम के साथ काम करता हूं। हमने एक ऐसी प्रक्रिया का निर्माण किया है जहाँ हर दिन रिलीज़ होती है, और हर दिन एक या दूसरे कार्यात्मक को लाइव उपयोगकर्ताओं और वास्तविक डेटा पर पेश और परीक्षण किया जाता है। शोधन की ऐसी गति के कारण और वास्तव में आवश्यक चिप्स अगले दिन ही आ जाते हैं।
इसलिए, जब हमने रिज्यूमे के लिए लेखांकन का स्वचालन किया (ई-मेल द्वारा प्राप्त सभी फिर से शुरू, आदि, जो लड़की उन्हें खोजती है और उन्हें हाथ से जोड़ती है, और साइट के माध्यम से जोड़ा जाता है), वे स्थिति से टूट गए थे (नेत्रहीन, टैब की समीक्षा नहीं की गई थी; परीक्षण, इनकार, इनकार, आदि), वहां, एक टैब से दूसरे में फिर से शुरू करने की प्रक्रिया में, एक पॉपअप दिखाई दिया - जहां इसे स्थानांतरित करना है।
स्थानांतरण के बाद, व्यक्ति को अंतिम टैब पर फेंक दिया गया था (उदाहरण के लिए, वह "समीक्षा नहीं की गई थी" में, उसने व्यक्ति का चयन किया, "इनकार" करने के लिए स्थानांतरित करने के लिए क्लिक किया, अस्वीकृति का कारण दर्ज किया - और उसे "मना कर दिया गया")। स्टार्टअप में, यह पता चला कि जब मानव संसाधन विभाग के कर्मचारियों ने सैकड़ों रिज्यूमे सॉर्ट किए थे, तो उनके लिए वर्तमान टैब में रहना अधिक सुविधाजनक था - क्योंकि आपको अंतिम टैब पर चले जाने के बाद, उस पर वापस लौटें, जहां आपने फिर से शुरू की गई सूची को छांटा था।
यदि डिजाइनर ने एक सौ रिज्यूमे के साथ काम किया, और एक दर्जन नहीं, तो वास्तविक समस्या को हल करते हुए, उन्होंने यह गलती नहीं की होगी। उसके फिक्स प्रोग्रामर के काम के कुछ घंटे खर्च हुए, लेकिन वे नहीं रहे। नाम से एक फिल्टर के साथ - यदि कोई व्यक्ति 1000 रिज्यूमे के साथ काम करने की कोशिश करता है, तो वह समझ जाएगा कि नाम से एक फिल्टर बहुत आवश्यक है।
दरअसल, कई स्टार्टअप अनावश्यक हैं क्योंकि लोग सोचते हैं
खुद अपने उपयोगकर्ताओं की तुलना में होशियार हैं, और अनावश्यक इंटरफेस, इंजन और प्रोजेक्ट बनाते हैं, अपना समय और पैसा खर्च करते हैं (और अक्सर केवल अपने ही नहीं)।
यह ध्यान देने योग्य है कि यह दृष्टिकोण शब्द के व्यापक अर्थों में एक पैटर्न है। इसका मतलब है कि इसे किसी भी क्षेत्र में लागू किया जा सकता है। उदाहरण के लिए, प्रोग्रामिंग में - ग्राहक से तकनीकी विशिष्टताओं को प्राप्त करने के लिए, एक प्रोटोटाइप को स्केच करने के लिए जो तर्क के दृष्टिकोण से सही है, लेकिन कोड में "जितनी तेज़ी से" होगा। जब तक मुख्य तर्क नहीं किया जाता है, तब तक सुधार दिखाएं और सुधारों की एक सूची प्राप्त करें। फिर रिफ्लेक्टर करें और इसे सुनिश्चित करें। यह दृष्टिकोण आपके समय और ग्राहक समय के 100% से 1000% तक की बचत करेगा।
मैं चाहता हूं कि आपकी परियोजनाओं में आवश्यक कार्यक्षमता का प्रतिशत 100% के लिए प्रयास करना चाहिए!