एक विश्लेषक बनना

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

आगे की संरचना को तुरंत बयान करें:

1. संक्षिप्त परिचय
2. विश्लेषकों - यह कौन है? + तकनीकी पीछे हटना
3. हमें विश्लेषकों की आवश्यकता क्यों है? (हैलो कैप)
4. विश्लेषक कौन और कैसे बनता है?
5. एक विश्लेषक को क्या पता होना चाहिए और यह जानने में सक्षम होना चाहिए कि यह कैसे करना है?
6. निष्कर्ष।

इनमें से कुछ विषय स्पष्ट दिखते हैं। मैं कम से कम कप्तानी करने की कोशिश करूंगा।

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

संक्षिप्त परिचय

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

आईटी एनालिटिक्स पर पुस्तकों की संख्या भी अन्य आईटी विषयों की तुलना में काफी कम है (मुझे इस मुद्दे पर गलती करने में खुशी होगी - शायद इस क्षेत्र की कुछ महत्वपूर्ण पुस्तकों ने मुझे पास कर दिया है)। यहां तक ​​कि Habré पर, पिछले कुछ वर्षों के लिए विश्लेषिकी पर सीधे लेख लगभग एक हाथ ( 1 , 2 , 3 , 4 ) की उंगलियों पर गिना जा सकता है। खैर, हाँ, हमारे पास जो है वह हमारे पास है। अंत में, सब कुछ हमारे हाथ में है।

विश्लेषकों - यह कौन है?

आईटी क्षेत्र में, बड़े और बड़े, दो प्रकार के उनके विशेषज्ञता को प्रतिष्ठित किया जा सकता है:

• सिस्टम विश्लेषकों
• व्यावसायिक बुद्धि (यह भूमिका न केवल आईटी पर लागू होती है)।

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

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

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

संक्षिप्त तकनीकी विषयांतर

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

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

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

कार्यात्मक आवश्यकताओं
वे कार्यक्षमता के सभी तत्वों का विस्तार से वर्णन करते हैं, जिन्हें उपयोगकर्ता आवश्यकताओं में वर्णित सभी उपयोग परिदृश्यों को पूरा करने की संभावना सुनिश्चित करने के लिए सिस्टम में सीधे लागू किया जाना चाहिए।
कार्यात्मक आवश्यकताएं सबसे विस्तृत हैं। वे वर्णन करते हैं, जिसमें इनपुट / आउटपुट डेटा और इसके चेक, डेटा प्रोसेसिंग एल्गोरिदम और उपयोगकर्ता इंटरफ़ेस तत्व (बिना डिजाइन) शामिल हैं।
एक नियम के रूप में, इन आवश्यकताओं को एक अलग दस्तावेज़ ("संदर्भ की शर्तें", आदि) के रूप में किया जाता है। एक ही दस्तावेज़ में, सिस्टम (उपयोगकर्ता आवश्यकताएँ) का उपयोग करने के परिदृश्य विस्तृत हैं, जिसमें कार्यात्मक आवश्यकताएं आमतौर पर जुड़ी हुई हैं।
एक कार्यात्मक आवश्यकता का एक उदाहरण: "फॉर्म < बटन B> बटन <बटन A> पर क्लिक करके, एक मोडल डायलॉग बॉक्स जिसमें <Window सामग्री है > प्रदर्शित होनी चाहिए।"

प्रकार से:
कार्यात्मक आवश्यकताओं
वे सीधे सिस्टम द्वारा कार्यान्वित कार्यक्षमता का वर्णन करते हैं (एक उदाहरण ऊपर "कार्यात्मक आवश्यकताओं" में उनके स्तर से आवश्यकताओं के वर्गीकरण के विवरण में दिया गया है);

गैर-कार्यात्मक आवश्यकताएं
वे प्रणाली और उसके वातावरण की विशेषताओं, साथ ही लगाए गए प्रतिबंधों का वर्णन करते हैं।
गैर-कार्यात्मक आवश्यकताओं के उदाहरणों में हार्डवेयर प्लेटफॉर्म और विकसित सिस्टम द्वारा समर्थित ऑपरेटिंग सिस्टम, साथ ही प्रदर्शन, सुरक्षा आदि पर प्रतिबंध शामिल हो सकते हैं।

नोट:
जैसा कि ऊपर वर्णित विवरण से देखा जा सकता है, कार्यात्मक आवश्यकताएं अपने स्तर और प्रकार दोनों के संदर्भ में आवश्यकताओं की एक श्रेणी हैं। दुर्भाग्य से, इस समय, ऐसी अस्पष्ट शब्दावली विकसित हुई है (कई परियोजनाओं और कई नियोक्ताओं के अनुभव के आधार पर)। यदि आपके पास अन्य दृष्टिकोण हैं, तो कृपया साझा करें।

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

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

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

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

आवश्यकताओं को स्वयं एकत्रित करने की प्रक्रिया:

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

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

प्रबंधन बदलें
आधुनिक सॉफ्टवेयर सिस्टम विकसित करते समय, विश्लेषण चरण के अंत में आवश्यकताओं में बदलाव करना अक्सर आवश्यक होता है। यहां यह महत्वपूर्ण है कि पार्टियां निम्नलिखित सिद्धांतों को समझें और स्वीकार करें:

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

सूचना संसाधनों, हितधारकों, विषय वस्तु विशेषज्ञों और तकनीकी विशेषज्ञों की उपलब्धता
सिस्टम के लिए आवश्यकताओं की एक पूर्ण और सटीक सूची बनाने के लिए, ठेकेदार के विशेषज्ञों के पास पर्याप्त पहुंच होनी चाहिए:

• सॉफ्टवेयर विकास से संबंधित सभी सामग्रियों के लिए;
• सभी प्रमुख मीडिया और आवश्यक प्राधिकारी वाले व्यक्ति

दूसरे मामले में, हमारा मतलब है:

1. इच्छुक पक्ष
2. डोमेन विशेषज्ञ
3. आवश्यकताओं के समन्वय और अनुमोदन में शामिल व्यक्ति
4. ग्राहक या अन्य ठेकेदारों / उपठेकेदारों की ओर से तकनीकी विशेषज्ञ।

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

हमें विश्लेषकों की आवश्यकता क्यों है? (हैलो कैप)

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

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

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

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

कौन और कैसे (श्रम के संदर्भ में) एक विश्लेषक बन जाता है?

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

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

एक विश्लेषक को क्या पता होना चाहिए / सक्षम होना चाहिए और यह कैसे सीखना चाहिए?

जो लोग “द वे ऑफ द एनालिस्ट” किताब पढ़ते हैं। IT-», , , , . , , , , , .

, - , ( , ) . , , . Talisker 16 yo, ( - , , , ()), , ( ), .
, , . , . , , .

, , – . , .
, :

• ;
• (waterfall, RUP, - Agile, Scrum, . – 19 ( ) 34 ( ));
• ( );
• ( , : Sparx Enterprise Architect Rational Rose; UML/Aris/IDEF0 IDEF3);
• ;
• आदि

Word- (). , . - – , «» . Visio Evolus Pencil.
, , , , «». .

निष्कर्ष

, , . , , , . - , , . . Lifelong learning!