تحلیلگر کسب‌وکار چیست؟ راهنمای جامع (BA)Business Analyst

فرض کنید یک شرکت تصمیم گرفته است یک سیستم جدید برای فروش آنلاین، مدیریت سفارش‌ها یا خدمات مشتریان راه‌اندازی کند. اولین سؤال این نیست که چه کدی باید نوشته شود؟ بلکه ابتدا باید مشخص شود این سیستم قرار است دقیقاً چه مسئله‌ای را حل کند، کاربران چه نیازی دارند و کسب‌وکار از این راهکار چه انتظاری دارد.

در چنین شرایطی، تحلیلگر کسب و کار (Business Analyst) نقش مهمی در تبدیل یک نیاز یا مسئله کسب‌وکار به راهکاری روشن و قابل اجرا دارد. تحلیلگر کسب و کار با Stakeholderها صحبت می‌کند، نیازها و فرآیندهای موجود را بررسی می‌کند، ابهام‌ها و محدودیت‌ها را شناسایی می‌کند و به تیم کمک می‌کند بداند چه چیزی باید ساخته شود و چرا.

البته فعالیت تحلیلگر کسب و کار به پروژه‌های نرم‌افزاری محدود نمی‌شود. این نقش می‌تواند در حوزه‌هایی مانند بانکداری، فروش، خدمات، صنایع و سازمان‌های مختلف برای تحلیل و بهبود فرآیندها، حل مسائل کسب‌وکار و پشتیبانی از تصمیم‌گیری استفاده شود. با این حال، در پروژه‌های نرم‌افزاری، ارتباط تحلیلگر کسب و کار با تیم محصول، توسعه و تست اهمیت ویژه‌ای پیدا می‌کند.

یک نیاز مبهم می‌تواند از همان ابتدا زنجیره‌ای از مشکلات را ایجاد کند؛ از برداشت متفاوت Developer از نیاز گرفته تا طراحی Test Caseهای نامناسب و اختلاف در زمان UAT. به همین دلیل، تحلیلگر کسب و کار فقط با مدیران و کاربران نهایی در ارتباط نیست و در بسیاری از پروژه‌ها با تیم QA و Tester نیز همکاری نزدیکی دارد.

در این مقاله بررسی می‌کنیم تحلیلگر کسب و کار چیست، چه وظایفی دارد، چه مهارت‌هایی نیاز دارد، با چه مستندات و ابزارهایی کار می‌کند و چه تفاوتی با نقش‌هایی مانند تحلیلگر نرم‌افزار، Product Owner و QA دارد. همچنین ارتباط تحلیلگر کسب و کار با نیازمندی‌های نرم‌افزار و تست نرم‌افزار و مسیر ورود به این شغل را بررسی خواهیم کرد.

Table of Contents

۱. تحلیلگر کسب و کار کیست؟

تحلیلگر کسب و کار (Business Analyst یا BA) فردی است که به سازمان کمک می‌کند مسائل، نیازها و فرصت‌های کسب‌وکار را شناسایی و تحلیل کند و آن‌ها را به نیازها و راهکارهای قابل اجرا تبدیل کند.

به زبان ساده، تحلیلگر کسب و کار تلاش می‌کند بین آنچه کسب‌وکار نیاز دارد و راهکاری که قرار است برای پاسخ به این نیاز ایجاد شود ارتباط منطقی برقرار کند. برای این کار، باید وضعیت موجود را درک کند، با افراد و واحدهای مختلف صحبت کند، نیازها و محدودیت‌ها را بررسی کند و مطمئن شود راهکار پیشنهادی واقعاً مسئله موردنظر را هدف قرار می‌دهد.

نکته مهم این است که تحلیلگر کسب و کار الزاماً یک نقش فنی یا نرم‌افزاری نیست. یک BA می‌تواند در یک پروژه تحول سازمانی، بهبود فرآیند فروش، طراحی یک خدمت جدید یا پیاده‌سازی یک سیستم نرم‌افزاری فعالیت کند. چیزی که در همه این موقعیت‌ها اهمیت دارد، تحلیل مسئله و نیاز کسب‌وکار است.

تحلیلگر کسب و کار چه نقشی در یک سازمان دارد؟

در یک سازمان، ممکن است مشکلی وجود داشته باشد که راه‌حل آن در ابتدا کاملاً مشخص نباشد. برای مثال، کاهش فروش، افزایش زمان پاسخ‌گویی به مشتریان یا پیچیده بودن فرآیند ثبت سفارش، صرفاً نشانه‌هایی از یک مسئله هستند و هنوز مشخص نیست ریشه مشکل چیست و چه راهکاری باید برای آن اجرا شود.

تحلیلگر کسب و کار در چنین شرایطی مسئله را بررسی می‌کند، اطلاعات موردنیاز را از Stakeholderها جمع‌آوری می‌کند، فرآیندهای موجود را تحلیل می‌کند و به شناسایی نیازها و گزینه‌های مختلف برای حل مسئله کمک می‌کند.

بنابراین خروجی کار BA صرفاً یک سند نیست. تحلیل درست باید به تصمیم بهتر و راهکاری منجر شود که بتوان ارزش آن را برای کسب‌وکار بررسی و ارزیابی کرد.

تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری چه کاری انجام می‌دهد؟

در پروژه‌های نرم‌افزاری، نقش تحلیلگر کسب و کار معمولاً به نیازسنجی و تحلیل نیازهای کاربران و کسب‌وکار نزدیک‌تر می‌شود. BA باید مشخص کند نرم‌افزار چه مسئله‌ای را حل می‌کند، کاربران چه انتظاری از آن دارند و چه قوانین، محدودیت‌ها و شرایطی باید در راهکار در نظر گرفته شود.

این نیازها پس از تحلیل و شفاف‌سازی، می‌توانند در قالب‌هایی مانند نیازمندی‌های نرم‌افزار، داستان کاربر، یوز کیس و معیارهای پذیرش در اختیار تیم محصول، توسعه و تست قرار بگیرند.

در اینجا کیفیت تحلیل اهمیت زیادی دارد. اگر یک نیاز به‌درستی فهمیده یا مستند نشده باشد، ممکن است Developer برداشت متفاوتی از آن داشته باشد، Tester نتواند رفتار مورد انتظار سیستم را به‌درستی بررسی کند و در نهایت محصولی تولید شود که از نظر فنی کار می‌کند اما نیاز واقعی کسب‌وکار را برآورده نمی‌کند.

به همین دلیل، تحلیلگر کسب و کار در پروژه نرم‌افزاری فقط «نویسنده مستندات» نیست؛ بلکه درک درست مسئله، شفاف‌سازی نیاز و ایجاد درک مشترک میان افراد درگیر در پروژه، بخش مهمی از نقش اوست.

۲. تحلیلگر کسب و کار در چه کسب‌وکارهایی فعالیت می‌کند؟

تحلیلگر کسب و کار محدود به شرکت‌های نرم‌افزاری نیست. هر سازمانی که با مسئله‌های پیچیده، فرآیندهای ناکارآمد، تغییرات سازمانی یا نیاز به تصمیم‌گیری و بهبود عملکرد مواجه باشد، می‌تواند از تحلیل کسب و کار استفاده کند.

البته نوع فعالیت BA با توجه به صنعت و سازمان متفاوت است. در یک شرکت نرم‌افزاری ممکن است تمرکز اصلی روی تحلیل نیازمندی‌های یک محصول باشد، در حالی که در یک بانک یا شرکت خدماتی، تحلیلگر کسب و کار بیشتر روی فرآیندها، نیازهای مشتریان و بهبود روش انجام کار تمرکز کند.

تحلیلگر کسب و کار در شرکت‌های نرم‌افزاری

در شرکت‌های نرم‌افزاری، تحلیلگر کسب و کار معمولاً با Stakeholderها، کاربران، تیم محصول، توسعه و QA در ارتباط است. او نیازهای کسب‌وکار و کاربران را تحلیل می‌کند و به تبدیل آن‌ها به نیازمندی‌هایی کمک می‌کند که تیم بتواند بر اساس آن‌ها راهکار نرم‌افزاری را طراحی و پیاده‌سازی کند.

در این محیط، ارتباط BA با Requirement، User Story، Acceptance Criteria و UAT اهمیت بیشتری پیدا می‌کند؛ زیرا خروجی تحلیل باید بتواند در مراحل طراحی، توسعه، تست و پذیرش محصول مورد استفاده قرار گیرد.

تحلیلگر کسب و کار در بانک و خدمات مالی

در بانک‌ها و شرکت‌های خدمات مالی، تحلیلگر کسب و کار می‌تواند روی فرآیندهایی مانند افتتاح حساب، پرداخت، تسهیلات، خدمات مشتریان یا فرآیندهای داخلی سازمان کار کند.

در این حوزه، علاوه بر نیازهای کاربران و کسب‌وکار، عواملی مانند قوانین، الزامات نظارتی، کنترل‌های داخلی و ریسک نیز می‌توانند در تحلیل مسئله و طراحی فرآیندها اهمیت داشته باشند.

تحلیلگر کسب و کار در فروش و تجارت

در شرکت‌های فروش و تجارت، BA ممکن است فرآیند خرید، فروش، سفارش، ارتباط با مشتری، مدیریت موجودی یا زنجیره تأمین را بررسی کند.

برای مثال، اگر ثبت سفارش برای مشتریان بیش از حد زمان‌بر باشد، تحلیلگر کسب و کار می‌تواند فرآیند فعلی را بررسی کند، نقاط مشکل‌ساز را شناسایی کند و به طراحی فرآیندی ساده‌تر و کارآمدتر کمک کند؛ حتی اگر راه‌حل نهایی الزاماً یک نرم‌افزار جدید نباشد.

تحلیلگر کسب و کار در صنایع و سازمان‌های بزرگ

در صنایعی مانند تولید، لجستیک، مخابرات و همچنین سازمان‌های بزرگ، تحلیلگر کسب و کار می‌تواند روی بهبود فرآیندها، کاهش هزینه، افزایش بهره‌وری، تغییر روش‌های کاری و اجرای پروژه‌های تحول سازمانی فعالیت کند.

در چنین پروژه‌هایی ممکن است بخشی از راهکار شامل تغییر فرآیند یا ساختار سازمانی باشد و بخش دیگری به پیاده‌سازی یا تغییر یک سیستم نرم‌افزاری مربوط شود. بنابراین BA باید بتواند مسئله را از دید کسب‌وکار بررسی کند، نه اینکه از ابتدا فرض کند راه‌حل حتماً یک نرم‌افزار است.

آیا تحلیلگر کسب و کار حتماً باید در حوزه فناوری اطلاعات کار کند؟

خیر. تحلیلگر کسب و کار یک نقش محدود به فناوری اطلاعات نیست. موضوع اصلی این نقش، تحلیل مسئله و نیاز کسب‌وکار و کمک به پیدا کردن راهکار مناسب است.

با این حال، بخش قابل‌توجهی از موقعیت‌های تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری و فناوری اطلاعات تعریف می‌شوند. به همین دلیل، بسیاری از موقعیت‌های شغلی این حوزه روی Requirement، سیستم‌های نرم‌افزاری، Agile و همکاری با تیم‌های توسعه و تست تمرکز دارند.

در ادامه مقاله، تمرکز ما بیشتر روی تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری خواهد بود؛ زیرا در این محیط، ارتباط BA با تحلیل نیازمندی، توسعه نرم‌افزار و تست نرم‌افزار اهمیت ویژه‌ای پیدا می‌کند.

۳. تحلیلگر کسب و کار دقیقاً چه کاری انجام می‌دهد؟

کار تحلیلگر کسب و کار از زمانی شروع می‌شود که یک مسئله، نیاز یا فرصت در کسب‌وکار شناسایی شده است؛ اما هنوز مشخص نیست دقیقاً چه راهکاری باید اجرا شود. BA تلاش می‌کند این فاصله را با بررسی مسئله، جمع‌آوری اطلاعات، تحلیل نیازها و ایجاد درک مشترک میان افراد مختلف پر کند.

این کار یک فعالیت خطی و یک‌باره نیست. در بسیاری از پروژه‌ها، تحلیلگر کسب و کار در طول چرخه عمر پروژه با Stakeholderها و تیم‌های مختلف در ارتباط است و با تغییر شرایط یا آشکار شدن اطلاعات جدید، تحلیل‌ها و نیازمندی‌ها نیز ممکن است تغییر کنند.

شناسایی مسئله و نیاز کسب و کار

اولین قدم، فهمیدن این است که مسئله واقعی چیست. گاهی چیزی که Stakeholder به‌عنوان نیاز مطرح می‌کند، در واقع راه‌حلی است که از قبل برای یک مسئله تصور کرده است.

برای مثال، ممکن است مدیر یک سازمان بگوید: «به یک سیستم جدید برای ثبت سفارش نیاز داریم.» تحلیلگر کسب و کار نباید صرفاً این درخواست را به‌عنوان Requirement ثبت کند. باید بررسی کند چرا سیستم فعلی پاسخ‌گو نیست، مشکل در کدام بخش فرآیند ایجاد می‌شود و کاربران دقیقاً با چه محدودیتی مواجه هستند.

هدف این است که پیش از رفتن به سمت راهکار، مسئله و هدف کسب‌وکار به‌درستی فهمیده شود.

شناسایی و تحلیل Stakeholderها

افراد مختلف ممکن است از یک فرآیند یا محصول انتظارهای متفاوتی داشته باشند. مشتری، مدیر، کاربر نهایی، واحد مالی و تیم فنی ممکن است هرکدام دیدگاه متفاوتی درباره یک قابلیت داشته باشند.

تحلیلگر کسب و کار باید Stakeholderهای مرتبط را شناسایی کند، نیازها و دغدغه‌های آن‌ها را بشناسد و در صورت وجود تضاد یا ابهام، به شفاف شدن موضوع کمک کند.

این کار فقط به جمع‌آوری نظر افراد محدود نمی‌شود؛ BA باید بتواند تشخیص دهد کدام نیاز واقعاً به مسئله کسب‌وکار مرتبط است و چه محدودیت‌ها یا وابستگی‌هایی روی آن تأثیر می‌گذارند.

جمع‌آوری و تحلیل نیازمندی‌ها

پس از شناخت مسئله و Stakeholderها، نوبت به جمع‌آوری و تحلیل نیازها می‌رسد. این کار می‌تواند از طریق مصاحبه، جلسه، مشاهده فرآیند، بررسی مستندات موجود، تحلیل داده‌ها و روش‌های دیگر انجام شود.

اما جمع‌آوری اطلاعات به‌تنهایی کافی نیست. تحلیلگر کسب و کار باید نیازهای به‌دست‌آمده را بررسی کند تا مواردی مانند ابهام، تناقض، تکرار، وابستگی و نیازهای ناقص شناسایی شوند.

در این مرحله، خروجی تحلیل می‌تواند به شکل Requirement یا قالب‌های مناسب دیگر مستند شود.

تبدیل نیاز کسب و کار به Requirement قابل اجرا

یکی از مهم‌ترین وظایف تحلیلگر کسب و کار، تبدیل یک نیاز کلی به اطلاعاتی است که تیم بتواند بر اساس آن راهکار را طراحی و پیاده‌سازی کند.

برای مثال، جمله «کاربر باید بتواند سفارش خود را لغو کند» به‌تنهایی برای پیاده‌سازی کافی نیست. باید مشخص شود لغو سفارش در چه شرایطی مجاز است، در چه مرحله‌ای از فرآیند امکان لغو وجود دارد، در صورت پرداخت وجه چه اتفاقی می‌افتد و برای هر حالت چه نتیجه‌ای مورد انتظار است.

هرچه این جزئیات بهتر تحلیل و شفاف شوند، احتمال برداشت متفاوت افراد از نیاز کمتر خواهد شد.

شناسایی Business Ruleها و محدودیت‌ها

بسیاری از رفتارهای یک کسب‌وکار بر اساس قوانین و محدودیت‌هایی انجام می‌شوند که ممکن است در درخواست اولیه به‌صراحت بیان نشده باشند.

برای مثال، در یک سیستم فروش ممکن است لغو سفارش فقط تا پیش از ارسال امکان‌پذیر باشد یا بازپرداخت وجه برای برخی روش‌های پرداخت شرایط متفاوتی داشته باشد.

تحلیلگر کسب و کار باید این قوانین، محدودیت‌ها و شرایط خاص را شناسایی و مستند کند تا در طراحی راهکار و مراحل بعدی پروژه نادیده گرفته نشوند.

مدل‌سازی و تحلیل فرآیندهای کسب و کار

گاهی برای درک یک مسئله، بررسی متن نیازمندی کافی نیست و باید فرآیند فعلی به‌صورت تصویری یا مرحله‌به‌مرحله بررسی شود.

تحلیلگر کسب و کار می‌تواند فرآیند As-Is را بررسی کند، نقاط مشکل‌ساز را شناسایی کند و در صورت نیاز فرآیند To-Be را برای وضعیت مطلوب تحلیل و مدل‌سازی کند.

این کار کمک می‌کند قبل از پیاده‌سازی راهکار، مشخص شود چه چیزی در فرآیند فعلی باید حفظ، حذف یا تغییر داده شود.

مستندسازی و ایجاد درک مشترک

