مسئله را از درخواست قابلیت جدا کنید
«یک داشبورد می خواهیم» هنوز شرح مسئله نیست. باید روشن شود چه کسی قرار است از آن استفاده کند، کدام تصمیم با اطلاعات فعلی دشوار است و داده مورد نیاز از کجا می آید. ممکن است پاسخ نهایی یک گزارش ساده باشد یا به تغییر جریان ثبت اطلاعات نیاز داشته باشد. این تفاوت، دامنه و هزینه اجرا را تغییر می دهد.
در شرح اولیه، یک نمونه واقعی از کار روزانه را بنویسید: درخواست از کجا شروع می شود، چه واحدهایی آن را بررسی می کنند و در پایان چه خروجی ثبت می شود. اگر بخشی از فرایند بیرون از نرم افزار انجام می شود، آن را هم ذکر کنید. یک نمونه دقیق معمولا از چند صفحه عبارت کلی مفیدتر است.
کاربران و مرز مسئولیت را مشخص کنید
فهرست کاربران را به عنوان شغلی محدود نکنید. برای هر نقش بنویسید چه اطلاعاتی می بیند، چه چیزی را تغییر می دهد و در کدام مرحله مسئول پاسخگویی است. تفاوت دسترسی مدیر، کارشناس و مشتری باید در همین مرحله قابل توضیح باشد.
سامانه های موجود، منبع داده و تیم مسئول هر اتصال را هم معرفی کنید. اگر دریافت اطلاعات از یک نرم افزار دیگر لازم است، وجود API، امکان خروجی گرفتن و محدودیت دسترسی را بررسی کنید. این موضوع مستقیما به دامنه یکپارچه سازی سامانه ها مربوط است.
معیار تحویل را قابل بررسی بنویسید
عبارت هایی مانند «سریع، حرفه ای و بدون نقص» به تنهایی معیار پذیرش نیستند. یک سناریوی مشخص تعریف کنید: کاربر با چه ورودی، در چه وضعیتی و با چه سطح دسترسی باید به کدام نتیجه برسد؟ برای گزارش هم نام شاخص، منبع محاسبه و بازه زمانی مورد نیاز را ثبت کنید.
دامنه نسخه اول را از ایده های بعدی جدا کنید. بهتر است معلوم باشد چه چیزی در این مرحله تحویل می شود و چه موضوعی نیاز به تصمیم بعدی دارد. روش همکاری فَدین بر همین تقسیم مراحل و خروجی های قابل بررسی تکیه دارد.
یک بسته اولیه کوتاه اما کافی
- مسئله اصلی و نتیجه مورد انتظار
- کاربران، نقش ها و مسیر فعلی انجام کار
- سامانه های موجود و وابستگی های اطلاعاتی
- محدودیت های زمان، محیط اجرا و دسترسی
- سناریوهای اصلی پذیرش و خروجی تحویل
با این اطلاعات، گفتگو درباره توسعه سامانه سازمانی از انتخاب زودهنگام ابزار فاصله می گیرد و روی نیاز واقعی متمرکز می شود. برای بررسی موضوع خود، همین ساختار را در فرم درخواست مشاوره بنویسید.
