راهنمای سفارش نرم‌افزار اختصاصی؛ بریف، دامنه و معیار پذیرش

بریف را با نتیجه مورد انتظار شروع کنید

«یک پنل مدیریت می‌خواهیم» هنوز توضیح نمی‌دهد کدام کار باید بهتر انجام شود. بنویسید چه کاربری در چه موقعیتی چه نتیجه‌ای می‌خواهد و امروز چه مانعی دارد. راهنمای مرحله کشف GDS نیز شناخت مسئله، کاربر و محدودیت‌ها را پیش از تعهد به ساخت قرار می‌دهد. در این مقاله، هدف تهیه ورودی قابل بررسی برای کشف است؛ انتخاب میان خرید و ساخت در راهنمای جداگانه بررسی شده است.

منبع فنی این بخش: Government Digital Service [۱]

• هنوز درباره خرید یا ساخت تصمیم نگرفته‌اید؟

یک پرونده واقعی را از ابتدا تا پایان دنبال کنید

برای مثال آموزشی، فرض کنید درخواست تخفیف یک توزیع‌کننده میان فروش، مدیر فروش و مالی جابه‌جا می‌شود. ثبت کنید درخواست از کجا می‌آید، چه کسی تصمیم می‌گیرد و چه وقت به سفارش تبدیل می‌شود. مسیر عادی را کنار برگشت برای اصلاح، نبود تأییدکننده و لغو درخواست ببینید. مصاحبه را با مشاهده فرم‌ها و پرونده‌های بی‌نام تکمیل کنید؛ اختلاف میان روایت مدیر و کار روزانه کاربر، موضوع کشف است.

• برای هر گام، ورودی، مسئول، خروجی و سامانه مورد استفاده را ثبت کنید.
• زمان انجام کار را از زمان انتظار جدا کنید و روش اندازه‌گیری و بازه مشاهده را بنویسید.
• مشخص کنید کدام مشکل با تغییر فرایند حل می‌شود و کدام به قابلیت نرم‌افزاری نیاز دارد.

قالب بریف: پاسخ کوتاه به پرسش‌های تصمیم‌ساز

این جدول یک قالب پیشنهادی برای جلسه اولیه است. لازم نیست پاسخ همه ردیف‌ها قطعی باشد؛ موارد نامعلوم را با مالک پیگیری و شواهد مورد نیاز ثبت کنید. بودجه و تاریخ هدف، محدودیت‌اند و به‌تنهایی دامنه قابل تحویل را تعیین نمی‌کنند. محرمانگی را حفظ کنید: برای شروع، شناسه‌ها و داده‌های حساس را از نمونه‌ها حذف کنید.

معیار پذیرش را به سناریو تبدیل کنید

هر نیاز باید رفتاری داشته باشد که کاربر و تیم تحویل بتوانند آن را مشاهده کنند. برای نمونه آموزشی درخواست تخفیف، فقط ذخیره موفق فرم کافی نیست. وضعیت قبل از اقدام، اقدام و نتیجه را مشخص کنید. برای زمان پاسخ یا ظرفیت، آستانه توافق‌شده، حجم داده و محیط اندازه‌گیری را بنویسید؛ عبارت «سریع باشد» مبنای پذیرش نیست.

• درخواست کامل با شناسه یکتا ثبت شود و ارسال دوباره همان درخواست، پرونده اضافی نسازد.
• کاربر واحد دیگر نتواند درخواست خارج از محدوده دسترسی خود را ببیند یا تأیید کند.
• اگر سامانه مالی پاسخ نداد، وضعیت نامشخص و اقدام بعدی برای کاربر و پشتیبان روشن باشد.
• خطای هر فیلد، استفاده با صفحه‌کلید و نمایش فارسی در موبایل در مسیر اصلی بررسی شود.

ابهام اتصال و مهاجرت را پیش از برآورد پیدا کنید

نام یک سامانه یا وعده «API دارد» برای برآورد کافی نیست. یک نمونه پاسخ، روش احراز هویت، محدودیت فراخوانی، مسئول پشتیبانی و محیط آزمایشی بخواهید. معلوم کنید کدام سامانه مرجع مشتری یا سفارش است و تغییرات در کدام جهت حرکت می‌کنند. برای مهاجرت، نمونه داده و قواعد تطبیق شناسه‌ها را بررسی کنید؛ امکان ورود داده با فایل لزوماً به معنای مهاجرت کامل و قابل بازگشت نیست.

• برای قطع ارتباط، پیام تکراری و داده ناقص، وضعیت و مسئول رسیدگی تعیین کنید.
• فهرست داده‌ای که منتقل نمی‌شود و روش دسترسی به سوابق قدیمی را ثبت کنید.
• تعداد رکورد و چند جمع کنترلی مناسب را برای تطبیق آزمایشی پیش و پس از انتقال انتخاب کنید.

نسخه اول را پیرامون یک جریان کامل ببندید

در مثال تخفیف، ثبت، بررسی، تصمیم، اطلاع‌رسانی و مشاهده وضعیت می‌تواند یک جریان ارزشمند باشد؛ داشبوردهای متعدد پیش از تکمیل همین مسیر ممکن است یادگیری را عقب بیندازند. نیازها را به ضروری برای اجرای جریان، قابل تعویق و فرضیه نیازمند آزمون تقسیم کنید. اگر بزرگ‌ترین ابهام، امکان اتصال به مالی است، بررسی محدود همان اتصال می‌تواند پیش از طراحی همه صفحه‌ها لازم باشد. این بررسی آزمایشی، تعهد به آماده بودن سامانه برای بهره‌برداری نیست.

خروجی کشف باید امکان تصمیم بعدی را بسازد

در پایان، یک بریف نسخه‌دار، نقشه جریان، فهرست ابهام‌ها و معیارهای پذیرش بخواهید. برآورد باید فرض‌ها، استثناهای دامنه، وابستگی به دسترسی‌ها و مسئول تغییر را همراه خود داشته باشد. اگر مسئله هنوز شاهد کافی ندارد، ادامه تحقیق یا توقف هم تصمیم معتبر است. برای درخواست اولیه، یک فرایند مشخص و نمونه بی‌نام آن از فهرست بلند امکانات مفیدتر است.

• آیا کاربر اصلی و مالک پذیرش حضور دارند؟
• آیا نسخه اول بدون قابلیت‌های تعویقی یک کار کامل را تمام می‌کند؟
• آیا مسئول داده، اتصال و بهره‌برداری مشخص است؟
• آیا برای هر ابهام مهم، آزمون یا تصمیم بعدی تعریف شده است؟

• دامنه و اقلام تحویلی توسعه نرم‌افزار اختصاصی