تحلیلگر کسب و کار باید نتایج تحلیل را به شکلی مستند کند که افراد مختلف بتوانند برداشت مشترکی از آن داشته باشند.

بسته به نوع پروژه و سازمان، این اطلاعات ممکن است در قالب Requirement، BRD، SRS، User Story، Use Case، Acceptance Criteria یا سایر مستندات و ابزارهای مورد استفاده تیم ثبت شوند.

هدف مستندسازی صرفاً تولید سند نیست؛ بلکه باید اطلاعات لازم را برای تصمیم‌گیری، توسعه، تست و پذیرش راهکار در اختیار افراد مرتبط قرار دهد.

همکاری با تیم توسعه و QA

در پروژه‌های نرم‌افزاری، تحلیلگر کسب و کار پس از تحویل مستندات لزوماً از پروژه کنار نمی‌رود. در طول توسعه ممکن است Developer درباره یک نیاز سؤال داشته باشد یا Tester هنگام طراحی سناریوهای تست با ابهامی مواجه شود.

BA در این شرایط به شفاف‌سازی نیاز، بررسی تفسیرهای مختلف و هماهنگ شدن افراد با هدف اصلی کسب‌وکار کمک می‌کند.

این همکاری اهمیت زیادی دارد؛ زیرا یک Requirement ممکن است از دید کسب‌وکار واضح به نظر برسد، اما هنگام طراحی راهکار یا Test Case مشخص شود که بخشی از آن هنوز تعریف نشده است.

مدیریت تغییرات نیازمندی

نیازهای کسب‌وکار همیشه ثابت نمی‌مانند. ممکن است قوانین تغییر کنند، بازخورد کاربران جدیدی ایجاد شود یا محدودیت فنی باعث شود راهکار اولیه نیاز به بازنگری داشته باشد.

تحلیلگر کسب و کار باید تغییرات را بررسی کند و مشخص کند این تغییر چه تأثیری بر نیازمندی‌های موجود، فرآیندها، راهکار و سایر بخش‌های پروژه خواهد داشت.

در نتیجه، مدیریت تغییر فقط ثبت یک درخواست جدید نیست؛ بلکه باید تأثیر تغییر و ارتباط آن با نیازهای قبلی نیز بررسی شود.

مشارکت در UAT و بررسی تحقق نیاز کسب و کار

در پایان توسعه، صرفاً این موضوع که نرم‌افزار بدون خطای فنی اجرا می‌شود به معنی برآورده شدن نیاز کسب‌وکار نیست.

تحلیلگر کسب و کار می‌تواند در UAT و فرآیند پذیرش کسب‌وکار مشارکت داشته باشد تا بررسی شود راهکار پیاده‌سازی‌شده با نیازها و انتظاراتی که در ابتدای کار مشخص شده‌اند همخوانی دارد یا خیر.

به این ترتیب، کار BA از شناسایی مسئله شروع می‌شود و می‌تواند تا بررسی راهکار نهایی و میزان انطباق آن با نیاز کسب‌وکار ادامه پیدا کند.

۴. وظایف تحلیلگر کسب و کار چیست؟

وظایف تحلیلگر کسب و کار به نوع سازمان، صنعت، اندازه تیم و نوع پروژه بستگی دارد و در همه شرکت‌ها دقیقاً یکسان نیست. با این حال، چند مسئولیت در بسیاری از موقعیت‌های شغلی این حوزه مشترک هستند.

شناخت مسئله و اهداف کسب‌وکار: درک اینکه سازمان یا کاربران با چه مشکلی مواجه هستند و از اجرای راهکار چه نتیجه‌ای انتظار می‌رود.
شناسایی Stakeholderها: مشخص کردن افراد و واحدهایی که تحت تأثیر پروژه قرار می‌گیرند یا اطلاعات و تصمیم‌های مهمی در اختیار دارند.
جمع‌آوری و تحلیل نیازمندی‌ها: استخراج نیازها از منابع مختلف و بررسی آن‌ها برای شناسایی ابهام، تناقض، وابستگی و محدودیت.
مستندسازی نیازمندی‌ها: ثبت اطلاعات تحلیل‌شده در قالب مناسب برای پروژه، مانند Requirement، User Story یا سایر مستندات مورد استفاده سازمان.
تحلیل فرآیندهای کسب‌وکار: بررسی فرآیندهای موجود، شناسایی نقاط ضعف و کمک به طراحی فرآیند مطلوب.
تعریف Business Ruleها: شناسایی قوانین، شرایط و محدودیت‌هایی که بر رفتار فرآیند یا راهکار تأثیر می‌گذارند.
همکاری با تیم‌های مختلف: ایجاد هماهنگی میان Stakeholderها، تیم محصول، Developerها، طراحان و QA.
شفاف‌سازی نیازمندی‌ها در طول پروژه: پاسخ به پرسش‌ها و ابهام‌هایی که هنگام طراحی، توسعه یا تست ایجاد می‌شوند.
تحلیل تأثیر تغییرات: بررسی اینکه تغییر یک نیاز یا قانون کسب‌وکار چه اثری بر سایر نیازمندی‌ها و بخش‌های پروژه دارد.
مشارکت در UAT و پذیرش راهکار: کمک به بررسی اینکه راهکار نهایی نیازهای مورد انتظار کسب‌وکار را برآورده می‌کند.

بنابراین، اگر بخواهیم وظایف تحلیلگر کسب و کار را در یک جمله خلاصه کنیم، می‌توان گفت BA باید کمک کند مسئله درست شناسایی شود، نیاز درست فهمیده و منتقل شود و راهکار نهایی با هدف کسب‌وکار همخوانی داشته باشد.

البته در برخی سازمان‌ها بخشی از این مسئولیت‌ها بر عهده Product Owner، Product Manager، System Analyst یا حتی افراد دیگری در تیم است. به همین دلیل، برای شناخت دقیق یک موقعیت شغلی، بررسی شرح وظایف همان موقعیت اهمیت بیشتری از عنوان شغلی به‌تنهایی دارد.

۵. تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری چه نقشی دارد؟

در یک پروژه نرم‌افزاری، معمولاً یک نیاز یا مسئله از سمت کسب‌وکار، مشتری یا کاربران مطرح می‌شود؛ اما این نیاز در ابتدا لزوماً به شکلی نیست که تیم فنی بتواند مستقیماً آن را پیاده‌سازی کند.

برای مثال، ممکن است یک مدیر بگوید: «کاربران باید بتوانند سفارش خود را به‌راحتی لغو کنند.» این جمله هدف کلی را مشخص می‌کند، اما هنوز سؤال‌های زیادی بدون پاسخ باقی مانده است: لغو سفارش در چه مرحله‌ای مجاز است؟ اگر سفارش ارسال شده باشد چه اتفاقی می‌افتد؟ اگر مبلغ پرداخت شده باشد، وجه چگونه برگردانده می‌شود؟ آیا امکان لغو بخشی از سفارش وجود دارد؟

تحلیلگر کسب و کار در این مرحله به بررسی و شفاف‌سازی نیاز کمک می‌کند تا مشخص شود سیستم دقیقاً چه رفتاری باید داشته باشد و این رفتار چرا برای کسب‌وکار اهمیت دارد.

از نیاز کسب و کار تا Requirement

یکی از فعالیت‌های مهم تحلیلگر کسب و کار، تبدیل نیازهای کلی کسب‌وکار و کاربران به نیازمندی‌های واضح و قابل بررسی است.

BA باید مطمئن شود Requirementها فقط خواسته‌های کلی نیستند و شرایط، محدودیت‌ها، قوانین کسب‌وکار و رفتارهای مورد انتظار را نیز تا حد لازم مشخص می‌کنند.

برای مثال، به‌جای اینکه فقط گفته شود «امکان لغو سفارش وجود داشته باشد»، باید شرایط مجاز بودن لغو، وضعیت سفارش، نحوه بازپرداخت و سایر قواعد مرتبط نیز مشخص شوند.

در این مرحله، آشنایی با مفهوم Requirement برای تحلیلگر کسب و کار اهمیت زیادی دارد؛ زیرا کیفیت این نیازمندی‌ها مستقیماً روی مراحل طراحی، توسعه و تست تأثیر می‌گذارد.

از Requirement تا راهکار نرم‌افزاری

تحلیلگر کسب و کار معمولاً مسئول طراحی جزئیات فنی سیستم نیست، اما باید بتواند درک درستی از راهکاری که برای نیاز کسب‌وکار در نظر گرفته شده داشته باشد.

او در تعامل با تیم فنی و محصول کمک می‌کند مشخص شود آیا راهکار پیشنهادی با نیاز اصلی سازگار است و آیا محدودیت یا نیازی وجود دارد که در تحلیل اولیه دیده نشده باشد.

در نتیجه، BA قرار نیست به Developer بگوید چگونه کد نوشته شود؛ تمرکز او بیشتر روی این است که چه چیزی باید ایجاد شود، چه مسئله‌ای را حل می‌کند و چه شرایطی باید بر رفتار راهکار حاکم باشد.

نقش تحلیلگر کسب و کار در فرآیند توسعه نرم‌افزار

نقش BA با تحویل Requirementها به تیم توسعه تمام نمی‌شود. در طول توسعه ممکن است سؤالات جدیدی مطرح شود، محدودیت فنی کشف شود یا Stakeholder درخواست تغییر در نیاز داشته باشد.

تحلیلگر کسب و کار در این شرایط به شفاف‌سازی نیازمندی‌ها، بررسی تغییرات و حفظ درک مشترک میان افراد کمک می‌کند.

در محیط‌های Agile نیز این تعامل معمولاً مستمرتر است و BA ممکن است در فعالیت‌هایی مانند Backlog Refinement، بررسی User Storyها و Acceptance Criteria و هماهنگی با تیم محصول، توسعه و QA مشارکت داشته باشد.

نقش تحلیلگر کسب و کار در پذیرش محصول

پس از پیاده‌سازی، باید مشخص شود راهکار ایجادشده واقعاً نیاز کسب‌وکار را برآورده می‌کند یا خیر.

تحلیلگر کسب و کار می‌تواند در این مرحله با بررسی سناریوهای واقعی کسب‌وکار، هماهنگی با کاربران و مشارکت در UAT به فرآیند پذیرش کمک کند.

بنابراین می‌توان نقش تحلیلگر کسب و کار در یک پروژه نرم‌افزاری را به‌صورت یک زنجیره در نظر گرفت:

نیاز کسب و کار → تحلیل → Requirement → راهکار → توسعه → تست → UAT → ارزش کسب و کار

نقش BA در این زنجیره این است که ارتباط میان مسئله اولیه و راهکار نهایی حفظ شود و در طول مسیر، نیاز واقعی کسب‌وکار از بین نرود.

۶. تحلیلگر کسب و کار چه مستنداتی تهیه می‌کند؟

یکی از بخش‌های مهم کار تحلیلگر کسب و کار، ثبت و انتقال نتایج تحلیل به شکلی است که افراد مختلف بتوانند برداشت مشترکی از نیاز و راهکار داشته باشند. نوع مستندات به صنعت، سازمان، روش توسعه و نوع پروژه بستگی دارد و ممکن است همه آن‌ها در یک پروژه استفاده نشوند.

در پروژه‌های مختلف، تحلیلگر کسب و کار ممکن است در تهیه، بررسی یا به‌روزرسانی مستنداتی مانند موارد زیر نقش داشته باشد.

BRD

BRD یا Business Requirements Document بیشتر برای ثبت نیازها و اهداف سطح کسب‌وکار استفاده می‌شود. تحلیلگر کسب و کار می‌تواند با Stakeholderها درباره اهداف، مسئله و انتظارات کسب‌وکار صحبت کند و نتیجه این تحلیل را در قالب BRD یا مستند مشابه ثبت کند.

PRD

PRD یا Product Requirements Document اطلاعات مورد نیاز برای تعریف قابلیت‌ها و نیازهای یک محصول را سازمان‌دهی می‌کند. بسته به ساختار سازمان، تحلیلگر کسب و کار ممکن است در تهیه یا تکمیل PRD با Product Manager یا Product Owner همکاری کند.

SRS

در پروژه‌های نرم‌افزاری، SRS می‌تواند نیازمندی‌های سیستم را به شکلی ساختاریافته‌تر ثبت کند تا مبنایی برای طراحی، توسعه و تست باشد. BA بسته به ساختار تیم ممکن است مسئول تهیه بخش‌هایی از SRS باشد یا در تحلیل و بررسی محتوای آن مشارکت کند.

FRD

FRD یا Functional Requirements Document بر نیازمندی‌های عملکردی سیستم تمرکز دارد. در سازمان‌هایی که از این نوع مستند استفاده می‌کنند، تحلیلگر کسب و کار می‌تواند نیازهای کسب‌وکار را به رفتارهای عملکردی مورد انتظار سیستم نزدیک‌تر کند.

User Story

در تیم‌های Agile، نیازها ممکن است به شکل User Story بیان شوند. تحلیلگر کسب و کار می‌تواند در استخراج، نوشتن یا اصلاح User Storyها مشارکت کند تا هدف کاربر، نیاز او و ارزشی که انتظار می‌رود ایجاد شود، برای تیم روشن باشد.

این مسئولیت در همه تیم‌ها الزاماً بر عهده BA نیست و ممکن است Product Owner یا سایر اعضای تیم نیز در آن نقش داشته باشند.

Use Case

Use Case برای توصیف تعامل کاربر یا یک Actor با سیستم در سناریوهای مشخص کاربرد دارد. در پروژه‌هایی که از Use Case استفاده می‌شود، BA می‌تواند جریان‌های اصلی، شرایط و حالت‌های مختلف تعامل را تحلیل و مستند کند.

Acceptance Criteria

Acceptance Criteria شرایطی را مشخص می‌کند که بر اساس آن می‌توان بررسی کرد یک قابلیت، نیاز یا User Story چه زمانی قابل پذیرش است.

تحلیلگر کسب و کار ممکن است در تعریف یا اصلاح Acceptance Criteria مشارکت کند تا معیارهای پذیرش با نیاز واقعی کسب‌وکار همخوان باشند. با این حال، مانند User Story، مالکیت و مسئولیت تهیه آن در همه سازمان‌ها یکسان نیست.

Business Rules و Process Flow

همه اطلاعات مورد نیاز پروژه الزاماً در قالب یک سند رسمی ثبت نمی‌شوند. Business Ruleها، محدودیت‌ها و قوانین حاکم بر کسب‌وکار نیز باید به شکلی قابل دسترسی برای افراد مرتبط ثبت شوند.

همچنین برای فرآیندهای پیچیده، تحلیلگر کسب و کار ممکن است از Process Flow، BPMN یا سایر روش‌های مدل‌سازی استفاده کند تا وضعیت موجود و فرآیند مطلوب برای Stakeholderها و تیم اجرایی قابل درک‌تر باشد.

در نتیجه، نمی‌توان گفت یک فهرست ثابت از مستندات برای همه تحلیلگران کسب و کار وجود دارد. نوع مستندات به روش کاری سازمان و ماهیت پروژه بستگی دارد؛ اما هدف مشترک آن‌ها این است که نیاز کسب‌وکار، رفتار مورد انتظار و قواعد مرتبط به شکلی روشن و قابل استفاده برای افراد درگیر در پروژه منتقل شوند.

۷. تحلیلگر کسب و کار در Agile چه کاری انجام می‌دهد؟

در روش‌های Agile، نیازمندی‌ها معمولاً در طول پروژه به‌صورت تدریجی و همراه با بازخورد کاربران و Stakeholderها تکامل پیدا می‌کنند. به همین دلیل، تحلیل کسب و کار در Agile بیشتر یک فعالیت مستمر است تا کاری که فقط در ابتدای پروژه انجام شود.

تحلیلگر کسب و کار در این محیط کمک می‌کند نیازهای کسب‌وکار و کاربران به شکلی روشن و قابل فهم برای اعضای تیم تبدیل شوند و در طول توسعه، ارتباط میان هدف کسب‌وکار و قابلیت‌های محصول حفظ شود.

نقش تحلیلگر کسب و کار در Agile

در یک تیم Agile، تحلیلگر کسب و کار می‌تواند در فعالیت‌هایی مانند کشف و تحلیل نیازها، آماده‌سازی و اصلاح Backlog، بررسی User Storyها، شفاف‌سازی Acceptance Criteria و پاسخ به پرسش‌های تیم توسعه و QA مشارکت کند.

هدف این نیست که BA تمام تصمیم‌های محصول را به‌تنهایی بگیرد؛ بلکه باید کمک کند اطلاعات لازم برای تصمیم‌گیری و اجرای درست نیازها در اختیار افراد مناسب قرار داشته باشد.

نحوه تقسیم این مسئولیت‌ها به ساختار سازمان و تیم بستگی دارد. در برخی تیم‌ها Product Owner بخش زیادی از فعالیت‌های تحلیل را انجام می‌دهد و در برخی دیگر، BA نقش پررنگ‌تری دارد.

تحلیلگر کسب و کار و User Story

در Agile، نیازهای کاربران اغلب در قالب User Story بیان می‌شوند. تحلیلگر کسب و کار می‌تواند با بررسی نیاز کاربر و هدف کسب‌وکار، در نوشتن یا اصلاح User Story مشارکت کند.

یک User Story خوب نباید صرفاً یک قابلیت را نام ببرد؛ باید به تیم کمک کند بفهمد این قابلیت برای چه کسی، با چه هدفی و با چه ارزشی ایجاد می‌شود.

