چگونه برای استخراج نیازمندی‌ها سوالات عمیق‌تری بپرسیم؟
یک تحلیلگر کسب‌وکار باید در طول بحث‌های مربوط به استخراج نیازمندی‌ها به سطوح گذشته هم پرداخته و وارد عمق مسائل شود.
یک تحلیلگر کسب‌وکار (BA) صرفاً یک نویسنده نیست که هر چیزی که مشتریان می‌گویند را ثبت کرده و اطلاعات را به تیم توسعه منتقل کند. تحلیلگر باید پرسش‌های چالشی را مطرح کند که باعث برانگیختن قدرت تفکر افرادی شود که با آن‌ها صحبت می‌کند. این مقاله نکاتی کاربردی را به BA ها پیشنهاد می‌دهد، زیرا هنگامی که می‌خواهند یک شبکه گسترده برای استخراج نیازمندی‌ها ایجاد کند به این اطلاعات نیاز خواهند داشت. به خاطر داشته باشید که استخراج نیازمندی‌ها یک فرایند پرس و جو هست نه بازجویی، از این رو باید مراقب سوالاتی باشید که ممکن است به صورت پرخاشگرانه و یا خصمانه مطرح شوند.
کاوش در سطوح عمیق‌تر برای استخراج نیازمندی‌ها
علاوه بر بررسی مواردی که ذینفعان اعلام می‌کنند، BA باید به ذینفعان کمک کند تا در سطحی عمیق‌تر فکر کنند. بعد از این که در مورد برخی از سناریوهای مورد استفاده بحث کردید، سوالات زیر را در نظر بگیرید.
- آیا راه دیگری وجود دارد که کسی بتواند استخراج نیازمندی را انجام دهد؟
- آیا کاربر اصلا می‌خواهد «کاری» انجام دهد؟
- آیا ممکن است «بعضی شرایط» رخ دهد؟ آن وقت چه اتفاقی می‌افتد؟
- چه چیز دیگری ممکن است اتفاق بیفتد که قبلاً در مورد آن صحبت نکرده‌ایم؟
این سوالات راه‌هایی برای کشف سناریوهای با احتمال وقوع کم‌تر هستند و گزینه‌هایی که سیستم باید برای کاربر فراهم کند، شناسایی می‌کنند.
پرسش‌هایی که به یک پاسخ بله / خیر یا چند گزینه‌ای ختم شوند، می‌توانند پاسخ را محدود کنند. این موضوع در بحث نیازمندی‌ها ممکن است باعث از دست رفتن فرصتی برای کشف یا اختراع چیزی شود که فراتر از پیش‌فرض‌های BA است. پرسش‌هایی که مجموعه محدودی از گزینه‌ها را ارائه می‌دهند (آیا واقعا در دسترس بودن باید ۹ / ۹۹ درصد باشد یا ۹۷ درصد کافی خواهد بود؟)، می‌توانند فرآیند تفکر را محدود کنند. در این جا ممکن است حتی پاسخ بهتری که در لیست احتمالات قرار ندارد را از دست دهید. پس بهتر است سوالات کلی‌تری مانند “دوره‌های قابل قبول برای در دسترس نبودن سیستم چیست؟” را در نظر بگیرید؟
در استخراج نیازمندی‌ها چه چیزی می‌تواند اشتباه پیش برود؟
بحث‌های استخراج نیازمندی‌ها معمولاً بر رفتار عادی و مورد انتظار سیستم تأکید می کند. این چیزی است که ذینفعان به طور طبیعی در مورد آن فکر کرده و آن را مطرح می‌کنند. با این حال، هر کسی که تجربه برنامه‌نویسی داشته باشد، می‌داند که توسعه‌دهندگان خوب کدهای زیادی را برای مدیریت حالات استثنا می‌نویسند. بنابراین در حین استخراج نیازمندی‌ها تحلیلگر باید مواردی را شناسایی کند که ممکن است درست پیش نرود. همچنین او باید نحوه شناسایی و مدیریت آن‌ها را نیز مشخص کند.
به عنوان یک تحلیل گر کسب‌وکار لازم است در طول جلسات استخراج نیازمندی‌ها در موارد استثنا هم کاوش کنید. باید سوالاتی مانند اگر «شرایط خطا بوجود آمد» چه اتفاقی باید بیفتد؟ را بپرسید. چنین سوالاتی ممکن است برخی نیازمندی‌ها که در بحث‌ها جا افتاده است را مشخص نماید. من دوست دارم کسی که در تست نرم‌افزار تجربه دارد هم در جلسات استخراج نیازمندی‌ها شرکت کند. چون تسترها به طور خاص در تشخیص شرایط استثنا مهارت دارند. من همچنین یک تستر را درگیر فرایند بازبینی اسناد مربوط به نیازمندی‌ها می‌کنم تا استثناها و جریان‌های فرعی که در نظر گرفته نشده است را شناسایی کند.
هنگام استخراج نیازمندی‌ها هر چیزی را که می‌شنوید، باور نکنید.
یک BA باید کمی شکاک باشد. به این نمونه توجه کنید. قرار بود پروژه‌ای جایگزین سیستم موجود با راهکار package شود. یک کاربر درخواست اضافه نمودن یک قابلیت به هسته این راهکار را داشت که قابلیت پرهزینه‌ای هم محسوب می‌شد. وقتی BA علت نیاز به این قابلیت را جویا شد، کاربر اعلام کرد که این قابلیت در نسخه فعلی وجود دارد. BA تحقیقات بیش‌تری انجام داد و در نهایت کشف کرد که تعدادی از ذینفعان تصور می‌کردند که شخص دیگری از داده استفاده می‌کند. اما در حقیقت هیچ‌کس از آن استفاده نمی‌کرد. چند بار پرسیدن «چرا»، باعث شد که BA و نماینده کاربر موافقت کنند که نیازی به این کارکرد نیست، در نتیجه در میزان هزینه و تلاش به قابل توجهی صرفه‌جویی شد.
علت پرسیدن علت
در طی یک پروژه مهندسی معکوس، یک BA به نام دان از یک توسعه‌دهنده پرسید که چرا محاسبه هزینه یک شرکت خدماتی به شیوه‌ای خاص در سیستم کنونی انجام شده است. او پاسخ داد: ” یک قانون دولتی نشان می‌دهد که ما چگونه باید این هزینه‌ها را محاسبه کنیم.” براساس تحقیقات انجام شده دان متوجه شد که سیستم فعلی محاسبات مربوطه را بر اساس این قانون به درستی اجرا نکرده است. این سیستم مدتی بود که هزینه‌های آب و برق را اشتباه محاسبه کرده بود. اگر دان به سادگی نیاز اعلام شده به فرمول کنونی را پذیرفته بود، این اختلاف هرگز روشن نمی‌شد. پرسیدن چرایی، خطای قابل توجهی را نشان داد که سیستم جایگزین آن را تصحیح کرد.
“چرا؟” یک سوال عالی در مجموعه ترفندهای BA است. سعی کنید طوری این سوال را بپرسید که به نظر نرسد طرف مقابل با سوالی اعتراض‌آمیز اتهام زننده و یا چالش برانگیز روبرو شده‌است. من اغلب سوالاتی می‌پرسم که با این جمله شروع می شود: “آیا می‌توانید به من کمک کنید تا متوجه شوم …” این عبارت طولانی تر از یک دلیل ساده است، اما به همان معناست و حس مشارکتی بیش‌تری دارد. به اندازه کافی «چرا» را بپرسید تا مطمئن شوید که نیاز واقعی را پیدا کردید.
زمانی که یک کاربر یک نیازمندی را ارائه می‌دهد که حاوی یک ایده یا راه‌حل تعبیه‌شده (embedded solution idea) است، شما باید بفهمید که آیا ایده و راه‌حل یک محدودیت طراحی معتبر است یا فقط تنها یک فکر. پرسیدن چرایی برای چند بار متوالی، راهی برای حرکت از پیشنهادات سطحی یک کاربر به سمت نیاز واقعی است. این کار به تیم نرم‌افزار کمک می‌کند تا به مساله واقعی بپردازند، نه فقط یک موضوع سطحی.
پاسخ به چرایی
، ممکن است یک قانون تجاری را که بر پروژه تأثیر می‌گذارد روشن کند. بعد از آن، شما می‌توانید تصدیق کنید که آیا قانون کسب‌وکار هنوز هم مناسب است؟ آیا اطلاعات شما در مورد آن کامل و دقیق است؟ همچنین شما می‌فهمید که چگونه و کجا قانون کسب‌وکار مستند شده است؟ چه کسی اطلاعات را نگهداری می‌کند؟ و آیا قوانین مرتبطی وجود دارد که شما باید در مورد آن بدانید؟
پرسیدن “چرا” گاهی اوقات موجب روشن شدن گمان‌ها و فرضیات می‌شود. یک فرض گفته‌ای است که شما آن را در غیاب وجود دانش صریحی که کاملا درست است صحیح می‌دانید. سعی کنید فرض‌هایی را شناسایی کنید که ذینفعان مختلف ممکن است انجام دهند. این فرض‌ها ممکن است اشتباه، منسوخ یا غیر قابل اجرا باشند. آن‌ها همچنین ممکن است با فرضیات دیگران در تضاد باشند و رسیدن به یک توقع مشترک برای نتیجه پروژه را دشوار کنند.
پاسخ به این سوال که ” چرا این نیازمندی در نظر گرفته شده‌است؟ منطق پشت این نیازمندی را فراهم می کند. ایده خوبی است که همیشه بدانید هر نیازمندی از کجا آمده و چرا ضروری است؟ این دانش به BA کمک می‌کند تا تعیین کند که آیا این درخواست در محدوده (scope) پروژه است یا خیر؟ این سوال گاهی اوقات نشان می‌دهد که “نیاز” در واقع یک ایده‌ی راه‌حل، برای یک نیاز بیان نشده و سطح بالاتر است.
فرض کنید شما با نیازمندی مواجه هستید و در آن یک کاربر، کاری با اولویت بالا ارائه می‌دهد. این نیازمندی برای شما مهم یا ضروری به نظر نمی‌رسد. اگر بپرسید چرا اولویت بالایی دارد، شاید متوجه شوید که به طور منطقی به دیگر نیازمندی‌ها با اولویت بالا مرتبط است. بدون این درک در مورد وابستگی‌های بین نیازمندی‌ها ممکن است شخصی نیازی را که چندان مهم به نظر نمی‌رسد، به تعویق بیاندازد و عملکردهای مربوط به آن را که برای اجرای اولیه برنامه‌ریزی شده است را مختل کند.
پرسش‌های بدون زمینه
در کتاب بررسی نیازمندی‌ها: کیفیت قبل از طراحی، دونالد گوس و جرالد وینبرگ، سوالات بدون زمینه را توصیف می‌کنند. به بیان آن‌ها پرسش‌های بدون زمینه ” پرسش‌های سطح بالایی هستند که می‌توانند در ابتدای یک پروژه مطرح شوند تا اطلاعاتی در مورد ویژگی‌های کلی مشکلات طراحی و راه‌حل‌های بالقوه به دست آورند.” چنین سوالاتی، پرسش‌های خاصی در مورد قابلیت‌ها و ویژگی‌های محصول را تکمیل می‌کنند. در ادامه به چند نمونه پرسش بدون زمینه اشاره می‌کنیم:
- انتظار دارید این سیستم چه مشکلاتی را حل کند؟
- چه مشکلاتی می‌توانست ایجاد کند؟
- چگونه می‌توانیم درباره موفقیت این پروژه قضاوت کنیم؟
- چه کسی این قضاوت را انجام خواهد داد؟
- یک راه حل بسیار موفق چه ارزشی برای مشتریان دارد؟
- برای بدست آوردن بهترین اطلاعات در مورد سیستم با چه کسی باید کار کنم؟
فراسوال‌ها
آخرین سوال من در بحث استخراج نیازمندی ها این است: “آیا چیز دیگری وجود دارد که باید از شما بپرسم؟” ” این یک فراسوال است. یک سوال در مورد یک سوال پیچیده. من آزادانه اعتراف می‌کنم که همه سوالات درست را نمی‌دانم. گاهی اوقات بعد از این که این سوال را می‌پرسم، فردی که با او صحبت می‌کنم، متوجه می‌شود که ما هنوز در مورد یک موضوع مهم صحبت نکرده‌ایم: ” بله، ما باید در مورد امتیازات امنیتی پیش‌فرضی که در سیستم داریم برای کارمندان جدید صحبت کنیم.” من به سادگی به اندازه کافی نمی‌دانستم که این موضوع را مطرح کنم.
من از همین سوال در زندگی روزمره خود هم استفاده می‌کنم. وقتی کانترهای آشپزخانه جدیدی در خانه نصب کردم، از پیمانکار پرسیدم: “آیا چیز دیگری هست باید در مورد این کار از شما بپرسم؟” او یک لحظه فکر کرد و سپس پرسید که آیا می‌خواهم لبه‌های آن تخت یا اریب باشد؟ من هیچ وقت به ظاهر لبه‌های بالایی فکر نکرده بودم. آخرین سوال یعنی:”آیا چیز دیگری وجود دارد؟” تصدیق می‌کند که شما برای رسیدن به نتیجه رضایت‌بخش در یک پروژه به تلاش و تخصص افراد دیگر تکیه می‌کنید. اگر این سوال را نپرسید ممکن است افراد مفروضاتی داشته باشند که نتایج مورد نظر شما را به همراه نداشته باشد.
جمع‌بندی
تجزیه و تحلیل کسب و کار، کاری دشوار است! از آن جایی که این کار در ذات خود یک فعالیت انسانی و ارتباط محور است، من هیچ میانبری برای ساده کردن آن نمی‌شناسم. ذینفعانی که در استخراج نیازمندی‌ها شرکت می‌کنند، می‌توانند با تمام سوالات BA و این که این فرآیند چقدر طول می‌کشد، ناامید شوند. اما این دقیقا همان مسیری است که باید طی شود. انجام این بحث‌ها، پیش از ساختن نرم‌افزار، از بسیاری از دردسرها پیشگیری می‌کند
نویسنده: تیم تحلیل نرم افزار آسا
