اگر بخواهم خیلی ساده بگویم، تبدیل نیازمندی به راهکار فرآیندی در اجایل یعنی اینکه یک خواستهی خام، مبهم یا کلی را به یک جریان کاری روشن، قابل اجرا، قابل سنجش و قابل بهبود تبدیل کنم. من در این مسیر فقط دنبال نوشتن یک سند نیستم؛ هدفم این است که از دل نیاز، یک راهکار واقعی بسازم که هم با اصول اجایل هماهنگ باشد و هم در عمل برای تیم و کسبوکار ارزش ایجاد کند.
در دنیای امروز، موفقترین تیمها آنهایی هستند که نیازمندی را سریع میفهمند، آن را به زبان کاربر و کسبوکار ترجمه میکنند، و بعد با بازخوردهای مستمر آن را به یک فرآیند قابلتحویل تبدیل میکنند. این دقیقاً همان چیزی است که در Agile Manifesto و 12 اصل اجایل روی آن تأکید شده است.
چرا تبدیل نیازمندی به راهکار فرآیندی در اجایل مهم است؟
من وقتی با یک نیازمندی مواجه میشوم، اول از خودم میپرسم: این نیاز دقیقاً چه مشکلی را حل میکند؟ اگر جواب این سؤال روشن نباشد، هر راهکاری که بسازم احتمالاً فقط یک پاسخ فنی است، نه یک راهحل فرآیندی.
در چارچوب اجایل، من باید نیازمندی را به گونهای تعریف کنم که:
- برای تیم قابل فهم باشد
- برای ذینفعان قابل تأیید باشد
- برای توسعه قابل پیادهسازی باشد
- برای تست و بازبینی قابل اندازهگیری باشد
این نگاه با Scrum Guide 2020 همراستاست؛ جایی که تأکید اصلی روی شفافیت، بازخورد، سازگاری با تغییر و تحویل تدریجی ارزش است.
مراحل تبدیل نیازمندی به راهکار فرآیندی در اجایل
1) نیازمندی را شفاف میکنم
اولین قدم من این است که نیازمندی را از حالت کلی و مبهم خارج کنم.
برای این کار این سؤالها را از خودم و ذینفعان میپرسم:
- این نیاز دقیقاً چه مسئلهای را حل میکند؟
- چه کسی از این راهکار استفاده میکند؟
- خروجی مطلوب چیست؟
- موفقیت را با چه شاخصی میسنجیم؟
- چه محدودیتهایی داریم؟
مثلاً اگر نیازمندی این باشد که «زمان پاسخگویی به درخواست مشتری کم شود»، من آن را به یک صورت شفافتر تبدیل میکنم:
«فرآیند پاسخگویی باید طوری بازطراحی شود که زمان متوسط پاسخ به درخواست مشتری از 24 ساعت به 4 ساعت کاهش پیدا کند.»
2) نیازمندی را به هدف کسبوکار وصل میکنم
من هیچ نیازمندی را جدا از هدف کسبوکار بررسی نمیکنم.
اگر ندانم چرا این کار را انجام میدهیم، احتمالاً راهکاری که میسازم ارزش واقعی نخواهد داشت.
در این مرحله، من رابطهی بین نیازمندی و هدف را مشخص میکنم:
- نیازمندی: چه چیزی لازم است؟
- هدف: چرا لازم است؟
- نتیجه: چه تغییری باید رخ دهد؟
- شاخص موفقیت: از کجا بفهمم درست عمل کردهایم؟
این کار باعث میشود تبدیل نیازمندی به راهکار فرآیندی در اجایل فقط یک تمرین مستندسازی نباشد، بلکه به یک تصمیم ارزشآفرین تبدیل شود.
3) ذینفعان، ورودیها و محدودیتها را مشخص میکنم
هر راهکار فرآیندی در اجایل باید با واقعیت سازمان هماهنگ باشد.
برای همین من قبل از طراحی، ذینفعان را شناسایی میکنم:
- کاربر نهایی
- مالک محصول
- مالک فرآیند
- تیم اجرایی
- تیم فنی
- مدیر کسبوکار
بعد ورودیها و محدودیتها را مینویسم:
- ورودی فرآیند چیست؟
- چه دادههایی لازم داریم؟
- چه قوانین یا تأییدهایی وجود دارد؟
- فرآیند در کجا متوقف میشود؟
- چه ریسکهایی باید مدیریت شوند؟
این مرحله کمک میکند راهکار من فقط روی کاغذ خوب نباشد، بلکه در اجرا هم جواب بدهد.
4) نیازمندی را به User Story تبدیل میکنم
در رویکرد اجایل، من معمولاً نیازمندی را به User Story ترجمه میکنم تا تیم دقیقاً بفهمد چه ارزشی باید تحویل دهد.
فرم استانداردی که استفاده میکنم این است:
بهعنوان [نقش]، میخواهم [نیاز] تا بتوانم [ارزش].
مثال:
بهعنوان کارشناس پشتیبانی، میخواهم درخواست مشتری بهصورت خودکار دستهبندی شود تا سریعتر به آن رسیدگی کنم.
بعد از آن، برای هر User Story معیار پذیرش تعریف میکنم:
- درخواست باید در کمتر از 5 ثانیه دستهبندی شود
- در صورت ناقص بودن اطلاعات، پیام خطای واضح نمایش داده شود
- کاربر امکان اصلاح دستهبندی را داشته باشد
این کار باعث میشود نیازمندی از یک جملهی مبهم به چیزی قابل تست و قابل تحویل تبدیل شود.
5) راهکار فرآیندی را مدلسازی میکنم
در این مرحله، من نیازمندی را به یک فرآیند عملیاتی تبدیل میکنم.
برای این کار از مدلسازی فرآیند استفاده میکنم و معمولاً BPMN 2.0 را انتخاب میکنم. طبق صفحه رسمی OMG، BPMN یک استاندارد شناختهشده برای مدلسازی فرآیندهای کسبوکار است که هم برای ذینفعان قابل فهم است و هم برای تبدیل به اجزای نرمافزاری دقت کافی دارد:
در مدل فرآیند، من این عناصر را مشخص میکنم:
- شروع فرآیند
- فعالیتها
- تصمیمها
- نقشها
- استثناها
- پایان فرآیند
مثلاً اگر نیازمندی درباره ثبت و پیگیری درخواست مشتری باشد، فرآیند میتواند اینطور تعریف شود:
- دریافت درخواست
- اعتبارسنجی اطلاعات
- دستهبندی خودکار
- ارجاع به واحد مربوطه
- انجام اقدام لازم
- ثبت نتیجه
- اطلاعرسانی به مشتری
6) راهکار را در اسپرینتهای کوچک آزمایش میکنم
من هیچ راهکار فرآیندی را یکباره و کامل پیاده نمیکنم.
در اجایل، بهتر است راهکار در نسخههای کوچک و قابل بازخورد ساخته شود. این همان روحیهای است که در Scrum Guide و اصول اجایل دیده میشود.
روش من این است:
- ابتدا نسخه ساده فرآیند را طراحی میکنم
- آن را در بکلاگ قرار میدهم
- در اسپرینت کوتاه پیادهسازی میکنم
- بازخورد میگیرم
- اصلاح و بهبود میدهم
به این ترتیب، تبدیل نیازمندی به راهکار فرآیندی در اجایل تبدیل میشود به یک مسیر یادگیری مستمر، نه یک پروژهی سنگین و ایستا.
7) شاخصهای موفقیت را تعریف میکنم
اگر نتوانم موفقیت را اندازه بگیرم، نمیتوانم بگویم راهکارم واقعاً جواب داده یا نه.
برای همین من از ابتدا KPI تعریف میکنم، مثل:
- زمان چرخه فرآیند
- زمان پاسخگویی
- نرخ خطا
- نرخ تکمیل
- میزان رضایت کاربر
- تعداد بازکاری
این شاخصها به من کمک میکنند بفهمم آیا فرآیند جدید واقعاً بهتر از قبل شده یا فقط پیچیدهتر شده است.
8) مستندات را سبک، کاربردی و بهروز نگه میدارم
من طرفدار مستندات سنگین و طولانی نیستم.
در عوض، ترجیح میدهم مستنداتم کوتاه، دقیق و کاربردی باشند؛ چیزی که تیم بتواند واقعاً از آن استفاده کند.
این رویکرد با اصول مدیریت کیفیت و نگاه فرآیندی در ISO 9001:2015 هم سازگار است؛ جایی که روی رویکرد فرآیندی، انطباق با تغییر و همراستایی با نیازهای سازمان تأکید شده است.
یک الگوی ساده برای تبدیل نیازمندی به راهکار فرآیندی در اجایل
اگر بخواهم این مسیر را خیلی خلاصه کنم، من این 6 قدم را دنبال میکنم:
- نیازمندی را شفاف میکنم
- آن را به هدف کسبوکار وصل میکنم
- ذینفعان و محدودیتها را مشخص میکنم
- نیازمندی را به User Story تبدیل میکنم
- راهکار فرآیندی را با BPMN مدل میکنم
- در اسپرینتهای کوچک تست و بهبود میدهم
این الگو برای من یک مسیر مطمئن است، چون هم چابک است، هم فرآیندی، هم قابل اجرا.
اشتباهاتی که من سعی میکنم انجام ندهم
- نیازمندی را بدون فهم مسئله اجرا نکنم
- فرآیند را بدون مشارکت ذینفعان طراحی نکنم
- راهکار را بدون معیار موفقیت نسازم
- منتظر پایان پروژه نمانم تا بازخورد بگیرم
- مستندسازی را از ارزش واقعی مهمتر نکنم
جمعبندی
من وقتی میخواهم تبدیل نیازمندی به راهکار فرآیندی در اجایل را انجام دهم، در واقع از یک خواستهی خام به یک جریان ارزش میرسم.
یعنی نیازمندی را شفاف میکنم، به هدف کسبوکار وصل میکنم، آن را به User Story و معیار پذیرش تبدیل میکنم، سپس با BPMN مدل میسازم و در نهایت در اسپرینتهای کوتاه آزمایش و بهبود میدهم.
به نظر من، این بهترین مسیر برای ساخت راهکارهای فرآیندی در دنیای امروز است؛ مسیری که هم با اجایل سازگار است و هم با استانداردهای روز مدیریت فرآیند.