BA همچنین باید هنگام بررسی User Story به وابستگی‌ها، شرایط خاص و ابهام‌های احتمالی توجه کند تا موضوعاتی که ممکن است در زمان توسعه یا تست مشکل ایجاد کنند، زودتر شناسایی شوند.

تحلیلگر کسب و کار و Acceptance Criteria

بعد از مشخص شدن User Story، لازم است شرایطی که بر اساس آن می‌توان تحقق نیاز را بررسی کرد نیز روشن باشد.

Acceptance Criteria در این مرحله اهمیت پیدا می‌کند. تحلیلگر کسب و کار می‌تواند در تعریف یا بررسی این معیارها مشارکت کند و مطمئن شود شرایط پذیرش با نیاز واقعی کسب‌وکار هماهنگ هستند.

برای مثال، اگر User Story مربوط به لغو سفارش باشد، فقط گفتن «کاربر بتواند سفارش را لغو کند» کافی نیست. باید شرایطی مانند وضعیت سفارش، امکان یا عدم امکان لغو و نتیجه مورد انتظار پس از لغو نیز مشخص شوند.

این شفافیت بعداً برای Developer، Tester و افرادی که در UAT مشارکت می‌کنند نیز مفید خواهد بود.

تحلیلگر کسب و کار در Backlog Refinement

در جلسات Backlog Refinement، تیم درباره آیتم‌هایی که قرار است در آینده توسعه داده شوند صحبت می‌کند و ابهام‌ها، وابستگی‌ها و جزئیات مورد نیاز را بررسی می‌کند.

BA می‌تواند در این جلسات اطلاعات کسب‌وکار را در اختیار تیم قرار دهد، به سؤال‌های مربوط به نیاز پاسخ دهد و مواردی را که هنوز به تحلیل بیشتری نیاز دارند مشخص کند.

در این فرآیند، همکاری نزدیک BA با Product Owner، Developer و QA باعث می‌شود قبل از شروع توسعه، اختلاف برداشت‌ها و ابهام‌های مهم تا حد امکان کاهش پیدا کنند.

همکاری تحلیلگر کسب و کار با Product Owner

BA و Product Owner می‌توانند در بسیاری از فعالیت‌ها همکاری نزدیکی داشته باشند، اما این دو نقش الزاماً یکسان نیستند.

Product Owner در Scrum مسئولیت مشخصی در قبال Product Backlog و به حداکثر رساندن ارزش محصول دارد، در حالی که تحلیلگر کسب و کار بیشتر روی درک و تحلیل نیاز، جزئیات مسئله، فرآیندها و تبدیل نیاز به اطلاعات قابل استفاده برای تیم تمرکز می‌کند.

در بعضی سازمان‌ها یک نفر ممکن است هر دو نقش را بر عهده داشته باشد؛ بنابراین عنوان شغلی به‌تنهایی نمی‌تواند مسئولیت دقیق افراد را مشخص کند.

تحلیلگر کسب و کار در Sprint Planning

در زمان Sprint Planning، اطلاعات حاصل از تحلیل نیاز می‌تواند به تیم کمک کند تا درک دقیق‌تری از کاری که قرار است انجام شود داشته باشد.

BA ممکن است درباره هدف یک قابلیت، شرایط کسب‌وکار، محدودیت‌ها یا ابهام‌های باقی‌مانده توضیح دهد و به سؤالات تیم پاسخ دهد.

در نهایت، نقش تحلیلگر کسب و کار در Agile را می‌توان در یک جمله خلاصه کرد: کمک به تیم برای اینکه نیاز کسب‌وکار را درست بفهمد، آن را به شکل قابل اجرا تبدیل کند و در طول توسعه ارتباط خود را با هدف اصلی حفظ کند.

۸. ارتباط تحلیلگر کسب و کار با تست نرم افزار چیست؟

در یک پروژه نرم‌افزاری، تحلیلگر کسب و کار و Tester دو نقش متفاوت دارند، اما خروجی کار یکی می‌تواند مستقیماً روی کار دیگری تأثیر بگذارد. تحلیلگر کسب و کار روی درک نیاز و مسئله کسب‌وکار تمرکز می‌کند و Tester بررسی می‌کند که نرم‌افزار در شرایط مختلف چگونه رفتار می‌کند و آیا کیفیت مورد انتظار را دارد.

این ارتباط از همان ابتدای تحلیل نیازمندی شکل می‌گیرد. هرچه نیازها شفاف‌تر، دقیق‌تر و قابل بررسی‌تر باشند، تیم تست نیز مبنای بهتری برای طراحی و اجرای تست خواهد داشت.

چرا تحلیلگر کسب و کار باید با Tester همکاری کند؟

Tester برای اینکه بتواند رفتار مورد انتظار سیستم را بررسی کند، باید بداند سیستم چه کاری باید انجام دهد و در چه شرایطی چه نتیجه‌ای باید ایجاد شود.

این اطلاعات معمولاً از منابعی مانند Requirement، User Story، Acceptance Criteria، مستندات محصول و گفت‌وگو با اعضای تیم به دست می‌آید.

اگر بخشی از نیاز برای Tester مبهم باشد، ممکن است سؤال‌هایی در زمان طراحی یا اجرای تست ایجاد شود. در این شرایط، تحلیلگر کسب و کار می‌تواند به روشن شدن منطق کسب‌وکار و شرایط مورد انتظار کمک کند.

بنابراین همکاری BA و Tester فقط در زمان اجرای تست اتفاق نمی‌افتد؛ بلکه هرچه این همکاری زودتر شکل بگیرد، احتمال شناسایی ابهام‌ها پیش از توسعه بیشتر می‌شود.

تأثیر Requirement بر تست نرم افزار

یک Requirement مشخص می‌کند سیستم یا محصول چه نیاز یا رفتاری را باید پوشش دهد. اگر این نیاز به‌اندازه کافی واضح نباشد، طراحی تست نیز می‌تواند با مشکل مواجه شود.

برای مثال، فرض کنید Requirement می‌گوید:

«کاربر می‌تواند سفارش خود را لغو کند.»

Tester برای طراحی تست‌های مناسب باید بداند:

لغو سفارش در چه وضعیت‌هایی مجاز است؟
آیا سفارش ارسال‌شده قابل لغو است؟
اگر مبلغ سفارش پرداخت شده باشد، چه اتفاقی برای وجه می‌افتد؟
آیا همه اقلام یک سفارش را می‌توان لغو کرد؟
بعد از لغو، وضعیت سفارش چه خواهد بود؟

تحلیلگر کسب و کار با شناسایی این شرایط و قواعد، به تبدیل یک نیاز کلی به Requirement قابل بررسی کمک می‌کند.

به همین دلیل، کیفیت Requirement فقط برای Developer اهمیت ندارد و مستقیماً روی فعالیت‌های تست نیز اثر می‌گذارد.

تحلیلگر کسب و کار و Testability نیازمندی‌ها

یکی از ویژگی‌های یک نیازمندی مناسب این است که بتوان تحقق آن را بررسی کرد. اگر یک Requirement بیش از حد کلی یا مبهم باشد، ممکن است دو نفر درباره اینکه «سیستم درست کار می‌کند یا نه» برداشت متفاوتی داشته باشند.

برای مثال، عبارت «صفحه باید سریع باشد» معیار مشخصی برای بررسی ارائه نمی‌کند. تحلیلگر کسب و کار باید در صورت مرتبط بودن با نیاز کسب‌وکار، مشخص کند منظور از سرعت چیست و چه انتظار قابل سنجشی وجود دارد.

البته تعیین معیارهای فنی دقیق ممکن است به همکاری تیم فنی یا متخصص مربوطه نیاز داشته باشد. نقش BA این است که نیاز کسب‌وکار و انتظار موردنظر را شفاف کند تا بتوان درباره معیار مناسب تصمیم گرفت.

این موضوع باعث می‌شود Requirementها از همان ابتدا با نگاه به قابلیت بررسی و پذیرش تحلیل شوند.

ارتباط Requirement، User Story و Acceptance Criteria با تست

در تیم‌های Agile، یک نیاز ممکن است در قالب User Story بیان شود و Acceptance Criteria شرایطی را مشخص کند که برای پذیرش آن قابلیت باید برقرار باشند.

این اطلاعات می‌توانند مبنای مهمی برای طراحی تست باشند. Tester با استفاده از آن‌ها می‌تواند سناریوهای مختلف را شناسایی کند و بررسی کند رفتار پیاده‌سازی‌شده با انتظار کسب‌وکار مطابقت دارد یا خیر.

برای مثال، اگر Acceptance Criteria یک قابلیت مشخص کند که کاربر پس از وارد کردن رمز اشتباه برای چند بار متوالی باید با محدودیت خاصی مواجه شود، این شرط می‌تواند مستقیماً روی سناریوهای تست تأثیر بگذارد.

در اینجا نقش BA این است که مطمئن شود قواعد و شرایط مهم کسب‌وکار در نیازها و معیارهای پذیرش نادیده گرفته نشده‌اند.

نقش تحلیلگر کسب و کار در Test Scenario و Test Case

تحلیلگر کسب و کار معمولاً مسئول اصلی طراحی و اجرای Test Case نیست؛ این مسئولیت در بسیاری از تیم‌ها بر عهده Tester یا QA است.

با این حال، BA می‌تواند اطلاعات ارزشمندی برای شناسایی Test Scenario در اختیار تیم تست قرار دهد؛ به‌خصوص زمانی که سناریو به قوانین و فرآیندهای کسب‌وکار وابسته است.

برای مثال، در فرآیند بازپرداخت وجه، BA ممکن است شرایط مختلفی مانند پرداخت موفق، پرداخت ناموفق، سفارش لغوشده، سفارش ارسال‌شده یا بازپرداخت جزئی را مشخص کند. Tester می‌تواند بر اساس این شرایط سناریوها و Test Caseهای مناسب را طراحی کند.

بنابراین BA لزوماً تست را انجام نمی‌دهد، اما تحلیل دقیق او می‌تواند مبنای تست دقیق‌تر قرار گیرد.

نقش تحلیلگر کسب و کار در UAT

UAT بیشتر از اینکه صرفاً بررسی فنی سیستم باشد، به این موضوع می‌پردازد که آیا راهکار پیاده‌سازی‌شده نیاز و انتظار کسب‌وکار را برآورده می‌کند یا خیر.

به همین دلیل، تحلیلگر کسب و کار می‌تواند در آماده‌سازی سناریوهای کسب‌وکار، هماهنگی با کاربران و Stakeholderها، شفاف‌سازی شرایط پذیرش و بررسی نتایج UAT مشارکت داشته باشد.

با این حال، مسئولیت نهایی پذیرش محصول بسته به ساختار سازمان ممکن است بر عهده Business Owner، نماینده کسب‌وکار، Product Owner یا نقش دیگری باشد.

تحلیلگر کسب و کار و Regression Testing

تغییر یک Requirement یا اضافه شدن یک قابلیت جدید ممکن است روی بخش‌های دیگری از سیستم نیز تأثیر بگذارد.

تحلیلگر کسب و کار با شناخت فرآیندها و وابستگی‌های کسب‌وکار می‌تواند به شناسایی بخش‌هایی که ممکن است تحت تأثیر تغییر قرار بگیرند کمک کند. این اطلاعات برای تیم تست نیز ارزشمند است، زیرا می‌تواند در تعیین محدوده مناسب Regression Testing مورد استفاده قرار گیرد.

BA قرار نیست Regression Testing را اجرا کند؛ نقش او بیشتر در شناخت تأثیر تغییر از دید کسب‌وکار است.

ارتباط تحلیلگر کسب و کار با Requirements Traceability Matrix

در پروژه‌هایی که نیاز به Traceability وجود دارد، ارتباط میان Requirementها، قابلیت‌ها و Test Caseها می‌تواند به تیم کمک کند تا مشخص باشد هر نیاز چگونه در مراحل مختلف پروژه پوشش داده شده است.

تحلیلگر کسب و کار می‌تواند با حفظ ساختار و شفافیت Requirementها و کمک به مشخص بودن ارتباط میان نیازها و خروجی‌های پروژه، به این فرآیند کمک کند.

در پروژه‌های بزرگ‌تر، Requirements Traceability Matrix می‌تواند این ارتباط را ساختاریافته‌تر نشان دهد و به بررسی پوشش نیازمندی‌ها کمک کند.

Requirement مبهم چه مشکلی برای تست ایجاد می‌کند؟

یک Requirement مبهم می‌تواند زنجیره‌ای از مشکلات ایجاد کند:

نیاز مبهم → برداشت متفاوت → پیاده‌سازی متفاوت → تست دشوار → اختلاف در پذیرش

برای مثال، اگر مشخص نباشد «لغو سفارش» دقیقاً در چه شرایطی مجاز است، Developer ممکن است یک رفتار را پیاده‌سازی کند و Tester بر اساس برداشت دیگری تست بنویسد. در نهایت، ممکن است اختلافی ایجاد شود که ریشه آن نه در کد و نه در Test Case، بلکه در ابهام اولیه نیاز بوده است.

به همین دلیل، همکاری میان تحلیلگر کسب و کار و تیم تست می‌تواند به شناسایی این ابهام‌ها پیش از آنکه به مشکل جدی تبدیل شوند کمک کند.

در مجموع، ارتباط BA و تست نرم‌افزار را می‌توان این‌گونه خلاصه کرد:

تحلیل نیاز → شفاف‌سازی Requirement → تعریف شرایط پذیرش → توسعه → طراحی تست → اجرای تست → UAT

تحلیلگر کسب و کار در این زنجیره نقش Tester را بر عهده نمی‌گیرد، اما کیفیت تحلیل و شفافیت نیازهای او می‌تواند مستقیماً روی کیفیت فعالیت‌های تست و پذیرش راهکار اثر بگذارد.

۹. آیا تحلیلگر کسب و کار باید تست نرم افزار بلد باشد؟

اگر تحلیلگر کسب و کار در یک پروژه نرم‌افزاری فعالیت می‌کند، آشنایی با مفاهیم اصلی Software Testing می‌تواند بخش مهمی از مهارت‌های او باشد. با این حال، این موضوع به معنی آن نیست که BA باید همانند یک Tester یا QA متخصص تست باشد.

تحلیلگر کسب و کار باید بداند نیازمندی‌ها چگونه روی فعالیت‌های تست تأثیر می‌گذارند و Tester برای بررسی یک قابلیت به چه اطلاعاتی نیاز دارد. چنین دانشی باعث می‌شود BA هنگام تحلیل و مستندسازی نیازها، شرایط و حالت‌هایی را که ممکن است در توسعه و تست اهمیت داشته باشند، بهتر شناسایی کند.

آیا تحلیلگر کسب و کار باید Tester باشد؟

خیر. وظیفه اصلی تحلیلگر کسب و کار، تحلیل مسئله و نیازهای کسب‌وکار است؛ در حالی که Tester یا QA روی بررسی کیفیت و رفتار سیستم از جنبه‌های مختلف تمرکز می‌کند.

ممکن است یک BA در طراحی برخی سناریوهای کسب‌وکار، بررسی Acceptance Criteria یا UAT مشارکت داشته باشد، اما این موضوع به معنی بر عهده گرفتن تمام فعالیت‌های تست نیست.

در برخی شرکت‌ها نیز ممکن است یک نفر چند مسئولیت را هم‌زمان بر عهده داشته باشد. بنابراین اینکه BA چقدر درگیر فعالیت‌های تست باشد، به ساختار تیم و شرح شغل بستگی دارد.

تحلیلگر کسب و کار چه مفاهیمی از تست را باید بداند؟

برای یک تحلیلگر کسب و کار که در پروژه نرم‌افزاری فعالیت می‌کند، آشنایی با مفاهیم زیر می‌تواند بسیار مفید باشد:

Test Scenario و Test Case: برای درک اینکه نیازهای تحلیل‌شده چگونه به سناریوهای قابل بررسی تبدیل می‌شوند.
Functional Testing و Non-Functional Testing: برای شناخت انواع انتظاراتی که ممکن است از یک سیستم وجود داشته باشد.
Regression Testing: برای درک تأثیر تغییرات روی قابلیت‌های موجود.
UAT: برای درک فرآیند بررسی و پذیرش راهکار از دید کسب‌وکار.
Acceptance Criteria: برای مشخص کردن شرایطی که تحقق یک قابلیت بر اساس آن‌ها قابل بررسی است.
Verification و Validation: برای درک تفاوت بررسی انطباق با مشخصات و بررسی اینکه راهکار واقعاً نیاز موردنظر را پاسخ می‌دهد.
Requirements Traceability Matrix: برای درک ارتباط میان نیازمندی‌ها و خروجی‌هایی مانند Test Case.

BA لازم نیست در تمام این حوزه‌ها به اندازه یک متخصص تست عمیق شود؛ اما شناخت آن‌ها کمک می‌کند نیازمندی‌ها را با درک بهتری از مراحل بعدی پروژه تحلیل کند.

آیا تحلیلگر کسب و کار باید تست اتوماسیون بلد باشد؟

معمولاً Automation Testing جزو مهارت‌های اصلی تحلیلگر کسب و کار نیست.

