محسن سیف محمدیشناسایی نیازمندی چابک به ما کمک میکند درخواستهای مبهم ذینفعان را به مسئلهای روشن، نتیجهای قابلاندازهگیری و مجموعهای از نیازهای قابلآزمایش تبدیل کنیم. بسیاری از پروژهها نه به دلیل ضعف فنی، بلکه به این دلیل شکست میخورند که تیم، «راهحل پیشنهادی ذینفع» را با «نیاز واقعی کاربر» اشتباه میگیرد. در این مقاله، فرایند کشف نیازمندی را از مشاهده مسئله و گفتوگو با ذینفعان تا تدوین User Story، معیار پذیرش، MVP و اعتبارسنجی، با یک مثال عملی بررسی میکنیم.
برای مثال، وقتی مدیر یک سازمان میگوید «یک داشبورد مدیریتی هوشمند میخواهم»، هنوز با یک نیازمندی روشن روبهرو نیستیم. داشبورد، راهحلی است که ذینفع در ذهن خود ساخته؛ اما مسئله اصلی، نتیجه مورد انتظار و معیار سنجش موفقیت هنوز مشخص نشدهاند.
نیازمندی چابک چیست؟
لیست نیازمندی چابک یک سند قطعی و تغییرناپذیر نیست. نیازمندی در رویکرد چابک، بیان فعلی ما از یک مسئله یا نیاز است که با دریافت بازخورد تکمیل میشود. بنابراین، هدف از شناسایی نیازمندی چابک تولید یک سند قطعی و حجیم نیست؛ بلکه باید ابهامهای مهم را کاهش دهیم و نیاز را برای گفتوگو، آزمایش و یادگیری آماده کنیم.
به زبان ساده:
نیازمندی چابک، یک فرضیه درباره ارزشی است که باید برای کاربر یا کسبوکار ایجاد شود.
این نیازمندی ممکن است در قالبهای مختلفی بیان شود:
- مسئله یا Problem Statement؛
- نتیجه مورد انتظار یا Outcome؛
- User Story؛
- Job Story؛
- سناریو و مثال واقعی؛
- معیار پذیرش؛
- Story Map؛
- Prototype؛
- آزمایش یا Experiment؛
- آیتم Product Backlog.
نکته مهم این است که User Story خودِ نیازمندی نیست؛ بلکه یکی از ابزارهای گفتوگو، ثبت و انتقال نیازمندی است.
تفاوت جمعآوری نیازمندی و کشف نیازمندی
اصطلاح «جمعآوری نیازمندی» این تصور را ایجاد میکند که نیازمندیها از قبل وجود دارند و تحلیلگر فقط باید آنها را از ذینفعان تحویل بگیرد.
در عمل، معمولاً چنین نیست.
ذینفعان ممکن است:
- مسئله را از زاویه واحد خود ببینند؛
- راهحل مورد علاقه خود را بهجای نیاز مطرح کنند؛
- از نیازهای سایر کاربران اطلاع نداشته باشند؛
- فرایند واقعی را با دستورالعمل رسمی اشتباه بگیرند؛
- برخی استثناها را فراموش کنند؛
- درباره علت اصلی مشکل برداشت نادرستی داشته باشند.
بنابراین، در تحلیل کسبوکار چابک بهتر است بهجای Requirement Gathering از مفهوم Requirement Discovery یا «کشف نیازمندی» استفاده کنیم.
کشف نیازمندی یک فعالیت مشارکتی و تکرارشونده است:
- مسئله را مشاهده میکنیم؛
- درباره آن سؤال میپرسیم؛
- یک فرضیه میسازیم؛
- راهحل کوچکی طراحی میکنیم؛
- آن را با کاربر آزمایش میکنیم؛
- از نتیجه یاد میگیریم؛
- Backlog را اصلاح میکنیم.
فرایند هشتمرحلهای شناسایی نیازمندی چابک
مرحله اول: درخواست را از نیاز جدا کنید
اولین جمله ذینفع معمولاً یک راهحل پیشنهادی است:
- «یک اپلیکیشن موبایل میخواهیم.»
- «فرایند را اتوماتیک کنید.»
- «برای مدیرعامل داشبورد بسازید.»
- «در سیستم از هوش مصنوعی استفاده کنید.»
- «یک چتبات سازمانی لازم داریم.»
در این مرحله با راهحل مخالفت نکنید؛ اما آن را نیز بهعنوان نیاز نپذیرید. بهجای آن، درباره مسئله سؤال کنید.
پرسشهای عملی
- اکنون چه اتفاقی میافتد که مطلوب نیست؟
- چه کسی بیشتر از این مشکل آسیب میبیند؟
- این مشکل چند بار در روز یا ماه رخ میدهد؟
- تأثیر آن بر زمان، هزینه، کیفیت یا رضایت چیست؟
- کاربران اکنون چگونه مشکل را دور میزنند؟
- اگر هیچ کاری انجام ندهیم، چه اتفاقی میافتد؟
- از کجا بفهمیم مسئله حل شده است؟
قالب تعریف مسئله
از این الگو استفاده کنید:
[گروه کاربر] هنگام [انجام فعالیت] با [مسئله مشخص] مواجه میشود که باعث [پیامد قابلاندازهگیری] میشود. انتظار داریم با بهبود این وضعیت، [نتیجه مورد انتظار] حاصل شود.
مرحله دوم: ذینفعان و کاربران واقعی را شناسایی کنید
کسی که بودجه محصول را تأمین میکند، الزاماً کسی نیست که هر روز از آن استفاده میکند.
برای شناسایی نیازمندی چابک باید دستکم این گروهها را از هم تفکیک کنیم:
- خریدار یا حامی مالی: بودجه و مجوز را فراهم میکند؛
- کاربر نهایی: مستقیماً با محصول یا فرایند کار میکند؛
- بهرهبردار: مسئول اداره و پشتیبانی راهحل است؛
- ناظر یا کنترلکننده: الزامات قانونی، امنیتی یا کنترلی را بررسی میکند؛
- ذینفع متأثر: از نتیجه فرایند تأثیر میپذیرد، حتی اگر از سیستم استفاده نکند.
ابزار پیشنهادی: نقشه ذینفعان
ذینفعان را بر اساس دو معیار دستهبندی کنید:
- میزان تأثیرگذاری بر تصمیمها؛
- میزان تأثیرپذیری از راهحل.
افرادی که هم تأثیرگذاری و هم تأثیرپذیری زیادی دارند، باید در جلسات کشف، بازبینی و اعتبارسنجی مشارکت فعال داشته باشند.
مرحله سوم: فرایند واقعی را مشاهده کنید
یکی از خطاهای رایج این است که نیازمندی فقط در اتاق جلسه شناسایی شود.
فرایندی که در دستورالعمل نوشته شده، معمولاً با فرایندی که واقعاً اجرا میشود تفاوت دارد. کاربران ممکن است از فایل اکسل، پیامرسان، تماس تلفنی، کاغذ یا توافقهای غیررسمی استفاده کنند.
در رویکرد Agile BPM، مشاهده فرایند موجود یکی از مهمترین منابع کشف نیازمندی است.
هنگام مشاهده فرایند به چه چیزهایی توجه کنیم؟
- نقطه شروع و پایان واقعی فرایند؛
- محرک آغاز فرایند؛
- نقشها و مسئولیتها؛
- زمان انتظار بین فعالیتها؛
- دوبارهکاری و ورود تکراری اطلاعات؛
- تصمیمهای انسانی؛
- استثناها و مسیرهای غیرعادی؛
- انتقال اطلاعات میان سیستمها؛
- کنترلهای امنیتی و قانونی؛
- راهحلهای موقتی کاربران؛
- گلوگاهها و نقاط ایجاد نارضایتی.
خروجی این مرحله
خروجی نباید الزاماً یک مدل پیچیده باشد. یک نقشه ساده شامل مراحل، بازیگران، مشکلات و فرصتهای بهبود برای شروع کافی است.
مرحله چهارم: شواهد را جمعآوری کنید
نیازمندی نباید فقط بر مبنای نظر پرقدرتترین فرد جلسه تعریف شود. تا حد امکان، ادعاها را با شواهد ترکیب کنید.
شواهد مفید
- تعداد درخواستها؛
- میانگین زمان انجام فرایند؛
- درصد خطا یا برگشت؛
- تعداد تماسهای پشتیبانی؛
- نرخ رهاکردن فرایند؛
- شکایتهای مشتریان؛
- دادههای سیستم و Logها؛
- متن تیکتها و مکالمات مرکز تماس؛
- نتایج نظرسنجی؛
- مصاحبه با کاربران؛
- مشاهده مستقیم کار.
نقش هوش مصنوعی در تحلیل نیازمندی
هوش مصنوعی مولد میتواند برای این فعالیتها کمککننده باشد:
- خوشهبندی شکایتهای کاربران؛
- خلاصهسازی مصاحبهها؛
- استخراج موضوعات پرتکرار؛
- پیشنهاد سؤالهای تکمیلی؛
- شناسایی تناقض میان اظهارات ذینفعان؛
- تولید پیشنویس User Story و معیار پذیرش؛
- استخراج سناریوهای لبه و استثناها.
بااینحال، خروجی هوش مصنوعی شاهد قطعی یا نیازمندی تأییدشده نیست. اطلاعات محرمانه نیز نباید بدون کنترل امنیتی در ابزارهای عمومی وارد شود.
مرحله پنجم: نتیجه مورد انتظار را تعریف کنید
اگر تیم فقط Feature تعریف کند، احتمال دارد محصولی تحویل دهد که از نظر فنی کامل، اما از نظر کسبوکار بیاثر باشد.
بهجای این عبارت:
سامانه باید امکان بارگذاری مدارک را فراهم کند.
ابتدا نتیجه مورد انتظار را روشن کنید:
متقاضی باید بتواند بدون مراجعه حضوری، مدارک صحیح را در همان بار اول ارسال کند تا نرخ برگشت پرونده کاهش یابد.
ویژگی یک Outcome مناسب
نتیجه باید:
- به مسئله مشخصی مربوط باشد؛
- برای کاربر یا کسبوکار ارزش ایجاد کند؛
- قابلاندازهگیری باشد؛
- به یک راهحل خاص محدود نباشد؛
- در بازه زمانی مشخص ارزیابی شود.
الگوی هدف
میخواهیم [شاخص] را از [وضعیت فعلی] به [وضعیت هدف] تا [زمان مشخص] برسانیم.
مثال:
میخواهیم نرخ برگشت پروندههای ناقص را طی سه ماه از ۳۸ درصد به کمتر از ۱۵ درصد برسانیم.
مرحله ششم: نیاز را به User Story و سناریو تبدیل کنید
قالب رایج User Story چنین است:
بهعنوان [نوع کاربر] میخواهم [قابلیت یا هدف] تا بتوانم [ارزش یا نتیجه] را به دست آورم.
مثال:
بهعنوان متقاضی تسهیلات میخواهم قبل از ارسال درخواست، نقص مدارک خود را مشاهده کنم تا پروندهام به دلیل نقص اطلاعات برگشت نخورد.
یک User Story خوب باید زمینه گفتوگو ایجاد کند. اگر فقط جملهای نوشته و به تیم توسعه تحویل داده شود، بخش مهمی از ماهیت آن از بین میرود.
Job Story برای موقعیتهای پیچیده
گاهی رفتار کاربر بیشتر از نقش او اهمیت دارد. در این شرایط میتوان از Job Story استفاده کرد:
وقتی [موقعیت] رخ میدهد، میخواهم [انگیزه یا اقدام] را انجام دهم تا [نتیجه] حاصل شود.
مثال:
وقتی اعتبار یکی از مدارکم تا قبل از بررسی پرونده منقضی میشود، میخواهم قبل از رد درخواست مطلع شوم تا بتوانم مدرک جدید را جایگزین کنم.
مرحله هفتم: معیار پذیرش را با مثال واقعی بنویسید
User Story بدون معیار پذیرش، امکان برداشتهای متفاوت را افزایش میدهد.
معیار پذیرش تعیین میکند در چه شرایطی میتوان گفت رفتار موردنظر درست پیادهسازی شده است.
قالب Given–When–Then
Given: با توجه به اینکه...
When: هنگامی که...
Then: آنگاه سیستم باید...
مثال:
با توجه به اینکه تاریخ اعتبار کارت ملی متقاضی گذشته است،
هنگامی که او پرونده را برای بررسی ارسال میکند،
آنگاه سامانه باید از ارسال نهایی جلوگیری کند،
مدرک نامعتبر را مشخص کند
و روش جایگزینی آن را نمایش دهد.
معیارهای پذیرش باید چه چیزهایی را پوشش دهند؟
- مسیر عادی؛
- اطلاعات ناقص؛
- اطلاعات نامعتبر؛
- دسترسی غیرمجاز؛
- قطع ارتباط با سرویس خارجی؛
- ثبت سوابق و قابلیت پیگیری؛
- زمان پاسخ؛
- پیام خطای قابلفهم؛
- سناریوهای مرزی؛
- الزامات امنیتی و قانونی.
بهتر است معیار پذیرش پیش از توسعه، با حضور تحلیلگر، نماینده کسبوکار، توسعهدهنده و آزمونگر مرور شود.
مرحله هشتم: نیازمندی را با یک آزمایش کوچک اعتبارسنجی کنید
هر نیازمندی، حتی اگر در جلسه تأیید شده باشد، هنوز میتواند اشتباه باشد.
اعتبارسنجی یعنی بررسی کنیم:
- آیا مسئله واقعاً وجود دارد؟
- آیا این مسئله ارزش حلکردن دارد؟
- آیا راهحل برای کاربر قابلفهم و قابلاستفاده است؟
- آیا رفتار کاربر تغییر میکند؟
- آیا نتیجه کسبوکار بهبود مییابد؟
آزمایشهای کمهزینه
- طراحی Prototype کاغذی؛
- ساخت Wireframe قابل کلیک؛
- اجرای فرایند بهصورت دستی؛
- Wizard of Oz؛
- عرضه محدود برای گروه کوچکی از کاربران؛
- A/B Test؛
- مصاحبه مبتنی بر نمونه واقعی؛
- بررسی دادههای یک Sprint آزمایشی.
در شناسایی نیازمندی چابک، هدف این نیست که قبل از شروع توسعه همهچیز را بدانیم. هدف این است که پرریسکترین فرضیه را زودتر و ارزانتر آزمایش کنیم. برای درک بهتر شناسایی نیازمندی چابک، یک درخواست پیچیده سازمانی را از طرح اولیه مسئله تا تدوین MVP و معیارهای پذیرش بررسی میکنیم.
مثال عملی و نسبتاً پیچیده: شناسایی نیازمندی سامانه تسهیلات
فرض کنید مدیر یک مؤسسه مالی چنین درخواستی مطرح میکند:
«میخواهیم با استفاده از هوش مصنوعی، سامانه اعطای تسهیلات را کاملاً خودکار کنیم.»
این جمله یک نیازمندی قابلاجرا نیست. در آن، دستکم سه راهحل از قبل فرض شده است:
- استفاده از هوش مصنوعی؛
- ساخت سامانه؛
- خودکارسازی کامل.
بیایید این درخواست را بهصورت چابک بررسی کنیم.
گام اول مثال: کشف مسئله
پس از مصاحبه با مدیر شعب، کارشناسان اعتباری، مرکز تماس و متقاضیان، این مشاهدات ثبت میشود:
- ۳۸ درصد پروندهها حداقل یک بار به دلیل نقص مدارک برگشت میخورند؛
- هر پرونده در سه سامانه و یک فایل اکسل پیگیری میشود؛
- متقاضی از وضعیت دقیق پرونده اطلاع ندارد؛
- کارشناسان روزانه زمان زیادی را صرف پاسخگویی تلفنی میکنند؛
- برخی پروندههای پرریسک به دلیل بررسی دستی دیر شناسایی میشوند؛
- قواعد اعتبارسنجی بین شعب یکسان اجرا نمیشود.
تعریف مسئله
متقاضیان و کارشناسان اعتباری هنگام تکمیل و بررسی پرونده تسهیلات، به اطلاعات یکپارچه و قواعد شفاف دسترسی ندارند. این مسئله باعث برگشت مکرر پرونده، افزایش تماس با مرکز پشتیبانی و طولانیشدن زمان تصمیمگیری میشود.
گام دوم مثال: تعیین نتایج
تیم بهجای هدف «ساخت سامانه هوشمند»، این نتایج را تعریف میکند:
- کاهش نرخ برگشت پرونده از ۳۸ به ۱۵ درصد؛
- کاهش میانگین زمان تصمیمگیری اولیه از پنج روز به دو روز؛
- کاهش ۳۰ درصدی تماسهای پیگیری وضعیت؛
- ثبت دلیل هر تصمیم اعتباری برای کنترل و ممیزی؛
- اجرای یکسان قواعد پایه در همه شعب.
این نتایج جهت محصول را مشخص میکنند، اما هنوز راهحل را محدود نمیسازند.
گام سوم مثال: ترسیم Story Map
فعالیتهای اصلی کاربر به این صورت شناسایی میشوند:
- بررسی شرایط اولیه؛
- انتخاب نوع تسهیلات؛
- ثبت مشخصات؛
- بارگذاری مدارک؛
- کنترل کاملبودن پرونده؛
- ارسال درخواست؛
- پیگیری وضعیت؛
- رفع نقص؛
- دریافت نتیجه.
سپس برای هر فعالیت، داستانهای کاربر و استثناها استخراج میشوند.
برای فعالیت «کنترل کاملبودن پرونده» میتوان این داستانها را نوشت:
- مشاهده فهرست مدارک موردنیاز؛
- تشخیص مدرک بارگذارینشده؛
- تشخیص انقضای مدرک؛
- نمایش علت نامعتبر بودن فایل؛
- جایگزینی مدرک؛
- ذخیره پیشنویس درخواست؛
- کنترل تفاوت مدارک اشخاص حقیقی و حقوقی.
گام چهارم مثال: برش MVP
اشتباه رایج این است که تیم همه فعالیتها را برای همه انواع تسهیلات و همه شعب توسعه دهد.
MVP مناسب میتواند چنین تعریف شود:
اجرای آزمایشی فرایند درخواست یک نوع تسهیلات برای مشتریان حقیقی در دو شعبه، با تمرکز بر کنترل کاملبودن مدارک و اطلاعرسانی وضعیت پرونده.
در این MVP، قابلیتهای زیر وجود دارند:
- فهرست مدارک متناسب با نوع متقاضی؛
- بارگذاری و جایگزینی مدرک؛
- کنترل اولیه فرمت و تاریخ اعتبار؛
- نمایش نقصهای پرونده؛
- ارسال درخواست کامل؛
- مشاهده وضعیت پرونده؛
- ثبت رخدادها برای پیگیری.
اما این موارد فعلاً خارج از MVP قرار میگیرند:
- تصمیمگیری کاملاً خودکار اعتباری؛
- پوشش همه انواع تسهیلات؛
- اتصال به همه منابع بیرونی؛
- مدل پیچیده هوش مصنوعی؛
- حذف کامل بررسی انسانی.
این برش، یک جریان ارزش انتهابهانتها ایجاد میکند و امکان یادگیری واقعی را فراهم میسازد.
گام پنجم مثال: تدوین User Story
داستان اصلی
بهعنوان متقاضی تسهیلات میخواهم پیش از ارسال پرونده، نقص مدارک خود را مشاهده کنم تا درخواست من به دلیل نقص قابلپیشگیری برگشت نخورد.
معیارهای پذیرش
- فهرست مدارک باید بر اساس نوع متقاضی و نوع تسهیلات نمایش داده شود.
- مدارک اجباری و اختیاری باید از یکدیگر قابلتشخیص باشند.
- ارسال پرونده در صورت نبودن مدرک اجباری امکانپذیر نباشد.
- فرمتها و حداکثر حجم مجاز فایل قبل از بارگذاری نمایش داده شود.
- در صورت رد فایل، علت دقیق و روش اصلاح نمایش داده شود.
- متقاضی بتواند فایل قبلی را جایگزین کند.
- تاریخ و هویت کاربر جایگزینکننده مدرک ثبت شود.
- اطلاعات ذخیرهشده فقط برای افراد دارای مجوز قابلمشاهده باشد.
سناریوی اختلال سرویس بیرونی
با توجه به اینکه سرویس استعلام هویت در دسترس نیست،
هنگامی که متقاضی درخواست خود را ارسال میکند،
آنگاه سامانه باید پرونده را با وضعیت «در انتظار استعلام» ذخیره کند،
از ثبت مجدد درخواست جلوگیری کند
و زمان تقریبی بررسی بعدی را به متقاضی اطلاع دهد.
این سناریو مهم است؛ زیرا در پروژههای واقعی، رفتار سیستم هنگام اختلال سرویسها بخشی از نیازمندی است، نه موضوعی که بعداً به تیم فنی واگذار شود.
گام ششم مثال: تعریف فرضیه
باور داریم اگر نقص مدارک پیش از ارسال پرونده بهصورت دقیق به متقاضی نمایش داده شود، نرخ برگشت پرونده حداقل ۲۰ درصد کاهش پیدا میکند. این فرضیه را زمانی تأیید میکنیم که در اجرای آزمایشی ۲۰۰ پرونده، نرخ برگشت نسبت به خط مبنا کاهش معناداری داشته باشد.
این ساختار باعث میشود تیم میان «تحویل قابلیت» و «تحقق نتیجه» تفاوت قائل شود.
گام هفتم مثال: اجرای آزمایش
پیش از توسعه کامل، یک Prototype قابل کلیک به ۱۰ متقاضی و پنج کارشناس اعتباری نمایش داده میشود.
نتیجه آزمایش:
- کاربران عبارت «اعتبار مدرک» را بهدرستی درک نمیکنند؛
- مشخص نیست کدام مدرک باید جایگزین شود؛
- کاربران انتظار دارند نمونه مدرک قابلقبول را مشاهده کنند؛
- کارشناسان به تاریخچه تغییر مدارک نیاز دارند؛
- یکی از مدارک برای گروهی از متقاضیان اجباری نیست.
در نتیجه، User Story و معیارهای پذیرش قبل از توسعه اصلاح میشوند. این همان ارزش کشف نیازمندی چابک است: یادگیری پیش از پرداخت هزینه سنگین توسعه.
چگونه یک نیازمندی بزرگ را کوچک کنیم؟
اگر یک نیازمندی در یک Sprint قابلتحویل نیست، باید آن را به برشهای ارزشمند کوچکتر تقسیم کنیم.
روشهای مناسب برش نیازمندی
- بر اساس مراحل جریان کار؛
- بر اساس نوع کاربر؛
- بر اساس نوع داده؛
- بر اساس قواعد ساده و پیچیده؛
- بر اساس مسیر عادی و استثناها؛
- بر اساس کانال ارائه خدمت؛
- بر اساس سطح دسترسی؛
- بر اساس محدوده جغرافیایی یا سازمانی؛
- بر اساس روش دستی، نیمهخودکار و خودکار؛
- بر اساس درجه اطمینان یا ریسک.
نمونه برش نامناسب
- ابتدا طراحی پایگاه داده؛
- سپس Backend؛
- بعد API؛
- در پایان رابط کاربری.
این تقسیمبندی فعالیت فنی ایجاد میکند، اما تا پایان کار ارزش قابلاستفادهای به کاربر تحویل نمیدهد.
نمونه برش مناسب
- ثبت و ارسال درخواست ساده برای یک نوع متقاضی؛
- اضافهکردن امکان ذخیره پیشنویس؛
- اضافهکردن کنترل تاریخ اعتبار مدارک؛
- اضافهکردن رفع نقص؛
- اضافهکردن استعلام بیرونی؛
- اضافهکردن کنترلهای پیشرفته ریسک.
هر برش باید تا حد امکان یک رفتار قابلاستفاده و قابلآزمایش ایجاد کند.
چه زمانی یک نیازمندی برای ورود به Sprint آماده است؟
تعریف آمادگی یا Definition of Ready نباید به دروازهای بوروکراتیک تبدیل شود؛ اما یک چکلیست سبک میتواند از ابهام و دوبارهکاری جلوگیری کند.
پیش از ورود آیتم به Sprint بررسی کنید:
- کاربر یا ذینفع اصلی مشخص است؛
- مسئله و ارزش مورد انتظار روشن است؛
- آیتم به هدف محصول مرتبط است؛
- معیار پذیرش قابلآزمایش دارد؛
- مثالهای اصلی و استثناهای مهم بررسی شدهاند؛
- وابستگیهای حیاتی شناسایی شدهاند؛
- ریسکهای امنیتی و قانونی بررسی شدهاند؛
- دادهها و دسترسیهای موردنیاز مشخصاند؛
- آیتم بهاندازه کافی کوچک شده است؛
- تیم درباره آن گفتوگو کرده است؛
- سؤال حیاتی پاسخدادهنشدهای که مانع شروع باشد وجود ندارد.
آمادهبودن به معنی کامل و قطعی بودن نیست. نیازمندی باید فقط بهاندازهای روشن باشد که تیم بتواند کار را شروع کند، بازخورد بگیرد و یادگیری را ادامه دهد.
خطاهای رایج در شناسایی نیازمندی چابک
۱. تبدیل مستقیم درخواست مدیر به Backlog
قدرت سازمانی یک فرد، درخواست او را به نیاز معتبر کاربر تبدیل نمیکند. ابتدا باید مسئله و شواهد بررسی شوند.
۲. نوشتن User Story بدون گفتوگو
User Story جایگزین مکالمه نیست. کارت داستان فقط یادآور گفتوگویی است که باید میان افراد شکل بگیرد.
۳. تمرکز بر راهحل بهجای نتیجه
«افزودن چتبات» یک قابلیت است؛ اما «کاهش زمان یافتن پاسخ» یک نتیجه قابلسنجش است.
۴. تلاش برای تکمیل همه نیازمندیها در ابتدای پروژه
نیازها با تغییر بازار، قوانین، فناوری و یادگیری کاربران تغییر میکنند. تحلیل کامل پیشاپیش معمولاً پرهزینه و کماعتبار است.
۵. بیتوجهی به استثناها
فرایند واقعی فقط Happy Path نیست. اختلال سرویس، داده ناقص، دسترسی غیرمجاز و قواعد متناقض باید بررسی شوند.
۶. اولویتبندی بر اساس صدای بلندتر
اولویت باید بر اساس ارزش، ریسک، هزینه تأخیر، یادگیری و وابستگی تعیین شود؛ نه صرفاً جایگاه سازمانی درخواستکننده.
۷. اشتباه گرفتن تأیید با اعتبارسنجی
اینکه ذینفع بگوید «همین را میخواستم»، ثابت نمیکند راهحل به نتیجه مطلوب رسیده است. اعتبارسنجی به مشاهده رفتار و سنجش نتیجه نیاز دارد.
۸. استفاده نمایشی از هوش مصنوعی
نیازمندی نباید برای توجیه استفاده از AI ساخته شود. ابتدا مسئله، داده، ریسک و شاخص موفقیت را مشخص کنید؛ سپس درباره فناوری تصمیم بگیرید.
قالب آماده کارگاه کشف نیازمندی چابک
برای یک جلسه ۹۰ دقیقهای میتوانید از ساختار زیر استفاده کنید.
- همراستاسازی ـ ۱۰ دقیقه
- مسئلهای که میخواهیم بررسی کنیم چیست؟
- چه تصمیمی باید در پایان جلسه گرفته شود؟
- چه چیزی خارج از محدوده جلسه است؟
- بخش دوم: شناخت کاربر ـ ۱۵ دقیقه
- کاربر اصلی چه کسی است؟
- چه هدفی دارد؟
- اکنون کار را چگونه انجام میدهد؟</li>
- چه محدودیته
- ایی دارد؟
- ترسیم فرایند موجود ـ ۲۰ دقیقه
- نقطه شروع چیست؟
- مراحل اصلی کداماند؟
- اطلاعات چگونه جابهجا میشوند؟
- انتظار، خطا و دوبارهکاری کجا رخ میدهد؟
- تعریف مسئله و Outcome ـ ۱۵ دقیقه
- مشکل دقیق چیست؟
- چه شواهدی داریم؟
- چه شاخصی باید تغییر کند؟
- خط مبنا و هدف چیست؟
- تولید فرضیه و راهحل ـ ۱۵ دقیقه
- g=”fa”>چه فرضیههایی داریم؟
- پرریسکترین فرضیه کدام است؟
- کوچکترین آزمایش چیست؟
- تدوین Story و معیار پذیرش ـ ۱۵ دقیقه
- User Story چیست؟
- مسیر عادی کدام است؟
- مهمترین استثنا چیست؟
- چه زمانی میگوییم Story پذیرفته شده است؟
خروجی جلسه
جلسه کشف نیازمندی باید حداقل این خروجیها را داشته باشد:
- تعریف مسئله؛
- کاربر یا ذینفع اصلی؛
- شواهد موجود؛
- نتیجه و شاخص موفق
جمعبندی: نیازمندی را کشف کنید، نه اینکه فقط آن را ثبت کنید
شناسایی نیازمندی چابک زمانی موفق است که تیم بهجای اجرای سریع یک راهحل ازپیشتعیینشده، مسئله واقعی، کاربران، شواهد و نتیجه مورد انتظار را بشناسد. درخواست اولیه ذینفع فقط نقطه شروع گفتوگو است و نباید بدون تحلیل، مستقیماً به یک قابلیت یا آیتم Product Backlog تبدیل شود.
محسن سیف محمدی
محسن سیف محمدی
محسن سیف محمدی
seifmohammadi
