🤷 ⚪️ 🚀 व्यापार और सिस्टम विश्लेषक। आप क्या जानना चाहते है 🚡 🎢 🖐️

अभिवादन! मेरा नाम सर्गेई है, और मैं एक व्यवसाय / सिस्टम विश्लेषक हूं। मैं आईटी उद्योग में लगभग 8 वर्षों से काम कर रहा हूं, समर्थन के साथ शुरू हुआ जो परीक्षण में बह रहा है और विश्लेषण के साथ जारी है: दोनों व्यापार और प्रणाली। मैंने अभी तक एक व्यवसाय और एक सिस्टम विश्लेषक के रूप में अलग से काम नहीं किया है।

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

किसके लिए, मेरी राय में, लेख उपयोगी होगा:

व्यवसाय / सिस्टम विश्लेषकों की शुरुआत;
विश्लेषकों जो अपने प्रोफेसर को पंप करना जारी रखना चाहते हैं। कौशल
शायद भर्ती प्रबंधक।

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

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

व्यापारिक विश्लेषणात्मक

शुरुआती चरणों में अस्पष्ट आवश्यकताओं को हटा दें

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

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

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

आवश्यकता की आवश्यकताओं के बारे में ग्राहक के साथ जांच करने से डरो मत

मैं ऐसे मामलों से मिला जब मैंने एक व्यावसायिक लक्ष्य को तय किए बिना विकास वक्तव्य का वर्णन किया था: क्या यह पूरा होने से व्यवसाय को मदद मिलेगी? यह शोधन व्यवसाय से किस दर्द से छुटकारा दिलाएगा?

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

ग्राहक के साथ मिलकर लक्ष्य लिखें, ताकि किसी भी समय इस प्रक्रिया में सभी प्रतिभागी समझ सकें कि वे अपना काम क्यों कर रहे हैं।

व्यावसायिक बैठकों में अपने ग्राहक की उपस्थिति की मांग करें

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

, — UX- — « », , . : , , windows-, . , .

कई विश्लेषकों ने, स्वयं सहित, आवश्यकताओं को तैयार करने की प्रक्रिया में, एक कठिन समय सीमा के साथ सामना किया, निम्नलिखित तकनीक का उपयोग किया: उन्होंने प्रक्रिया के प्रतिभागियों को एक समय सीमा के साथ एक पत्र लिखा, जिसके द्वारा पत्र का उत्तर दिया जाना चाहिए और आवश्यकताओं पर सहमति / टिप्पणी की जानी चाहिए। अन्यथा, आवश्यकताओं को स्वचालित रूप से सहमति के रूप में मान्यता दी जाएगी।

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

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

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

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

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

डेवलपर्स के लिए विषय क्षेत्र का परिचय दें

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

यदि आवश्यक हो (और स्क्रैम की कमी), तो ऐसी बैठक के लिए ग्राहक को आकर्षित करें। एक नियम के रूप में, व्यापार प्रतिनिधि स्वेच्छा से इस तरह की पहल के लिए सहमत हैं।

प्रश्न का उत्तर देने के लिए ग्राहक को सिखाएं "क्या?" प्रारूप में आवश्यकताओं को पूरा करने के बजाय "कैसे"

ग्राहक को "कैसे" स्थिति से व्यवसाय / उपयोगकर्ता की आवश्यकता नहीं बनानी चाहिए: हमें रिपोर्ट बनाने के लिए इस स्क्रीन पर एक बटन की आवश्यकता होती है; हमें इस अनुभाग में एक बाहरी प्रणाली के लिंक की आवश्यकता है; आदि।

प्रक्रिया के प्रारंभिक विश्लेषण के चरण में, डिजाइन से पहले, ग्राहक को समाधान की पेशकश नहीं करनी चाहिए।

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

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

कई मामलों में, यह दृष्टिकोण वास्तविकता का सामना करेगा: समय सीमा और प्राथमिकताएं। लेकिन आपने, किसी भी मामले में, ईमानदारी से कोशिश की।