BA باید بداند تست خودکار چیست و چه نقشی در فرآیند تست دارد، اما در اغلب موقعیت‌ها نیازی نیست خودش با ابزارها و فریم‌ورک‌های اتوماسیون تست کار کند؛ مگر اینکه در شرح شغل، مسئولیت‌های فنی بیشتری برای این نقش تعریف شده باشد.

برای مثال، دانستن اینکه یک Test Case می‌تواند به‌صورت خودکار اجرا شود با توانایی طراحی و نگهداری یک فریم‌ورک تست اتوماسیون دو مهارت کاملاً متفاوت هستند.

آیا تحلیلگر کسب و کار باید Performance Testing و Security Testing بداند؟

آشنایی مفهومی با Performance Testing، Security Testing و سایر انواع تست می‌تواند برای BA مفید باشد، به‌خصوص زمانی که نیازهای کسب‌وکار به این حوزه‌ها وابسته باشند.

برای مثال، اگر یک کسب‌وکار انتظار داشته باشد سیستم در زمان‌های پرترافیک تعداد مشخصی کاربر را پشتیبانی کند، این انتظار باید در تحلیل نیاز مورد توجه قرار گیرد. جزئیات فنی مربوط به نحوه اجرای Performance Testing یا Security Testing معمولاً توسط متخصصان مربوطه تعیین و اجرا می‌شود.

بنابراین بهتر است بین دو موضوع تفاوت قائل شویم:

BA باید بداند چه انتظاری از سیستم وجود دارد و این انتظار چگونه باید قابل بررسی باشد؛ اما لزوماً مسئول اجرای تخصصی تمام انواع تست نیست.

در نتیجه، برای تحلیلگر کسب و کاری که در پروژه‌های نرم‌افزاری فعالیت می‌کند، دانش تست نرم‌افزار یک مزیت مهم برای همکاری بهتر با QA و تیم توسعه است، نه الزاماً یک تخصص شغلی مستقل.

11. چرا در بعضی آگهی‌های استخدامی تحلیلگر کسب و کار و QA کنار هم هستند؟

اگر آگهی‌های استخدامی حوزه فناوری اطلاعات را بررسی کنید، ممکن است گاهی با موقعیت‌هایی مواجه شوید که در آن مسئولیت‌های تحلیلگر کسب و کار و QA یا Testing در یک موقعیت شغلی ترکیب شده‌اند.

این موضوع به این معنی نیست که تحلیلگر کسب و کار و QA یک شغل هستند. این دو نقش اهداف و مسئولیت‌های متفاوتی دارند، اما در پروژه‌های نرم‌افزاری نقاط تماس زیادی میان آن‌ها وجود دارد.

آیا تحلیلگر کسب و کار و QA یک شغل هستند؟

خیر، در حالت معمول این دو نقش متفاوت هستند.

تحلیلگر کسب و کار بیشتر روی شناخت مسئله، نیازهای کسب‌وکار، تحلیل نیازمندی‌ها و اطمینان از انتقال درست این نیازها به تیم پروژه تمرکز دارد.

در مقابل، QA و Tester روی کیفیت محصول و بررسی رفتار سیستم تمرکز می‌کنند و با استفاده از اطلاعاتی مانند Requirement و Acceptance Criteria، سناریوهای مختلف سیستم را بررسی می‌کنند.

البته در بعضی سازمان‌ها مرز مسئولیت‌ها می‌تواند متفاوت باشد و یک فرد ممکن است بخشی از وظایف چند نقش را هم‌زمان انجام دهد.

چرا بعضی شرکت‌ها مسئولیت‌های BA و QA را ترکیب می‌کنند؟

یکی از دلایل می‌تواند اندازه و ساختار تیم باشد. در یک تیم کوچک، ممکن است تعداد افراد محدود باشد و سازمان بخواهد یک نفر علاوه بر تحلیل نیازها، بخشی از فعالیت‌های تست یا UAT را نیز انجام دهد.

در چنین شرایطی، عنوان شغلی ممکن است BA/QA، Business Analyst & Tester یا عنوان مشابه باشد و شرح وظایف ترکیبی از تحلیل و تست را شامل شود.

نقش تحلیلگر کسب و کار در UAT

یکی از نقاطی که فعالیت BA و QA می‌تواند به هم نزدیک شود، UAT است.

تحلیلگر کسب و کار معمولاً شناخت خوبی از فرآیندها و نیازهای کسب‌وکار دارد و می‌تواند در آماده‌سازی سناریوهای کسب‌وکار، هماهنگی با کاربران و شفاف‌سازی معیارهای پذیرش مشارکت کند.

از طرف دیگر، تیم QA نیز ممکن است در آماده‌سازی محیط، اجرای تست‌ها، ثبت نتایج و مدیریت مسائل کشف‌شده در فرآیند پذیرش نقش داشته باشد.

این همکاری نباید با یکی دانستن UAT و تست‌های QA اشتباه گرفته شود؛ هدف UAT بررسی مناسب بودن راهکار برای نیاز واقعی کسب‌وکار است.

نقش‌های ترکیبی BA و QA

در برخی شرکت‌ها ممکن است یک موقعیت شغلی، بخشی از فعالیت‌های تحلیل و بخشی از فعالیت‌های تست را شامل شود.

برای مثال، شرح شغل ممکن است از فرد بخواهد:

نیازهای کاربران را تحلیل کند؛
Requirementها را مستند کند؛
با Developerها و Stakeholderها ارتباط داشته باشد؛
Test Scenario یا Test Case تهیه کند؛
تست‌های Functional را اجرا کند؛
نتایج تست را گزارش کند؛
در UAT مشارکت داشته باشد.

در چنین موقعیتی، صرفاً دانستن عنوان شغلی کافی نیست و باید مشخص شود چه درصدی از زمان و مسئولیت فرد به تحلیل و چه بخشی به تست اختصاص دارد.

عنوان شغلی همیشه تصویر کاملی از نقش نمی‌دهد

در بازار کار، عنوان‌هایی مانند Business Analyst، Business Systems Analyst، QA Analyst، Test Analyst یا حتی عنوان‌های ترکیبی ممکن است در شرکت‌های مختلف برای مسئولیت‌های متفاوت استفاده شوند.

به همین دلیل، اگر قصد دارید برای موقعیت تحلیلگر کسب و کار درخواست شغلی ارسال کنید، بهتر است علاوه بر عنوان آگهی، بخش‌هایی مانند Responsibilities، Requirements و Skills را نیز با دقت بررسی کنید.

اگر در شرح شغل، فعالیت‌هایی مانند Requirement Analysis، Stakeholder Management، Process Analysis و مستندسازی نیازها پررنگ باشد، نقش به تحلیل کسب و کار نزدیک‌تر است. اگر بخش عمده مسئولیت‌ها به طراحی و اجرای تست، گزارش خطا و بررسی کیفیت محصول مربوط باشد، نقش بیشتر به حوزه QA و Testing نزدیک می‌شود.

بنابراین قرار گرفتن نام تحلیلگر کسب و کار و QA در کنار یکدیگر در یک آگهی استخدامی، بیشتر نشان‌دهنده ترکیب یا نزدیکی برخی مسئولیت‌ها در آن سازمان خاص است و نباید آن را به‌عنوان یکسان بودن این دو شغل در نظر گرفت.

12. تفاوت تحلیلگر کسب و کار و تحلیلگر نرم افزار چیست؟

تحلیلگر کسب و کار (Business Analyst) و تحلیلگر نرم‌افزار (Software Analyst) هر دو با تحلیل نیازها و تبدیل آن‌ها به اطلاعات قابل استفاده برای تیم پروژه سروکار دارند، اما تمرکز آن‌ها معمولاً متفاوت است.

به‌صورت ساده می‌توان گفت تحلیلگر کسب و کار بیشتر از زاویه مسئله و نیاز کسب‌وکار به موضوع نگاه می‌کند، در حالی که تحلیلگر نرم‌افزار بیشتر روی سیستم و راهکار نرم‌افزاری تمرکز دارد.

البته مرز این دو نقش در همه سازمان‌ها یکسان نیست و در برخی شرکت‌ها ممکن است بخشی از مسئولیت‌های آن‌ها با یکدیگر ترکیب شود.

تحلیلگر کسب و کار روی چه چیزی تمرکز می‌کند؟

تحلیلگر کسب و کار ابتدا تلاش می‌کند مشخص کند:

مسئله یا فرصت کسب‌وکار چیست؟
چه کسانی تحت تأثیر این مسئله قرار دارند؟
کاربران و Stakeholderها چه نیازهایی دارند؟
فرآیند فعلی چگونه انجام می‌شود؟
چه محدودیت‌ها و Business Ruleهایی وجود دارد؟
راهکار موردنظر چه نتیجه‌ای باید برای کسب‌وکار ایجاد کند؟

بنابراین نقطه شروع BA لزوماً یک نرم‌افزار نیست. ممکن است مسئله با تغییر یک فرآیند، ساختار سازمانی یا روش انجام کار حل شود و اصلاً به توسعه نرم‌افزار نیاز نداشته باشد.

تحلیلگر نرم افزار روی چه چیزی تمرکز می‌کند؟

تحلیلگر نرم‌افزار معمولاً زمانی بیشتر وارد جزئیات می‌شود که قرار است نیازهای شناسایی‌شده به یک راهکار نرم‌افزاری قابل طراحی و پیاده‌سازی تبدیل شوند.

برای مثال، در یک سیستم فروش آنلاین ممکن است تحلیلگر نرم‌افزار روی موضوعاتی مانند موارد زیر تمرکز کند:

اجزای سیستم و ارتباط میان آن‌ها؛
جریان داده بین بخش‌های مختلف؛
رفتار مورد انتظار سیستم؛
تعامل سیستم با سرویس‌های دیگر؛
ساختار و جزئیات Functional Requirementها؛
محدودیت‌ها و وابستگی‌های فنی مرتبط با راهکار.

در برخی سازمان‌ها این مسئولیت‌ها ممکن است تحت عنوان System Analyst نیز تعریف شوند.

تفاوت خروجی‌های تحلیلگر کسب و کار و تحلیلگر نرم افزار

برای درک بهتر تفاوت، می‌توان مسیر یک نیاز را در نظر گرفت:

نیاز کسب‌وکار → تحلیل مسئله → Requirement → تحلیل راهکار نرم‌افزاری → طراحی و پیاده‌سازی → تست → پذیرش

تحلیلگر کسب و کار بیشتر در بخش‌های ابتدایی این مسیر تمرکز دارد و تلاش می‌کند مشخص شود چه مسئله‌ای باید حل شود و چرا.

تحلیلگر نرم‌افزار بیشتر به این موضوع می‌پردازد که سیستم برای پاسخ دادن به این نیاز چگونه باید رفتار کند و چه ساختاری داشته باشد.

البته این به معنی وجود یک خط مرزی ثابت میان این دو نقش نیست. در یک تیم ممکن است BA و System Analyst فعالیت‌های مشترکی داشته باشند یا حتی یک نفر هر دو نقش را بر عهده بگیرد.

آیا یک نفر می‌تواند هم تحلیلگر کسب و کار و هم تحلیلگر نرم افزار باشد؟

بله. در بسیاری از تیم‌ها، به‌خصوص تیم‌های کوچک‌تر، یک فرد ممکن است هم مسئول تحلیل نیازهای کسب‌وکار باشد و هم جزئیات سیستم را تحلیل کند.

برای مثال، یک فرد ممکن است ابتدا با Stakeholder درباره مشکل موجود صحبت کند، فرآیند فعلی را بررسی کند و Requirementها را مشخص کند؛ سپس همین فرد جزئیات رفتار سیستم و تعامل آن با سایر اجزا را نیز تحلیل کند.

در تیم‌های بزرگ‌تر، این مسئولیت‌ها ممکن است بین چند نقش تقسیم شوند.

بنابراین برای تشخیص نقش واقعی یک موقعیت شغلی، بهتر است به شرح وظایف و خروجی‌های مورد انتظار توجه شود، نه فقط عنوان شغلی.

یک تفاوت مهم: BA فقط به نرم‌افزار محدود نیست

یکی از مهم‌ترین تفاوت‌ها این است که تحلیلگر کسب و کار الزاماً در حوزه نرم‌افزار فعالیت نمی‌کند.

برای مثال، یک BA می‌تواند فرآیند رسیدگی به درخواست مشتریان در یک سازمان را تحلیل کند و پیشنهاد دهد که با تغییر فرآیند، تقسیم مسئولیت‌ها یا اصلاح گردش کار، زمان پاسخ‌گویی کاهش پیدا کند.

اما تحلیلگر نرم‌افزار معمولاً زمانی معنا پیدا می‌کند که مسئله در چارچوب یک سیستم یا راهکار نرم‌افزاری مورد تحلیل قرار می‌گیرد.

در نتیجه، می‌توان این تفاوت را به شکل زیر خلاصه کرد:

موضوع	تحلیلگر کسب و کار	تحلیلگر نرم افزار
نقطه تمرکز	مسئله و نیاز کسب‌وکار	سیستم و راهکار نرم‌افزاری
سؤال اصلی	چه مسئله‌ای را باید حل کنیم و چرا؟	سیستم برای پاسخ به نیاز چگونه باید عمل کند؟
ارتباط با کسب‌وکار	پررنگ	پررنگ، اما معمولاً با تمرکز بیشتر بر سیستم
ارتباط با تیم فنی	برای انتقال و شفاف‌سازی نیازها	معمولاً عمیق‌تر در سطح سیستم
فعالیت خارج از پروژه نرم‌افزاری	ممکن است	معمولاً کمتر مطرح است
مرز مسئولیت	وابسته به سازمان و پروژه	وابسته به سازمان و پروژه

در نهایت، تحلیلگر کسب و کار و تحلیلگر نرم‌افزار رقیب یکدیگر نیستند؛ در بسیاری از پروژه‌ها این دو نقش مکمل یکدیگرند. BA کمک می‌کند مسئله و نیاز کسب‌وکار به‌درستی فهمیده شود و تحلیلگر نرم‌افزار کمک می‌کند این نیاز در قالب رفتار و راهکار یک سیستم نرم‌افزاری تحلیل شود.

13. تفاوت تحلیلگر کسب و کار با نقش‌های مشابه چیست؟

در پروژه‌های نرم‌افزاری، نقش تحلیلگر کسب و کار ممکن است در کنار نقش‌هایی مانند Product Owner، Product Manager، System Analyst، QA یا Project Manager قرار بگیرد. شباهت بخشی از فعالیت‌های این نقش‌ها گاهی باعث می‌شود مرز میان آن‌ها مشخص نباشد.

در عمل، تعریف مسئولیت‌ها به ساختار سازمان، روش توسعه و اندازه تیم بستگی دارد؛ بنابراین تفاوت‌های زیر را باید به‌عنوان تفاوت در نقطه تمرکز نقش‌ها در نظر گرفت، نه یک مرزبندی ثابت برای همه شرکت‌ها.

تحلیلگر کسب و کار و Product Owner

Product Owner بیشتر با ارزش محصول، اولویت‌بندی Product Backlog و تصمیم‌گیری درباره اینکه چه چیزی در محصول توسعه پیدا کند، سروکار دارد.

تحلیلگر کسب و کار بیشتر روی تحلیل نیازها، مسئله کسب‌وکار، فرآیندها و جزئیات Requirement تمرکز می‌کند.

برای مثال، در یک قابلیت جدید فروشگاه اینترنتی، Product Owner ممکن است مشخص کند این قابلیت به دلیل اهمیت برای محصول باید در اولویت قرار گیرد؛ در حالی که BA جزئیات نیاز کاربران، فرآیند موجود، Business Ruleها و شرایط مورد انتظار را تحلیل و شفاف کند.

در بعضی تیم‌ها یک نفر ممکن است هر دو نقش را انجام دهد.

تحلیلگر کسب و کار و Product Manager

Product Manager معمولاً نگاه گسترده‌تری به محصول دارد و موضوعاتی مانند نیاز بازار، کاربران، اهداف محصول، اولویت‌ها و مسیر توسعه محصول را دنبال می‌کند.

تحلیلگر کسب و کار بیشتر روی تحلیل مسئله، نیازمندی‌ها، فرآیندها و تبدیل نیاز به اطلاعات قابل استفاده برای اجرای راهکار تمرکز دارد.

برای مثال، Product Manager ممکن است بر اساس بازخورد بازار به این نتیجه برسد که فرآیند بازگشت کالا باید بهبود پیدا کند؛ BA می‌تواند این مسئله را با بررسی فرآیند فعلی، Stakeholderها و نیازهای کاربران به Requirementهای مشخص تبدیل کند.

این دو نقش می‌توانند همکاری نزدیکی داشته باشند و در برخی سازمان‌ها بخشی از مسئولیت‌هایشان هم‌پوشانی دارد.

تحلیلگر کسب و کار و System Analyst

این دو نقش در پروژه‌های نرم‌افزاری بیشترین نزدیکی را در سطح تحلیل دارند.

BA بیشتر از منظر نیاز و مسئله کسب‌وکار به موضوع نگاه می‌کند، در حالی که System Analyst بیشتر روی رفتار، ساختار و تعاملات سیستم تمرکز دارد.

