پاسخ کوتاه
حداقل خروجی نیازسنجی شامل خلاصه مسئله و هدف، نقشه فرایند فعلی، ذینفعان و نقشها، جریانهای اصلی، قواعد و استثناها، نیازهای داده و اتصال، الزامات امنیت و عملکرد، محدوده نسخه اول و خارج از محدوده، معیارهای پذیرش، ریسکها و تصمیمهای باز است. یک جلسه معمولاً برای پروژه پیچیده کافی نیست؛ نیازسنجی فرایندی تکرارشونده برای کشف و تأیید اطلاعات است.
چه کسانی باید در نیازسنجی شرکت کنند؟
مالک کسبوکار
- دانشی که وارد جلسه میکند
- هدف، اولویت و محدودیت تصمیم
- ریسک نبودن
- فهرست قابلیت بدون ارزش روشن
کاربر عملیاتی
- دانشی که وارد جلسه میکند
- مسیر واقعی، استثنا و دورزدنها
- ریسک نبودن
- طراحی بر اساس دستورالعمل غیرواقعی
مالک داده یا گزارش
- دانشی که وارد جلسه میکند
- منبع، کیفیت و تعریف شاخصها
- ریسک نبودن
- مغایرت در مهاجرت و گزارش
IT یا امنیت
- دانشی که وارد جلسه میکند
- زیرساخت، دسترسی و اتصالها
- ریسک نبودن
- کشف دیرهنگام محدودیت فنی
تحلیلگر و تیم اجرا
- دانشی که وارد جلسه میکند
- مدلسازی، پرسش و ثبت تصمیم
- ریسک نبودن
- نیازهای مبهم و برآورد ناپایدار
قبل از جلسه چه اطلاعاتی آماده شود؟
- هدف کسبوکار و علت شروع پروژه در یک پاراگراف
- نمونه فرم، فایل Excel، گزارش و دستورالعمل فعلی
- نام سامانههای موجود و مالک دسترسی آنها
- فهرست نقشها و چند کاربر نماینده
- نمونه واقعی یک جریان عادی و یک مورد استثنا
- محدودیت زمانی، بودجهای، قانونی یا زیرساختی شناختهشده
پرسشهای جلسه باید از مسئله به راهحل برسند
هدف
- پرسش نمونه
- اگر پروژه موفق شود چه شاخصی تغییر میکند؟
- خروجی
- معیار موفقیت
وضعیت فعلی
- پرسش نمونه
- کار از کجا شروع و کجا متوقف میشود؟
- خروجی
- نقشه As-Is
کاربر
- پرسش نمونه
- چه کسی تصمیم میگیرد و چه کسی فقط مشاهده میکند؟
- خروجی
- نقش و مجوز
استثنا
- پرسش نمونه
- چه موردی مسیر عادی را تغییر میدهد؟
- خروجی
- قاعده و سناریوی مرزی
داده
- پرسش نمونه
- منبع معتبر هر فیلد کجاست؟
- خروجی
- مدل و مالک داده
محدوده
- پرسش نمونه
- چه چیزی در نسخه اول عمداً ساخته نمیشود؟
- خروجی
- Out of Scope
بسته خروجی قابل تحویل نیازسنجی
- Problem Statement و نتیجه مورد انتظار کسبوکار
- نقشه فرایند فعلی و نقاط درد یا توقف
- فهرست ذینفعان، کاربران و ماتریس نقش و دسترسی
- جریانهای کاربری اصلی و استثناهای مهم
- واژهنامه قواعد و اصطلاحات کسبوکار
- فهرست دادهها، گزارشها، مهاجرت و اتصالها
- نیازهای غیرعملکردی مانند امنیت، سرعت، دسترسپذیری و Audit
- محدوده نسخه اول، خارج از محدوده و نقشه راه احتمالی
- معیار پذیرش، ریسکها، فرضها و پرسشهای باز
نیازهای غیرعملکردی را فراموش نکنید
عبارت «سامانه امن و سریع باشد» قابل برآورد و آزمون نیست. تعداد کاربر همزمان، زمان پاسخ برای عملیات مشخص، ساعات دسترسپذیری، نقطه بازیابی داده، نگهداری Log و مرورگر یا دستگاه هدف را با معیار قابل مشاهده ثبت کنید.
عملکرد
- ابهام رایج
- گزارش سریع باشد
- صورت قابل آزمون
- گزارش نمونه در حجم توافقشده زیر زمان مشخص
دسترسپذیری
- ابهام رایج
- همیشه کار کند
- صورت قابل آزمون
- ساعات خدمت، هدف Uptime و زمان نگهداری
پشتیبانگیری
- ابهام رایج
- Backup داشته باشد
- صورت قابل آزمون
- RPO، RTO و دوره آزمون Restore
امنیت
- ابهام رایج
- سطح دسترسی داشته باشد
- صورت قابل آزمون
- نقش، داده مجاز، Audit و دوره بازبینی
هر نیاز را از جمله مبهم به سناریوی قابل آزمون تبدیل کنید
برای هر نیاز، نقش کاربر، محرک شروع، ورودی، قاعده تصمیم، خروجی، استثنا و معیار پذیرش را ثبت کنید. این قالب تیم را مجبور میکند قبل از برآورد، تفاوت میان خواسته، رفتار سامانه و نتیجه کسبوکار را روشن کند.
ثبت سفارش سریع باشد
- اطلاعاتی که باید اضافه شود
- نقش، تعداد اقلام، خط پایه و هدف زمان
- نمونه خروجی قابل آزمون
- کاربر فروش سفارش نمونه را با حجم توافقشده در زمان هدف ثبت کند
گزارش مدیریتی داشته باشیم
- اطلاعاتی که باید اضافه شود
- شاخص، منبع داده، فیلتر، تناوب و خروجی
- نمونه خروجی قابل آزمون
- مدیر گزارش فروش را با فیلتر شعبه و بازه زمانی مشاهده و دریافت کند
به حسابداری وصل شود
- اطلاعاتی که باید اضافه شود
- جهت داده، تناوب، شناسه تطبیق و مسئول خطا
- نمونه خروجی قابل آزمون
- سند تأییدشده یکبار ارسال و خطای ناموفق با شناسه قابل پیگیری ثبت شود
سطح دسترسی داشته باشد
- اطلاعاتی که باید اضافه شود
- نقش، عملیات، محدوده داده و Audit
- نمونه خروجی قابل آزمون
- کاربر شعبه فقط رکوردهای شعبه خود را ببیند و تغییر حساس ثبت شود
نکته: اعداد عملکرد را بدون خط پایه و روش آزمون حدس نزنید. ابتدا حجم، دستگاه، شبکه و سناریوی اندازهگیری را توافق کنید.
نسخه اول را با ارزش و ریسک اولویتبندی کنید
هر درخواست مهم نیست که در نسخه اول باشد. قابلیتها را بر اساس ارزش، ضرورت عملیاتی، ریسک و وابستگی مرتب کنید. یک جریان کامل و قابل استفاده بهتر از چند ماژول نیمهتمام است.
- Must: بدون آن جریان اصلی قابل استفاده نیست
- Should: مهم است اما راه موقت قابل قبول دارد
- Could: ارزشمند است اما تصمیم نسخه اول را تغییر نمیدهد
- Won’t now: آگاهانه به مرحله بعد منتقل میشود
خروجی را تأیید کنید، نه اینکه فقط صورتجلسه بفرستید
پس از جلسه، مدل و تصمیمها برای شرکتکنندگان ارسال شود و ابهامها با مثال، Prototype یا جلسه تکمیلی بسته شوند. تأیید به معنی ثابتماندن ابدی نیازها نیست؛ یک خط پایه مشترک برای برآورد و مدیریت تغییر ایجاد میکند.
- نام مالک هر تصمیم و پرسش باز
- مهلت بازبینی و اعلام اصلاح
- ثبت نسخه سند و تاریخ تغییر
- ارتباط هر قابلیت با هدف و معیار پذیرش
- فرایند رسمی اضافهکردن یا تغییر نیاز پس از تأیید
پرسشهای متداول
یک جلسه نیازسنجی چند ساعت طول میکشد؟
به دامنه بستگی دارد. جلسه اولیه معمولاً برای شناخت مسئله و برنامه کشف است؛ پروژه چندفرایندی به مصاحبه، مشاهده کار، تحلیل اسناد و جلسات تأیید جدا نیاز دارد.
آیا نیازسنجی باید رایگان باشد؟
گفتوگوی اولیه میتواند رایگان باشد، اما تحلیل عمیق با خروجی قابل استفاده یک خدمت تخصصی است و ممکن است قرارداد یا هزینه مستقل داشته باشد.
آیا خروجی نیازسنجی همان RFP است؟
نه دقیقاً. خروجی تحلیل میتواند مبنای RFP شود، اما RFP معمولاً شرایط همکاری، ارزیابی تأمینکننده و قالب پیشنهاد را نیز در بر میگیرد.
آیا در نیازسنجی باید فناوری انتخاب شود؟
پس از روشنشدن نیاز، محدودیت و گزینهها میتوان تصمیم فناوری را بررسی کرد. انتخاب زودهنگام ممکن است تحلیل را به قابلیتهای یک ابزار محدود کند.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.