हम प्रोग्रामर से रूसी में अनुवाद करते हैं

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

आइए अधिक विस्तार से विचार करने का प्रयास करें:

मुख्यमंत्री। वह अवधारणा का वर्णन करता है। कहते हैं: “मैं चाहता हूं कि यह नीला हो, लेकिन यह बटन सब कुछ कम कर देता है। और यहाँ, विंडोज 8 में जैसा कि | iOS | उस एप्लिकेशन में | प्रतियोगी से बेहतर (अनावश्यक को पार करें)। और, जाहिर है , यह सब कुछ लाल रंग में करने और वर्गों में करने में सक्षम होना चाहिए। "

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

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

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

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

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

कुल मिलाकर, विकास प्रक्रिया में उपर्युक्त प्रतिभागियों में से प्रत्येक को इसके "समाशोधन" द्वारा अच्छी तरह से निर्देशित किया जाता है, लेकिन ज्यादातर में उत्पाद की पूरी तस्वीर नहीं होती है।

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

वैसे, क्या आप किसी उत्पाद को बेहतर बनाने का सबसे तेज़ तरीका जानते हैं? बेशक, बटन का नाम बदलें! यहाँ इस विषय पर प्रसिद्ध हास्य पट्टी का एक रूपांतर है vonvogel :

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

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

और तकनीकी लेखक उपयोगकर्ता गाइड, व्यवस्थापक गाइड, लघु उपयोगकर्ता गाइड, और बहुत कुछ बनाते हैं। प्रत्येक दस्तावेज़ का अपना उद्देश्य होता है, जिसका अर्थ है अपनी विशेषताओं और बारीकियों।

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

एक और कहानी है। हमने कुछ साल पहले फाइनरएडर एन जारी किया था। सब कुछ वैसा ही था जैसा कि फ़ाइल के साथ होना चाहिए: विश्लेषकों ने विश्लेषण किया, डिजाइनरों ने चित्रित किया, प्रोग्रामर ने कार्यान्वित किया, तकनीकी विवरण का वर्णन किया गया और सब कुछ 22 भाषाओं में अनुवादित किया गया। और यहाँ आप बीटा परीक्षण है। और उपयोगकर्ता हमें बताते हैं (या बल्कि, यहां तक ​​कि एक उपयोगकर्ता, या बल्कि, उपयोगकर्ता नंबर एक): “और हमें दो आज्ञाओं को वापस करें, ठीक है, हम सिर्फ उनके बिना नहीं रह सकते। हां, एक ही समय में दो अतिरिक्त स्क्रिप्ट हटा दें। " उन्होंने डीएम से पूछा कि कब तक बदलना है। "नहीं," वह कहते हैं, दो पंक्तियों पर टिप्पणी करें और दो को हटा दें। तकनीकी लेखकों को छोड़कर सभी को खुशी हुई। उपयोगकर्ता मैनुअल (जो कि उस समय पहले से ही बना हुआ था), QRC (उर्फ क्विक रेफरेंस कार्ड या एक त्वरित परिचित कार्ड) में मदद करने के लिए उन्हें प्रोग्राम के संसाधनों में बदलाव करने की जरूरत थी, स्क्रीनशॉट के भाग को रीटेक करने के लिए ... एक भाषा के लिए, 49 संस्करण सामने आए। स्वयं भाषाओं की संख्या से गुणा करें ( एमकेवीओशेव से एक ड्राइंग मदद कर सकती है यदि कैल्क काम नहीं करता है। चित्र के लिए वीडियो स्पष्टीकरण )।

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

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

एलेना फोमेनको की भागीदारी के साथ इवान कोर्निव क्रोनोमैस्टर
पाठ पहचान उत्पादों का विभाग।