برای مثال، BA ممکن است مشخص کند که مشتری باید بتواند سفارش خود را تحت شرایط مشخصی لغو کند. System Analyst می‌تواند این نیاز را در سطح سیستم تحلیل کند و مشخص کند این قابلیت چه اجزایی از سیستم، جریان داده یا سرویس‌های مرتبط را تحت تأثیر قرار می‌دهد.

در برخی سازمان‌ها، یک نفر ممکن است مسئولیت هر دو نقش را بر عهده داشته باشد.

تحلیلگر کسب و کار و QA

تحلیلگر کسب و کار و QA هدف یکسانی ندارند، اما همکاری آن‌ها در پروژه نرم‌افزاری بسیار مهم است.

BA روی درست فهمیدن و شفاف‌سازی نیاز تمرکز می‌کند و QA یا Tester بررسی می‌کند که محصول مطابق انتظارات و معیارهای تعریف‌شده رفتار می‌کند یا خیر.

برای مثال، BA می‌تواند شرایط کسب‌وکار مربوط به لغو سفارش را مشخص کند و Tester بر اساس Requirement و Acceptance Criteria، Test Scenario و Test Caseهای لازم را طراحی و اجرا کند.

بنابراین کیفیت تحلیل و شفافیت Requirement می‌تواند مستقیماً روی کیفیت فعالیت‌های تست اثر بگذارد.

تحلیلگر کسب و کار و Project Manager

Project Manager بیشتر مسئول هماهنگی و مدیریت پروژه از نظر مواردی مانند زمان‌بندی، منابع، هزینه، ریسک و هماهنگی ذی‌نفعان است.

تحلیلگر کسب و کار روی فهم مسئله، نیازمندی‌ها و فرآیندهای کسب‌وکار تمرکز دارد.

برای مثال، اگر اجرای یک قابلیت جدید با تأخیر مواجه شود، Project Manager ممکن است موضوع برنامه زمان‌بندی و منابع را مدیریت کند؛ در حالی که BA بررسی می‌کند آیا تغییر ایجادشده روی Requirementها، فرآیند کسب‌وکار یا نیازهای Stakeholderها تأثیری داشته است یا خیر.

مقایسه نقش‌ها در یک نگاه

نقش	نقطه تمرکز اصلی	نمونه فعالیت
تحلیلگر کسب و کار	مسئله، نیاز و فرآیند کسب‌وکار	تحلیل Requirement و فرآیند
Product Owner	ارزش محصول و اولویت Backlog	اولویت‌بندی نیازهای محصول
Product Manager	محصول، بازار و مسیر توسعه	تحلیل نیاز بازار و Product Roadmap
System Analyst	سیستم و راهکار نرم‌افزاری	تحلیل رفتار و تعاملات سیستم
QA / Tester	کیفیت و بررسی رفتار محصول	طراحی و اجرای تست
Project Manager	مدیریت و هماهنگی پروژه	زمان‌بندی، منابع و ریسک

این جدول به معنی جداسازی کامل این نقش‌ها نیست. در یک سازمان ممکن است BA و Product Owner دو فرد متفاوت باشند، در سازمانی دیگر یک نفر هر دو مسئولیت را انجام دهد و در یک تیم کوچک حتی بخشی از وظایف BA، System Analyst و QA نیز میان اعضای محدود تیم تقسیم شود.

به همین دلیل، هنگام بررسی یک موقعیت شغلی، عنوان نقش به‌تنهایی کافی نیست و باید شرح وظایف، خروجی‌های مورد انتظار و سطح مسئولیت آن موقعیت را نیز بررسی کرد.

14. مهارت‌های تحلیلگر کسب و کار چیست؟

کار تحلیلگر کسب و کار فقط به نوشتن Requirement یا تهیه مستندات محدود نمی‌شود. BA باید بتواند یک مسئله را به‌درستی درک کند، اطلاعات موردنیاز را از Stakeholderها به دست آورد، داده‌ها و فرآیندها را تحلیل کند و نتیجه این تحلیل را به شکلی منتقل کند که برای افراد مختلف قابل فهم و قابل استفاده باشد.

به همین دلیل، مهارت‌های موردنیاز تحلیلگر کسب و کار را می‌توان در چند گروه اصلی بررسی کرد.

مهارت تحلیل و حل مسئله

یکی از مهم‌ترین مهارت‌های تحلیلگر کسب و کار، توانایی Problem Solving و تحلیل مسئله است.

BA نباید صرفاً اولین راهکاری را که Stakeholder پیشنهاد می‌کند، به Requirement تبدیل کند. ابتدا باید مشخص شود مشکل واقعی چیست، چرا ایجاد شده و چه کسانی تحت تأثیر آن قرار دارند.

برای مثال، اگر یک مدیر بگوید «یک سیستم جدید برای ثبت سفارش لازم داریم»، تحلیلگر کسب و کار باید بتواند سؤال‌هایی مانند این موارد را مطرح کند:

مشکل سیستم فعلی چیست؟
کدام بخش فرآیند باعث مشکل شده است؟
چه کسانی از این فرآیند استفاده می‌کنند؟
چه محدودیت‌هایی وجود دارد؟
نتیجه مورد انتظار از راهکار جدید چیست؟

این نوع نگاه کمک می‌کند BA بین نیاز واقعی و راهکاری که Stakeholder پیشنهاد کرده است تفاوت قائل شود.

مهارت تحلیل نیازمندی

تحلیلگر کسب و کار باید بتواند اطلاعات پراکنده را به نیازمندی‌های روشن و قابل بررسی تبدیل کند.

این کار شامل فعالیت‌هایی مانند شناسایی نیازهای Functional و Non-Functional، پیدا کردن ابهام‌ها، شناسایی وابستگی‌ها، بررسی محدودیت‌ها و مشخص کردن Business Ruleها می‌شود.

یک Requirement خوب نباید صرفاً خواسته‌ای کلی باشد؛ باید تا حد امکان به شکلی بیان شود که افراد کسب‌وکار، توسعه‌دهنده و Tester برداشت مشترکی از آن داشته باشند.

مهارت ارتباط با Stakeholder

بخش قابل توجهی از کار BA با افراد مختلف انجام می‌شود؛ از مدیر و کاربر گرفته تا تیم فنی، Product Owner و سایر اعضای پروژه.

به همین دلیل، Communication Skill اهمیت زیادی دارد.

تحلیلگر کسب و کار باید بتواند:

سؤال مناسب بپرسد؛
به پاسخ‌ها دقیق گوش دهد؛
اطلاعات متناقض را شناسایی کند؛
موضوعات پیچیده را ساده توضیح دهد؛
اختلاف دیدگاه‌ها را آشکار کند؛
و در صورت نیاز، برای رسیدن به یک درک مشترک مذاکره کند.

در بسیاری از پروژه‌ها، مشکل اصلی کمبود اطلاعات نیست؛ بلکه تفاوت برداشت افراد مختلف از یک نیاز است.

مهارت مذاکره و مدیریت تعارض

Stakeholderهای مختلف ممکن است اهداف متفاوتی داشته باشند.

برای مثال، واحد فروش ممکن است بخواهد فرآیند ثبت سفارش سریع‌تر باشد، در حالی که واحد مالی به کنترل‌های بیشتری نیاز داشته باشد. تحلیلگر کسب و کار باید بتواند این نیازهای متفاوت را شناسایی و مستند کند و به تیم کمک کند درباره راهکار مناسب به توافق برسد.

BA لزوماً تصمیم‌گیرنده نهایی درباره همه این اختلاف‌ها نیست، اما باید بتواند تعارض میان نیازها و محدودیت‌ها را شفاف کند و از تصمیم‌گیری مبتنی بر اطلاعات پشتیبانی کند.

مهارت مستندسازی و ارائه

تحلیل انجام‌شده زمانی ارزشمند است که بتوان آن را به شکلی واضح به دیگران منتقل کرد.

بسته به پروژه، تحلیلگر کسب و کار ممکن است با مستنداتی مانند BRD، PRD، SRS، FRD، User Story، Use Case، Business Rule و Process Flow کار کند.

اما هدف از مستندسازی، تولید تعداد زیادی سند نیست. سند باید به اندازه‌ای واضح باشد که افراد مرتبط بتوانند از آن برای تصمیم‌گیری، توسعه، تست یا پذیرش استفاده کنند.

توانایی ارائه شفاهی نیز در کنار مستندسازی اهمیت دارد؛ زیرا بسیاری از ابهام‌ها در جلسه با Stakeholder یا تیم فنی کشف و برطرف می‌شوند.

مهارت تحلیل فرآیند

BA باید بتواند فرآیندهای کسب‌وکار را درک و در صورت نیاز مدل‌سازی کند.

برای مثال، در فرآیند بازگشت کالا ممکن است مراحل مختلفی مانند ثبت درخواست مشتری، بررسی شرایط بازگشت، تأیید درخواست، دریافت کالا و بازپرداخت وجه وجود داشته باشد.

تحلیلگر کسب و کار باید بتواند فرآیند As-Is را درک کند، نقاط مشکل‌دار آن را پیدا کند و در صورت تعریف راهکار جدید، فرآیند To-Be را تحلیل کند.

آشنایی با روش‌هایی مانند BPMN و مدل‌سازی فرآیند می‌تواند در این زمینه مفید باشد.

مهارت‌های فنی مورد نیاز

تحلیلگر کسب و کار الزاماً یک برنامه‌نویس نیست، اما در پروژه‌های نرم‌افزاری داشتن درک فنی مناسب می‌تواند همکاری با تیم توسعه و QA را بسیار ساده‌تر کند.

بسته به نوع پروژه، آشنایی با موضوعاتی مانند موارد زیر می‌تواند مفید باشد:

SDLC و فرآیند توسعه نرم‌افزار؛
مفاهیم پایه Database و SQL؛
API و نحوه ارتباط سیستم‌ها؛
معماری نرم‌افزار در سطح مفهومی؛
ابزارهای مدیریت پروژه و Requirement؛
مفاهیم پایه Software Testing؛
مدل‌سازی با UML یا BPMN.

میزان دانش فنی موردنیاز به نقش و محیط کاری بستگی دارد. برای مثال، نیازمندی‌های فنی یک BA در یک شرکت نرم‌افزاری ممکن است با BA فعال در یک سازمان غیرنرم‌افزاری متفاوت باشد.

در نهایت، می‌توان گفت یک تحلیلگر کسب و کار مؤثر باید بتواند مسئله را بفهمد، سؤال درست بپرسد، نیاز واقعی را استخراج کند، ابهام‌ها را کاهش دهد و نتیجه تحلیل را به زبان قابل فهم برای کسب‌وکار و تیم فنی منتقل کند. این ترکیب از مهارت‌های تحلیلی، ارتباطی و فنی است که نقش BA را شکل می‌دهد.

15. آیا تحلیلگر کسب و کار باید برنامه نویسی بلد باشد؟

خیر، برنامه‌نویسی معمولاً جزو الزامات اصلی برای تبدیل شدن به تحلیلگر کسب و کار نیست. تحلیلگر کسب و کار قرار نیست مانند Developer نرم‌افزار را پیاده‌سازی کند؛ تمرکز اصلی او روی شناخت مسئله، تحلیل نیازها، فرآیندهای کسب‌وکار و تبدیل این نیازها به اطلاعات قابل استفاده برای تیم پروژه است.

با این حال، اگر BA در یک پروژه نرم‌افزاری فعالیت کند، داشتن درک فنی مناسب می‌تواند همکاری او با تیم توسعه، QA و سایر اعضای فنی را بسیار مؤثرتر کند.

آیا برای تحلیلگر کسب و کار شدن برنامه‌نویسی لازم است؟

برای شروع مسیر شغلی BA، معمولاً نیازی نیست زبان‌هایی مانند Java، Python یا C# را در سطح یک برنامه‌نویس حرفه‌ای بلد باشید.

اما بهتر است مفاهیم پایه‌ای مانند این موارد را بشناسید:

نرم‌افزار چگونه توسعه و نگهداری می‌شود؟
Front-end و Back-end چه تفاوتی دارند؟
API چه نقشی در ارتباط سیستم‌ها دارد؟
Database چیست و داده‌ها چگونه ذخیره می‌شوند؟
یک Requirement چگونه به توسعه و سپس تست تبدیل می‌شود؟
سیستم‌ها چگونه با یکدیگر Integration می‌شوند؟

این دانش به BA کمک می‌کند هنگام صحبت با تیم فنی، محدودیت‌ها و وابستگی‌های فنی را بهتر درک کند و Requirementهایی تعریف کند که از نظر اجرایی قابل بررسی باشند.

آیا SQL برای تحلیلگر کسب و کار ضروری است؟

SQL برای همه موقعیت‌های BA الزامی نیست، اما در بسیاری از پروژه‌های نرم‌افزاری می‌تواند یک مهارت کاربردی باشد.

فرض کنید BA در یک سیستم فروش متوجه شده تعداد سفارش‌های ناموفق افزایش پیدا کرده است. اگر به SQL مسلط باشد، می‌تواند با بررسی داده‌ها به سؤالاتی مانند این موارد پاسخ دهد:

سفارش‌های ناموفق بیشتر در چه شرایطی رخ داده‌اند؟
این مشکل مربوط به چه بازه زمانی است؟
آیا خطا فقط برای گروه خاصی از کاربران رخ داده است؟
وضعیت سفارش‌ها در Database چگونه ثبت شده است؟

البته این موضوع به معنی جایگزین شدن BA با Data Analyst یا Database Specialist نیست. هدف، استفاده از داده برای درک بهتر مسئله و اعتبارسنجی فرضیات است.

بنابراین می‌توان SQL را برای بسیاری از موقعیت‌های BA یک مزیت مهم دانست، نه یک الزام عمومی.

آیا تحلیلگر کسب و کار باید API را بلد باشد؟

در پروژه‌هایی که چند سیستم با یکدیگر ارتباط دارند، آشنایی با API می‌تواند برای BA بسیار مفید باشد.

برای مثال، در فرآیند ثبت سفارش ممکن است سیستم فروشگاه با سرویس پرداخت، سیستم انبار و سرویس ارسال ارتباط داشته باشد. BA باید بتواند در سطح مفهومی درک کند:

چه سیستمی با چه سیستمی ارتباط دارد؟
چه داده‌ای بین آن‌ها منتقل می‌شود؟
در صورت خطا چه اتفاقی باید بیفتد؟
کدام بخش از فرآیند به سرویس خارجی وابسته است؟

لازم نیست BA API را مانند یک Developer پیاده‌سازی کند، اما درک این ارتباط‌ها می‌تواند در تحلیل Requirement و شناسایی Edge Caseها کمک‌کننده باشد.

آشنایی با Database چقدر اهمیت دارد؟

درک مفاهیم پایه Database نیز می‌تواند برای تحلیلگر کسب و کار مفید باشد؛ به‌خصوص زمانی که Requirementها با داده‌های مشتری، سفارش، تراکنش یا گزارش‌های سازمانی سروکار دارند.

برای مثال، BA باید بتواند مفهوم موجودیت‌هایی مانند Customer، Order و Payment و رابطه میان آن‌ها را در سطح مناسبی درک کند.

این دانش کمک می‌کند هنگام تحلیل فرآیند و Requirement، سؤالات دقیق‌تری درباره داده‌های موردنیاز، ارتباط اطلاعات و تغییرات آن‌ها مطرح شود.

آیا آشنایی با SDLC لازم است؟

برای BA فعال در پروژه‌های نرم‌افزاری، آشنایی با SDLC بسیار مهم‌تر از یادگیری یک زبان برنامه‌نویسی خاص است.

تحلیلگر باید بداند Requirement چگونه وارد فرآیند توسعه می‌شود و چه ارتباطی با فعالیت‌هایی مانند طراحی، Development، Software Testing، Release و Maintenance دارد.

برای مثال، وقتی یک Requirement تغییر می‌کند، BA باید بتواند پیامدهای آن را روی توسعه، تست و سایر Requirementهای مرتبط درک کند.

در نهایت، BA چقدر باید فنی باشد؟

پاسخ به این سؤال به نوع موقعیت شغلی بستگی دارد.

یک BA که در یک سازمان غیرنرم‌افزاری روی بهبود فرآیندهای کسب‌وکار کار می‌کند، ممکن است به دانش برنامه‌نویسی بسیار کمی نیاز داشته باشد. در مقابل، Business Analyst یک شرکت نرم‌افزاری، به‌خصوص در پروژه‌های پیچیده، معمولاً از داشتن دانش فنی بیشتر سود می‌برد.

پس بهتر است این دو موضوع را از هم جدا کنیم:

برنامه‌نویس بودن ≠ فنی نبودن

تحلیلگر کسب و کار لازم نیست Developer باشد، اما در پروژه‌های نرم‌افزاری باید بتواند زبان کسب‌وکار و زبان فنی را تا حدی به یکدیگر نزدیک کند.

به همین دلیل، برای شروع مسیر BA بهتر است به جای اینکه ابتدا چند زبان برنامه‌نویسی را یاد بگیرید، روی تحلیل نیازمندی، فرآیندهای کسب‌وکار، SDLC، Database و SQL مقدماتی، API و مفاهیم پایه تست نرم‌افزار تمرکز کنید. سپس بر اساس نوع پروژه و موقعیت شغلی، دانش فنی خود را عمیق‌تر کنید.

16. ابزارهای تحلیلگر کسب و کار چیست؟

