تحلیلگر کسب و کار در محیط چابک (Agile)

درباره نویسنده

ادوارد انگوبان، مدیر IIBA در افریقای جنوبی و رئیس تحلیل کسب و کار در DVT است. او حدود ۲۰ سال در حوزه تحلیل کسب و کار سابقه کار اجرایی دارد. وی در حال تکمیل تحصیلات خود در مقطع دکتری است.

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

تحلیل برخی علل ریشه‌ای

اولا، چرا ما خودمان، به عنوان تحلیلگر کسب و کار، خودمان را در شرایط دشوار قرار می‌دهیم و وجود خود را قضاوت می‌کنیم؟ من به شدت معتقدم که ریشه مشکلات ما در تیم‌های چابک در مانیفست آن نهفته است. اگرچه یکی از نقش‌های حیاتی تحلیلگران کسب و کار ایجاد مستنداتی است که برای ثبت نیازمندی‌ها و جریان فرآیند کل پروژه مورد نیاز هستند، نقش یک تحلیلگر کسب و کار چابک کمی متفاوت می‌باشد. این مانیفست توسط گروهی از توسعه‌دهندگان پایه‌گذاری شده و این استدلال منصفانه‌ای است که می‌گوییم محرک اصلی توسعه‌دهندگان این است که مهارت‌ها و تخصص خود را از طریق نوشتن کدی که کار می‌کند، به نمایش بگذارند و لزوماً نگران نباشند که آیا این کد نیازهای کسب‌وکار یا مشتری را برآورده می‌سازد یا خیر.
آیا به طور تصادفی چارچوب اسکرام نقش “تحلیلگر کسب و کار” را ذکر نمی‌کند و فقط به سه نقش تیم توسعه، مالک محصول و اسکرام مستر اشاره دارد؟ قدرت “اشاره” به چیزها را نمی‌توان نادیده گرفت. اینجاست که زمینه برای تجزیه و تحلیل کسب و کار از دست می‌رود.
به طور خیلی عادی، “تیم توسعه” همیشه به توسعه‌دهندگان، آزمایش‌کنندگان و (گاهی اوقات) تحلیلگران کسب و کار اشاره می‌کند. این سؤال مناسبی است که آیا مانیفست چابک از بدو تاسیس، نقش مهمی را که تحلیلگران کسب و کار در فرایند توسعه محصول ایفا کرده‌اند، به رسمیت شناخته است؟

اصلا این چشم‌انداز چه کسی است؟

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

اما آیا نقش تحلیلگر کسب و کار فقط نوشتن داستان‌های کاربر (User Story) خوب است؟

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

همچنین بخوانید: داستان کاربر (User Story) چیست و چگونه استفاده می‌شود؟

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

برای من واضح است که یک تحلیلگر کسب و کار نمی‌تواند جایگزین یک توسعه‌دهنده در تیم چابک شود. و بنابراین، چگونه توسعه‌دهندگان گمان می‌کنند که می‌توانند کار تحلیلگر کسب و کار را در این تیم‌ها انجام دهند؟ به نظر من، این نگرش اهمال‌کارانه است که بر یک دیدگاه محدود درباره آنچه که یک تحلیلگر کسب و کار انجام می‌دهد، پایه‌گذاری شده است: فردی که فقط “داستان‌های کاربر” را می‌نویسد.

توصیف تحلیلگران کسب و کار به عنوان “افراد تیمی” و “تیم‌های خودسامانده” روشی مناسب برای تضعیف قدرت تحلیلگران کسب و کار در دنیای چابک است. بسیار بعید است که افراد ذینفع (از جمله “تیم توسعه”)  بتوانند این را قبول کنند که تحلیلگر کسب و کار بگوید “به دلیل اینکه فرد توسعه‌دهنده برای دو هفته آینده مرخصی است، من نقش او را بر عهده خواهم گرفت و عملکرد، روال یا روشی را که او می‌نویسد را می‌نویسم تا بتوانیم یا حداکثر سرعت دمو را به مشتری ارائه دهیم”.

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

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

ذهنیت “خط تولید”

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

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

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

این مؤلفه‌های کوچک نه تنها از طریق سیستم‌های IT بلکه به واسطه فرایندهای کسب و کار به مشتری منتقل می‌شوند. پس چگونه می‌توان تجزیه و تحلیل کسب و کار را فقط مرتبط با نوشتن داستان‌های کاربر دانست؟
داستان‌های کاربر، نیازمندی‌های (Requirements) کسب و کار نیستند. این‌ها تلفیقی از نیازمندی‌های کسب و کار، کاربردی، غیر کاربردی و قوانین کسب و کار هستند. آن‌ها وضعیت نهایی، آرزوی مشتری را بیان می‌کنند. اما برای تحقق آرزوی مشتری، کسب و کار با اطمینان از اینکه تمام فرایندهای اصلی کسب و کار (از جمله پشتیبانی مشتری) در جای خود وجود دارد، آرزوی مشتری به واسطه یک سیستم IT محقق می‌شود. آیا یک توسعه‌دهنده می‌تواند به این فکر کند؟ فکر نمی‌کنم. این مسئولیت به عهده یک تحلیلگر کسب و کار است. جذابیت کسب و کار اطمینان از این است که همه اجزای کوچک‌تر به درستی مورد تجزیه و تحلیل قرار گرفته‌اند.

منظور از “درک کسب و کار” چیست؟

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

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

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

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

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

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

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

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

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

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