मुझे TK की आवश्यकता क्यों है? मुझे पहले से ही पता है!

_Notreading_ TK की समस्या लगभग हर बार उठती है जब TK के "लेखक" और डेवलपर्स विभिन्न कार्यालयों के लोग होते हैं।

यह पोस्ट इंटरफेस के विकास के लिए संदर्भ की शर्तों के बारे में है [उपयोगकर्ताओं के लिए]।

डेवलपर्स हर किसी की तरह लोग हैं। लिपिक भाषा में लिखे इंटरफेस के बारे में तलमुद को पढ़ना शायद बहुत सुखद शगल नहीं है। इंटरफ़ेस विशेषज्ञ तकनीकी विनिर्देश विकसित करते हैं और उन्हें ग्राहकों को सौंपते हैं। और वे संदर्भ (या विनिर्देश) की शर्तों को पढ़ने के लिए कहते हैं - डिज़ाइन किए गए इंटरफ़ेस को कैसे विकसित और संशोधित किया जाए।

डिज़ाइन किए गए इंटरफ़ेस के विकास के लिए संदर्भ की शर्तें क्या शामिल हैं?

आमतौर पर, ठेकेदार काम के विवरण के स्तर पर सहमत हो सकता है:

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

टीके दो सवालों के जवाब देने में मदद करता है

1. इंटरफ़ेस SO- बनाया गया है?
2. क्या इसका उपयोग किया जा सकता है और वास्तविक विकास में इसे कैसे लागू किया जाए?

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

लेकिन आप स्थिति पर एक अलग नज़र डाल सकते हैं "मैं पहले से ही सब कुछ जानता हूं।"

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

वास्तविक जीवन में

इंटरफ़ेस अवधारणा के विकास के चरण में डिजाइन चरण से पहले टीके पर चर्चा करना बेहतर है:

• अधिमानतः, तकनीकी सीमाओं, बजट विकल्पों और विकास संसाधनों पर चर्चा करना आवश्यक है जो वास्तविकता में लागू होते हैं (अन्यथा आप एक लाख, या बहुत सारे काम का आविष्कार कर सकते हैं);
• अधिकतम के रूप में, अपने मौजूदा और भविष्य के ग्राहकों की कथित कठिनाइयों पर चर्चा करें, क्या वे आपके द्वारा विकसित उत्पाद का उपयोग करेंगे जैसा कि अवधारणा में वर्णित है, क्या उनके पास कोई प्रतिबंध है, क्या यह संभव है?

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

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

पहला सवाल "क्या इंटरफ़ेस SO-DONE है?"

SO उपयोगकर्ता की आवश्यकताओं (उपयोगकर्ता पहले आता है), व्यावसायिक आवश्यकताओं, विकास की आवश्यकताओं को पूरा करने के लिए है।

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

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

दूसरा सवाल "क्या मैं विकास के लिए डिज़ाइन किए गए इंटरफ़ेस का उपयोग कर सकता हूं"

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

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

लेकिन कोई आदर्श नहीं है

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

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

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

तो टीके क्यों पढ़ें?

0. न केवल पढ़ें, बल्कि भाग भी लें;
1. विकास का अनुभव अच्छा है, और संतुष्ट उपयोगकर्ता अधिक महत्वपूर्ण हैं (ग्राहक या कर्मचारी => या पैसा जो लाता है, या समय जो बचाया जाता है, या दोनों);
2. उपयोगकर्ता और ग्राहक के अनुभव के आधार पर उपयोगकर्ता और सिस्टम की गैर-स्पष्ट बातचीत के साथ त्रुटियों को रोकने के लिए, और डेवलपर नहीं;
3. टीके को उपयोगकर्ता की आवश्यकताओं के अनुपालन के लिए विकसित उत्पाद की जांच के लिए चेकलिस्ट के रूप में उपयोग किया जाना चाहिए।
4. टीके इंटरफ़ेस को बदलने का वर्णन करता है: सभी पक्षों को नुकसान पहुंचाए बिना, किन मामलों में और किस क्रम में।

और यह केवल एक तरफ का दृश्य है।
मैं TK - डेवलपर्स के पाठकों की राय सुनना चाहूंगा।