تحلیلگر کسب و کار برای انجام وظایفی مانند جمع‌آوری و مدیریت Requirementها، مستندسازی، مدل‌سازی فرآیند، همکاری با Stakeholderها و ارتباط با تیم توسعه و QA می‌تواند از ابزارهای مختلفی استفاده کند.

انتخاب ابزار به نوع سازمان، روش توسعه، اندازه تیم و نوع پروژه بستگی دارد. بنابراین هیچ ابزار واحدی برای همه تحلیلگران کسب و کار ضروری نیست.

Jira

Jira بیشتر برای مدیریت کارها و پیگیری فعالیت‌های تیم‌های توسعه نرم‌افزار استفاده می‌شود.

تحلیلگر کسب و کار ممکن است از Jira برای فعالیت‌هایی مانند:

ثبت و مدیریت Requirementها؛
ایجاد یا Refinement کردن User Storyها؛
تعریف Acceptance Criteria؛
پیگیری وضعیت کارها؛
مشاهده و مدیریت Backlog؛
و ارتباط دادن نیازها با فعالیت‌های توسعه و تست

استفاده کند.

در تیم‌های Agile، آشنایی با Jira می‌تواند به BA کمک کند تا نیازهای تحلیل‌شده را در فرآیند واقعی توسعه دنبال کند.

Confluence

Confluence معمولاً برای مستندسازی و اشتراک دانش در تیم استفاده می‌شود.

تحلیلگر کسب و کار می‌تواند اطلاعاتی مانند فرآیندهای کسب‌وکار، Requirementها، تصمیمات جلسات، Business Ruleها و مستندات پروژه را در آن ثبت و به‌روزرسانی کند.

یکی از مزیت‌های چنین ابزارهایی این است که مستندات از حالت فایل‌های پراکنده خارج می‌شوند و اعضای تیم می‌توانند به یک منبع مشترک برای اطلاعات پروژه دسترسی داشته باشند.

Miro

Miro یک ابزار آنلاین برای همکاری و کار بصری روی اطلاعات است.

BA می‌تواند از آن برای فعالیت‌هایی مانند:

Brainstorming؛
ترسیم جریان فرآیند؛
Customer Journey Mapping؛
برگزاری جلسات مشارکتی؛
دسته‌بندی ایده‌ها و نیازها؛
و تحلیل روابط میان اجزای یک مسئله

استفاده کند.

این نوع ابزارها به‌خصوص در جلسات Remote یا تیم‌های توزیع‌شده می‌توانند مفید باشند.

Figma

Figma بیشتر به‌عنوان ابزار طراحی رابط کاربری شناخته می‌شود، اما تحلیلگر کسب و کار نیز ممکن است در برخی پروژه‌ها با آن کار کند.

برای مثال، BA می‌تواند از یک Prototype یا Wireframe برای بهتر فهمیدن و شفاف کردن نیازمندی‌های مربوط به یک صفحه استفاده کند یا در بررسی جریان تعامل کاربر با تیم طراحی همکاری داشته باشد.

البته طراحی نهایی UI معمولاً مسئولیت اصلی BA نیست و به ساختار تیم بستگی دارد.

ابزارهای مدل‌سازی BPMN و UML

وقتی نیاز باشد یک فرآیند یا ساختار سیستم به‌صورت تصویری نمایش داده شود، ابزارهای مدل‌سازی اهمیت پیدا می‌کنند.

BPMN می‌تواند برای نمایش فرآیندهای کسب‌وکار استفاده شود؛ برای مثال، فرآیند ثبت درخواست بازگشت کالا از زمان ثبت درخواست مشتری تا بررسی و پرداخت وجه.

UML نیز مجموعه‌ای از نمودارها برای مدل‌سازی جنبه‌های مختلف سیستم است و بسته به پروژه می‌توان از نمودارهایی مانند Use Case، Activity یا Sequence استفاده کرد.

ابزار مورد استفاده می‌تواند متفاوت باشد؛ مهم‌تر از نام ابزار، توانایی BA در مدل‌سازی صحیح و قابل فهم اطلاعات است.

Excel و Google Sheets

با وجود ابزارهای تخصصی، Excel و Google Sheets همچنان می‌توانند در کار تحلیلگر کسب و کار کاربرد داشته باشند.

برای مثال، BA می‌تواند از آن‌ها برای:

تحلیل و دسته‌بندی داده‌ها؛
مقایسه اطلاعات؛
تهیه ماتریس‌ها؛
پیگیری Requirementها؛
تحلیل اولیه داده‌های کسب‌وکار؛
و تهیه گزارش‌های ساده

استفاده کند.

به‌خصوص در پروژه‌هایی که هنوز ابزار تخصصی مدیریت Requirement یا تحلیل داده وجود ندارد، Spreadsheetها می‌توانند ابزارهای عملی و در دسترسی باشند.

آیا تحلیلگر کسب و کار باید همه این ابزارها را بلد باشد؟

خیر.

ممکن است یک BA در یک سازمان بیشتر با Jira و Confluence کار کند، در سازمان دیگری ابزار اصلی مدیریت Requirement متفاوت باشد و در پروژه‌ای دیگر تمرکز اصلی روی BPMN، Excel یا ابزارهای مدل‌سازی قرار بگیرد.

بنابراین بهتر است ابزارها را بر اساس نیاز پروژه یاد بگیرید، نه اینکه صرفاً فهرستی از نرم‌افزارها را حفظ کنید.

برای یک تحلیلگر کسب و کار، مهارت اصلی تحلیل مسئله، استخراج و مدیریت نیازمندی و برقراری ارتباط مؤثر است؛ ابزار فقط وسیله‌ای برای انجام بهتر این فعالیت‌هاست.

17. یک مثال واقعی از کار تحلیلگر کسب و کار

برای درک بهتر نقش تحلیلگر کسب و کار، فرض کنید یک فروشگاه اینترنتی با مشکلی در فرآیند بازگشت کالا مواجه شده است.

تعداد زیادی از مشتریان برای بازگرداندن کالا با پشتیبانی تماس می‌گیرند و کارشناسان نیز مجبورند درخواست‌ها را به‌صورت دستی بررسی و ثبت کنند. کسب‌وکار تصمیم گرفته است این فرآیند را در سایت بهبود دهد تا مشتری بتواند درخواست بازگشت کالا را به‌صورت آنلاین ثبت و پیگیری کند.

در اینجا کار تحلیلگر کسب و کار از نوشتن یک Requirement شروع نمی‌شود؛ ابتدا باید مشخص شود مشکل دقیقاً چیست و راهکار جدید قرار است چه چیزی را بهبود دهد.

مرحله اول: شناخت مسئله کسب و کار

BA با Stakeholderهای مختلف مانند مدیر محصول، واحد پشتیبانی و مسئول عملیات صحبت می‌کند و سؤالاتی مانند این موارد می‌پرسد:

چرا مشتریان نمی‌توانند به‌راحتی درخواست بازگشت کالا ثبت کنند؟
فرآیند فعلی چگونه انجام می‌شود؟
چه شرایطی باعث پذیرفته یا رد شدن درخواست بازگشت می‌شود؟
چه کسانی درخواست را بررسی می‌کنند؟
مشتری بعد از ثبت درخواست چه اطلاعاتی باید دریافت کند؟
هدف کسب‌وکار از تغییر این فرآیند چیست؟

ممکن است در همین مرحله مشخص شود که مشکل فقط «نبود یک صفحه برای ثبت درخواست» نیست و بخشی از مشکل به قوانین بازگشت کالا یا فرآیند بررسی داخلی مربوط می‌شود.

مرحله دوم: تحلیل فرآیند موجود

تحلیلگر کسب و کار فرآیند فعلی یا As-Is را بررسی می‌کند.

دریافت کالا → بررسی شرایط بازگشت → ثبت درخواست → تأیید یا رد → دریافت کالا → بازپرداخت وجه

در این بررسی ممکن است مشخص شود بعضی مراحل به‌صورت دستی انجام می‌شوند یا اطلاعات یک درخواست در چند سیستم مختلف ثبت می‌شود.

BA می‌تواند این فرآیند را مدل‌سازی کند تا نقاط مشکل‌دار و وابستگی‌ها برای Stakeholderها و تیم فنی واضح‌تر شوند.

مرحله سوم: تبدیل نیاز به Requirement

پس از شناخت مسئله، تحلیلگر کسب و کار باید نیاز را به Requirementهای مشخص تبدیل کند.

برای مثال، یکی از نیازهای شناسایی‌شده می‌تواند این باشد:

مشتری باید بتواند برای سفارش واجد شرایط، درخواست بازگشت کالا را از طریق حساب کاربری خود ثبت کند.

اما این Requirement هنوز ممکن است به اندازه کافی دقیق نباشد.

BA باید مشخص کند:

چه سفارش‌هایی واجد شرایط بازگشت هستند؟
حداکثر چند روز بعد از تحویل می‌توان درخواست ثبت کرد؟
آیا همه کالاها مشمول بازگشت هستند؟
مشتری باید دلیل بازگشت را انتخاب کند؟
چه اطلاعاتی باید هنگام ثبت درخواست وارد شود؟
بعد از ثبت درخواست، وضعیت آن چگونه نمایش داده می‌شود؟

اینجاست که Business Ruleها اهمیت پیدا می‌کنند.

مرحله چهارم: تبدیل Requirement به User Story و Acceptance Criteria

اگر پروژه با Agile توسعه داده شود، این نیاز ممکن است در قالب یک User Story بیان شود.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم برای سفارش واجد شرایط درخواست بازگشت کالا ثبت کنم تا بتوانم کالای خود را طبق قوانین فروشگاه بازگردانم.

سپس شرایط قابل پذیرش شدن این قابلیت مشخص می‌شود.

برای نمونه، یکی از Acceptance Criteriaها می‌تواند این باشد که اگر مهلت مجاز بازگشت کالا گذشته باشد، کاربر نتواند برای آن سفارش درخواست بازگشت ثبت کند.

در این مرحله BA باید با Stakeholder و تیم فنی همکاری کند تا Requirement و شرایط پذیرش، برای همه افراد برداشت مشترکی ایجاد کند.

مرحله پنجم: همکاری با Developer و Tester

پس از شفاف شدن نیاز، تیم توسعه بر اساس اطلاعات موجود راهکار را پیاده‌سازی می‌کند.

در این مرحله ممکن است Developer درباره یک Business Rule سؤال داشته باشد یا Tester یک حالت خاص را مطرح کند که در Requirement مشخص نشده است.

برای مثال، Tester می‌پرسد:

اگر مشتری درخواست بازگشت را ثبت کند اما سفارش شامل چند کالا باشد، آیا می‌تواند فقط یکی از کالاها را بازگرداند؟

این سؤال می‌تواند یک ابهام واقعی در Requirement باشد.

تحلیلگر کسب و کار موضوع را با Stakeholder بررسی می‌کند و نتیجه را به Requirement یا Business Rule اضافه می‌کند.

در نتیجه، تست فقط مرحله‌ای نیست که بعد از پایان تحلیل اتفاق بیفتد؛ سؤالات و یافته‌های تیم QA می‌توانند به شفاف‌تر شدن نیازمندی نیز کمک کنند.

مرحله ششم: تست و بررسی قابلیت

پس از پیاده‌سازی، Tester بر اساس Requirementها، User Story و Acceptance Criteria، سناریوهای مختلف را بررسی می‌کند.

برای مثال:

سفارش هنوز در مهلت بازگشت باشد؛
مهلت بازگشت تمام شده باشد؛
سفارش شامل چند کالا باشد؛
کالای موردنظر مشمول بازگشت نباشد؛
درخواست قبلاً ثبت شده باشد؛
اطلاعات ضروری وارد نشده باشد.

BA در این مرحله لزوماً Test Caseها را اجرا نمی‌کند، اما اگر درباره رفتار مورد انتظار سیستم ابهامی وجود داشته باشد، می‌تواند آن را از دید کسب‌وکار شفاف کند.

مرحله هفتم: UAT و پذیرش کسب و کار

پس از اینکه قابلیت از نظر تیم توسعه و QA بررسی شد، ممکن است نوبت به UAT برسد.

در این مرحله کاربران یا نمایندگان کسب‌وکار بررسی می‌کنند که راهکار جدید واقعاً با فرآیند و نیاز مورد انتظار آن‌ها مطابقت دارد یا خیر.

تحلیلگر کسب و کار می‌تواند در آماده‌سازی سناریوهای کسب‌وکار، هماهنگی با کاربران و شفاف‌سازی نتایج مورد انتظار مشارکت داشته باشد.

برای مثال، نماینده واحد پشتیبانی بررسی می‌کند که آیا درخواست بازگشت ثبت‌شده توسط مشتری، اطلاعات لازم برای ادامه فرآیند داخلی را در اختیار کارشناسان قرار می‌دهد یا خیر.

در نهایت چه چیزی تغییر کرده است؟

در این مثال، کار تحلیلگر کسب و کار فقط نوشتن یک Requirement نبود.

مسیر کار به این شکل طی شد:

مشکل کسب‌وکار → شناخت Stakeholderها → تحلیل فرآیند → شناسایی نیاز → Requirement → Business Rule → User Story و Acceptance Criteria → همکاری با Development و QA → UAT → تحقق نیاز کسب‌وکار

این مثال نشان می‌دهد چرا تحلیلگر کسب و کار باید علاوه بر شناخت کسب‌وکار، درک مناسبی از فرآیند توسعه نرم‌افزار و مفاهیمی مانند Requirement، User Story، Acceptance Criteria، تست و UAT داشته باشد.

نکته مهم این است که BA قرار نیست وظیفه همه اعضای تیم را انجام دهد. ارزش اصلی او در این فرآیند، درست فهمیدن مسئله و تبدیل آن به نیاز شفاف و قابل اجرا برای تیم و قابل ارزیابی برای کسب‌وکار است.

18. چگونه تحلیلگر کسب و کار شویم؟

برای تبدیل شدن به تحلیلگر کسب و کار لازم نیست از ابتدا همه مهارت‌های این حوزه را در سطح حرفه‌ای داشته باشید. مسیر ورود به این شغل معمولاً با یادگیری مفاهیم پایه، تمرین تحلیل مسئله و نیازمندی و سپس کسب تجربه در پروژه‌های واقعی شکل می‌گیرد.

مسیر دقیق افراد می‌تواند متفاوت باشد؛ بعضی افراد از حوزه کسب‌وکار وارد BA می‌شوند و بعضی دیگر از زمینه‌هایی مانند تست نرم‌افزار، توسعه، پشتیبانی یا مدیریت محصول به سمت تحلیل کسب‌وکار حرکت می‌کنند.

از کجا شروع کنیم؟

اگر با این حوزه آشنایی ندارید، بهتر است ابتدا مفهوم اصلی Business Analysis را یاد بگیرید و با موضوعاتی مانند موارد زیر آشنا شوید:

تحلیل مسئله و شناسایی نیاز کسب‌وکار؛
Stakeholder Analysis؛
Requirement Analysis؛
Business Rules؛
تحلیل و مدل‌سازی فرآیند؛
As-Is و To-Be؛
مستندسازی نیازمندی‌ها؛
User Story و Use Case؛
Acceptance Criteria؛
مفاهیم پایه Agile و SDLC.

هدف در این مرحله حفظ کردن اصطلاحات نیست؛ باید بتوانید یک مسئله واقعی را تحلیل کنید و توضیح دهید که چگونه از یک مشکل کسب‌وکار به یک Requirement مشخص می‌رسید.

آیا مدرک دانشگاهی برای تحلیلگر کسب و کار لازم است؟

برای BA شدن یک رشته دانشگاهی واحد و اجباری وجود ندارد.

افرادی با پیشینه‌هایی مانند مدیریت، مهندسی صنایع، فناوری اطلاعات، کامپیوتر، اقتصاد و حتی رشته‌های دیگر می‌توانند وارد این مسیر شوند.

آنچه اهمیت بیشتری دارد، توانایی تحلیل، درک فرآیند، ارتباط با Stakeholderها و تبدیل نیازهای مبهم به اطلاعات شفاف و قابل استفاده است.

البته نوع مدرک یا تحصیلات ممکن است در بعضی آگهی‌های استخدامی به‌عنوان یکی از شرایط شغلی مطرح شود؛ بنابراین شرایط هر موقعیت باید جداگانه بررسی شود.

آیا سابقه تست نرم افزار برای ورود به BA مفید است؟

بله، سابقه Software Testing می‌تواند برای ورود به تحلیل کسب و کار، به‌خصوص در پروژه‌های نرم‌افزاری، یک نقطه قوت باشد.

یک Tester معمولاً با Requirement، User Story، Acceptance Criteria، Test Scenario و رفتار مورد انتظار سیستم سروکار دارد. همین تجربه می‌تواند در شناسایی ابهام‌های Requirement و درک ارتباط میان نیازمندی و محصول مفید باشد.

برای مثال، Tester ممکن است هنگام طراحی Test Case متوجه شود که یک Requirement درباره رفتار سیستم در یک شرایط خاص توضیحی نداده است. این نوع تجربه به BA کمک می‌کند از همان مرحله تحلیل، به قابل بررسی و قابل تست بودن نیازمندی توجه بیشتری داشته باشد.

با این حال، انتقال از Testing به BA به معنی ادامه دادن همان شغل با یک عنوان جدید نیست. فرد باید مهارت‌هایی مانند تحلیل مسئله، Stakeholder Management، تحلیل فرآیند و درک اهداف کسب‌وکار را نیز توسعه دهد.

