نیازسنجی نرم‌افزار: پیش از سفارش سامانه اختصاصی، نیازهایتان را چگونه مستند کنیم؟
بخش بزرگی از مشکلات پروژه‌های نرم‌افزاری از نیازهای مبهم شروع می‌شود. در این مقاله یک روش ساده و عملی برای مستند کردن نیازها پیش از سفارش سامانه اختصاصی ارائه می‌کنیم.
فهرست مطالب
- ۱. مسئله را تعریف کنید، نه راه‌حل را
- نتیجه مطلوب را هم بنویسید
- ۲. کاربران و نقش‌ها را فهرست کنید
- ۳. فرآیندها را قدم به قدم بنویسید
- ۴. داده‌ها و فرم‌ها را مشخص کنید
- داده‌های موجود
- ۵. گزارش‌ها و اعلان‌ها
- ۶. ارتباط با سیستم‌های دیگر
- ۷. الزامات غیرعملکردی
- ۸. اولویت‌بندی: ضروری، مهم، خوب است داشته باشیم
- یک قالب ساده برای سند نیازها
- جمع‌بندی
«یک سامانه برای مدیریت درخواست‌ها می‌خواهیم.» این جمله برای شروع گفت‌وگو کافی است، اما برای ساختن نرم‌افزار نه. هر کس از این جمله تصویر متفاوتی در ذهن دارد و همین تفاوت، بعدها به صورت تأخیر، هزینه اضافه و سامانه‌ای که «آن چیزی نیست که می‌خواستیم» خودش را نشان می‌دهد. نیازسنجی یعنی تبدیل این تصویر ذهنی به سندی روشن که همه طرف‌ها آن را یکسان بفهمند.
لازم نیست برای این کار متخصص فنی باشید. اگر سازمان خودتان را می‌شناسید، می‌توانید بخش مهمی از نیازها را با پاسخ به سوال‌های زیر مستند کنید.
۱. مسئله را تعریف کنید، نه راه‌حل را
به جای شروع با «یک پنل با این دکمه‌ها می‌خواهیم»، بنویسید امروز چه مشکلی دارید. برای مثال: «درخواست‌های مشتریان در پیام‌رسان‌ها و ایمیل پراکنده است، معلوم نیست هر درخواست دست چه کسی است و پیگیری وضعیت آن زمان‌بر است.» تعریف دقیق مسئله کمک می‌کند تیم فنی گاهی راه‌حلی ساده‌تر و ارزان‌تر از آنچه در ذهن شماست پیشنهاد دهد.
نتیجه مطلوب را هم بنویسید
اگر سامانه موفق باشد، چه چیزی تغییر می‌کند؟ مثلاً «هر درخواست مسئول مشخص دارد و مشتری بدون تماس تلفنی، وضعیت درخواست را می‌بیند.» این جمله بعدها معیار ارزیابی پروژه خواهد بود.
۲. کاربران و نقش‌ها را فهرست کنید
چه کسانی از سامانه استفاده می‌کنند و هرکدام چه کاری انجام می‌دهند؟ یک جدول ساده کافی است:
- مشتری: ثبت درخواست، مشاهده وضعیت، دریافت پاسخ
- کارشناس: بررسی درخواست‌های ارجاع‌شده، ثبت پاسخ، تغییر وضعیت
- مدیر واحد: ارجاع درخواست‌ها، مشاهده گزارش عملکرد
- مدیر سیستم: تعریف کاربران و سطح دسترسی‌ها
مشخص کردن نقش‌ها، پایه طراحی سطح دسترسی است؛ یعنی هر کس فقط اطلاعات و عملیاتی را ببیند که به آن نیاز دارد.
۳. فرآیندها را قدم به قدم بنویسید
برای هر فرآیند مهم، مسیر را از شروع تا پایان بنویسید. نیازی به نمودارهای پیچیده نیست؛ یک فهرست مرحله‌ای کافی است:
- مشتری درخواست را با انتخاب نوع درخواست ثبت می‌کند.
- سامانه کد پیگیری صادر و به مشتری پیامک می‌کند.
- مدیر واحد درخواست را به یک کارشناس ارجاع می‌دهد.
- کارشناس درخواست را بررسی و در صورت نیاز اطلاعات بیشتر می‌خواهد.
- پس از انجام، وضعیت «انجام‌شده» ثبت و به مشتری اطلاع داده می‌شود.
استثناها را هم فراموش نکنید: اگر درخواست ناقص بود چه می‌شود؟ اگر کارشناس در دسترس نبود؟ اگر مشتری انصراف داد؟ بخش زیادی از پیچیدگی نرم‌افزار در همین حالت‌های استثنا پنهان است.
۴. داده‌ها و فرم‌ها را مشخص کنید
سامانه چه اطلاعاتی نگه می‌دارد؟ فرم‌های فعلی (کاغذی یا اکسل) را جمع کنید؛ این فرم‌ها بهترین منبع برای فهم داده‌ها هستند. برای هر داده مهم مشخص کنید اجباری است یا اختیاری، چه کسی آن را وارد می‌کند و چه کسی اجازه تغییرش را دارد.
داده‌های موجود
اگر اطلاعاتی در سیستم‌های قدیمی یا فایل‌های اکسل دارید که باید به سامانه جدید منتقل شود، این موضوع را از ابتدا مطرح کنید. انتقال داده یک بخش مستقل از کار است و نیاز به برنامه‌ریزی دارد.
۵. گزارش‌ها و اعلان‌ها
مدیران چه سوال‌هایی دارند که سامانه باید به آن‌ها پاسخ دهد؟ مثلاً «چند درخواست باز داریم؟»، «میانگین زمان پاسخ هر کارشناس چقدر است؟». همچنین مشخص کنید در چه رویدادهایی چه کسی باید باخبر شود و از چه راهی: اعلان درون سامانه، ایمیل یا پیامک.
۶. ارتباط با سیستم‌های دیگر
آیا سامانه باید با نرم‌افزار حسابداری، سامانه پیامک، درگاه پرداخت یا نرم‌افزارهای داخلی دیگر ارتباط داشته باشد؟ برای هر مورد بنویسید چه داده‌ای و در چه جهتی جابه‌جا می‌شود. وجود یا نبود امکان اتصال (API) در سیستم‌های موجود، روی برآورد پروژه اثر مستقیم دارد.
۷. الزامات غیرعملکردی
این‌ها به «چه کاری» مربوط نیستند، بلکه به «چگونه» مربوط‌اند:
- تعداد تقریبی کاربران هم‌زمان
- الزامات امنیتی و نگهداری سوابق تغییرات
- محل استقرار: سرور داخلی سازمان یا سرور ابری
- نیاز به نسخه موبایل یا امکان کار در شبکه داخلی
- پشتیبان‌گیری و زمان قابل قبول برای بازیابی
۸. اولویت‌بندی: ضروری، مهم، خوب است داشته باشیم
همه امکانات ارزش یکسانی ندارند. کنار هر امکان یکی از این سه برچسب را بگذارید. این کار اجازه می‌دهد نسخه اول سامانه با امکانات ضروری زودتر آماده شود و بقیه در مراحل بعد اضافه شوند. توسعه مرحله‌ای، ریسک پروژه را کم می‌کند و بازخورد کاربران واقعی را زودتر به تصمیم‌ها وارد می‌کند.
یک قالب ساده برای سند نیازها
- تعریف مسئله و نتیجه مطلوب
- کاربران و نقش‌ها
- فرآیندهای اصلی و استثناها
- داده‌ها، فرم‌ها و داده‌های قابل انتقال
- گزارش‌ها و اعلان‌ها
- یکپارچگی با سیستم‌های دیگر
- الزامات غیرعملکردی
- اولویت‌بندی امکانات
جمع‌بندی
سند نیازها لازم نیست کامل و بی‌نقص باشد؛ کافی است صادقانه و روشن، وضعیت امروز و انتظار شما از فردا را نشان دهد. تیم فنی با این سند می‌تواند سوال‌های دقیق‌تری بپرسد، برآورد واقع‌بینانه‌تری ارائه دهد و راه‌حلی متناسب با نیاز واقعی شما طراحی کند. اگر برای تکمیل این سند به کمک نیاز دارید، فرم ثبت سفارش هیواسا بخش نیازسنجی دارد و جلسه تحلیل نیاز هم بخشی از فرآیند همکاری ماست.
