एक गैर-तकनीकी व्यक्ति कैसे छोटी परियोजनाओं के लिए एक युक्ति लिखना सीख सकता है?


24

एक गैर-तकनीकी व्यक्ति कैसे छोटी परियोजनाओं के लिए चश्मा लिखना सीख सकता है?

मेरा एक दोस्त एक सांख्यिकी परियोजना पर कुछ विकास को आउटसोर्स करने की कोशिश कर रहा है।

विशेष रूप से, वह एक्सेल में बहुत काम करता है, और स्क्रिप्ट के निर्माण को आउटसोर्स करना चाहता है जो वह अब हाथ से करता है।

हालाँकि, मेरा दोस्त बेहद गैर-तकनीकी है। वह तकनीकी चश्मा लिखने में गरीब है।

जब वह एक युक्ति लिखता है, तो यह लिखा जाता है कि आप एक्सेल में कुछ करने का वर्णन करेंगे (इस सेल पर जाएं और फिर उस सेल का मान कॉपी करें)। यह अत्यधिक क्रिया भी है, और कई बार उदाहरण देता है। मुझे यकीन नहीं है कि वह ठीक से कोने के मामलों का वर्णन करता है।

पहली परियोजना जो उन्होंने आउटसोर्स की थी, वह असफल रही। मुझे लगता है कि उन्होंने कुछ विवरणों को रेखांकित किया, लेकिन कोने के मामलों को रेखांकित किया। वह और / या कोडर जो उसने काम पर रखा है, कोने के मामलों के माध्यम से नहीं सोचा और उचित प्रश्न पूछें। मुझे यकीन नहीं है। मैं उसके साथ आईएम पर गया और मुझे एक विवरण खोदने में आधा घंटा लग गया जिसे वर्णन करने में पाँच मिनट या उससे कम समय लगना चाहिए था। मैंने अंत में उसके लिए स्क्रिप्ट लिखी, लेकिन यह जांच नहीं की कि कोडर के साथ उसकी प्रक्रिया क्यों विफल रही।

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

उसके लिए सीखने का सही तरीका क्या है? क्या ऐसे संसाधन हैं जिनका वह उपयोग कर सकता है? क्या ऐसे तरीके हैं जिनसे वह कोडर के साथ छोटे, कम दबाव वाले अभ्यास परियोजनाओं से सीख सकता है?

उनकी अधिकांश लिपियाँ सांख्यिकीय और डेटा प्रोसेसिंग उन्मुख हैं। उदाहरण के लिए इस कॉलम को लें और इसके ऊपर एक औसत चलाएं। इन शर्तों के तहत इन पंक्तियों को हटा दें। तो चुनौती एक वेब ऐप को दर्शाने से अलग है।


8
मैं आपका दोस्त वास्तव में गैर-तकनीकी हूं, वह वैध आंकड़े कैसे बना सकता है?
पीटर बी

क्या यह एजाइल / स्क्रैम के लिए नहीं बनाया गया था?
डेल्ट्री

जवाबों:


18

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

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

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

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

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


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

इस विषय पर एक और पुस्तक है:
मास्टरीइंग

एरिक इवांस की पुस्तक 'डोमेन ड्रिवेन डिज़ाइन' इस बारे में है कि डेवलपर्स कैसे डोमेन विशेषज्ञों से ज्ञान प्राप्त कर सकते हैं। तो, इसमें रुचि रखने वाले लोगों के लिए प्रासंगिक हो सकता है।
JW01

एक विशेष प्रारूप में अच्छा लिखने में सक्षम होना कुछ ऐसा है जो (मेरे अनुभव में) नियमित रूप से कम करके आंका जाता है।
मार्को

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

5

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

वास्तव में "इस कॉलम को लें और इसके ऊपर एक औसत चलाएं।" सही दिशा में एक कदम है। एक बेहतर व्याख्या होगी "तालिका में यह और वह है" (यदि संरचना पूर्वनिर्धारित है); "एक्स का औसत प्राप्त करें"। मूल रूप से, विवरण खोए बिना संभव कम से कम तकनीकी तरीका।