برای Junior BA چه چیزهایی باید بلد باشیم؟

برای شروع به‌عنوان Junior Business Analyst بهتر است بتوانید حداقل یک مسئله را از ابتدا تا انتها تحلیل کنید.

برای مثال، یک سناریوی ساده مانند «بهبود فرآیند بازگشت کالا در فروشگاه اینترنتی» را انتخاب کنید و برای آن:

مسئله کسب‌وکار را مشخص کنید.
Stakeholderهای اصلی را شناسایی کنید.
فرآیند فعلی را تحلیل کنید.
نیازهای کسب‌وکار را استخراج کنید.
Requirementهای مشخص بنویسید.
Business Ruleهای احتمالی را مشخص کنید.
یک User Story و Acceptance Criteria مناسب بنویسید.
فرآیند جدید را به‌صورت ساده مدل کنید.
سؤالاتی را که هنوز پاسخ داده نشده‌اند مشخص کنید.
سناریوهای پذیرش راهکار را تعریف کنید.

چنین تمرینی نشان می‌دهد که صرفاً با اصطلاحات آشنا نیستید و می‌توانید از ابزارهای تحلیل برای حل یک مسئله استفاده کنید.

آیا باید ابزارهای BA را قبل از پیدا کردن شغل یاد بگیریم؟

بهتر است با ابزارهای رایج مانند Jira، Confluence، Miro و ابزارهای مدل‌سازی آشنا شوید، اما یادگیری ابزار نباید جایگزین یادگیری Business Analysis شود.

مثلاً اگر بدانید چگونه در Jira یک User Story ایجاد کنید اما نتوانید Requirement مبهم را شناسایی کنید، مهارت شما در ابزار به‌تنهایی برای انجام وظیفه BA کافی نیست.

بنابراین اولویت بهتر این است:

تحلیل مسئله و Requirement → مدل‌سازی و مستندسازی → آشنایی با فرآیند توسعه → ابزارها

چگونه برای اولین موقعیت شغلی آماده شویم؟

یکی از روش‌های مفید، ساختن یک Portfolio کوچک از نمونه‌کارهای تحلیلی است.

این Portfolio می‌تواند شامل یک یا چند پروژه فرضی باشد؛ برای مثال:

تحلیل یک فرآیند کسب‌وکار؛
As-Is و To-Be؛
چند Requirement؛
User Story؛
Acceptance Criteria؛
Use Case؛
Business Rule؛
نمودار فرآیند؛
و توضیح تصمیم‌هایی که در طول تحلیل گرفته شده‌اند.

در این نمونه‌کار، بهتر است فقط خروجی نهایی را نشان ندهید؛ توضیح دهید چرا یک نیاز را به این شکل تحلیل کرده‌اید و چه ابهام‌هایی را برطرف کرده‌اید.

در نهایت، مسیر ورود به تحلیل کسب و کار بیشتر از اینکه به یادگیری یک ابزار یا گرفتن یک مدرک خاص وابسته باشد، به توانایی فرد در فهمیدن مسئله، پرسیدن سؤال درست، تحلیل نیاز، مستندسازی و ارتباط مؤثر با افراد مختلف وابسته است.

اگر پیش‌زمینه شما در حوزه‌هایی مانند تست نرم‌افزار یا توسعه نرم‌افزار باشد، می‌توانید از دانش فنی موجود به‌عنوان نقطه شروع استفاده کنید و به‌تدریج دانش کسب‌وکار و مهارت‌های تحلیل خود را گسترش دهید.

19. مسیر شغلی تحلیلگر کسب و کار چگونه است؟

مسیر شغلی تحلیلگر کسب و کار می‌تواند با توجه به صنعت، ساختار سازمان و نوع پروژه متفاوت باشد. در بعضی شرکت‌ها مسیر رشد با افزایش سطح تخصص در Business Analysis ادامه پیدا می‌کند و در برخی دیگر، BA پس از چند سال به سمت نقش‌هایی مانند Product Management، Product Ownership یا مدیریت پروژه حرکت می‌کند.

بنابراین مسیر زیر یک الگوی رایج است، نه یک مسیر اجباری برای همه افراد.

Junior Business Analyst

در سطح Junior، فرد معمولاً روی وظایف مشخص‌تر و با پیچیدگی کمتر کار می‌کند و در کنار تحلیلگران باتجربه‌تر تجربه کسب می‌کند.

برخی فعالیت‌های این سطح می‌تواند شامل موارد زیر باشد:

جمع‌آوری اطلاعات از کاربران و Stakeholderها؛
مستندسازی Requirementها؛
به‌روزرسانی مستندات پروژه؛
تحلیل اولیه فرآیندها؛
تهیه یا اصلاح User Story و Acceptance Criteria؛
مشارکت در جلسات تحلیل؛
همکاری با تیم توسعه و QA برای رفع ابهام‌های Requirement.

در این مرحله، مهم‌تر از داشتن دانش گسترده، یادگیری روش درست تحلیل و پرسیدن سؤال است.

Business Analyst

با افزایش تجربه، تحلیلگر کسب و کار می‌تواند مسئولیت Requirementهای پیچیده‌تر و بخش‌های مهم‌تری از پروژه را بر عهده بگیرد.

در این سطح، BA معمولاً استقلال بیشتری در فعالیت‌هایی مانند:

تحلیل مسئله؛
Stakeholder Management؛
تحلیل فرآیندهای کسب‌وکار؛
شناسایی Business Ruleها؛
تحلیل تأثیر تغییرات؛
مستندسازی نیازمندی‌ها؛
همکاری با Product، Development و QA؛
و مشارکت در تصمیم‌گیری درباره راهکار

خواهد داشت.

تفاوت اصلی این مرحله با سطح Junior فقط افزایش تعداد وظایف نیست؛ پیچیدگی مسئله و میزان مسئولیت فرد در تحلیل نیز بیشتر می‌شود.

Senior Business Analyst

یک Senior BA معمولاً با مسائل پیچیده‌تر، Stakeholderهای بیشتر و پروژه‌هایی با وابستگی‌های گسترده‌تر سروکار دارد.

در این سطح، علاوه بر انجام تحلیل، ممکن است فرد:

تحلیل پروژه‌ها یا حوزه‌های پیچیده را هدایت کند؛
به BAهای Junior و Mid-level کمک کند؛
استانداردها و روش‌های تحلیل را در تیم بهبود دهد؛
در تصمیم‌های مهم مربوط به Requirementها مشارکت کند؛
وابستگی میان فرآیندها و سیستم‌های مختلف را تحلیل کند؛
و در پروژه‌های بزرگ‌تر نقش هماهنگ‌کننده میان چند گروه را داشته باشد.

در بعضی سازمان‌ها، بعد از Senior BA نقش‌هایی مانند Lead Business Analyst یا Business Analysis Manager نیز وجود دارد.

بعد از تحلیلگر کسب و کار چه مسیرهایی وجود دارد؟

BA فقط یک مسیر شغلی ندارد. بر اساس علاقه و مهارت‌های فرد، مسیرهای مختلفی می‌توانند شکل بگیرند.

برای مثال، فردی که به تحلیل عمیق نیازمندی‌ها و فرآیندها علاقه دارد، ممکن است مسیر تخصصی Business Analysis را ادامه دهد.

فرد دیگری که بیشتر به محصول، بازار، کاربران و اولویت‌بندی قابلیت‌ها علاقه دارد، ممکن است به سمت Product Owner یا Product Manager حرکت کند.

همچنین بسته به تجربه و ساختار سازمان، مسیرهایی مانند System Analyst، Solution Analyst، Project Management یا حوزه‌های تخصصی یک صنعت نیز ممکن است مطرح باشند.

آیا BA می‌تواند به Product Manager تبدیل شود؟

بله، این انتقال در برخی مسیرهای شغلی ممکن است؛ اما BA و Product Manager یک نقش واحد نیستند.

BA معمولاً تجربه زیادی در تحلیل مسئله، نیاز کاربران، فرآیندها و Requirement دارد. Product Manager علاوه بر این موضوعات، معمولاً با مسائل گسترده‌تری مانند استراتژی محصول، بازار، اهداف محصول، اولویت‌بندی و چرخه عمر محصول سروکار دارد.

بنابراین اگر یک BA بخواهد به سمت Product Management حرکت کند، لازم است علاوه بر مهارت‌های فعلی خود، دانش و تجربه مرتبط با Product Management را نیز توسعه دهد.

رشد شغلی BA فقط با تغییر عنوان اتفاق نمی‌افتد

افزایش سطح شغلی در Business Analysis را نباید فقط با تغییر عنوان از Junior به Senior سنجید.

با افزایش تجربه، انتظار می‌رود فرد بتواند مسائل مبهم‌تر را بهتر تحلیل کند، نیازهای متعارض را شناسایی کند، ارتباط میان فرآیندها و سیستم‌ها را درک کند و در تعامل با Stakeholderهای مختلف، درک مشترک ایجاد کند.

به همین دلیل، رشد واقعی تحلیلگر کسب و کار بیشتر به افزایش عمق تحلیل، استقلال، دامنه مسئولیت و توانایی حل مسئله مربوط می‌شود.

در یک نگاه کلی، یکی از مسیرهای ممکن چنین شکلی دارد:

Junior Business Analyst → Business Analyst → Senior Business Analyst → Lead / Manager

و یک مسیر دیگر می‌تواند از Business Analysis به سمت نقش‌هایی مانند:

Business Analyst → Product Owner / Product Manager

ادامه پیدا کند.

این مسیرها قطعی نیستند و هر سازمان ممکن است ساختار شغلی متفاوتی داشته باشد.

20. بازار کار تحلیلگر کسب و کار چگونه است؟

بازار کار تحلیلگر کسب و کار به صنعت، اندازه سازمان، نوع پروژه و میزان تجربه فرد بستگی دارد. این نقش فقط در شرکت‌های نرم‌افزاری وجود ندارد و در حوزه‌هایی مانند بانکداری و خدمات مالی، تجارت، بیمه، صنایع، مشاوره و سازمان‌های بزرگ نیز می‌تواند موردنیاز باشد.

در شرکت‌های فناوری، تقاضا برای BA معمولاً با پروژه‌هایی مرتبط است که نیاز به تحلیل دقیق نیازهای کاربران، فرآیندهای کسب‌وکار و تبدیل آن‌ها به Requirementهای قابل اجرا دارند.

تحلیلگر کسب و کار در چه شرکت‌هایی می‌تواند کار کند؟

یک BA می‌تواند در محیط‌های مختلفی فعالیت کند؛ برای مثال:

شرکت‌های تولیدکننده نرم‌افزار و محصولات دیجیتال؛
شرکت‌های تجارت الکترونیک؛
بانک‌ها و شرکت‌های خدمات مالی؛
شرکت‌های بیمه؛
شرکت‌های مشاوره مدیریت و فناوری؛
سازمان‌های بزرگ با پروژه‌های تحول دیجیتال؛
شرکت‌های فعال در حوزه ERP و سیستم‌های سازمانی.

نوع کاری که BA در هرکدام از این محیط‌ها انجام می‌دهد یکسان نیست. برای مثال، BA در یک شرکت محصول‌محور ممکن است بیشتر با Product، User Story و Backlog سروکار داشته باشد، در حالی که BA در یک پروژه سازمانی ممکن است زمان بیشتری را صرف تحلیل فرآیندها، مستندات و Integration میان سیستم‌ها کند.

عنوان‌های شغلی مرتبط با تحلیلگر کسب و کار

در زمان جست‌وجوی شغل، نباید فقط عبارت Business Analyst را جست‌وجو کرد. شرکت‌های مختلف ممکن است برای نقش‌های مشابه یا نزدیک از عنوان‌های متفاوتی استفاده کنند؛ مانند:

Business Analyst
Junior Business Analyst
Senior Business Analyst
Business Systems Analyst
Systems Analyst
IT Business Analyst
Business Process Analyst

البته شباهت عنوان‌ها به معنی یکسان بودن مسئولیت‌ها نیست. برای همین، بررسی شرح وظایف هر آگهی اهمیت زیادی دارد.

چه عواملی روی درآمد تحلیلگر کسب و کار تأثیر می‌گذارند؟

درآمد BA یک عدد ثابت نیست و عواملی مانند موارد زیر می‌توانند روی آن اثر بگذارند:

میزان سابقه و سطح شغلی؛
صنعت و اندازه شرکت؛
نوع پروژه؛
دانش تخصصی در یک حوزه کسب‌وکار؛
مهارت تحلیل و Requirement Management؛
دانش فنی؛
توانایی کار با Stakeholderهای مختلف؛
زبان انگلیسی؛
محل فعالیت و نوع قرارداد.

برای مثال، یک BA که علاوه بر مهارت‌های تحلیل کسب‌وکار، با SQL، API، Database و سیستم‌های سازمانی نیز آشنایی دارد، ممکن است برای موقعیت‌هایی با مسئولیت فنی‌تر مناسب باشد.

آیا بازار کار BA فقط به شرکت‌های نرم‌افزاری محدود است؟

خیر.

یکی از مزیت‌های مهم این مسیر شغلی این است که Business Analysis یک مهارت وابسته به یک صنعت خاص نیست.

برای مثال، فردی که دانش مناسبی از فرآیندهای بانکی دارد می‌تواند روی پروژه‌های مرتبط با خدمات مالی فعالیت کند. فرد دیگری ممکن است در حوزه فروش، زنجیره تأمین، بیمه یا صنایع فعالیت کند.

به همین دلیل، توسعه هم‌زمان دانش تحلیل کسب‌وکار و Domain Knowledge می‌تواند دامنه فرصت‌های شغلی فرد را افزایش دهد.

آیا داشتن سابقه تست نرم افزار برای بازار کار BA مزیت محسوب می‌شود؟

برای موقعیت‌های BA در شرکت‌های نرم‌افزاری، تجربه تست می‌تواند درک فرد از چرخه توسعه، Requirementها، Acceptance Criteria و همکاری با تیم QA را تقویت کرده باشد.

با این حال، سابقه Testing به‌تنهایی به معنی داشتن تمام مهارت‌های موردنیاز BA نیست. فردی که از Testing به سمت Business Analysis حرکت می‌کند، بهتر است دانش خود را در حوزه‌هایی مانند تحلیل مسئله، Stakeholder Management، تحلیل فرآیند، Business Rules و Requirement Engineering نیز گسترش دهد.

در نتیجه، برای ارزیابی بازار کار BA بهتر است فقط به تعداد آگهی‌ها یا یک عنوان شغلی خاص نگاه نکنیم. نوع صنعت، سطح تجربه، حوزه تخصصی و مجموعه مهارت‌های فرد همگی در نوع فرصت‌های شغلی موجود نقش دارند.

نکته: اعداد مربوط به حقوق و تعداد فرصت‌های شغلی به کشور، شهر و زمان وابسته‌اند و به‌سرعت تغییر می‌کنند؛ بنابراین اگر قرار است در این مقاله عدد مشخصی درباره درآمد تحلیلگر کسب و کار ارائه شود، باید بر اساس آمار و آگهی‌های استخدامی به‌روز همان بازار گزارش شود.

۲۱. تحلیلگر کسب و کار برای چه کسانی مناسب است؟

شغل تحلیلگر کسب و کار برای افرادی مناسب است که از فهمیدن مسئله، پیدا کردن علت‌ها، کار با اطلاعات و ارتباط با افراد مختلف لذت می‌برند. در این نقش، فقط داشتن دانش فنی یا مدیریتی کافی نیست؛ توانایی ترکیب تحلیل، ارتباط و درک کسب‌وکار اهمیت زیادی دارد.

اگر از حل مسئله لذت می‌برید

در کار BA معمولاً با مسئله‌هایی مواجه می‌شوید که پاسخ آن‌ها از ابتدا مشخص نیست.

ممکن است Stakeholder یک مشکل کلی را مطرح کند، اما برای رسیدن به نیاز واقعی لازم باشد سؤال‌های بیشتری پرسیده شود، فرآیند فعلی بررسی شود و اطلاعات از منابع مختلف جمع‌آوری و تحلیل شود.

اگر از این نوع کار تحلیلی و پیدا کردن ارتباط میان اطلاعات مختلف لذت می‌برید، Business Analysis می‌تواند حوزه مناسبی برای شما باشد.

اگر به ارتباط با افراد مختلف علاقه دارید

تحلیلگر کسب و کار معمولاً با افراد مختلفی در ارتباط است؛ از کاربران و مدیران گرفته تا Product Owner، Developer و Tester.

به همین دلیل، توانایی گوش دادن، سؤال پرسیدن، توضیح دادن و ایجاد درک مشترک اهمیت زیادی دارد.

BA ممکن است یک موضوع را یک‌بار از دید کسب‌وکار و بار دیگر از دید تیم فنی بررسی کند و بتواند آن را برای هر دو گروه به شکل قابل فهم بیان کند.

اگر به جزئیات توجه می‌کنید

یک Requirement کوچک می‌تواند روی بخش‌های مختلف سیستم یا فرآیند اثر بگذارد.

برای مثال، تغییر یک قانون مربوط به بازگشت کالا ممکن است روی ثبت درخواست، وضعیت سفارش، بازپرداخت وجه و حتی گزارش‌های مالی تأثیر داشته باشد.

