قبل از سفارش نرم‌افزار اختصاصی چه اطلاعاتی آماده کنیم؟
سفارش نرم‌افزار اختصاصی با یک جمله مانند «یک سامانه کامل می‌خواهم» شروع خوبی نیست. تیم اجرا برای برآورد و طراحی اولیه باید بداند چه مسئله‌ای قرار است حل شود، چه کسانی با سیستم کار می‌کنند و خروجی قابل قبول دقیقاً چیست. هرچه این اطلاعات روشن‌تر باشد، گفت‌وگو درباره محدوده، اولویت‌ها و هزینه قابل فهم‌تر می‌شود؛ با این حال هیچ بریف اولیه‌ای جای بررسی فنی و توافق نهایی را نمی‌گیرد.
بریف نیازمندی را از مسئله آغاز کنید
در یک صفحه بنویسید اکنون چه کاری زمان‌بر، پراکنده یا مستعد خطا است. سپس نتیجه مطلوب را با زبان عملی توضیح دهید. برای مثال، اگر شرکت شما سفارش‌های خدماتی دریافت می‌کند، مسئله می‌تواند پراکندگی درخواست‌ها در پیام‌رسان‌ها و فایل‌ها باشد. نتیجه مطلوب شاید ثبت یک درخواست، مشاهده وضعیت آن و دسترسی مسئول مربوط به سوابق باشد. از عبارت‌های مبهم مانند «سریع و حرفه‌ای» به‌تنهایی استفاده نکنید؛ آن‌ها را به رفتار قابل مشاهده تبدیل کنید.
فرایند و نقش‌ها
یک گردش‌کار فرضی و مشخص بنویسید: درخواست ایجاد می‌شود، مسئول بررسی آن را می‌بیند، مدیر تأیید می‌کند، کارشناس وضعیت را تغییر می‌دهد و گزارش پایان کار ثبت می‌شود. این مثال صرفاً فرضی است، اما کمک می‌کند نقاط تصمیم‌گیری آشکار شوند. برای هر مرحله، نقش، ورودی، خروجی و حالت خطا را مشخص کنید. بگویید چه کسی فقط مشاهده می‌کند، چه کسی ویرایش می‌کند و چه کسی اجازه تأیید یا حذف دارد.
| بخش | نمونه اطلاعات قابل ثبت | پرسش تکمیلی |
|---|---|---|
| درخواست | عنوان، شرح، فایل، وضعیت | چه فیلدهایی الزامی هستند؟ |
| نقش‌ها | مدیر، کارشناس، مشاهده‌گر | هر نقش چه کاری می‌تواند انجام دهد؟ |
| تأیید | تأیید یا برگشت برای اصلاح | چه کسی و در چه مرحله‌ای تصمیم می‌گیرد؟ |
| گزارش | فهرست، فیلتر، خروجی | گزارش برای چه تصمیمی استفاده می‌شود؟ |
| پشتیبانی | مسئول پاسخ‌گویی و سطح دسترسی | پس از تحویل چه کسی مالک پیگیری است؟ |
یکپارچه‌سازی و داده
اگر نرم‌افزار باید با سامانه دیگری تبادل اطلاعات کند، نام سامانه، نوع داده، زمان تبادل و مسئول دسترسی را بنویسید. مشخص کنید اطلاعات از کجا وارد می‌شود و در صورت قطع ارتباط چه اتفاقی باید رخ دهد. همچنین نمونه فایل‌ها، فیلدها و داده‌های غیرحساس را آماده کنید. بدون این اطلاعات، ممکن است بخشی از پیچیدگی پروژه دیرتر آشکار شود.
معیار پذیرش قابل ویرایش
معیار پذیرش باید به تست تبدیل شود. جدول زیر نمونه‌ای فرضی و قابل ویرایش است:
| قابلیت | شرط پذیرش | وضعیت بررسی |
|---|---|---|
| ثبت درخواست | کاربر مجاز می‌تواند فیلدهای الزامی را ثبت کند. | □ تأیید □ اصلاح |
| سطح دسترسی | مشاهده‌گر امکان تغییر وضعیت ندارد. | □ تأیید □ اصلاح |
| جست‌وجو | نتیجه بر اساس شناسه یا وضعیت نمایش داده می‌شود. | □ تأیید □ اصلاح |
| گزارش | مدیر می‌تواند خروجی موردنیاز را بررسی کند. | □ تأیید □ اصلاح |
تحویل، پشتیبانی و مالکیت پرسش‌ها
پیش از سفارش بپرسید کد منبع، مستندات، اطلاعات دسترسی و نسخه پشتیبان چگونه تحویل می‌شوند و هر بخش در اختیار چه کسی قرار می‌گیرد. همچنین مشخص کنید پس از تحویل، رفع خطا، آموزش کاربران و توسعه قابلیت جدید بر عهده چه طرفی است. این پرسش‌ها توصیه حقوقی نیستند؛ فقط برای روشن‌کردن مسئولیت‌های اجرایی و کاهش سوءتفاهم مفیدند. جزئیات نهایی باید در توافق قابل بررسی دو طرف درج شود.
چه چیزهایی روی برآورد اثر می‌گذارد؟
تعداد نقش‌ها، پیچیدگی گردش‌کار، حجم داده، تعداد رابط‌های بیرونی، نیاز به گزارش‌های سفارشی، سطح آزمون، مهاجرت اطلاعات و میزان مستندسازی، همگی می‌توانند دامنه کار را تغییر دهند. تعداد کاربران به‌تنهایی معیار کافی نیست؛ گاهی یک فرایند ساده با کاربران زیاد، از سامانه‌ای با کاربران کمتر اما نقش‌ها و اتصال‌های متعدد، ساده‌تر است. به‌جای درخواست قیمت قطعی از روی عنوان پروژه، بریف را ارائه کنید و درباره فرضیات برآورد سؤال بپرسید.
برای آشنایی با زمینه خدمات، صفحه شرکت برنامه نویسی در شیراز را ببینید و برای مشاهده نمونه‌های منتشرشده به نمونه‌کارها سر بزنید. پیش از شروع همکاری، بریف خود را برای بررسی محدوده و اولویت‌ها آماده کنید.
جمع‌بندی
یک بریف خوب باید مسئله، کاربران، نقش‌ها، گردش‌کار، داده‌ها، اتصال‌ها، معیار پذیرش و مسئولیت‌های پس از تحویل را روشن کند. همین اطلاعات به تیم توسعه اجازه می‌دهد پرسش‌های دقیق‌تری بپرسد و به شما کمک می‌کند پیشنهادها را بر اساس محدوده واقعی مقایسه کنید، نه بر پایه چند وعده کلی.