दृश्य विनिर्देशों

विनिर्देशों नश्वर बोरियत हैं। यह शायद उत्पाद प्रबंधक की नौकरी का सबसे उबाऊ हिस्सा है। शायद इसीलिए अधिकांश विनिर्देश भयानक हैं और देरी, परिवर्तन और बग का मुख्य स्रोत हैं।

सक्रिय संचार और उत्पाद प्रबंधक की उपलब्धता अपर्याप्त रूप से अच्छे विनिर्देशों की समस्या को हल करने में मदद करती है, लेकिन हमेशा नहीं।

चंचल आंदोलन विनिर्देशों पर अपनी खुद की नज़र है। सबसे चरम विंग अपने विचार इस प्रकार व्यक्त करता है:

गधा विनिर्देशों में!

और इस तरह की परियोजनाओं में आवश्यकता का एक विशिष्ट विवरण इस प्रकार है:

उपयोगकर्ता के रूप में
मैं जल्दी से एक नया कार्य जोड़ना चाहता हूं
समय बचाने के लिए और संदर्भ नहीं खोना है

हैरानी की बात है, यह दृष्टिकोण काम करता है। कुछ मामलों में। नीचे दी गई सभी शर्तें पूरी होनी चाहिए:

• टीम एक ही कमरे में बैठी है
• उत्पाद प्रबंधक तक 24x5 पहुंच है
• टीम में कोई परीक्षक नहीं हैं
• डिजाइनर 1 व्यावसायिक दिन में किसी भी समस्या के समाधान के साथ आने में सक्षम हैं

यदि कम से कम एक भी शर्त पूरी नहीं की जाती है, तो टीम को गंभीर समस्याएं हैं।

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

विनिर्देशों और प्रोग्रामर

कई प्रोग्रामर विनिर्देशों को पसंद नहीं करते हैं। हम एक परिभाषा प्रस्तुत करते हैं, इसे "क्लास 1 प्रोग्रामर" होने दें। वे अच्छी तरह से जानते हैं कि सिस्टम को कैसे काम करना चाहिए, किन परिदृश्यों में आपको "अज्ञात त्रुटि" या "आप ऐसा नहीं कर सकते" संदेश प्राप्त कर सकते हैं और जहां आपको निर्बाध चीजों से कम परेशान करने के लिए कोनों को काटने की आवश्यकता है।

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

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


प्रकार से प्रोग्रामर का वितरण। ज्यादातर आम तौर पर विनिर्देशों पर लागू होते हैं।

कक्षा 2 के प्रोग्रामर ने कवर से कवर तक के विनिर्देशन को पढ़ा, इसे व्यवस्थित रूप से पचाया और घातक सटीक प्रश्न पूछे।

कक्षा 2 प्रोग्रामर के लिए, आप कोई भी विनिर्देश बना सकते हैं - वे सब कुछ निगल लेंगे। कक्षा 1 के प्रोग्रामर केवल जटिल शब्दों के बिना लघु, स्पष्ट कैप्शन के साथ चित्र दिखा सकते हैं। बेहतर अभी तक, उन्हें एक कार्टून दिखाओ। मैं एनीमेशन कहना चाहता था।

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

विनिर्देशों और परीक्षक

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

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

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

विशिष्टता गुण

आइए उन संकेतों के बारे में बात करें जिनके द्वारा कोई भी मूर्ख एक अच्छे से बुरे विनिर्देश को अलग कर सकता है।

(इन) पूर्णता

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

इस बिंदु पर, आप छोड़ सकते हैं और कह सकते हैं कि चूंकि हम पूर्ण विनिर्देश नहीं कर सकते हैं, इसलिए हम इसके बारे में क्या कर सकते हैं? हालाँकि, संपूर्णता के लिए उचित प्रयास बहुत सारे फायदे देते हैं, और केवल दो minuses: समय और प्रयास।

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

तो विनिर्देशों को कैसे पूरा किया जाना चाहिए? जवाब बहुत आसान है। सबसे पहले, आवश्यकता का विनिर्देश कुछ वाक्यों तक सीमित होना चाहिए। विकास शुरू करने से पहले, यह समय के संदर्भ में उचित होना चाहिए।


