مطالعه امکانسنجی پروژه نرمافزاری چگونه انجام میشود؟

«آیا این پروژه اصلاً شدنی است؟» پرسشی که باید پیش از امضای قرارداد، تخصیص بودجه و انتخاب تیم پاسخ داده شود؛ اما در عمل اغلب به یک تشریفات اداری تبدیل میشود: چند صفحه پر از جدول که پس از تصویب، دیگر هیچکس به آن نگاه نمیکند. مطالعه امکانسنجی (Feasibility Study) قرار است چنین سرنوشتی نداشته باشد؛ این مطالعه یک بررسی منظم و پیشدستانه است که مشخص میکند ایدهای نرمافزاری با محدودیتهای واقعی فنی، مالی و انسانی، پا برجا میماند یا با نخستین آزمون جدی فرو میریزد.
نکته مهم این است که امکانسنجی به دنبال جواب مثبت نیست؛ به دنبال جواب درست است. گاهی نتیجه سالم یک مطالعه امکانسنجی، کنار گذاشتن ایده یا بازطراحی کامل آن است و همین نتیجه «منفی» میتواند ساعتها کار بیهوده را از سازمان حذف کند. در پروژههای نرمافزاری که هزینه شکست دیر و پرهزینه آشکار میشود، این بررسی پیش از شروع، ارزشی چندبرابر دارد.
در این مقاله بررسی میکنیم مطالعه امکانسنجی دقیقاً چه پرسشی را پاسخ میدهد، پنج بُعد اصلی آن کداماند، فرآیند اجرای آن چگونه پیش میرود و چه تفاوتی با سند توجیه اقتصادی (Business Case) دارد. در پایان هم با یک مثال سازمانی و فهرستی از خطاهای رایج، تصویر را عملیاتی میکنیم.
امکانسنجی چه پرسشی را پاسخ میدهد؟
پرسش محوری امکانسنجی این است: «آیا میتوانیم این کار را انجام دهیم؟» — نه «آیا انجامدادن آن ارزش دارد؟». این تفکیک ظریف اما تعیینکننده است. پرسش اول درباره توان و شرایط اجراست و پرسش دوم درباره ارزش و توجیه. یک پروژه میتواند کاملاً شدنی باشد اما هیچ ارزش اقتصادیای تولید نکند؛ یا برعکس، فرصتی جذاب باشد اما سازمان ظرفیت اجرایش را نداشته باشد.
به همین دلیل امکانسنجی هیچگاه جایگزین Business Case نمیشود، بلکه مکمل آن است. سند توجیه اقتصادی به مدیران میگوید چرا این پروژه باید انجام شود و امکانسنجی میگوید آیا اصلاً میشود. هر دو سند با هم تصویر کامل تصمیم را میسازند و حذف هرکدام، تصمیم را به حدس نزدیک میکند.
پنج بُعد اصلی مطالعه امکانسنجی
امکانسنجی فنی (Technical Feasibility)
در این بُعد بررسی میشود آیا راهکار فنی موردنظر با دانش تیم، فناوریهای موجود و زیرساخت سازمان قابل پیادهسازی است یا خیر. سؤالات نمونه: آیا تجربه کافی برای کار با این فناوری داخل تیم یا در بازار کار وجود دارد؟ آیا زیرساخت سرور و شبکه ظرفیت لازم را دارد؟ آیا یکپارچهسازی (Integration) با سامانههای موجود عملی است؟ اگر پاسخ بخشی از این سؤالات «نمیدانیم» باشد، همانجا نقطه شروع یک آزمون فنی کوچک مشخص میشود.
امکانسنجی مالی (Financial Feasibility)
اینجا پرسش این است که آیا بودجه لازم برای ساخت و — مهمتر — نگهداری نرمافزار در دسترس است. خطای رایج سازمانها آن است که فقط هزینه توسعه را میبینند و هزینههای تمدید لایسنسها، پشتیبانی، ارتقای زیرساخت و آموزش کاربران را از قلم میاندازند. در این بُعد باید هزینهها برآورد و با منابع مالی قابل تخصیص مقایسه شوند؛ بدون آنکه اعداد صرفاً خوشبینانه تخمین زده شوند.
امکانسنجی عملیاتی (Operational Feasibility)
نرمافزار ممکن است ساخته شود، اما آیا کسی از آن استفاده میکند؟ امکانسنجی عملیاتی بررسی میکند که کاربران و واحدهای سازمان چقدر آماده پذیرش راهکار جدید هستند: فرآیندهای فعلی چگونه با نرمافزار همراستا میشوند؟ آیا تغییر عادتها یا بازآرایی ساختار لازم است؟ مقاومت پنهان کاربران یکی از شایعترین دلایل مردودی سامانههای فنی درست است و دقیقاً در همین بُعد شناسایی میشود.
امکانسنجی زمانی (Schedule Feasibility)
هر پروژهای موعد دارد؛ رونمایی از یک محصول، انطباق با الزام جدید یا مهلت قرارداد. در امکانسنجی زمانی بررسی میشود که آیا زمان در دسترس با برآورد واقعبینانه کار سازگار است یا خیر. اگر فاصله این دو زیاد باشد، گزینهها روشن میشوند: کمکردن محدوده، واگذاری بخشی از کار یا جابهجایی موعد. پنهانکاری در این مرحله، یعنی انتقال بحران به میانه پروژه.
امکانسنجی سازمانی و قانونی (Organizational and Legal Feasibility)
بُعد سازمانی میپرسد ساختار و فرهنگ سازمان از این پروژه پشتیبانی میکند یا نه: آیا مالک محصول (Product Owner) و حامی اجرایی پروژه در سازمان وجود دارد؟ بُعد قانونی هم بررسی میکند الزامات مقرراتی، مالکیت دادهها، مجوزها و قراردادها چه محدودیتهایی میسازند. برای نمونه، دادههایی که قرار است در سامانه جدید پردازش شوند ممکن است مشمول محدودیتهای حفظ اطلاعات شخصی باشند و کل طراحی را زیر سؤال ببرند.
فرآیند اجرای مطالعه امکانسنجی
امکانسنجی یک فرآیند مرحلهای است و انجام آن به ترتیب، کیفیت نتیجه را تضمین میکند:
- شفافسازی ایده: اهداف، محدوده اولیه و معیارهای موفقیت ایده در یکدو صفحه مکتوب میشود تا ارزیابی روی چیزی مشخص انجام شود، نه روی تصویری مبهم.
- گردآوری اطلاعات: گفتوگو با ذینفعان (Stakeholders) کلیدی، بررسی زیرساخت، قوانین و شرایط بازار. کیفیت امکانسنجی مستقیماً به کیفیت همین ورودیها وابسته است.
- تعریف گزینهها: بهجای قفلشدن روی یک راهکار، دستکم دو یا سه گزینه — از ساخت داخلی تا خرید محصول آماده — کنار هم گذاشته میشود.
- ارزیابی در پنج بُعد: هر گزینه از منظر فنی، مالی، عملیاتی، زمانی و سازمانی-قانونی سنجیده و ریسکهای اصلی هر مسیر ثبت میشود.
- مستندسازی و ارائه: یافتهها، مقایسه گزینهها و توصیه نهایی در گزارشی مختصر نوشته و به تصمیمگیرندگان ارائه میشود.
- تصمیم شفاف: خروجی فرآیند باید یکی از این سه باشد: پیشروی، بازطراحی ایده یا توقف. «فعلاً هیچ» تصمیم نیست، عقبنشینی است.
تفاوت مطالعه امکانسنجی با Business Case
این دو سند مکرراً با هم اشتباه گرفته میشوند، در حالی که هرکدام پرسش متفاوتی را پاسخ میدهند و در جایگاه متفاوتی از چرخه حیات پروژه نوشته میشوند. جدول زیر تفاوتها را خلاصه میکند:
| ویژگی | سند توجیه اقتصادی (Business Case) | مطالعه امکانسنجی (Feasibility Study) |
|---|---|---|
| پرسش محوری | چرا باید این پروژه انجام شود؟ | آیا انجامدادن این پروژه ممکن است؟ |
| تمرکز اصلی | ارزش، بازگشت سرمایه و همراستایی با استراتژی | توان اجرا در ابعاد فنی، مالی، عملیاتی، زمانی و سازمانی |
| زمان نگارش | پیش از هر تصمیم درباره شروع پروژه | همزمان یا بلافاصله پس از آن، برای اعتبارسنجی گزینه اجرایی |
| خروجی | توجیه یا رد ایده از منظر ارزش | گزینه اجرایی منتخب یا اعلام ناپذیربودن اجرا |
| رابطه دو سند | بدون امکانسنجی ممکن است آرزو بماند | بدون توجیه اقتصادی ممکن است بیارزش پیش برود |
خلاصه رابطه این است: Business Case پروژه را «میفروشد» و امکانسنجی بررسی میکند که این فروش روی واقعیت سوار است یا روی توهم. سازمانهای بالغ هر دو سند را کنار هم میگذارند و تا وقتی هر دو روشن نشدهاند، منابع اصلی پروژه را آزاد نمیکنند.
مثال کاربردی: جایگزینی سامانه مدیریت خسارت در یک شرکت بیمه
فرض کنید یک شرکت بیمه بزرگ تصمیم دارد سامانه قدیمی مدیریت خسارت را با یک پلتفرم جدید جایگزین کند. تیم بررسی، سه گزینه را مطرح میکند: توسعه داخلی، خرید محصول آماده و سفارش ساخت به یک شرکت پیمانکار. مطالعه امکانسنجی برای هر سه گزینه اجرا میشود.
در بُعد فنی مشخص میشود سامانههای قدیمی شرکت برای اتصال به محصول خارجی، رابطهای برنامهنویسی (API) استاندارد ندارند و نیاز به کار واسطهای سنگین است. در بُعد عملیاتی، مصاحبه با سرپرستان شعب نشان میدهد فرآیند فعلی ثبت خسارت عادتهای ریشهداری دارد و هر راهکاری بدون برنامه تغییر و آموزش، با مقاومت روبهرو میشود. در بُعد زمانی هم معلوم میشود فصل اوج ثبت خسارت در پایان سال است و بازه امن برای مهاجرت دادهها فقط یک پنجره کوتاه بهاری است.
نتیجه مطالعه، انتخاب مسیر مرکبی است: خرید هسته محصول آماده، توسعه لایههای اتصال بهصورت داخلی و آغاز آموزش شعب دو ماه پیش از مهاجرت. این «ترکیب» چیزی است که هیچیک از سه گزینه اولیه به تنهایی پیشنهاد نمیداد و فقط از دل امکانسنجی بیرون آمد. اگر شرکت مستقیماً به سراغ یکی از گزینهها میرفت، یا هزینه یکپارچهسازی را دستکم میگرفت یا مقاومت شعب را نادیده میانگاشت.
خطاهای رایج در مطالعه امکانسنجی
- امکانسنجی پس از تصمیم: وقتی تیم پروژه انتخاب شده و بودجه تخصیص یافته، امکانسنجی به سند توجیهی تبدیل میشود؛ یعنی کاری که باید پاسخ صادقانه بگیرد، فقط امضای رسمی میگیرد.
- ارزیابی تکگزینهای: بررسی فقط یک راهکار، امکانسنجی را به توجیه همان راهکار تقلیل میدهد؛ ارزش اصلی در مقایسه گزینههاست.
- نادیدهگرفتن بُعد عملیاتی: فنیها عاشق معماری میشوند و فراموش میکنند کاربرانی که قرار است سیستم را بپذیرند، انسانهایی با عادتهای ریشهدارند.
- تخمینهای خوشبینانه: برآورد هزینه و زمان بدون ذخیره برای عدمقطعیت، سند را از ابتدا غیرواقعی میکند.
- گزارشهای بیتصمیم: گزارشی که به یکی از سه سرنوشت روشن (پیشروی، بازطراحی، توقف) ختم نشود، فقط زمان جلسات را هدر داده است.
کاربرد عملی: از امکانسنجی تا شروع پروژه
خروجی امکانسنجی نباید در قفسه بماند؛ مستقیماً به اسناد آغازین پروژه تغذیه میشود. گزینه اجرایی منتخب، محدوده اولیه و ریسکهای شناساییشده در گزارش امکانسنجی، ورودی طبیعی منشور پروژه (Project Charter) و برنامههای بعدی هستند. به این ترتیب تیمی که پروژه را میگیرد میداند چرا این مسیر انتخاب شده و کجاها احتمال لغزش وجود دارد.
یک توصیه عملی: امکانسنجی را کوتاه و صادقانه نگه دارید. گزارشهای طولانی خوانده نمیشوند و جدولهای شلوغ، تصمیمگیرندگان را خسته میکنند. یک گزارش دهصفحهای صادقانه از یک صدصفحهای محتاطانه بسیار مؤثرتر است؛ مشروط بر اینکه هر ادعا با شاهدی واقعی — یک مصاحبه، یک آزمون کوچک، یک بررسی مستند — پشتیبانی شود.
امکانسنجی خوب پروژه را متوقف نمیکند؛ مسیر اشتباه را زودتر میبندد تا منابع، مسیر درست را باز کنند.
نکات کلیدی این مقاله
- مطالعه امکانسنجی پرسش «آیا میتوانیم؟» را پاسخ میدهد و سند توجیه اقتصادی پرسش «آیا ارزشش را دارد؟» را؛ این دو مکمل یکدیگرند.
- ارزیابی باید دستکم در پنج بُعد فنی، مالی، عملیاتی، زمانی و سازمانی-قانونی انجام شود؛ حذف هر بُعد، کوررنگی عمدی است.
- مقایسه دو یا سه گزینه اجرایی هسته اصلی امکانسنجی است و ارزیابی تکگزینهای ارزش بررسی را از بین میبرد.
- خروجی سالم امکانسنجی یکی از سه تصمیم پیشروی، بازطراحی یا توقف است و مستقیماً به منشور پروژه تغذیه میشود.
سوالات متداول
آیا برای پروژههای کوچک هم امکانسنجی لازم است؟
بله، اما در مقیاس متناسب. برای پروژه کوچک، امکانسنجی میتواند سندی چندصفحهای باشد که همین پنج بُعد را مختصر بررسی میکند؛ حذف کامل بررسی اشتباه است، نه کوتاهکردن آن.
چه کسی باید مطالعه امکانسنجی را انجام دهد؟
معمولاً تحلیلگر کسبوکار (Business Analyst) یا مدیر پروژه پیشتاز آن است، اما بدون مشارکت کارشناسان فنی، مالی و واحدهای بهرهبردار، نتیجه ناقص میماند. امکانسنجی یک کار گروهی است که با یک قلم واحد نوشته میشود.
اگر نتیجه امکانسنجی منفی شود چه باید کرد؟
نتیجه منفی شکست نیست؛ صرفهجویی است. ایده یا کنار گذاشته میشود یا با رفع موانع شناساییشده بازطراحی و دوباره ارزیابی میشود. آنچه خطرناک است، چرخاندن نتیجه منفی به سند توجیهی است.