به همین دلیل، توجه به جزئیات، شناسایی وابستگی‌ها و پرسیدن سؤال درباره حالت‌های مختلف برای BA اهمیت دارد.

اگر به کسب‌وکار و فناوری علاقه دارید

برای افرادی که هم به کسب‌وکار و هم به فناوری علاقه دارند، BA می‌تواند یک مسیر جذاب باشد.

در پروژه‌های نرم‌افزاری، تحلیلگر کسب و کار باید نیاز کسب‌وکار را درک کند و بتواند آن را به شکلی منتقل کند که تیم فنی نیز بتواند بر اساس آن راهکار را توسعه دهد.

برای انجام این کار لازم نیست برنامه‌نویس حرفه‌ای باشید، اما آشنایی با مفاهیم فنی می‌تواند بسیار کمک‌کننده باشد.

آیا تسترها می‌توانند وارد مسیر تحلیل کسب و کار شوند؟

بله. Testerهایی که به تحلیل نیازمندی‌ها، فرآیندهای کسب‌وکار و تعامل با Stakeholderها علاقه دارند، می‌توانند از تجربه قبلی خود در مسیر BA استفاده کنند.

تجربه تست می‌تواند درک خوبی از Requirement، Acceptance Criteria، رفتار مورد انتظار سیستم و نقاط ابهام ایجاد کرده باشد.

اما برای تبدیل شدن به BA، لازم است مهارت‌هایی مانند تحلیل مسئله، Stakeholder Management، تحلیل فرآیند و درک اهداف کسب‌وکار نیز تقویت شوند.

آیا افراد فنی می‌توانند تحلیلگر کسب و کار شوند؟

بله.

توسعه‌دهندگان، Test Engineerها، System Analystها و سایر افراد فنی نیز ممکن است با توجه به علاقه و تجربه خود به سمت Business Analysis حرکت کنند.

مزیت چنین افرادی معمولاً درک بهتر محدودیت‌ها و نحوه کار سیستم است؛ اما در کنار آن باید توانایی تحلیل نیازهای کسب‌وکار و ارتباط با Stakeholderها را نیز توسعه دهند.

چه کسانی ممکن است از این شغل لذت کمتری ببرند؟

کار BA بخش قابل توجهی از زمان خود را صرف جلسه، سؤال پرسیدن، بررسی اطلاعات، مستندسازی، پیگیری ابهام‌ها و هماهنگی با افراد مختلف می‌کند.

بنابراین اگر فردی ترجیح می‌دهد بیشتر زمان خود را صرف کار کاملاً فنی، برنامه‌نویسی یا فعالیت‌های فردی و مستقل کند، ممکن است برخی موقعیت‌های BA با ترجیحات کاری او هماهنگ نباشند.

البته این موضوع به محیط کاری و نوع نقش BA نیز بستگی دارد و نمی‌توان یک الگوی واحد برای همه موقعیت‌ها در نظر گرفت.

یک نشانه مهم برای انتخاب مسیر BA

اگر هنگام مواجه شدن با یک قابلیت جدید، به‌جای اینکه فقط بپرسید «چطور آن را پیاده کنیم؟» به‌طور طبیعی سؤال‌هایی مانند این موارد برایتان مطرح می‌شود:

چرا به این قابلیت نیاز داریم؟
چه مشکلی قرار است حل شود؟
کاربر دقیقاً چه نیازی دارد؟
چه شرایط و محدودیت‌هایی وجود دارد؟
اگر این فرآیند تغییر کند، چه بخش‌هایی تحت تأثیر قرار می‌گیرند؟
از کجا بفهمیم راهکار واقعاً نیاز کسب‌وکار را برآورده کرده است؟

احتمالاً نوع تفکر موردنیاز در Business Analysis برای شما آشناست.

در نهایت، تحلیلگر کسب و کار بودن بیشتر از اینکه به یک مدرک یا پیشینه شغلی خاص وابسته باشد، به نوع نگاه فرد به مسئله، توانایی تحلیل، ارتباط مؤثر و علاقه به درک عمیق نیازهای کسب‌وکار مربوط است.

۲۲. جمع‌بندی

تحلیلگر کسب و کار (Business Analyst) نقشی است که به سازمان کمک می‌کند مسئله‌ها، نیازها و فرصت‌های کسب‌وکار را بهتر بشناسد و آن‌ها را به نیازها و راهکارهای قابل اجرا تبدیل کند.

کار BA فقط نوشتن مستندات یا تبدیل خواسته‌های مدیر به Requirement نیست. تحلیلگر باید بتواند مسئله واقعی را پیدا کند، Stakeholderها و نیازهای آن‌ها را بشناسد، فرآیندها و Business Ruleها را تحلیل کند، ابهام‌ها را کاهش دهد و اطلاعات لازم را در اختیار تیم‌های مختلف قرار دهد.

در پروژه‌های نرم‌افزاری، این نقش با بخش‌های مختلف چرخه توسعه ارتباط پیدا می‌کند. یک مسیر ساده را می‌توان این‌گونه خلاصه کرد:

Business Problem → Requirement → Analysis → Documentation → Development → Testing → UAT → Business Value

در این مسیر، تحلیلگر کسب و کار درک درستی از نیاز و هدف کسب‌وکار ایجاد می‌کند و با تیم Product، Development و QA همکاری دارد. او لزوماً برنامه‌نویس یا Tester نیست، اما داشتن دانش فنی و آشنایی با Software Testing می‌تواند همکاری او با تیم پروژه را مؤثرتر کند.

همچنین عنوان‌هایی مانند Product Owner، Product Manager، System Analyst و QA ممکن است در بعضی سازمان‌ها با BA هم‌پوشانی داشته باشند، اما تمرکز و مسئولیت آن‌ها الزاماً یکسان نیست. به همین دلیل، برای شناخت یک موقعیت شغلی باید علاوه بر عنوان، شرح وظایف و خروجی‌های مورد انتظار را نیز بررسی کرد.

از نظر مسیر شغلی نیز یک مسیر ثابت برای همه وجود ندارد. فرد می‌تواند در مسیر Business Analysis تخصص بیشتری پیدا کند یا با توجه به تجربه و علاقه خود به حوزه‌هایی مانند Product Management، Product Ownership یا System Analysis حرکت کند.

در نهایت، می‌توان گفت ارزش اصلی تحلیلگر کسب و کار در درست فهمیدن مسئله و تبدیل آن به نیاز شفاف، قابل اجرا و قابل ارزیابی است. هرچه این تحلیل دقیق‌تر باشد، احتمال ایجاد برداشت‌های متفاوت میان کسب‌وکار، تیم توسعه و QA نیز کمتر خواهد شد.

منابع

سوالات متداول درباره تحلیلگر کسب و کار

تحلیلگر کسب و کار چیست؟

تحلیلگر کسب و کار فردی است که مسئله‌ها، نیازها و اهداف کسب‌وکار را تحلیل می‌کند و به تبدیل آن‌ها به نیازمندی‌ها و راهکارهای قابل اجرا کمک می‌کند. این نقش می‌تواند در پروژه‌های نرم‌افزاری یا خارج از حوزه فناوری اطلاعات وجود داشته باشد.

وظایف تحلیلگر کسب و کار چیست؟

شناسایی مسئله و اهداف کسب‌وکار، تحلیل Stakeholderها، جمع‌آوری و تحلیل نیازمندی‌ها، بررسی فرآیندها و Business Ruleها، مستندسازی، همکاری با تیم‌های مختلف و مشارکت در پذیرش راهکار از وظایف رایج تحلیلگر کسب و کار هستند. این مسئولیت‌ها بسته به سازمان و پروژه می‌توانند متفاوت باشند.

آیا تحلیلگر کسب و کار باید برنامه‌نویسی بلد باشد؟

معمولاً برنامه‌نویسی جزو الزامات اصلی این نقش نیست. با این حال، در پروژه‌های نرم‌افزاری آشنایی با مفاهیم فنی مانند SDLC، API، پایگاه داده و معماری نرم‌افزار می‌تواند به تحلیلگر کسب و کار کمک کند تا ارتباط مؤثرتری با تیم فنی داشته باشد.

آیا SQL برای تحلیلگر کسب و کار ضروری است؟

SQL برای همه موقعیت‌های تحلیلگر کسب و کار الزامی نیست، اما در پروژه‌هایی که تحلیل داده، گزارش‌گیری یا کار با پایگاه داده اهمیت دارد، دانستن SQL می‌تواند یک مهارت کاربردی و مزیت شغلی باشد.

تفاوت تحلیلگر کسب و کار و QA چیست؟

تحلیلگر کسب و کار بیشتر روی مسئله، نیازمندی‌ها و اهداف کسب‌وکار تمرکز دارد، در حالی که QA و Tester بیشتر مسئول بررسی کیفیت و رفتار راهکار و یافتن مشکلات هستند. این دو نقش در پروژه‌های نرم‌افزاری همکاری نزدیکی دارند، اما الزاماً یک شغل نیستند.

آیا تحلیلگر کسب و کار باید تست نرم افزار بلد باشد؟

لازم نیست تحلیلگر کسب و کار یک Tester حرفه‌ای باشد، اما آشنایی با مفاهیم پایه تست نرم‌افزار، Acceptance Criteria، Test Scenario، Test Case، Regression Testing و UAT می‌تواند در تحلیل و شفاف‌سازی نیازمندی‌ها مفید باشد.

آیا یک تستر نرم افزار می‌تواند تحلیلگر کسب و کار شود؟

بله. تجربه تست نرم‌افزار می‌تواند درک مناسبی از Requirement، Acceptance Criteria، رفتار سیستم و همکاری با تیم توسعه ایجاد کند. برای حرکت به سمت تحلیل کسب و کار، لازم است مهارت‌هایی مانند تحلیل فرآیند، Stakeholder Management، استخراج نیازمندی و درک مسائل کسب‌وکار نیز تقویت شوند.

تفاوت تحلیلگر کسب و کار و Product Owner چیست؟

Product Owner در Scrum مسئولیت بیشینه‌کردن ارزش محصول و مدیریت Product Backlog را بر عهده دارد، در حالی که تحلیلگر کسب و کار بیشتر روی تحلیل مسئله، نیازمندی‌ها، فرآیندها و جزئیات نیاز کسب‌وکار تمرکز می‌کند. در بعضی سازمان‌ها یک نفر ممکن است هر دو نقش را انجام دهد.

آیا تحلیلگر کسب و کار باید User Story و Acceptance Criteria بنویسد؟

در برخی تیم‌ها تحلیلگر کسب و کار در تهیه، نوشتن یا Refinement کردن User Story و Acceptance Criteria نقش دارد، اما مالکیت این موارد در همه سازمان‌ها یکسان نیست و ممکن است بین BA، Product Owner و سایر اعضای تیم تقسیم شود.

برای تحلیلگر کسب و کار شدن از کجا شروع کنیم؟

بهتر است ابتدا مفاهیم Business Analysis، Requirement، Stakeholder، Business Rule، تحلیل فرآیند، User Story، Use Case و Acceptance Criteria را یاد بگیرید و سپس با یک پروژه فرضی یا واقعی، فرآیند تحلیل و مستندسازی نیازمندی‌ها را تمرین کنید.

ابزارهای تحلیلگر کسب و کار چیست؟

بسته به سازمان و پروژه، ابزارهایی مانند Jira، Confluence، Miro، Figma، ابزارهای مدل‌سازی BPMN و UML و همچنین Excel یا Google Sheets می‌توانند مورد استفاده قرار بگیرند. با این حال، توانایی تحلیل و ارتباط با Stakeholderها مهم‌تر از تسلط به یک ابزار خاص است.

آیا تحلیلگر کسب و کار فقط در شرکت‌های نرم‌افزاری کار می‌کند؟

خیر. تحلیل کسب و کار در حوزه‌هایی مانند بانکداری، خدمات مالی، فروش، تجارت، بیمه، صنایع و سازمان‌های بزرگ نیز انجام می‌شود. در پروژه‌های نرم‌افزاری، این نقش معمولاً ارتباط بیشتری با Requirement و تیم‌های محصول، توسعه و QA دارد.

طبقه بندی شده در:

دسته‌بندی نشده,

اخرین بروزرسانی: مهر 9, 1405

ESC را فشار دهید تا بسته شود

۱. تحلیلگر کسب و کار کیست؟

تحلیلگر کسب و کار چه نقشی در یک سازمان دارد؟

تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری چه کاری انجام می‌دهد؟

۲. تحلیلگر کسب و کار در چه کسب‌وکارهایی فعالیت می‌کند؟

تحلیلگر کسب و کار در شرکت‌های نرم‌افزاری

تحلیلگر کسب و کار در بانک و خدمات مالی

تحلیلگر کسب و کار در فروش و تجارت

تحلیلگر کسب و کار در صنایع و سازمان‌های بزرگ

آیا تحلیلگر کسب و کار حتماً باید در حوزه فناوری اطلاعات کار کند؟

۳. تحلیلگر کسب و کار دقیقاً چه کاری انجام می‌دهد؟

شناسایی مسئله و نیاز کسب و کار

شناسایی و تحلیل Stakeholderها

جمع‌آوری و تحلیل نیازمندی‌ها

تبدیل نیاز کسب و کار به Requirement قابل اجرا

شناسایی Business Ruleها و محدودیت‌ها

مدل‌سازی و تحلیل فرآیندهای کسب و کار

مستندسازی و ایجاد درک مشترک

همکاری با تیم توسعه و QA

مدیریت تغییرات نیازمندی

مشارکت در UAT و بررسی تحقق نیاز کسب و کار

۴. وظایف تحلیلگر کسب و کار چیست؟

۵. تحلیلگر کسب و کار در پروژه‌های نرم‌افزاری چه نقشی دارد؟

از نیاز کسب و کار تا Requirement

از Requirement تا راهکار نرم‌افزاری

نقش تحلیلگر کسب و کار در فرآیند توسعه نرم‌افزار

نقش تحلیلگر کسب و کار در پذیرش محصول

۶. تحلیلگر کسب و کار چه مستنداتی تهیه می‌کند؟

BRD

PRD

SRS

FRD

User Story

Use Case

Acceptance Criteria

Business Rules و Process Flow

۷. تحلیلگر کسب و کار در Agile چه کاری انجام می‌دهد؟

نقش تحلیلگر کسب و کار در Agile

تحلیلگر کسب و کار و User Story

تحلیلگر کسب و کار و Acceptance Criteria

تحلیلگر کسب و کار در Backlog Refinement

همکاری تحلیلگر کسب و کار با Product Owner

تحلیلگر کسب و کار در Sprint Planning

۸. ارتباط تحلیلگر کسب و کار با تست نرم افزار چیست؟

چرا تحلیلگر کسب و کار باید با Tester همکاری کند؟

تأثیر Requirement بر تست نرم افزار

تحلیلگر کسب و کار و Testability نیازمندی‌ها

ارتباط Requirement، User Story و Acceptance Criteria با تست

نقش تحلیلگر کسب و کار در Test Scenario و Test Case

نقش تحلیلگر کسب و کار در UAT

تحلیلگر کسب و کار و Regression Testing

ارتباط تحلیلگر کسب و کار با Requirements Traceability Matrix

Requirement مبهم چه مشکلی برای تست ایجاد می‌کند؟

۹. آیا تحلیلگر کسب و کار باید تست نرم افزار بلد باشد؟

آیا تحلیلگر کسب و کار باید Tester باشد؟

تحلیلگر کسب و کار چه مفاهیمی از تست را باید بداند؟

آیا تحلیلگر کسب و کار باید تست اتوماسیون بلد باشد؟

آیا تحلیلگر کسب و کار باید Performance Testing و Security Testing بداند؟

11. چرا در بعضی آگهی‌های استخدامی تحلیلگر کسب و کار و QA کنار هم هستند؟

آیا تحلیلگر کسب و کار و QA یک شغل هستند؟

چرا بعضی شرکت‌ها مسئولیت‌های BA و QA را ترکیب می‌کنند؟

نقش تحلیلگر کسب و کار در UAT

نقش‌های ترکیبی BA و QA

عنوان شغلی همیشه تصویر کاملی از نقش نمی‌دهد

12. تفاوت تحلیلگر کسب و کار و تحلیلگر نرم افزار چیست؟

تحلیلگر کسب و کار روی چه چیزی تمرکز می‌کند؟

تحلیلگر نرم افزار روی چه چیزی تمرکز می‌کند؟

تفاوت خروجی‌های تحلیلگر کسب و کار و تحلیلگر نرم افزار

آیا یک نفر می‌تواند هم تحلیلگر کسب و کار و هم تحلیلگر نرم افزار باشد؟

یک تفاوت مهم: BA فقط به نرم‌افزار محدود نیست

13. تفاوت تحلیلگر کسب و کار با نقش‌های مشابه چیست؟

تحلیلگر کسب و کار و Product Owner

تحلیلگر کسب و کار و Product Manager

تحلیلگر کسب و کار و System Analyst

تحلیلگر کسب و کار و QA

تحلیلگر کسب و کار و Project Manager

مقایسه نقش‌ها در یک نگاه

14. مهارت‌های تحلیلگر کسب و کار چیست؟

مهارت تحلیل و حل مسئله

مهارت تحلیل نیازمندی