उपयोगकर्ता कहानी के विकास के चरण के आधार पर विवरण विनिर्देश। पहले तो, कुछ वाक्य पर्याप्त हैं। वास्तविक कार्यान्वयन की शुरुआत में, एक पूर्ण विनिर्देश की आवश्यकता है।

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

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


लापता (अपूर्ण) विनिर्देशन के साथ विशिष्ट सुविधा विकास प्रक्रिया। नई समस्याओं की पहचान करने से काम की मात्रा बढ़ जाती है। फीचर को पूरा करने के लिए वीर प्रयासों की आवश्यकता होती है।

दिमागी दिमाग

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

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

न केवल उनके विनिर्देशों को पढ़ना मुश्किल है, लेकिन आपको यह समझने की कोशिश करने में ऊर्जा की कीमती कैलोरी खर्च करने की आवश्यकता है कि वाक्यांश का वास्तव में क्या मतलब है "उपयोगकर्ता माउस-टाइप मैनिप्युलेटर के बाएं बटन पर डबल-क्लिक करके क्लाइंट एप्लिकेशन के अगले भाग में जाने का संचालन करता है"।

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

आकार

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

ऐसा लगता है कि आकार पूरी तरह से सहसंबद्ध (लानत!) है। हालांकि, पानी के साथ विनिर्देश भरना स्पष्ट रूप से एक अच्छा विचार नहीं है। इसे अर्थ और जीवन से भरें।

विचारों को संप्रेषित करने के तरीके

मेरे विचारों को समझाने के लिए सामान्य तरीके क्या हैं? चलो उनके ऊपर चलते हैं।

छद्म कथन

बहुत सारे विनिर्देशन डेवलपर्स को संरचना पसंद है। सबसे सुलभ संरचनात्मक तत्व: टेबल और सूचियां। अक्सर, विनिर्देश में अधिक कुछ नहीं होता है: सूचियाँ, सूचियाँ, नेस्टेड सूचियाँ, नेस्टेड सूचियाँ सूची में नेस्टेड ... और तालिकाएँ।

एक ओर, तालिकाओं को वास्तव में अच्छी तरह से देखने में मदद मिलती है ... सारणीबद्ध डेटा। लेकिन यह संभावना नहीं है कि सारणीबद्ध डेटा के रूप में किसी भी विनिर्देश का प्रतिनिधित्व किया जा सकता है। हालांकि कुछ सफल:


तालिकाओं के उत्कृष्ट उपयोग का एक उदाहरण।

मॉडरेशन में भी लिस्ट अच्छी है। जब पूरे विनिर्देश उनमें से होते हैं, तो पांचवें पृष्ठ पर मैं लेखक को गोली मारना चाहता हूं, और सातवें द्वारा - खुद को।


सूचियों के सम्मोहक उपयोग का एक उदाहरण।

पाठ का ऐसा उपयोग कर्म को बिगाड़ता है। ऐसा न करें।

कथा

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

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

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

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

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

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

हो सकता है कि कथा विनिर्देश पर्याप्त औपचारिक नहीं है। लेकिन अगर आप इसे सही चित्रों के साथ पूरक करते हैं, तो सब कुछ ठीक हो जाएगा।

BDD

आवश्यकताओं का वर्णन करने के लिए व्यवहार-प्रेरित विकास का एक दिलचस्प प्रारूप है। वास्तव में, हम सुविधाओं को स्वीकार करने के लिए मापदंड का वर्णन करते हैं। यदि सभी मानदंड पास हो जाते हैं, तो सुविधा तैयार मानी जाती है। बीडीडी प्रारूप में विनिर्देशन का एक उदाहरण यहां दिया गया है:

एक स्क्रैम मास्टर के रूप में, मैं हफ्तों तक जारी बीडी चार्ट देखना चाहता हूं

एक स्कैम मास्टर के रूप में
मैं हफ्तों तक जारी बीडी चार्ट देखना चाहता हूं
जब Iterations अभ्यास अक्षम होता है
ताकि मैं बीडी चार्ट से लाभान्वित हो सकूं