दूसरे शब्दों में, विचार का वर्णन करें, कार्यान्वयन का नहीं।

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

यदि कोई ऐसा नहीं है जो पर्याप्त देखभाल करता है और प्रक्रिया को समझता है, तो परियोजना किसी भी मामले में विफल हो जाएगी।


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

4

वह स्टोरीबोर्ड दृष्टिकोण का उपयोग करने की कोशिश कर सकता है ।

क्या उसने उन चीजों ( कहानियों ) की एक सूची लिखी है, जो एप्लिकेशन को उस सूची में करनी है और प्रत्येक कहानी की कार्यक्षमता के बारे में विस्तार से बताना है।

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


हां, यह वेब ऐप चश्मा के लिए एक अच्छा तरीका है। हालाँकि, उनकी अधिकांश लिपियाँ सांख्यिकीय और डेटा प्रोसेसिंग उन्मुख हैं। उदाहरण के लिए इस कॉलम को लें और इसके ऊपर एक औसत चलाएं। इसलिए मुझे यकीन नहीं है कि कहानी बोर्डिंग उपयुक्त है।
जोसेफ टुरियन

3

इसे स्पष्ट आवश्यकताओं में अनुवाद करना स्पष्ट रूप से लिखित कल्पना पर अमल करने की तुलना में 10 गुना अधिक काम है।

तथास्तु। यह भी बताते हैं कि क्यों:

कोडर को उन्होंने काम पर रखा और कोने के मामलों के बारे में नहीं सोचा और उचित प्रश्न पूछे।

आवश्यकताओं को समझना सबसे प्रोग्रामिंग परियोजनाओं का सबसे कठिन (और सबसे महंगा) हिस्सा है। जब एक गैर-तकनीकी व्यक्ति आवश्यकताएं लिखता है, तो वे अक्सर केवल काम के दस्तावेज का निर्माण करते हैं-चारों ओर वे प्रतिस्थापित करना चाहते हैं ("एक्सेल खोलें, सेल बी 3 पर क्लिक करें ...")। वे जो सबसे अच्छी उम्मीद कर सकते हैं, वह उनकी मौजूदा कठिनाई का एक सटीक डुप्लिकेट है!

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

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

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


2

कोडर वह काम पर रखा है ... उचित प्रश्न पूछें

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

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

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

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


1

उनकी अधिकांश लिपियाँ सांख्यिकीय और डेटा प्रोसेसिंग उन्मुख हैं। उदाहरण के लिए इस कॉलम को लें और इसके ऊपर एक औसत चलाएं। इन शर्तों के तहत इन पंक्तियों को हटा दें। तो चुनौती एक वेब ऐप को दर्शाने से अलग है।

यह अलग है - यह वेब ऐप को निर्दिष्ट करने की तुलना में बहुत सरल लगता है। यह एक तार्किक प्रक्रिया है। यह आसान सामान है।

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

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

ध्यान दें कि मैंने 'सक्षम' कहा - यह 'औसत' के समान नहीं है, क्योंकि बहुत सारे 'औसत' डेवलपर्स हैं जो सक्षम नहीं हैं। यदि आपका दोस्त सिर्फ सबसे सस्ता कोडर बनाता है, या बस किसी को ऑनलाइन पाता है, तो उसे समस्याओं की उम्मीद करनी चाहिए। यह सुझाव देने के लिए नहीं कि ऑनलाइन काम खोजने वाले लोग अच्छे नहीं हैं, लेकिन आप किसी की सिफारिश के बिना नौकरी नहीं करेंगे।

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


0

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

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

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

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

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

लेकिन संक्षेप में, मुख्य बिंदु यह है कि आपकी भाषा सीखना आपके ग्राहक का काम नहीं है, यह आपकी भाषा सीखने के लिए है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.