बिज़नेस एनालिस्ट इंटरव्यू के सवाल और जवाब (हिंदी में)

BRD यानी business requirements document बताता है कि बिज़नेस को क्या चाहिए और क्यों: समस्या, उद्देश्य, scope और ऊंचे स्तर की requirements। यह sponsor और बिज़नेस टीम के लिए होता है। FRD बताता है कि system को क्या करना है, जैसे screens, नियम और validations, ताकि design और development टीम समझ सके। SRS सबसे विस्तृत होता है, जिसमें functional के साथ performance, security जैसी non-functional requirements और interfaces भी होते हैं। कई agile टीमों में ये अलग document नहीं होते, पर यही जानकारी user stories और wiki में रहती है।

मैं format रखता हूं: एक तरह के user के रूप में, मुझे यह सुविधा चाहिए, ताकि मुझे यह फ़ायदा मिले। जैसे, ब्रांच मैनेजर के रूप में मुझे daily cash report Excel में download करनी है, ताकि मैं उसे ledger से मिला सकूं। Acceptance criteria मैं Given, When, Then में लिखता हूं: अगर मैनेजर अपनी ब्रांच चुनता है और download दबाता है, तो उसी दिन के लेन-देन वाली file मिलनी चाहिए। Story इतनी छोटी रखता हूं कि एक sprint में पूरी हो, और developers व tester के साथ refinement में उसे जांचता हूं।

मैं बातचीत को राय से हटाकर मापदंड पर लाता हूं। अक्सर MoSCoW इस्तेमाल करता हूं: must have, should have, could have और इस बार नहीं। Must have का मतलब है कि इसके बिना release बेकार है या कानूनी तौर पर गलत होगा। फ़ैसले के लिए मैं हर requirement के सामने business value, कितने users पर असर, regulatory ज़रूरत और development का अनुमान रखता हूं। फिर sponsor के साथ बैठकर यह तय करवाता हूं कि सीमित समय में क्या पहले जाएगा। लिखित तर्क होने से बाद में विवाद कम होता है।

RTM एक table है जो हर requirement को उसके स्रोत, design, उसे बनाने वाली user story या code और उसे जांचने वाले test cases से जोड़ती है। इसका पहला फ़ायदा यह है कि कोई requirement बिना test के छूटती नहीं। दूसरा, जब कोई बदलाव आता है तो तुरंत दिखता है कि किन screens और tests पर असर होगा। तीसरा, audit या regulated प्रोजेक्ट में यह सबूत बनती है कि हर नियम लागू हुआ। एक banking प्रोजेक्ट में इसी से UAT से पहले दो छूटे हुए validations पकड़े गए थे।

मैं customers table से select करूंगा और orders table के साथ NOT EXISTS लगाऊंगा। यानी हर ग्राहक के लिए जांचूंगा कि orders में उसकी customer id वाली ऐसी कोई row न हो जिसकी order date आज से नब्बे दिन पहले के बाद की हो। NOT EXISTS इसलिए चुनता हूं क्योंकि NOT IN में अगर subquery में NULL आ जाए तो नतीजा गलत हो सकता है। इसमें वे ग्राहक भी आ जाएंगे जिन्होंने कभी order नहीं किया, इसलिए पहले बिज़नेस से पूछूंगा कि उन्हें गिनना है या नहीं।

पहले मैं बदलाव और उसकी वजह साफ़ करता हूं, क्योंकि कई बार असली ज़रूरत किसी और आसान तरीके से पूरी हो जाती है। फिर देखता हूं कि किन user stories, business rules, screens, integrations, reports और test cases पर असर पड़ेगा। Developers और tester से अनुमान लेता हूं। ये सब product owner के सामने रखता हूं, साथ में विकल्प: इसी sprint में कोई दूसरी story हटाकर लेना, या अगले sprint में रखना। फ़ैसला होने पर backlog, RTM और documents अपडेट करता हूं ताकि सबके पास एक ही जानकारी रहे।

एक NBFC के customer onboarding system में sales चाहती थी कि fields कम हों ताकि agents जल्दी ग्राहक जोड़ सकें, जबकि risk टीम शुरू में ही पूरी income और address verification चाहती थी। मैंने दोनों की requirements लिखीं और हर field के पीछे का कारण पूछा। पता चला कि risk को पूरी जानकारी loan मंज़ूर होने से पहले चाहिए, form भरते समय नहीं। हमने onboarding दो चरणों में बांटा: पहले छोटी जानकारी, फिर disbursement से पहले verification। दोनों heads ने इसे मंज़ूर किया।

एक HR leave system में मैंने लिखा था कि leave balance हर महीने calculate होगा। यह मैंने policy document से लिया था और payroll टीम से पुष्टि नहीं की थी। UAT में payroll ने बताया कि कुछ तरह की leave साल में एक बार जुड़ती है। इसे ठीक करने में कुछ दिन का rework लगा। मैंने टीम के सामने अपनी गलती मानी। उसके बाद से हर calculation वाली requirement को उस टीम से लिखित पुष्टि करवाता हूं जो रोज़ यह काम करती है, सिर्फ़ document पर भरोसा नहीं करता।

एक regional sales head नए CRM dashboard में चालीस extra columns चाहते थे, क्योंकि उनकी पुरानी Excel report में ये थे। सीधे मना करने के बजाय मैंने उनसे पूछा कि वे हर हफ़्ते report का इस्तेमाल कैसे करते हैं। पता चला कि वे असल में सिर्फ़ छह columns देखते थे, बाकी आदत से रखे थे। मैंने उन्हें छह मुख्य columns वाला dashboard और बाकी जानकारी के लिए export का विकल्प दिखाया। वे मान गए, और dashboard तेज़ और साफ़ बना।

मैंने पिछले कुछ साल lending और payments प्रोजेक्ट पर BA के तौर पर काम किया है, इसलिए onboarding, credit check और repayment flows समझता हूं। आपकी कंपनी cooperative banks के लिए software बनाती है, जिनके पुराने processes और नियम अलग होते हैं। मुझे ऐसी जगह काम करना अच्छा लगता है जहां users की असली मुश्किल समझकर उसे system में उतारना पड़े। मेरा banking अनुभव यहां सीधे काम आएगा, और cooperative sector के नियम मैं जल्दी सीखने के लिए तैयार हूं।

मेरे पास banking प्रोजेक्ट में BA का कुछ साल का अनुभव है, जिसमें SQL और Jira पर agile delivery शामिल है। इस भूमिका में क्लाइंट से सीधी बातचीत और UAT का नेतृत्व भी है, जो मेरे अभी के काम से ज़्यादा है। इसलिए मैं अपनी current CTC से उचित बढ़ोतरी चाहता हूं, जो इस स्तर की BA भूमिकाओं के आम दायरे में हो। मेरी current salary की जानकारी मैं दे सकता हूं। Fixed हिस्सा, learning budget और growth path देखकर मैं बातचीत के लिए खुला हूं।

मैं coding कर सकता हूं, और कॉलेज में मैंने canteen के लिए एक छोटा inventory app भी बनाया था। लेकिन उसमें मुझे सबसे अच्छा हिस्सा coding नहीं लगा। सबसे अच्छा लगा canteen staff के साथ बैठकर यह समझना कि stock क्यों ख़त्म हो जाता है और वे असल में क्या चाहते हैं। तब समझ आया कि मुझे समस्या को समझना और उसे साफ़ requirement में बदलना ज़्यादा पसंद है। मेरी technical समझ developers से बात करने में मदद करेगी, और SQL मैं पहले से जानता हूं।