किसी भी विकास प्रक्रिया को देखते हुए
जब मैं व्यवस्थापन में Iterations अभ्यास बंद कर देता हूं -> प्रक्रिया -> संपादन
और बीडी चार्ट रिलीज करने के लिए नेविगेट करें
फिर साप्ताहिक वेग के स्थान पर पुनरावृति वेग
और चार्ट समाप्ति तिथि रिलीज़ समाप्ति तिथि के समान है
और बीडी चार्ट पुनरावृत्तियों के बजाय हफ्तों तक खींचा गया
और चार्ट स्टार्ट डेट, रिलीज़ स्टार्ट डेट के समान है

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

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

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

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

BDD का उपयोग करते समय, एक बार में पूरी सुविधा को कवर करना लगभग असंभव है।

इंटरफ़ेस रूपरेखा

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

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


टारगेटप्रोसेस 3 में रिपोर्ट सिस्टम की रूपरेखा।

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


Targetprocess 3 में भूमिका, परियोजना और टीम के आधार पर लोगों के लिए अनुमत कार्य असाइनमेंट का एक स्केच

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


टारगेटप्रोसेस 3 में स्केच टाइमलाइन।

मुझे व्यक्तिगत रूप से रेखाचित्र पसंद हैं।

विस्तृत डिजाइन

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

एक समस्या है। ऐसा हो सकता है कि एक तैयार डिजाइन के साथ एक सुविधा अचानक अनावश्यक हो जाती है। कुछ भी नहीं किया जाना चाहिए, हमें उन विशेषताओं के लिए अनुमान लगाने और डिजाइन करने की कोशिश करनी चाहिए जो विकसित होने की अत्यधिक संभावना है।


Targetprocess 3 में तैयार समयरेखा डिजाइन

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


समय के साथ क्लेम कार्ड बदलने के तीन विकल्प

लेकिन यह लंबा और मुश्किल है। केवल कुछ चुनिंदा लोग ही सावधानीपूर्वक विकल्पों को पूरा करने में सक्षम हैं।

स्टोरीबोर्ड / स्टोरीबोर्ड

स्टोरीबोर्ड फिल्म निर्माताओं द्वारा पसंद किए जाते हैं। सामान्य तौर पर, यह किसी दृश्य के अलग-अलग मुख्य फ़्रेमों का एक सेट होता है।


एक अतुलनीय फिल्म के लिए विशिष्ट स्टोरीबोर्ड।

स्टोरीबोर्ड बनाने के लिए आपको एक महान कलाकार होने की आवश्यकता नहीं है। यह मनमाने कोणों पर घुमावदार रेखाएँ खींचने में सक्षम होने के लिए पर्याप्त है:


ठेठ तेज स्टोरीबोर्ड।

हमारे उद्योग में, स्टोरीबोर्ड व्यक्तिगत सिस्टम राज्यों का एक संग्रह है।

स्टोरीबोर्ड काफी कॉम्पैक्ट हैं और यह समझना संभव है कि सामान्य रूप से किस तरह की स्थितियां हैं। उत्कृष्ट स्टोरीबोर्ड यह भी बताता है कि इन राज्यों में कैसे जाना है।


वैकल्पिक स्क्रिप्ट के साथ Targetprocess 3 में कार्यों को जल्दी से जोड़ने के लिए एक स्टोरीबोर्ड।

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

प्रवाह / प्रवाह

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

प्रवाह आरेख बस यह दिखा सकता है कि उपयोगकर्ता कार्यों के जवाब में कौन से राज्य के संक्रमण संभव हैं, या इसमें यूआई तत्व भी हो सकते हैं (इस मामले में, यह एक स्टोरीबोर्ड पर पहुंचता है)।

मुझे इंटरफ़ेस रेखाचित्रों से कम फ्लोचार्ट खींचना पसंद है।


टारगेटप्रोसेस 3 में प्रासंगिक संपादन थ्रेड।

एनिमेशन / gifs

सभी बच्चों को कार्टून बहुत पसंद होते हैं। लेकिन जब उन्हें पता चलता है कि एक मिनट का कार्टून बनाने के लिए, उन्हें 1000 चित्र बनाने की आवश्यकता है, तो ज्यादातर लोग हमेशा के लिए एनिमेटेड फिल्मों में उलझने को हतोत्साहित करते हैं।

लेकिन फिर भी, स्टोरीबोर्ड एनिमेटेड हो सकते हैं! फिर यह एक अत्यंत दृश्य वस्तु है, जो हमें कल्पना करने की अनुमति देती है कि यह सब कैसे काम करेगा।

लाइव प्रोटोटाइप की तुलना में एनीमेशन बहुत तेजी से किया जा सकता है। बेशक, इंटरफ़ेस के साथ कोई वास्तविक बातचीत नहीं होगी, लेकिन मुख्य मामलों को काफी अच्छी तरह से दिखाया जा सकता है।

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


टारगेटप्रोसेस 3 में समय के साथ मांग कार्ड की प्रगति में परिवर्तन।

एनीमेशन बुनियादी चीजों को दिखा सकता है, लेकिन जटिल मामलों को एनिमेशन करना काफी समस्याग्रस्त और लंबा है।


टारगेटप्रोसेस 3 सूचियों में फास्ट डेटा एडिटिंग

कागज के प्रोटोटाइप

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

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

आप एक बैकपैक में एक पेपर सेट रख सकते हैं और भयभीत उपयोगकर्ताओं की तलाश में जा सकते हैं जो स्टारबक्स में सरल लट्टे के लिए आपके प्रोटोटाइप की सराहना करेंगे और आपको उनकी ... मौलिकता की गहराई का पता लगाएंगे।

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


IPad आवेदन के पेपर प्रोटोटाइप (जो हमने करना शुरू कर दिया, लेकिन खत्म नहीं किया)।


पंजीकरण फॉर्म को कागज के प्रोटोटाइप का एक अच्छा उदाहरण

इंटरएक्टिव चश्मा

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

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

लाइव प्रोटोटाइप

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

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

ऐसा लगता है कि बेहतर कुछ भी वांछित नहीं हो सकता है। लेकिन सब कुछ इतना रसपूर्ण नहीं है, प्रोटोटाइप पूरी तरह से विनिर्देश को प्रतिस्थापित नहीं कर सकता है।

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

दूसरी समस्या छोटे भागों की कमी है। प्रोटोटाइप आमतौर पर तैयार डिजाइन से काफी भिन्न होता है। यह आम तौर पर काफी डरावना लग सकता है, सबसे महत्वपूर्ण रूप से एक कार्यकर्ता।


टारगेटप्रोसेस 3 का पहला प्रोटोटाइप, अवधारणा का परीक्षण करने के लिए बनाया गया। यह ग्राहकों को दिखाया गया और सामान्य अनुमोदन का कारण बना। क्लिक करने योग्य , लेकिन वह सब कुछ नहीं जो काम करता है।

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

इसलिए प्रोटोटाइप विनिर्देश को प्रतिस्थापित नहीं करता है। पूरी तरह से पूरक - यह कृपया है। लेकिन मुझे सावधान रहना चाहिए कि एक उत्पाद प्रबंधक के साथ खुफिया में न जाएं जो डेवलपर को "यहां सब कुछ स्पष्ट है, शुरू करें" शब्दों के साथ एक प्रोटोटाइप देता है।

एक और माइनस समय है। प्रोटोटाइप लंबे समय तक करते हैं। सामान्य तौर पर, दो प्रकार के डेवलपर होते हैं: तेज और धीमा। आप तेजी से प्रोटोटाइप विकास पर भरोसा कर सकते हैं, धीमा - किसी भी मामले में। प्रोटोटाइप में कोड की गुणवत्ता, जैसा कि आप जानते हैं, मनमाने ढंग से खराब हो सकता है। मुख्य बात यह है कि आवश्यक स्क्रिप्ट काम करती हैं। और ऐसा लगता है कि केओ अब मुझे पीठ पर थपथपा रहा है, लेकिन मैंने खुद अतीत में ऐसी गलतियां की हैं।

विशिष्टता = दृश्य स्पष्टीकरण

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

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


एक बोतल में विचारों को व्यक्त करने के सभी तरीके।

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

अच्छाई की राह पर चलें, दोस्तों! स्पष्ट दृश्य विशिष्टताओं का निर्माण करें जो कहानियों को सरल भाषा में बताती हैं।

PS मेरे पास अभी भी 20 सुंदर चित्र हैं, लेकिन लेख बहुत बड़ा है, इसलिए क्षमा करें।