उपयोगकर्ताओं को कक्षाओं में विभाजित करना सुनिश्चित करें

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

सिस्टम के उपयोगकर्ताओं को भूमिकाओं में विभाजित करें, और कार्यक्षमता जो एक भूमिका के लिए तेज है, किसी अन्य भूमिका के तहत "स्मीयर" न करें।

एक बार, सिस्टम के ढांचे के भीतर, हमने ग्राहकों के साथ लेनदेन की एक सूची प्रदर्शित की।

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

परिणाम एक निश्चित राक्षस था, जिसे बाद में अंतिम रूप दिया और अंतिम रूप दिया जाना था।

यूएक्स से सर्वोत्तम अभ्यासों को लागू करें: पात्रों को बाहर करें - उपयोगकर्ता मॉडल। प्रत्येक चरित्र के लिए आवश्यकताओं को अलग करने के लिए ग्राहक को मनाएं।

सक्रिय रूप से विश्लेषणात्मक बुद्धिशीलता का उपयोग करें

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

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

यदि आप झरने में फंस गए हैं, तो निराशा न करें और स्क्रेम की ओर बढ़ें

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

ग्राहक को कभी डिमॉनेटाइज नहीं करें।

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

टीम को काम करने के लिए अच्छी तरह से प्रेरित किया जाना चाहिए, और प्रेरणा गठन की प्रक्रिया में एक व्यापार विश्लेषक की भूमिका महत्वपूर्ण है।

दखल न दे

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

कोशिश करें और वार्ताकार को सुनें, और उसे सुनें।

परजीवी शब्दों से छुटकारा पाएं

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

 :
-   "    ".
-   ", :    ".

सिस्टम एनालिटिक्स

कार्य को आगे और पीछे सेट करते समय, अनुक्रम आरेख का वर्णन करने का प्रयास करें

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

आरेख के एक क्रम को "ड्रा" करने के लिए, Confluence के लिए PlantUML प्लगइन का उपयोग करें। ऐसा लग रहा था कि पेन के साथ ब्लॉक और एरो के स्थान को समायोजित करने के लिए कोड टाइप करना तेज़ है । लेकिन इस हिस्से में हर किसी का अपना अनुभव और अपनी प्राथमिकताएं होती हैं।

स्वैगर संपादक जानें

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

क्लाइंट अनुरोध और सर्वर से प्रतिक्रियाओं का विश्लेषण करने के लिए लक्ष्य ब्राउज़र में सक्रिय रूप से डेवलपर टूल का उपयोग करें

सबसे पहले, प्रारंभिक स्वीकृति प्रक्रिया के दौरान, आप अपने द्वारा वर्णित एपीआई की जांच कर सकते हैं। कभी-कभी UI की तुलना में निवर्तमान अनुरोधों में से कुछ सुधारों की जांच करना तेज़ होता है, ताकि शुरुआती स्तर पर समस्या की जड़ को समझा जा सके।

एक विश्लेषक के रूप में, आपको डेवलपर से कार्यान्वयन की जांच करने के लिए बहुत कम समय की आवश्यकता होगी: आउटगोइंग डेटा, इनकमिंग डेटा, UI में परिणाम।

दूसरे, आप सही कॉल अनुक्रम को सत्यापित कर सकते हैं। आखिरकार, आपने खुद इसे अनुक्रम आरेख के ढांचे में वर्णित किया।

इस दृष्टिकोण ने हमारी टीम को विलंब के बिना प्रोमों के भाग के रूप में काफी मुश्किल सुधार लाने की अनुमति दी।

 :
-   " JavaScript".   JSON, , HTML, http / https,   .
- . , .  " . , , ".      ,  ,   ,   .

के अतिरिक्त

अपने आप को UX में डुबोएं

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

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

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

 :
-   "  ".
-   "   ".
-   ".   ".
-   ".   ".

***

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

व्यापार और सिस्टम विश्लेषक। आप क्या जानना चाहते है

व्यापारिक विश्लेषणात्मक

सिस्टम एनालिटिक्स

के अतिरिक्त

More articles: